Transport Layer Overview r transport layer services r

Transport Layer Overview: r transport layer services r multiplexing/demultiplexing r connectionless transport: UDP r principles of reliable data transfer r connection-oriented transport: TCP m reliable transfer m flow control m connection management m congestion control r Instantiation and implementation in the Internet 3: Transport Layer 1

Transport services and protocols r provide logical communication network data link physical po s an tr rt relies on, enhances, network layer services d en d- m en r al r network data link physical ic r network data link physical g lo r between app’ processes running on different hosts transport protocols run in end systems transport vs network layer services: network layer: data transfer between end systems transport layer: data transfer between processes application transport network data link physical 3: Transport Layer 2

Transport-layer protocols m network data link physical rt m network data link physical po m real-time bandwidth guarantee reliable multicast If IP layer can’t provide no way to simulate on top s an m network data link physical tr unordered unicast or multicast delivery: UDP r services not available: d en d- r unreliable (“best-effort”), en m al m Connection oriented flow control congestion control network data link physical ic m application transport network data link physical g lo Internet transport services: r reliable, in-order unicast delivery (TCP) application transport network data link physical 3: Transport Layer 3

Example r Nice example in Kurose and Ross of two houses full of cousins r Hosts = houses r Processes = cousins r Application messages = letters in envelopes r Network layer protocol = postal service r Transport layer protocol = Ann and Bill; Susan and Harvey 3: Transport Layer 4

UDP: User Datagram Protocol r “no frills, ” “bare bones” Internet transport protocol r “best effort” service, UDP segments may be: m lost m delivered out of order to app r connectionless: m no handshaking between UDP sender, receiver m each UDP segment handled independently of others [RFC 768] Why is there a UDP? r no connection establishment (which can add delay) r simple: no connection state at sender, receiver r small segment header r no congestion control: UDP can blast away as fast as desired 3: Transport Layer 5

UDP: more r often used for streaming multimedia apps m loss tolerant m rate sensitive Length, in bytes of UDP r other UDP uses (why? ): segment, m DNS: small, retransmit including header if necessary m SNMP r reliable transfer over UDP: add reliability at application layer m application-specific error recover! 32 bits source port # dest port # length checksum Application data (message) UDP segment format 3: Transport Layer 6

Process-to-Process Message Delivery Goal : Deliver application data to correct process (and more particularly to the right socket) Segment - unit of data exchanged between transport layer entities; transport protocol data unit (TPDU) application-layer data segment header segment Ht M Hn segment P 1 M application transport network P 3 receiver M M application transport network P 4 M P 2 application transport network 3: Transport Layer 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 application data (message) TCP/UDP segment format Demultiplexing: Stream of incoming data into one machine separated into smaller streams destined for individual processes Demultiplexing based on IP addresses of sender and port numbers of both sender and receiver m Can distinguish traffic coming to same port but part of separate conversations (like multiple client connections to a web server) 3: Transport Layer 8

Port Implementation r Message queue m Append incoming message to the end m Much like a mailbox file r If queue full, , message can be discarded m why is that ok? Best effort delivery m The network doesn’t guarantee not to drop, so the OS needn’t guarantee that either r When application, reads from socket, operating system removes some bytes from the head of the queue r If queue empty, application blocks waiting 3: Transport Layer 9

Demultiplexing r Packets arrive on Process A network interface, copied 2 ports up into system User level memory r Placed in message Kernel level queue by transport protocol, dest, port number, src port number and src IP address r Copied to user level when app Incoming messages reads socket Process B 1 port Drop? 3: Transport Layer 10

Demultiplexing (cont) r Receiving process may specify combinations of <srcaddr, srcport, destaddr, destport> it will receive or ANY r Demultiplexing by port numbers and IP address: other choices? m Ip address and process id? high overhead of coordination and couldn’t have multiple streams per process m Additional level of addressing by port number provides level of indirection and finer granularity addressing 3: Transport Layer 11

Multiplexing/demultiplexing example Two Web browsers on host A each open 1 socket Source IP: A Dest IP: B source port: x dest. port: 80 <A, x> to<B, 80> Source IP: A Dest IP: B source port: t dest. port: 80 <A, t> to<B, 80> Web server B One Web browser on host C opens 2 sockets Source IP: C Dest IP: B source port: x dest. port: 80 <C, x> to<B, 80> Source IP: C Dest IP: B source port: y dest. port: 80 <C, y> to<B, 80> 3: Transport Layer 12

UDP Headers r Source and destination ports for demultiplexing Length, in r Port field is 16 bits; bytes so of UDP segment, 216 or 64 K possible including ports -not enough for header whole Internet, why ok? Just for the single host! r Length and data pretty self explanatory r Checksum? 32 bits source port # dest port # length checksum Application data (message) UDP segment format 3: Transport Layer 13

