The Transport Layer application transport network data link

The Transport Layer application transport network data link physical t or Transport Layer network data link physical sp an tr 9/18/2021 d en – connection-oriented – connectionless nd • The transport layer relies on, and enhances network layer services • Two types of transport service is available network data link physical e al – network layer: data transfer between end systems – transport layer: data transfer between processes network data link physical c gi lo • Provides logical communication between processes running on different hosts application transport network data link physical 1

Why is there a transport layer? • Historically the network layer was part of the communications subnet and is run by the carrier. • Not all networks provide reliable delivery services • Some people make the following distinction: – transport service provider (layers 1 -4) – transport service user (above 4) • The transport layer forms a boundary between the provider and user of the reliable transmission service 9/18/2021 Transport Layer 2

Addressing • Transport addresses typically need to include more than a machine address • Many names, but the idea is essentially the same – (IP address, local port) – (AAL, SAP) – (NSAP, TSAP) • One component of the pair identifies the destination, the second component identifies an end point on that destination 9/18/2021 Transport Layer 3

Determining the End-Point • How does one determine what end-point a service is installed on? • One technique is to agree on a set of “wellknown” end-points 9/18/2021 Transport Layer 4

Initial Connection Protocol • Each machine wishing to offer services has a special process server • The process server scans a series of ports looking for connections • When a connection request is received, the process server starts the appropriate process to service the request • In UNIX this is handled by inetd 9/18/2021 Transport Layer 5

Name Server • A special process, called a name server or sometimes a directory server, to solve the addressing problem • Here clients ask the name server what end-point address the desired service is running on • This requires services to register themselves with the name server 9/18/2021 Transport Layer 6

Multiplexing/demultiplexing segment - unit of data exchanged between transport layer entities – aka TPDU: transport protocol data unit application-layer data segment header segment Ht M Hn segment 9/18/2021 P 1 M application transport network P 3 Demultiplexing: delivering received segments to correct app layer processes receiver M M application transport network Transport Layer P 4 M P 2 application transport network 7

Multiplexing/demultiplexing Multiplexing: gathering data from multiple app processes, enveloping data with header (later used for demultiplexing) 32 bits source port # dest port # other header fields multiplexing/demultiplexing: • based on sender, receiver port numbers, IP addresses – source, dest port #s in each segment – well-known port numbers for specific applications 9/18/2021 Transport Layer application data (message) TCP/UDP segment format 8

Multiplexing/demultiplexing: examples source port: x dest. port: 23 host A server B source port: 23 dest. port: x Source IP: C Dest IP: B source port: y dest. port: 80 port use: simple telnet app Web client host A 9/18/2021 Web client host C Source IP: A Dest IP: B source port: x dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 Web server B port use: Web server Transport Layer 9

Quality of Service • Another function of the transport layer is to enhance the Quality of Service provided by the network layer • The transport service may allow users to specify preferred, acceptable and minimum values for service parameters • The transport layer figures out how to provide the services based on the network layer it is using 9/18/2021 Transport Layer 10

Qo. S Parameters 9/18/2021 Transport Layer 11

Transport Service Primitives • Primitives allow access to the transport service • Each transport service has its own set of primitives 9/18/2021 Transport Layer 12

Transport Protocols • Transport protocols often need to make an unreliable channel appear to be error free • Transport protocols typically deal with – error control, sequencing, and flow control • Issues that affect transport protocols include – – 9/18/2021 routing connection establishment storage capacity on the net sophisticated buffering/flow control techniques Transport Layer 13

Principles of Reliable data transfer • characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) 9/18/2021 Transport Layer 14

Reliable data transfer: getting started rdt_send(): called from above, (e. g. , by app. ). Passed data to deliver to receiver upper layer deliver_data(): called by rdt to deliver data to upper send side receive side udt_send(): called by rdt, to transfer packet over unreliable channel to receiver 9/18/2021 rdt_rcv(): called when packet arrives on rcv-side of channel Transport Layer 15

