Transport Layer Overview r transport layer services r
![Transport Layer Overview: r transport layer services r multiplexing/demultiplexing r connectionless transport: UDP r Transport Layer Overview: r transport layer services r multiplexing/demultiplexing r connectionless transport: UDP r](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-1.jpg)
![Transport services and protocols r provide logical communication network data link physical po s Transport services and protocols r provide logical communication network data link physical po s](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-2.jpg)
![Transport-layer protocols m network data link physical rt m network data link physical po Transport-layer protocols m network data link physical rt m network data link physical po](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-3.jpg)
![Example r Nice example in Kurose and Ross of two houses full of cousins Example r Nice example in Kurose and Ross of two houses full of cousins](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-4.jpg)
![UDP: User Datagram Protocol r “no frills, ” “bare bones” Internet transport protocol r UDP: User Datagram Protocol r “no frills, ” “bare bones” Internet transport protocol r](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-5.jpg)
![UDP: more r often used for streaming multimedia apps m loss tolerant m rate UDP: more r often used for streaming multimedia apps m loss tolerant m rate](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-6.jpg)
![Process-to-Process Message Delivery Goal : Deliver application data to correct process (and more particularly Process-to-Process Message Delivery Goal : Deliver application data to correct process (and more particularly](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-7.jpg)
![Multiplexing/demultiplexing Multiplexing: gathering data from multiple app processes, enveloping data with header (later used Multiplexing/demultiplexing Multiplexing: gathering data from multiple app processes, enveloping data with header (later used](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-8.jpg)
![Port Implementation r Message queue m Append incoming message to the end m Much Port Implementation r Message queue m Append incoming message to the end m Much](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-9.jpg)
![Demultiplexing r Packets arrive on Process A network interface, copied 2 ports up into Demultiplexing r Packets arrive on Process A network interface, copied 2 ports up into](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-10.jpg)
![Demultiplexing (cont) r Receiving process may specify combinations of <srcaddr, srcport, destaddr, destport> it Demultiplexing (cont) r Receiving process may specify combinations of <srcaddr, srcport, destaddr, destport> it](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-11.jpg)
![Multiplexing/demultiplexing example Two Web browsers on host A each open 1 socket Source IP: Multiplexing/demultiplexing example Two Web browsers on host A each open 1 socket Source IP:](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-12.jpg)
![UDP Headers r Source and destination ports for demultiplexing Length, in r Port field UDP Headers r Source and destination ports for demultiplexing Length, in r Port field](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-13.jpg)
![UDP header field: checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted UDP header field: checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-14.jpg)
![UDP checksum r Checksum over UDP header and the “pseudo header” – not just UDP checksum r Checksum over UDP header and the “pseudo header” – not just](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-15.jpg)
![UDP checksum r Actually optional m If sender does not compute set checksum field UDP checksum r Actually optional m If sender does not compute set checksum field](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-16.jpg)
![UDP Header: length r Length of data and header (min value 8 bytes = UDP Header: length r Length of data and header (min value 8 bytes =](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-17.jpg)
![Experimenting with UDP r Programs like sock, ttcp or pcattcp allow you to generate Experimenting with UDP r Programs like sock, ttcp or pcattcp allow you to generate](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-18.jpg)
![Roadmap r UDP is a very thin layer over IP m multiplexing /demultiplexing m Roadmap r UDP is a very thin layer over IP m multiplexing /demultiplexing m](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-19.jpg)
![Principles of Reliable data transfer r top-10 list of important networking topics! r important Principles of Reliable data transfer r top-10 list of important networking topics! r important](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-20.jpg)
![Brainstorm r Problem: send message (broken into pieces) over unreliable channel such that it Brainstorm r Problem: send message (broken into pieces) over unreliable channel such that it](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-21.jpg)
![Faxing a document With Flaky Machine r Can’t talk to person on the other Faxing a document With Flaky Machine r Can’t talk to person on the other](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-22.jpg)
![Reliable data transfer: getting started rdt_send(): called from above, (e. g. , by app. Reliable data transfer: getting started rdt_send(): called from above, (e. g. , by app.](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-23.jpg)
![Reliable data transfer: getting started We’ll: r incrementally develop sender, receiver sides of reliable Reliable data transfer: getting started We’ll: r incrementally develop sender, receiver sides of reliable](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-24.jpg)
![Rdt 1. 0: reliable transfer over a reliable channel r underlying channel perfectly reliable Rdt 1. 0: reliable transfer over a reliable channel r underlying channel perfectly reliable](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-25.jpg)
![Rdt 2. 0: channel with bit errors r underlying channel may flip bits in Rdt 2. 0: channel with bit errors r underlying channel may flip bits in](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-26.jpg)
![Stop and Wait r Now that receiver will be sending feedback not just passively Stop and Wait r Now that receiver will be sending feedback not just passively](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-27.jpg)
![rdt 2. 0: FSM specification sender FSM receiver FSM 3: Transport Layer 28 rdt 2. 0: FSM specification sender FSM receiver FSM 3: Transport Layer 28](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-28.jpg)
![rdt 2. 0: in action (no errors) sender FSM receiver FSM 3: Transport Layer rdt 2. 0: in action (no errors) sender FSM receiver FSM 3: Transport Layer](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-29.jpg)
![rdt 2. 0: in action (error scenario) sender FSM receiver FSM 3: Transport Layer rdt 2. 0: in action (error scenario) sender FSM receiver FSM 3: Transport Layer](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-30.jpg)
![rdt 2. 0 has a fatal flaw! What happens if ACK/NAK corrupted? r sender rdt 2. 0 has a fatal flaw! What happens if ACK/NAK corrupted? r sender](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-31.jpg)
![rdt 2. 1: sender, handles garbled ACK/NAKs 3: Transport Layer 32 rdt 2. 1: sender, handles garbled ACK/NAKs 3: Transport Layer 32](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-32.jpg)
![rdt 2. 1: receiver, handles garbled ACK/NAKs 3: Transport Layer 33 rdt 2. 1: receiver, handles garbled ACK/NAKs 3: Transport Layer 33](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-33.jpg)
![rdt 2. 1: discussion Sender: r seq # added to pkt r two seq. rdt 2. 1: discussion Sender: r seq # added to pkt r two seq.](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-34.jpg)
![rdt 2. 2: a NAK-free protocol r Less intuitive but sender FSM getting us rdt 2. 2: a NAK-free protocol r Less intuitive but sender FSM getting us](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-35.jpg)
![rdt 3. 0: channels with errors and loss New assumption: underlying channel can also rdt 3. 0: channels with errors and loss New assumption: underlying channel can also](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-36.jpg)
![rdt 3. 0 sender 3: Transport Layer 37 rdt 3. 0 sender 3: Transport Layer 37](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-37.jpg)
![rdt 3. 0 in action 3: Transport Layer 38 rdt 3. 0 in action 3: Transport Layer 38](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-38.jpg)
![rdt 3. 0 in action 3: Transport Layer 39 rdt 3. 0 in action 3: Transport Layer 39](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-39.jpg)
![Analysis of rdt 3. 0 r We’ve put in bit errors and loss and Analysis of rdt 3. 0 r We’ve put in bit errors and loss and](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-40.jpg)
![Obvious Fix to Stop and Wait really means send one, stop and wait r Obvious Fix to Stop and Wait really means send one, stop and wait r](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-41.jpg)
![Pipelined protocols Pipelining: sender allows multiple, “in-flight” yet-tobe-acknowledges packets m m range of sequence Pipelined protocols Pipelining: sender allows multiple, “in-flight” yet-tobe-acknowledges packets m m range of sequence](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-42.jpg)
![Go-Back-N r Sender keeps track of beginning of a window of up to N Go-Back-N r Sender keeps track of beginning of a window of up to N](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-43.jpg)
![Go-Back-N Sender: r k-bit seq # in pkt header r “window” of up to Go-Back-N Sender: r k-bit seq # in pkt header r “window” of up to](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-44.jpg)
![GBN: sender extended FSM 3: Transport Layer 45 GBN: sender extended FSM 3: Transport Layer 45](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-45.jpg)
![GBN: receiver extended FSM receiver simple: r ACK-only: always send ACK for correctly-received pkt GBN: receiver extended FSM receiver simple: r ACK-only: always send ACK for correctly-received pkt](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-46.jpg)
![GBN in action Loss of one packets (pkt 2) causes retransmissi on of 4 GBN in action Loss of one packets (pkt 2) causes retransmissi on of 4](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-47.jpg)
![Selective Repeat r GBN forces sender to retransmit all packets in window even if Selective Repeat r GBN forces sender to retransmit all packets in window even if](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-48.jpg)
![Selective Repeat r receiver individually acknowledges all correctly received pkts m Must buffer any Selective Repeat r receiver individually acknowledges all correctly received pkts m Must buffer any](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-49.jpg)
![Selective repeat sender data from above : receiver pkt n in [rcvbase, rcvbase+N-1] r Selective repeat sender data from above : receiver pkt n in [rcvbase, rcvbase+N-1] r](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-50.jpg)
![Selective repeat: sender, receiver windows 3: Transport Layer 51 Selective repeat: sender, receiver windows 3: Transport Layer 51](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-51.jpg)
![Selective repeat in action Loss of one pkt causes retransmission of just that pkt Selective repeat in action Loss of one pkt causes retransmission of just that pkt](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-52.jpg)
![Selective repeat: dilemma Example: r seq #’s: 0, 1, 2, 3 r window size=3 Selective repeat: dilemma Example: r seq #’s: 0, 1, 2, 3 r window size=3](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-53.jpg)
![Selective Repeat vs GBN r Selective Repeat requires more buffering and complexity on receiver Selective Repeat vs GBN r Selective Repeat requires more buffering and complexity on receiver](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-54.jpg)
![Roadmap r Discussed general principles of reliable message delivery over unreliable channel m m Roadmap r Discussed general principles of reliable message delivery over unreliable channel m m](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-55.jpg)
- Slides: 55
![Transport Layer Overview r transport layer services r multiplexingdemultiplexing r connectionless transport UDP r Transport Layer Overview: r transport layer services r multiplexing/demultiplexing r connectionless transport: UDP r](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-1.jpg)
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 Transport services and protocols r provide logical communication network data link physical po s](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-2.jpg)
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
![Transportlayer protocols m network data link physical rt m network data link physical po Transport-layer protocols m network data link physical rt m network data link physical po](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-3.jpg)
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 Example r Nice example in Kurose and Ross of two houses full of cousins](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-4.jpg)
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 UDP: User Datagram Protocol r “no frills, ” “bare bones” Internet transport protocol r](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-5.jpg)
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 UDP: more r often used for streaming multimedia apps m loss tolerant m rate](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-6.jpg)
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
![ProcesstoProcess Message Delivery Goal Deliver application data to correct process and more particularly Process-to-Process Message Delivery Goal : Deliver application data to correct process (and more particularly](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-7.jpg)
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
![Multiplexingdemultiplexing Multiplexing gathering data from multiple app processes enveloping data with header later used Multiplexing/demultiplexing Multiplexing: gathering data from multiple app processes, enveloping data with header (later used](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-8.jpg)
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 Port Implementation r Message queue m Append incoming message to the end m Much](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-9.jpg)
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 Demultiplexing r Packets arrive on Process A network interface, copied 2 ports up into](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-10.jpg)
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 Demultiplexing (cont) r Receiving process may specify combinations of <srcaddr, srcport, destaddr, destport> it](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-11.jpg)
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
![Multiplexingdemultiplexing example Two Web browsers on host A each open 1 socket Source IP Multiplexing/demultiplexing example Two Web browsers on host A each open 1 socket Source IP:](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-12.jpg)
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 UDP Headers r Source and destination ports for demultiplexing Length, in r Port field](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-13.jpg)
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 UDP header field: checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-14.jpg)
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 UDP checksum r Checksum over UDP header and the “pseudo header” – not just](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-15.jpg)
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 UDP checksum r Actually optional m If sender does not compute set checksum field](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-16.jpg)
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 UDP Header: length r Length of data and header (min value 8 bytes =](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-17.jpg)
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 Experimenting with UDP r Programs like sock, ttcp or pcattcp allow you to generate](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-18.jpg)
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 Roadmap r UDP is a very thin layer over IP m multiplexing /demultiplexing m](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-19.jpg)
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 top10 list of important networking topics r important Principles of Reliable data transfer r top-10 list of important networking topics! r important](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-20.jpg)
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 Brainstorm r Problem: send message (broken into pieces) over unreliable channel such that it](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-21.jpg)
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 Cant talk to person on the other Faxing a document With Flaky Machine r Can’t talk to person on the other](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-22.jpg)
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 rdtsend called from above e g by app Reliable data transfer: getting started rdt_send(): called from above, (e. g. , by app.](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-23.jpg)
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 Well r incrementally develop sender receiver sides of reliable Reliable data transfer: getting started We’ll: r incrementally develop sender, receiver sides of reliable](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-24.jpg)
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 Rdt 1. 0: reliable transfer over a reliable channel r underlying channel perfectly reliable](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-25.jpg)
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 Rdt 2. 0: channel with bit errors r underlying channel may flip bits in](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-26.jpg)
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 Stop and Wait r Now that receiver will be sending feedback not just passively](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-27.jpg)
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: FSM specification sender FSM receiver FSM 3: Transport Layer 28](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-28.jpg)
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 rdt 2. 0: in action (no errors) sender FSM receiver FSM 3: Transport Layer](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-29.jpg)
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 rdt 2. 0: in action (error scenario) sender FSM receiver FSM 3: Transport Layer](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-30.jpg)
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 ACKNAK corrupted r sender rdt 2. 0 has a fatal flaw! What happens if ACK/NAK corrupted? r sender](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-31.jpg)
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 ACKNAKs 3 Transport Layer 32 rdt 2. 1: sender, handles garbled ACK/NAKs 3: Transport Layer 32](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-32.jpg)
rdt 2. 1: sender, handles garbled ACK/NAKs 3: Transport Layer 32
![rdt 2 1 receiver handles garbled ACKNAKs 3 Transport Layer 33 rdt 2. 1: receiver, handles garbled ACK/NAKs 3: Transport Layer 33](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-33.jpg)
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 rdt 2. 1: discussion Sender: r seq # added to pkt r two seq.](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-34.jpg)
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 NAKfree protocol r Less intuitive but sender FSM getting us rdt 2. 2: a NAK-free protocol r Less intuitive but sender FSM getting us](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-35.jpg)
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 rdt 3. 0: channels with errors and loss New assumption: underlying channel can also](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-36.jpg)
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 sender 3: Transport Layer 37](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-37.jpg)
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 38](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-38.jpg)
rdt 3. 0 in action 3: Transport Layer 38
![rdt 3 0 in action 3 Transport Layer 39 rdt 3. 0 in action 3: Transport Layer 39](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-39.jpg)
rdt 3. 0 in action 3: Transport Layer 39
![Analysis of rdt 3 0 r Weve put in bit errors and loss and Analysis of rdt 3. 0 r We’ve put in bit errors and loss and](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-40.jpg)
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 Obvious Fix to Stop and Wait really means send one, stop and wait r](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-41.jpg)
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 inflight yettobeacknowledges packets m m range of sequence Pipelined protocols Pipelining: sender allows multiple, “in-flight” yet-tobe-acknowledges packets m m range of sequence](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-42.jpg)
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
![GoBackN r Sender keeps track of beginning of a window of up to N Go-Back-N r Sender keeps track of beginning of a window of up to N](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-43.jpg)
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
![GoBackN Sender r kbit seq in pkt header r window of up to Go-Back-N Sender: r k-bit seq # in pkt header r “window” of up to](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-44.jpg)
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: sender extended FSM 3: Transport Layer 45](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-45.jpg)
GBN: sender extended FSM 3: Transport Layer 45
![GBN receiver extended FSM receiver simple r ACKonly always send ACK for correctlyreceived pkt GBN: receiver extended FSM receiver simple: r ACK-only: always send ACK for correctly-received pkt](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-46.jpg)
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 GBN in action Loss of one packets (pkt 2) causes retransmissi on of 4](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-47.jpg)
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 Selective Repeat r GBN forces sender to retransmit all packets in window even if](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-48.jpg)
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 Selective Repeat r receiver individually acknowledges all correctly received pkts m Must buffer any](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-49.jpg)
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 rcvbaseN1 r Selective repeat sender data from above : receiver pkt n in [rcvbase, rcvbase+N-1] r](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-50.jpg)
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: sender, receiver windows 3: Transport Layer 51](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-51.jpg)
Selective repeat: sender, receiver windows 3: Transport Layer 51
![Selective repeat in action Loss of one pkt causes retransmission of just that pkt Selective repeat in action Loss of one pkt causes retransmission of just that pkt](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-52.jpg)
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 size3 Selective repeat: dilemma Example: r seq #’s: 0, 1, 2, 3 r window size=3](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-53.jpg)
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 Selective Repeat vs GBN r Selective Repeat requires more buffering and complexity on receiver](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-54.jpg)
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 Roadmap r Discussed general principles of reliable message delivery over unreliable channel m m](https://slidetodoc.com/presentation_image_h/75b84f486710c3dcae2addb49b62e494/image-55.jpg)
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
Secure socket layer and transport layer security
Secure socket layer and transport layer security
Secure socket layer and transport layer security
Secure socket layer and transport layer security
Transport layer services
Master data services overview
Sql master data management
Pigmented layer and neural layer
Pathway of food from mouth to anus
Layer 6 presentation layer
Layer 2 e layer 3
Layer-by-layer assembly
Layer 2 vs layer 3 bitstream
Transport layer handles multiplexing and demultiplexing
Atamont fair
Principles of reliable data transfer in transport layer
Crash recovery in transport layer geeksforgeeks
Crash recovery in transport layer
Chapter 3 transport layer
Wireless transport layer security
Selective repeat dilemma
Reliable data transfer in transport layer
Multiplexing and demultiplexing in transport layer
Dns transport layer protocol
Transport layer
Mobile transport layer
Transport layer
Transport layer primitives
Transport layer
Transport layer
Transport layer
Multiplexed transport layer security
Design goals of transport layer protocol
Multiplexed transport layer security
Transport layer
Transport layer ppt
Transport layer.
Maximum segment size
Peran transport layer
Sodium potasium pump
Primary vs secondary active transport
Now answer the questions
Active vs passive transport venn diagram
Unlike passive transport active transport requires
Primary active transport vs secondary active transport
Bioflix activity membrane transport active transport
Passive trnasport
Bioflix activity membrane transport active transport
Swot transport routier
Spmt's
Difference between intserv and diffserv
Wake county human services community services center
Overview of www
Maximo overview
Universal modelling language
Uml