End to End Protocols 1 End to End
![End to End Protocols 1 End to End Protocols 1](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-1.jpg)
![End to End Protocols r Last week: m basic protocols m Stop & wait End to End Protocols r Last week: m basic protocols m Stop & wait](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-2.jpg)
![rdt 3. 0: Stop-and-Wait Operation r rdt 3. 0 works, but performance stinks r rdt 3. 0: Stop-and-Wait Operation r rdt 3. 0 works, but performance stinks r](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-3.jpg)
![Last week: Performance of rdt 3. 0 r rdt 3. 0 works, but performance Last week: Performance of rdt 3. 0 r rdt 3. 0 works, but performance](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-4.jpg)
![Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-tobe-acknowledged pkts m m range of sequence Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-tobe-acknowledged pkts m m range of sequence](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-5.jpg)
![Go Back N (GBN) 6 Go Back N (GBN) 6](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-6.jpg)
![Go-Back-N Sender: r k-bit seq # in pkt header m Unbounded seq. num. r Go-Back-N Sender: r k-bit seq # in pkt header m Unbounded seq. num. r](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-7.jpg)
![GBN: sender extended FSM /*for the packet at the new base*/ 8 GBN: sender extended FSM /*for the packet at the new base*/ 8](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-8.jpg)
![GBN: receiver extended FSM expectedseqnum=expectedseqnum+1 receiver simple: r ACK-only: always send ACK for correctly-received GBN: receiver extended FSM expectedseqnum=expectedseqnum+1 receiver simple: r ACK-only: always send ACK for correctly-received](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-9.jpg)
![GBN in action window size = 4 10 GBN in action window size = 4 10](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-10.jpg)
![GBN: Correctness r Claim I (safety): m The receiver outputs the data in the GBN: Correctness r Claim I (safety): m The receiver outputs the data in the](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-11.jpg)
![GBN: correctness - liveness r Let: m base=k; expecetdseqnum=m; nextseqnum=n; r Observation: k ≤ GBN: correctness - liveness r Let: m base=k; expecetdseqnum=m; nextseqnum=n; r Observation: k ≤](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-12.jpg)
![GBN - Bounding seq. num. Claim: After receiving Data k no Data i<k-N is GBN - Bounding seq. num. Claim: After receiving Data k no Data i<k-N is](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-13.jpg)
![Selective Repeat 14 Selective Repeat 14](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-14.jpg)
![Selective Repeat r receiver individually acknowledges all correctly received pkts m buffers pkts, as Selective Repeat r receiver individually acknowledges all correctly received pkts m buffers pkts, as](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-15.jpg)
![Selective repeat: sender, receiver windows 16 Selective repeat: sender, receiver windows 16](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-16.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_h2/af8b160c4982f1715c8e5b88a0dffa38/image-17.jpg)
![Selective repeat in action 18 Selective repeat in action 18](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-18.jpg)
![Selective Repeat - Correctness r Infinite seq. Num. m Safety: immediate from the seq. Selective Repeat - Correctness r Infinite seq. Num. m Safety: immediate from the seq.](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-19.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_h2/af8b160c4982f1715c8e5b88a0dffa38/image-20.jpg)
![Choosing the window size r Small window size: m idle link (under-utilization). r Large Choosing the window size r Small window size: m idle link (under-utilization). r Large](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-21.jpg)
![End to End Protocols: Multiplexing & Demultiplexing 22 End to End Protocols: Multiplexing & Demultiplexing 22](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-22.jpg)
![Multiplexing/demultiplexing Recall: segment - unit of data exchanged between transport layer entities m aka Multiplexing/demultiplexing Recall: segment - unit of data exchanged between transport layer entities m aka](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-23.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_h2/af8b160c4982f1715c8e5b88a0dffa38/image-24.jpg)
![Multiplexing/demultiplexing: examples host A source port: x dest. port: 23 server B source port: Multiplexing/demultiplexing: examples host A source port: x dest. port: 23 server B source port:](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-25.jpg)
![UDP Protocol 26 UDP Protocol 26](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-26.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_h2/af8b160c4982f1715c8e5b88a0dffa38/image-27.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_h2/af8b160c4982f1715c8e5b88a0dffa38/image-28.jpg)
![UDP checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment Sender: UDP checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment Sender:](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-29.jpg)
![TCP Protocol 30 TCP Protocol 30](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-30.jpg)
![TCP: Overview r point-to-point: m one sender, one receiver r reliable, in-order byte steam: TCP: Overview r point-to-point: m one sender, one receiver r reliable, in-order byte steam:](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-31.jpg)
![TCP segment structure 32 bits URG: urgent data (generally not used) ACK: ACK # TCP segment structure 32 bits URG: urgent data (generally not used) ACK: ACK #](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-32.jpg)
![Connection Management: Objective r Agree on initial sequence numbers m a sender will not Connection Management: Objective r Agree on initial sequence numbers m a sender will not](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-33.jpg)
![TCP seq. #’s and ACKs Seq. #’s: m byte stream “number” of first byte TCP seq. #’s and ACKs Seq. #’s: m byte stream “number” of first byte](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-34.jpg)
![Three Way Handshake (TWH) [Tomlinson 1975] r To ensure that the other side does Three Way Handshake (TWH) [Tomlinson 1975] r To ensure that the other side does](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-35.jpg)
![Connection Close r Objective of closure handshake: m each side can release resource and Connection Close r Objective of closure handshake: m each side can release resource and](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-36.jpg)
![TCP: reliable data transfer event: data received from application above create, send segment wait TCP: reliable data transfer event: data received from application above create, send segment wait](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-37.jpg)
![TCP: reliable data transfer Simplified TCP sender 00 sendbase = initial_sequence number 01 nextseqnum TCP: reliable data transfer Simplified TCP sender 00 sendbase = initial_sequence number 01 nextseqnum](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-38.jpg)
![TCP ACK generation [RFC 1122, RFC 2581] Event TCP Receiver action in-order segment arrival, TCP ACK generation [RFC 1122, RFC 2581] Event TCP Receiver action in-order segment arrival,](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-39.jpg)
![TCP: retransmission scenarios Host A , 8 byt es dat a 100 X = TCP: retransmission scenarios Host A , 8 byt es dat a 100 X =](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-40.jpg)
![TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments r TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments r](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-41.jpg)
![TCP Connection Management (cont. ) Three way handshake: Step 1: client end system sends TCP Connection Management (cont. ) Three way handshake: Step 1: client end system sends](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-42.jpg)
![TCP Connection Management (cont. ) Closing a connection: client closes socket: client. Socket. close(); TCP Connection Management (cont. ) Closing a connection: client closes socket: client. Socket. close();](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-43.jpg)
![TCP Connection Management (cont. ) Step 3: client receives FIN, replies with ACK. m TCP Connection Management (cont. ) Step 3: client receives FIN, replies with ACK. m](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-44.jpg)
![TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle 45 TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle 45](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-45.jpg)
![TCP state transition diagram 46 TCP state transition diagram 46](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-46.jpg)
![Simultaneous open SYN Seq=100 SYN-ACK Seq=101 Ack=330 SYN Seq=330 SYN_SENT SYN-ACK Seq=331 Ack=100 SYN_RCVD Simultaneous open SYN Seq=100 SYN-ACK Seq=101 Ack=330 SYN Seq=330 SYN_SENT SYN-ACK Seq=331 Ack=100 SYN_RCVD](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-47.jpg)
- Slides: 47
![End to End Protocols 1 End to End Protocols 1](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-1.jpg)
End to End Protocols 1
![End to End Protocols r Last week m basic protocols m Stop wait End to End Protocols r Last week: m basic protocols m Stop & wait](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-2.jpg)
End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol. • Go Back N • Selective Repeat m TCP protocol. m UDP protocol. r Next week: Flow control & congestion control 2
![rdt 3 0 StopandWait Operation r rdt 3 0 works but performance stinks r rdt 3. 0: Stop-and-Wait Operation r rdt 3. 0 works, but performance stinks r](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-3.jpg)
rdt 3. 0: Stop-and-Wait Operation r rdt 3. 0 works, but performance stinks r example: 1 Gbps link, 15 ms e-e prop. delay, 1 KB packet: sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK arrives, send next packet, t = RTT + L / R 3
![Last week Performance of rdt 3 0 r rdt 3 0 works but performance Last week: Performance of rdt 3. 0 r rdt 3. 0 works, but performance](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-4.jpg)
Last week: Performance of rdt 3. 0 r rdt 3. 0 works, but performance stinks r 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. 00027 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 transport protocol limits use of physical resources! 4
![Pipelined protocols Pipelining sender allows multiple inflight yettobeacknowledged pkts m m range of sequence Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-tobe-acknowledged pkts m m range of sequence](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-5.jpg)
Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-tobe-acknowledged pkts m m range of sequence numbers must be increased buffering at sender and/or receiver r Two generic forms of pipelined protocols: go-Back-N, selective repeat 5
![Go Back N GBN 6 Go Back N (GBN) 6](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-6.jpg)
Go Back N (GBN) 6
![GoBackN Sender r kbit seq in pkt header m Unbounded seq num r Go-Back-N Sender: r k-bit seq # in pkt header m Unbounded seq. num. r](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-7.jpg)
Go-Back-N Sender: r k-bit seq # in pkt header m Unbounded seq. num. r “window” of up to N, consecutive unack’ed pkts allowed r ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may deceive duplicate ACKs (see receiver) r timer for the packet at base r timeout(n): retransmit pkt n and all higher seq # pkts in window m 7
![GBN sender extended FSM for the packet at the new base 8 GBN: sender extended FSM /*for the packet at the new base*/ 8](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-8.jpg)
GBN: sender extended FSM /*for the packet at the new base*/ 8
![GBN receiver extended FSM expectedseqnumexpectedseqnum1 receiver simple r ACKonly always send ACK for correctlyreceived GBN: receiver extended FSM expectedseqnum=expectedseqnum+1 receiver simple: r ACK-only: always send ACK for correctly-received](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-9.jpg)
GBN: receiver extended FSM expectedseqnum=expectedseqnum+1 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 # 9
![GBN in action window size 4 10 GBN in action window size = 4 10](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-10.jpg)
GBN in action window size = 4 10
![GBN Correctness r Claim I safety m The receiver outputs the data in the GBN: Correctness r Claim I (safety): m The receiver outputs the data in the](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-11.jpg)
GBN: Correctness r Claim I (safety): m The receiver outputs the data in the correct order m Proof: unbounded seq. num. QED r Claim I (seqnum): m In the receiver: • Value of expectedseqnum only increases m In the sender: • The received ACK seqnum only increases. m This is why the sender does not need to test getacknum(rcvpkt) when updating variable base! 11
![GBN correctness liveness r Let m basek expecetdseqnumm nextseqnumn r Observation k GBN: correctness - liveness r Let: m base=k; expecetdseqnum=m; nextseqnum=n; r Observation: k ≤](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-12.jpg)
GBN: correctness - liveness r Let: m base=k; expecetdseqnum=m; nextseqnum=n; r Observation: k ≤ m ≤ n r Claim (Liveness): m If k<m then eventually base ≥ m m If (k=m and m<n) then eventually: • receiver outputs data item m • Expectedseqnum ≥ m+1 12
![GBN Bounding seq num Claim After receiving Data k no Data ikN is GBN - Bounding seq. num. Claim: After receiving Data k no Data i<k-N is](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-13.jpg)
GBN - Bounding seq. num. Claim: After receiving Data k no Data i<k-N is received. After receiving ACK k no ACK i<k is received. Ack i<k Clearing a FIFO channel: Seq num only Ack k Ack i<k increases impossible Data i<k-N Data k impossible Data i<k-N Not in window with k Corollary: Sufficient to use N+1 seq. num. 13
![Selective Repeat 14 Selective Repeat 14](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-14.jpg)
Selective Repeat 14
![Selective Repeat r receiver individually acknowledges all correctly received pkts m buffers pkts as Selective Repeat r receiver individually acknowledges all correctly received pkts m buffers pkts, as](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-15.jpg)
Selective Repeat r receiver individually acknowledges all correctly received pkts m buffers pkts, as needed, for eventual in-order delivery to upper layer 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 m sender timer for each un. ACKed pkt 15
![Selective repeat sender receiver windows 16 Selective repeat: sender, receiver windows 16](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-16.jpg)
Selective repeat: sender, receiver windows 16
![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_h2/af8b160c4982f1715c8e5b88a0dffa38/image-17.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 ACK(n) otherwise: r ignore 17
![Selective repeat in action 18 Selective repeat in action 18](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-18.jpg)
Selective repeat in action 18
![Selective Repeat Correctness r Infinite seq Num m Safety immediate from the seq Selective Repeat - Correctness r Infinite seq. Num. m Safety: immediate from the seq.](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-19.jpg)
Selective Repeat - Correctness r Infinite seq. Num. m Safety: immediate from the seq. Num. m Liveness: Eventually data and ACKs get through. r Finite Seq. Num. m Idea: Re-use seq. Num. m Use less bits to encode them. r Number of seq. Num. : m At least N. m Needs more! 19
![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_h2/af8b160c4982f1715c8e5b88a0dffa38/image-20.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 m m Passes duplicate data as new in (a) or Discards in (b) Q: what relationship between seq # size and window size? 20
![Choosing the window size r Small window size m idle link underutilization r Large Choosing the window size r Small window size: m idle link (under-utilization). r Large](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-21.jpg)
Choosing the window size r Small window size: m idle link (under-utilization). r Large window size: m Buffer space m Delay after loss r Ideal window size (assuming very low loss) m RTT =Round trip time m C = link capacity m window size = RTT * C r What happens with no loss? 21
![End to End Protocols Multiplexing Demultiplexing 22 End to End Protocols: Multiplexing & Demultiplexing 22](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-22.jpg)
End to End Protocols: Multiplexing & Demultiplexing 22
![Multiplexingdemultiplexing Recall segment unit of data exchanged between transport layer entities m aka Multiplexing/demultiplexing Recall: segment - unit of data exchanged between transport layer entities m aka](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-23.jpg)
Multiplexing/demultiplexing Recall: segment - unit of data exchanged between transport layer entities m aka TPDU: transport protocol data unit application-layer data segment header segment Ht M Hn segment P 1 M application transport network P 3 Demultiplexing: delivering received segments to correct app layer processes receiver M M application transport network P 4 M P 2 application transport network 23
![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_h2/af8b160c4982f1715c8e5b88a0dffa38/image-24.jpg)
Multiplexing/demultiplexing Multiplexing: gathering data from multiple app processes, enveloping data with header (later used for demultiplexing) multiplexing/demultiplexing: r based on sender, receiver port numbers, IP addresses m source, dest port #s in each segment m recall: well-known port numbers for specific applications r Using IP addresses – layer violation. 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format 24
![Multiplexingdemultiplexing examples host A source port x dest port 23 server B source port Multiplexing/demultiplexing: examples host A source port: x dest. port: 23 server B source port:](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-25.jpg)
Multiplexing/demultiplexing: examples host A source port: x dest. port: 23 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 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 25
![UDP Protocol 26 UDP Protocol 26](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-26.jpg)
UDP Protocol 26
![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_h2/af8b160c4982f1715c8e5b88a0dffa38/image-27.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 application 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 27
![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_h2/af8b160c4982f1715c8e5b88a0dffa38/image-28.jpg)
UDP: more r often used for streaming multimedia apps m loss tolerant m rate sensitive Length, in bytes of UDP segment, (why? ): including header r other UDP uses m DNS 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 28
![UDP checksum Goal detect errors e g flipped bits in transmitted segment Sender UDP checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment Sender:](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-29.jpg)
UDP checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment Sender: r treat segment contents as sequence of 16 -bit integers r checksum: addition (1’s complement sum) of segment contents r sender puts checksum value into UDP checksum field 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. 29
![TCP Protocol 30 TCP Protocol 30](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-30.jpg)
TCP Protocol 30
![TCP Overview r pointtopoint m one sender one receiver r reliable inorder byte steam TCP: Overview r point-to-point: m one sender, one receiver r reliable, in-order byte steam:](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-31.jpg)
TCP: Overview r point-to-point: m one sender, one receiver r reliable, in-order byte steam: m no “message boundaries” r pipelined: m TCP congestion and flow control set window size r send & receive buffers RFCs: 793, 1122, 1323, 2018, 2581 r full duplex data: m bi-directional data flow in same connection m MSS: maximum segment size r connection-oriented: m handshaking (exchange of control msgs) init’s sender, receiver state before data exchange r flow controlled: m sender will not overwhelm receiver 31
![TCP segment structure 32 bits URG urgent data generally not used ACK ACK TCP segment structure 32 bits URG: urgent data (generally not used) ACK: ACK #](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-32.jpg)
TCP segment structure 32 bits URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) source port # dest port # sequence number acknowledgement number head not UA P R S F len used checksum rcvr window size ptr urgent data Options (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept application data (variable length) 32
![Connection Management Objective r Agree on initial sequence numbers m a sender will not Connection Management: Objective r Agree on initial sequence numbers m a sender will not](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-33.jpg)
Connection Management: Objective r Agree on initial sequence numbers m a sender will not reuse a seq# before it is sure that all packets with the seq# are purged from the network • the network guarantees that a packet too old will be purged from the network: network bounds the life time of each packet m To avoid waiting for the seq# to start a session, use a larger seq# space • needs connection setup so that the sender tells the receiver initial seq# r Agree on other initial parameters 33 33
![TCP seq s and ACKs Seq s m byte stream number of first byte TCP seq. #’s and ACKs Seq. #’s: m byte stream “number” of first byte](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-34.jpg)
TCP seq. #’s and ACKs Seq. #’s: m byte stream “number” of first byte in segment’s data ACKs: m seq # of next byte expected from other side m cumulative ACK Q: how receiver handles out-of-order segments m A: TCP spec doesn’t say - up to implementor Host B Host A User types ‘C’ Seq=4 2, ACK = 79, da ta ata = d , 3 4 K= , AC q=79 Se host ACKs receipt of echoed ‘C’ = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=4 3, ACK =80 simple telnet scenario time 34
![Three Way Handshake TWH Tomlinson 1975 r To ensure that the other side does Three Way Handshake (TWH) [Tomlinson 1975] r To ensure that the other side does](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-35.jpg)
Three Way Handshake (TWH) [Tomlinson 1975] r To ensure that the other side does want to send a request Host A Host B SYN(s Host A eq=x) Host B SYN(s eq=x) y) ( ACK x), seq= SY q= N(se accept? N( ), SY q=x (se ACK(s eq=y) DATA y) seq= no such request ACK(s eq=z) (seq=x +1) REJEC reject T(seq= y ) 35 35
![Connection Close r Objective of closure handshake m each side can release resource and Connection Close r Objective of closure handshake: m each side can release resource and](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-36.jpg)
Connection Close r Objective of closure handshake: m each side can release resource and remove state about the connection client init. close I am d one. A r release resource? close server I one am d e you done t oo? too ! dbye o o. G close release resource? 36 36
![TCP reliable data transfer event data received from application above create send segment wait TCP: reliable data transfer event: data received from application above create, send segment wait](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-37.jpg)
TCP: reliable data transfer event: data received from application above create, send segment wait for event simplified sender, assuming • one way data transfer • no flow, congestion control event: timer timeout for segment with seq # y retransmit segment event: ACK received, with ACK # y ACK processing 37
![TCP reliable data transfer Simplified TCP sender 00 sendbase initialsequence number 01 nextseqnum TCP: reliable data transfer Simplified TCP sender 00 sendbase = initial_sequence number 01 nextseqnum](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-38.jpg)
TCP: reliable data transfer Simplified TCP sender 00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 02 03 loop (forever) { 04 switch(event) 05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compue new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers < y 17 sendbase = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */ 38
![TCP ACK generation RFC 1122 RFC 2581 Event TCP Receiver action inorder segment arrival TCP ACK generation [RFC 1122, RFC 2581] Event TCP Receiver action in-order segment arrival,](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-39.jpg)
TCP ACK generation [RFC 1122, RFC 2581] Event TCP Receiver action in-order segment arrival, no gaps, everything else already ACKed delayed ACK. Wait up to 500 ms for next segment. If no next segment, send ACK in-order segment arrival, no gaps, one delayed ACK pending immediately send single cumulative ACK out-of-order segment arrival higher-than-expect seq. # gap detected send duplicate ACK, indicating seq. # of next expected byte arrival of segment that partially or completely fills gap immediate ACK if segment starts at lower end of gap 39
![TCP retransmission scenarios Host A 8 byt es dat a 100 X TCP: retransmission scenarios Host A , 8 byt es dat a 100 X =](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-40.jpg)
TCP: retransmission scenarios Host A , 8 byt es dat a 100 X = ACK loss Seq=9 2 , 8 byt es dat a 0 10 = K 120 = C K A AC Seq=9 2, 8 by tes da t a 20 100 lost ACK scenario 2, 8 by tes da ta Seq= 100, 2 0 byte s data K=1 AC = ACK time Host B Seq=9 Seq=100 timeout Seq=92 timeout Seq=9 2 timeout Host A Host B time premature timeout, cumulative ACKs 40
![TCP Connection Management Recall TCP sender receiver establish connection before exchanging data segments r TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments r](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-41.jpg)
TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments r initialize TCP variables: m seq. #s m buffers, flow control info (e. g. Rcv. Window) r client: connection initiator r server: contacted by client 41
![TCP Connection Management cont Three way handshake Step 1 client end system sends TCP Connection Management (cont. ) Three way handshake: Step 1: client end system sends](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-42.jpg)
TCP Connection Management (cont. ) Three way handshake: Step 1: client end system sends TCP SYN control segment to server m specifies initial seq # Step 2: server end system receives SYN, replies with SYN-ACK control segment m m m ACKs received SYN allocates buffers specifies server-> receiver initial seq. # client server Syn se q =100 SYN_sent 0 k=10 c a 30 eq=3 Ks N-AC SY SYN_rcvd ACK ESTABLISHED Step 3: client receives SYNACK and replies with ACK (possibly with data). 42
![TCP Connection Management cont Closing a connection client closes socket client Socket close TCP Connection Management (cont. ) Closing a connection: client closes socket: client. Socket. close();](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-43.jpg)
TCP Connection Management (cont. ) Closing a connection: client closes socket: client. Socket. close(); client close Step 1: client end system close FIN timed wait FIN, replies with ACK. Closes connection, sends FIN ACK sends TCP FIN control segment to server Step 2: server receives server ACK closed 43
![TCP Connection Management cont Step 3 client receives FIN replies with ACK m TCP Connection Management (cont. ) Step 3: client receives FIN, replies with ACK. m](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-44.jpg)
TCP Connection Management (cont. ) Step 3: client receives FIN, replies with ACK. m client closing Enters “timed wait” will respond with ACK to received FINs server FIN ACK Step 4: server, receives closing FIN Note: with small modification, can handle simultaneous FINs. timed wait ACK. Connection closed. ACK closed 44
![TCP Connection Management cont TCP server lifecycle TCP client lifecycle 45 TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle 45](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-45.jpg)
TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle 45
![TCP state transition diagram 46 TCP state transition diagram 46](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-46.jpg)
TCP state transition diagram 46
![Simultaneous open SYN Seq100 SYNACK Seq101 Ack330 SYN Seq330 SYNSENT SYNACK Seq331 Ack100 SYNRCVD Simultaneous open SYN Seq=100 SYN-ACK Seq=101 Ack=330 SYN Seq=330 SYN_SENT SYN-ACK Seq=331 Ack=100 SYN_RCVD](https://slidetodoc.com/presentation_image_h2/af8b160c4982f1715c8e5b88a0dffa38/image-47.jpg)
Simultaneous open SYN Seq=100 SYN-ACK Seq=101 Ack=330 SYN Seq=330 SYN_SENT SYN-ACK Seq=331 Ack=100 SYN_RCVD ACK+Data ESTABLISHED ACK+Data 47
Close reading protocols
Ems
Protocols and standards in computer networks
Routing protocols
Protocols rhyme
Consistency and replication in distributed systems
Wireless sensor network protocols
Snmp port number
Network communication protocols map
Introduction to dynamic routing protocols
5 network topologies
Proofs of work and bread pudding protocols
Tcp and sctp are both layer protocols
Wireless lan protocols
Alohause reviews
Determine the taxonomy of multiple access protocols
Remsa protocols
The protocol ensures freedom from deadlock.
Ppdioo
Application layer protocols
Plc
Playfair cipher
Clinical assessment protocols
Real world protocols
Ssvems
Wan types
Presentation layer design issues
Distributed reliability protocols in dbms
Application layer protocols
High level data link control protocol
Omig audit protocols
Dicomn
Nyc bls protocols
Routing and switching protocols
Define nursing protocols
Categories of attacks
Routing and switching protocols
Therapist driven protocols
Presentation layer design issues
What is lock based protocol in dbms
Wireless lan protocols
Plc norms
Mobile station (ms)
Accountable talk protocols
Vaeai protocols
Remsa protocols
²orange
Cache coherence protocols