Reliable data transfer: getting started We’ll: • incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) • consider only unidirectional data transfer – but control info will flow on both directions! • use finite state machines (FSM) to specify sender, receiver event causing state transition actions taken on state transition state: when in this “state” next state uniquely determined by next event 9/18/2021 state 1 event actions Transport Layer state 2 16

Rdt 1. 0: reliable transfer over a reliable channel • underlying channel perfectly reliable – no bit errors – no loss of packets • separate FSMs for sender, receiver: – sender sends data into underlying channel – receiver read data from underlying channel 9/18/2021 Transport Layer 17

PAR Protocols • Most reliable protocols use a single fundamental technique called positive acknowledgement with retransmission. • The technique requires a recipient to communicate with the source, sending back an acknowledgement message as it receives data. • The sender keeps a record of each packet it sends and waits for an acknowledgement before sending the next packet. 9/18/2021 Transport Layer 18

PAR Protocols 9/18/2021 Transport Layer 19

PAR Protocols • Problem arise when a packet delivery system duplicates packets (or losses an ACK) • Reliable protocols detect duplicate packets by assigning each packet a sequence number and requiring the receiver to remember which sequence numbers it has received. • To avoid confusion caused by lost, delayed, or duplicated acknowledgements, PAR protocols send sequence numbers back in ACKs. 9/18/2021 Transport Layer 20

Rdt 2. 0: channel with bit errors • underlying channel may flip bits in packet • the question: how to recover from errors: – acknowledgements (ACKs): receiver explicitly tells sender that packet was received – negative acknowledgements (NAKs): receiver explicitly tells sender that packet had errors – sender retransmits packet on receipt of NAK • new mechanisms in rdt 2. 0 (beyond rdt 1. 0): – error detection – receiver feedback: control msgs (ACK, NAK) rcvr->sender 9/18/2021 Transport Layer 21

rdt 2. 0: FSM specification sender FSM 9/18/2021 receiver FSM Transport Layer 22

rdt 2. 0: in action (no errors) sender FSM 9/18/2021 receiver FSM Transport Layer 23

rdt 2. 0: in action (error scenario) sender FSM 9/18/2021 receiver FSM Transport Layer 24

rdt 2. 0 has a fatal flaw! What happens if ACK/NAK corrupted or Lost? • sender doesn’t know what happened at receiver! • can’t just retransmit: possible duplicate What to do? • sender ACKs/NAKs receiver’s ACK/NAK? What if sender ACK/NAK lost? • retransmit, but this might cause retransmission of correctly received packet! 9/18/2021 Handling duplicates: • sender adds sequence number to each packet • sender retransmits current packet if ACK/NAK garbled • receiver discards (doesn’t deliver up) duplicate packet stop and wait Sender sends one packet, then waits for receiver response Transport Layer 25

rdt 2. 1: sender, handles garbled ACK/NAKs 9/18/2021 Transport Layer 26

rdt 2. 1: receiver, handles garbled ACK/NAKs 9/18/2021 Transport Layer 27

rdt 2. 1: discussion Sender: • seq # added to pkt • two seq. #’s (0, 1) will suffice. Why? • must check if received ACK/NAK corrupted • twice as many states Receiver: • must check if received packet is duplicate – state indicates whether 0 or 1 is expected packet seq # – state must “remember” whether “current” packet has 0 or 1 seq. # 9/18/2021 • note: receiver can not know if its last ACK/NAK received OK at sender Transport Layer 28

rdt 2. 2: a NAK-free protocol sender FSM • same functionality as rdt 2. 1, using NAKs only • instead of NAK, receiver sends ACK for last pkt received OK – receiver must explicitly include seq # of pkt being ACKed • duplicate ACK at sender results in same action as NAK: retransmit current pkt 9/18/2021 ! Transport Layer 29