UDP header field: checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment Sender: r treat segment contents as sequence of 16 -bit integers (add 0 pad to get even 16 bit chunks if necessary) r checksum: addition (1’s complement sum) of segment contents r sender puts checksum value into UDP checksum field r Checksum optional but should always be used Receiver: r compute checksum of received segment r check if computed checksum equals checksum field value: m NO - error detected m YES - no error detected. But maybe errors nonethless? More later …. m Errors could be anywhere – in data, in headers, even in checksum 3: Transport Layer 14

UDP checksum r Checksum over UDP header and the “pseudo header” – not just the data r 12 byte Pseudo header precedes UDP header m duplicates source and destination IP addresses and the 8 bit protocol ID from IP header m also duplicates 16 bit UDP length from UDP header r Why? Double-check message correctly delivered between endpoints. m Ex. Detect if IP address modified in transit 3: Transport Layer 15

UDP checksum r Actually optional m If sender does not compute set checksum field to 0 m If calculated checksum is 0? Store it as all one bits (65535) which is equivalent in onescomplement arthimetic r If checksum is non-zero and receiver computes a different value, silently drop packet; no error msg generated r Note: We will talk about more about error detection and correction at the link layer…. 3: Transport Layer 16

UDP Header: length r Length of data and header (min value 8 bytes = 0 bytes data) r 16 bit length field => max length of 65535 bytes r Can you really send that much? m May be limited by kernel send buffer (often <= 8192 bytes) m May be limited by kernel’s IP implementation (possibly <= 512 bytes) ; Hosts required to receive 576 bytes of UDP data so senders may limit themselves to that as well 3: Transport Layer 17

Experimenting with UDP r Programs like sock, ttcp or pcattcp allow you to generate streams of TCP or UDP data according to your specifications (total amount of data to send, size of each segment sent, etc. ) r Normally, procedure is as follows m Start tracer like Ethereal m Start server machine (ex. pcattcp –r –u) m Start client machine sending traffic (ex. pcattcp –u <ip address of server) 3: Transport Layer 18

Roadmap r UDP is a very thin layer over IP m multiplexing /demultiplexing m error detection r TCP does these things also and then adds some other significant features r TCP is quite a bit more complicated and subtle r We are not going to jump right into TCP r Start gently thinking about principles of reliable message transfer in general 3: Transport Layer 19

Principles of Reliable data transfer r top-10 list of important networking topics! r important in application, transport, link layers r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) – what is worst underlying channel can do? 3: Transport Layer 20

Brainstorm r Problem: send message (broken into pieces) over unreliable channel such that it arrives on other side in its entirety and in the right order r No out of band communication! All communication sent along with the pieces of the message r Receiver allowed to send information back but only over the same unreliable channel! 3: Transport Layer 21

Faxing a document With Flaky Machine r Can’t talk to person on the other side any other r r way Number the pages – so sender can put back together Keep sending copy after copy until receiver begs up to stop (waste resources) Let receiver send you a fax back saying what pages they have and what they still need (include your fax number on the document!) Put some info on cover sheet that lets person verify fax info (summarize info like checksum) What if it is a really big document? Receiver might like to be able to tell you send first 10 pages then 10 more… 3: Transport Layer 22

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

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

Rdt 1. 0: reliable transfer over a reliable channel r underlying channel perfectly reliable m no bit erros m no loss of packets r separate FSMs for sender, receiver: m sender sends data into underlying channel m receiver read data from underlying channel 3: Transport Layer 25

Rdt 2. 0: channel with bit errors r underlying channel may flip bits in packet (can’t drop or reorder packets) m recall: UDP checksum to detect bit errors r the question: how to recover from errors: m acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK m negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors m sender retransmits pkt on receipt of NAK m human scenarios using ACKs, NAKs? r new mechanisms in rdt 2. 0 (beyond rdt 1. 0): m error detection (summarize fax info? ) m receiver feedback: control msgs (ACK, NAK) rcvr->sender (let receiver fax you back info? ) m Possible retransmission – detection of duplicates (number fax pages? ) 3: Transport Layer 26

Stop and Wait r Now that receiver will be sending feedback not just passively receiving, how should we coordinate sending data and receiving and responding to feedback? r Lots of things we could do…simplest? Stop and wait m Sender sends one pcket, then waits for receiver response r What is wrong with stop and wait? 3: Transport Layer 27

rdt 2. 0: FSM specification sender FSM receiver FSM 3: Transport Layer 28

rdt 2. 0: in action (no errors) sender FSM receiver FSM 3: Transport Layer 29

rdt 2. 0: in action (error scenario) sender FSM receiver FSM 3: Transport Layer 30

rdt 2. 0 has a fatal flaw! What happens if ACK/NAK corrupted? r sender doesn’t know what happened at receiver! r Was it an ACK or a NACK? What to do? r Assume it was an ACK and transmit next? What if it was a NACK? Missing data r Assume it was a NACK and retransmit; What if it was an ACK? Duplicate data Handling duplicates: r To detect duplicate, sender adds sequence number to each pkt r sender retransmits current pkt if ACK/NAK garbled r If receiver has pkt with that number already it will discards (I. e. not deliver up duplicate pkt) 3: Transport Layer 31

