Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol.

Similar presentations


Presentation on theme: "1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol."— Presentation transcript:

1 1 End to End Protocols

2 2 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

3 3 rdt3.0: Stop-and-Wait Operation first packet bit transmitted, t = 0 senderreceiver RTT last packet bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R r rdt3.0 works, but performance stinks r example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:

4 4 Last week: Performance of rdt3.0 r rdt3.0 works, but performance stinks r example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet: T transmit = 8kb/pkt 10**9 b/sec = 8 microsec Utilization = U = = 8 microsec msec fraction of time sender busy sending = m 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link m transport protocol limits use of physical resources!

5 5 Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-to- be-acknowledged pkts m range of sequence numbers must be increased m buffering at sender and/or receiver r Two generic forms of pipelined protocols: go-Back-N, selective repeat

6 6 Go Back N (GBN)

7 7 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” m 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

8 8 GBN: sender extended FSM /*for the packet at the new base*/

9 9 GBN: receiver extended FSM receiver simple: r ACK-only: always send ACK for correctly-received pkt with highest in-order seq # 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 # expectedseqnum=expectedseqnum+1

10 10 GBN in action window size = 4

11 11 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.  This is why the sender does not need to test getacknum(rcvpkt) when updating variable base !

12 12 GBN: correctness - liveness r Let: m base=k; expecetdseqnum=m; nextseqnum=n; r Observation: k ≤ m ≤ n r Claim (Liveness): m If k

13 13 GBN - Bounding seq. num. Clearing a FIFO channel: Data k Ack k impossible Data i

14 14 Selective Repeat

15 15 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 unACKed pkt r sender window m N consecutive seq #’s m again limits seq #s of sent, unACKed pkts m sender timer for each unACKed pkt

16 16 Selective repeat: sender, receiver windows

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

18 18 Selective repeat in action

19 19 Selective Repeat in Action

20 20 Selective repeat in action

21 21 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!

22 22 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 Passes duplicate data as new in (a) or m Discards in (b) Q: what relationship between seq # size and window size?

23 23 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?

24 24 End to End Protocols: Multiplexing & Demultiplexing

25 25 application transport network M P2 application transport network Multiplexing/demultiplexing Recall: segment - unit of data exchanged between transport layer entities m aka TPDU: transport protocol data unit receiver H t H n Demultiplexing: delivering received segments to correct app layer processes segment M application transport network P1 MMM P3 P4 segment header application-layer data

26 26 Multiplexing/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. gathering data from multiple app processes, enveloping data with header (later used for demultiplexing) source port #dest port # 32 bits application data (message) other header fields TCP/UDP segment format Multiplexing:

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

28 28 UDP Protocol

29 29 UDP: User Datagram Protocol [RFC 768] 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 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

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

31 31 UDP checksum 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. Goal: detect “errors” (e.g., flipped bits) in transmitted segment

32 32 TCP Protocol

33 33 TCP: Overview 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 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

34 34 TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number rcvr window size ptr urgent data checksum F SR PAU head len not used Options (variable length) URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) # bytes rcvr willing to accept counting by bytes of data (not segments!) Internet checksum (as in UDP)

35 35 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

36 36 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 A Host B Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80 User types ‘C’ host ACKs receipt of echoed ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ time simple telnet scenario

37 37 Three Way Handshake (TWH) [Tomlinson 1975] Host A SYN(seq=x) Host B ACK(seq=x), SYN(seq=y) ACK(seq=y) DATA(seq=x+1) SYN: indicates connection setup accept data only after verified x is the init. seq accept?

38 38 Scenarios with Duplicate Request Host A Host B ACK(seq=x), SYN(seq=y) REJECT(seq=y) SYN(seq=x) accept? no such request reject

39 39 Three Way Handshake (TWH) [Tomlinson 1975] r To ensure that the other side does want to send a request Host A SYN(seq=x) Host B ACK(seq=x), SYN(seq=y) ACK(seq=y) DATA(seq=x+1) Host A Host B ACK(seq=x), SYN(seq=y) REJECT(seq=y) SYN(seq=x) accept? no such request reject ACK(seq=z)

40 40 Connection Close r Objective of closure handshake: m each side can release resource and remove state about the connection client I am done. Are you done too? server I am done too. Goodbye! init. close close release resource? release resource? release resource?

41 41 TCP: reliable data transfer simplified sender, assuming wait for event wait for event event: data received from application above event: timer timeout for segment with seq # y event: ACK received, with ACK # y create, send segment retransmit segment ACK processing one way data transfer no flow, congestion control

42 42 TCP: reliable data transfer 00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 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 */ Simplified TCP sender

43 43 TCP ACK generation [RFC 1122, RFC 2581] Event in-order segment arrival, no gaps, everything else already ACKed in-order segment arrival, no gaps, one delayed ACK pending out-of-order segment arrival higher-than-expect seq. # gap detected arrival of segment that partially or completely fills gap TCP Receiver action delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK immediately send single cumulative ACK send duplicate ACK, indicating seq. # of next expected byte immediate ACK if segment starts at lower end of gap

44 44 TCP: retransmission scenarios Host A Seq=92, 8 bytes data ACK=100 loss timeout time lost ACK scenario Host B X Seq=92, 8 bytes data ACK=100 Host A Seq=100, 20 bytes data ACK=100 Seq=92 timeout time premature timeout, cumulative ACKs Host B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data Seq=100 timeout ACK=120

45 45 TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments r initialize TCP variables: m seq. #s  buffers, flow control info (e.g. RcvWindow ) r client: connection initiator r server: contacted by client 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 ACKs received SYN m allocates buffers m specifies server-> receiver initial seq. #

46 46 TCP Connection Management (cont.) Step 3: client receives SYN- ACK and replies with ACK (possibly with data). client Syn seq=100 server SYN-ACK seq=330 ack=100 ACK SYN_sent SYN_rcvd ESTABLISHED

47 47 TCP Connection Management (cont.) Closing a connection: client closes socket: clientSocket.close(); Step 1: client end system sends TCP FIN control segment to server Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN. client FIN server ACK FIN close closed timed wait

48 48 TCP Connection Management (cont.) Step 3: client receives FIN, replies with ACK. m Enters “timed wait” - will respond with ACK to received FINs Step 4: server, receives ACK. Connection closed. Note: with small modification, can handle simultaneous FINs. client FIN server ACK FIN closing closed timed wait closed

49 49 TCP Connection Management (cont) TCP client lifecycle TCP server lifecycle

50 50 TCP state transition diagram

51 51 Simultaneous open SYN Seq=100 SYN Seq=330 SYN-ACK Seq=101 Ack=330 ACK+Data SYN_SENT SYN-ACK Seq=331 Ack=100 SYN_RCVD ESTABLISHED


Download ppt "1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol."

Similar presentations


Ads by Google