rdt 3. 0: channels with errors and loss Approach: sender waits “reasonable” amount of time New assumption: underlying for ACK channel can also lose • retransmits if no ACK received in packets (data or ACKs) – checksum, seq. #, ACKs, retransmissions will be of help, but not enough Q: how to deal with loss? – sender waits until certain data or ACK lost, then retransmits – yuck: drawbacks? 9/18/2021 this time • if packet (or ACK) just delayed (not lost): – retransmission will be duplicate, but use of seq. #’s already handles this – receiver must specify seq # of pkt being ACKed • requires countdown timer Transport Layer 30

rdt 3. 0 sender 9/18/2021 Transport Layer 31

rdt 3. 0 in action 9/18/2021 Transport Layer 32

rdt 3. 0 in action 9/18/2021 Transport Layer 33

Performance of rdt 3. 0 • rdt 3. 0 works, but performance stinks • example: 1 Gbps link, 15 ms e-e prop. delay, 1 KB packet: Ttransmit = 8 kb/pkt = 8 microsec 10**9 b/sec 8 microsec fraction of time = = 0. 00015 Utilization = U = sender busy sending 30. 016 msec – 1 KB pkt every 30 msec -> 33 k. B/sec throughput over 1 Gbps link – network protocol limits use of physical resources! 9/18/2021 Transport Layer 34

Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-to-beacknowledged packets – range of sequence numbers must be increased – buffering at sender and/or receiver • Two generic forms of pipelined protocols: go-Back-N, selective repeat 9/18/2021 Transport Layer 35

Transmission Window • Once the sender receives an acknowledgement for the first packet inside the window, it "slides" the window along to the next unacknowledged packet. • The window partitions the sequence of packets into three sets: successfully transmitted, waiting acknowledgements, and waiting to be transmitted. 9/18/2021 Transport Layer 36

Sender: Go-Back-N • k-bit sequence # in packet header • “window” of up to N, consecutive unack’ed packets allowed • ACK(n): ACKs all packet up to, including seq # n - “cumulative ACK” – may deceive duplicate ACKs (see receiver) • timer for each in-flight packet • timeout(n): retransmit packet n and all higher seq # packets in window 9/18/2021 Transport Layer 37

GBN: sender extended FSM 9/18/2021 Transport Layer 38

GBN: receiver extended FSM receiver simple: • ACK-only: always send ACK for correctly-received packet with highest in-order sequence # – may generate duplicate ACKs – need only remember expectedseqnum • out-of-order packet: – discard (don’t buffer) -> no receiver buffering! – ACK packet with highest in-order sequence # 9/18/2021 Transport Layer 39

GBN in action 9/18/2021 Transport Layer 40

Selective Repeat • Receiver individually acknowledges all correctly received packets – buffers packets, as needed, for eventual in-order delivery to upper layer • sender only resends packets for which ACK not received – sender timer for each un. ACKed packet • sender window – N consecutive sequence #’s – again limits sequence #s of sent, un. ACKed packets 9/18/2021 Transport Layer 41

Selective repeat: sender, receiver windows 9/18/2021 Transport Layer 42

Selective repeat sender receiver pkt n in [rcvbase, rcvbase+N-1] data from above : • send ACK(n) • out-of-order: buffer • in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet -received pkt • if next available sequence # in window, send packet timeout(n): • resend pkt n, restart timer ACK(n) in [sendbase, sendbase+N]: • mark pkt n as received • if n smallest un. ACKed pkt, advance window base to next un. ACKed seq # 9/18/2021 pkt n in [rcvbase-N, rcvbase-1] • ACK(n) otherwise: • ignore Transport Layer 43

Selective repeat in action 9/18/2021 Transport Layer 44

Selective repeat: Dilemma Example: • sequence #’s: 0, 1, 2, 3 • window size=3 • receiver sees no difference in two scenarios! • incorrectly passes duplicate data as new in (a) Q: what relationship between sequence # size and window size? 9/18/2021 Transport Layer 45

Problems With Connections • The crux of most of the problems are delayed duplicates – throwaway transport addresses • each connection has a unique address • server model cannot work – connection identifiers • a unique number that identifies each connection • what happens when a host crashes? • Try killing old packets (aging) 9/18/2021 Transport Layer 46