rdt 2. 1: sender, handles garbled ACK/NAKs 3: Transport Layer 32

rdt 2. 1: receiver, handles garbled ACK/NAKs 3: Transport Layer 33

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

rdt 2. 2: a NAK-free protocol r Less intuitive but sender FSM getting us closer to TCP r same functionality as rdt 2. 1, using NAKs only r instead of NAK, receiver sends ACK for last pkt received OK m receiver must explicitly include seq # of pkt being ACKed ! r duplicate ACK at sender results in same action as NAK: retransmit current pkt 3: Transport Layer 35

rdt 3. 0: channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) m m How to deal with loss? Retransmission plus seq # to detect duplicates but not enough Q: how to detect loss? Approach: sender waits “reasonable” amount of time for ACK r retransmits if no ACK received in this time r if pkt (or ACK) just delayed (not lost): m retransmission will be duplicate, but use of seq. #’s already handles this m receiver must specify seq # of pkt being ACKed r requires countdown timer 3: Transport Layer 36

rdt 3. 0 sender 3: Transport Layer 37

rdt 3. 0 in action 3: Transport Layer 38

rdt 3. 0 in action 3: Transport Layer 39

Analysis of rdt 3. 0 r We’ve put in bit errors and loss and rdt 3. 0 works fine (reordering? ) r But performance stinks (remember what is wrong with stop and wait? ) r example: 1 Gbps link, 15 ms end-to-end 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 m m 1 KB pkt every 30 msec -> 33 k. B/sec thruput over 1 Gbps link network protocol limits use of physical resources! 3: Transport Layer 40

Obvious Fix to Stop and Wait really means send one, stop and wait r Instead send lots, stop and wait r Call this a pipelined protocol because many packets in the pipeline at the same time 3: Transport Layer 41

Pipelined protocols Pipelining: sender allows multiple, “in-flight” yet-tobe-acknowledges packets m m range of sequence numbers must be increased to be able to distinguish them all buffering at sender and/or receiver r Two generic forms of pipelined protocols: go-Back-N, selective repeat 3: Transport Layer 42

Go-Back-N r Sender keeps track of beginning of a window of up to N packets r Each time get an ACK for the beginning of the window can advance the window r If get a timeout for the first packet in the window, retransmit all packets in the window r Some of those retransmitted packets may have been correctly received 3: Transport Layer 43

Go-Back-N Sender: r k-bit seq # in pkt header r “window” of up to N, consecutive unack’ed pkts allowed (want N large enough to fill the pipeline, based on link characterisitcs) r ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may deceive duplicate ACKs (see receiver) r timer for each in-flight pkt r timeout(n): retransmit pkt n and all higher seq # pkts in window m 3: Transport Layer 44

GBN: sender extended FSM 3: Transport Layer 45

GBN: receiver extended FSM receiver simple: r ACK-only: always send ACK for correctly-received pkt with highest in-order seq # m m may generate duplicate ACKs need only remember expectedseqnum r out-of-order pkt: m discard (don’t buffer) -> no receiver buffering! m ACK pkt with highest in-order seq # 3: Transport Layer 46

GBN in action Loss of one packets (pkt 2) causes retransmissi on of 4 packets (2 -5) 3: Transport Layer 47

Selective Repeat r GBN forces sender to retransmit all packets in window even if some have been correctly received r To fix that we need a finer granularity of acknowledgement: individual acknowledgements vs cummulative acknowledgements 3: Transport Layer 48

Selective Repeat r receiver individually acknowledges all correctly received pkts m Must buffer any packet acknowledged for eventual inorder delivery to upper layer (even if cannot deliver right now) r sender only resends pkts for which ACK not received m sender timer for each un. ACKed pkt r sender window m N consecutive seq #’s m again limits seq #s of sent, un. ACKed pkts 3: Transport Layer 49

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

Selective repeat: sender, receiver windows 3: Transport Layer 51

Selective repeat in action Loss of one pkt causes retransmission of just that pkt 3: Transport Layer 52

Selective repeat: dilemma Example: r seq #’s: 0, 1, 2, 3 r window size=3 r receiver sees no difference in two scenarios! r incorrectly passes duplicate data as new in (a) Q: what relationship between seq # size and window size? A: window size <= ½ sequence number space 3: Transport Layer 53

Selective Repeat vs GBN r Selective Repeat requires more buffering and complexity on receiver r GBN results in unnecessary retransmission of data correctly received r Based on requirements in Internet, which do you think is closest to TCP? • Actually a little of both, TCP is a sliding window protocol like GBN but many TCP implementations will buffer correctly received but of order segments and senders use duplicate acknowledgments to infer which segment dropped 3: Transport Layer 54

Roadmap r Discussed general principles of reliable message delivery over unreliable channel m m Lots of it is common sense (like with our flaky fax machine) But there is a significant degree of subtlety in getting it right! r We are going to move on to talking specifically about TCP m Flow control? Congestion control? r We have most of the tools we need now: sequence numbers, cummulative acknowledgments, retransmisson timers…. 3: Transport Layer 55