Restricting Packet Lifetime • Packet lifetime can be restricted to a known maximum using one of the following – restricted subnet design – hop counters – timestamps • Not only do we need to kill packets, but any acknowledgement of the packets as well – T is some multiple of the true packet lifetime. After waiting T units all traces of the packet are gone 9/18/2021 Transport Layer 47

Generating Sequence Numbers • With packet lifetimes limited, it is possible to devise a way to generate sequence numbers safely • Basic idea is to generate sequence numbers such that two identically numbered packets are never outstanding at the same time (for one connection) • Equip each machine with a clock that never stops – takes on the form of a binary counter – incremented at regular intervals – number of bits equals/exceeds size of sequence number 9/18/2021 Transport Layer 48

Generating Sequence Numbers • At connection set up, the low order k bits of the clock are used as the initial sequence number. • Each connection starts with a different sequence number • Once the initial sequence number is picked, things work as before • The sequence space is so large that by the time sequence numbers wrap, the old packets are long gone 9/18/2021 Transport Layer 49

Host Crashes • When a host crashes, and then restarts, it does not know where it was in the sequence space • One solution is to require transport entities to be idle for T seconds after recovery to let all old packets dies off • If T is large, as it would be in a complex internetwork, this strategy is unattractive. 9/18/2021 Transport Layer 50

Example • Let T = 60 sec and the clock ticks once per second – At time = 30 secs, a packet is sent with sequence number 80 (this is an existing connection, packet lives until time = 90 secs) – The machine crashes and restarts – At time = 70 secs, it reopens the connection, and uses initial sequence number 70 – Within the next 15 secs it sends packets 70 -80 – At time=85 secs two packets with sequence 80 exist 9/18/2021 Transport Layer 51

Forbidden Regions • We must prevent sequence numbers from being used for a time T before their potential use as initial sequence numbers • The forbidden region indicates the illegal combinations of time and sequence number • Before sending any packet, on any connection, the clock must be checked to be sure the packet is not in a forbidden region 9/18/2021 Transport Layer 52

Problems • The protocol can get into trouble if the host sends data too quickly on a newly opened connection – This happens if the transmission rate is faster than the clock • This means the maximum data rate on any connection is one packet per clock tick • It also means the hosts must wait until the clock ticks before opening a connection after restart • A short clock tick is desired 9/18/2021 Transport Layer 53

Problems • The protocol can also run into problems if the transmission rate is too slow • At any data rate less than the clock rate, the sequence numbers will eventually run into the forbidden region from the left • This is fixed by re-synchronizing the sequence numbers 9/18/2021 Transport Layer 54

Establishing A Connection • Sounds straight forward – one side sends CONNECTION REQUEST – other side sends CONNECTION ACCEPTED – when originator gets the ACK the connection is established • Imagine creating a connection where all the packets are duplicated and you are transferring money!! 9/18/2021 Transport Layer 55

Three Way Handshake • The clock based approach solves the delayed duplicate problem, only if a connection has been established CR (seq=x) ACK (seq=y, ACK=x) DATA (seq=x, ACK=y) 9/18/2021 Transport Layer 56

Problems CR (seq=x) ACK (seq=y, ACK=x) DATA (seq=y, ACK=z) REJECT (ACK=y) 9/18/2021 Transport Layer 57

Releasing a Connection • Releasing connections is easier than establishing one • There are two styles of release: – asymmetric – symmetric • Asymmetric release is abrupt and may result in data loss. A more sophisticated protocol is required to avoid data loss 9/18/2021 Transport Layer 58

Two-Army Problem • Two armies, separated by a valley. One army is split in half on either side of the valley • The split army is larger than the one in the valley, but each half is smaller that the army in the valley • How do the split army commander coordinate an attack so that they can defeat the army in the valley? 9/18/2021 Transport Layer 59

Two Army Problem • Commander #1 sends message - attack at dawn – no reply does nothing – reply received but how does other commander the reply was received • Three way handshake does not help – attack at dawn – okay – Okay (how do I know the other side got the ACK? ) • Nothing can fix the problem 9/18/2021 Transport Layer 60