Download presentation
Presentation is loading. Please wait.
Published byEthelbert McCarthy Modified over 9 years ago
1
Transport Layer 3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 Part 2: Principles of reliable data transfer
2
Transport Layer 3-2 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control
3
Transport Layer 3-3 Principles of Reliable data transfer r important in app., transport, link layers r top-10 list of important networking topics! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
4
Transport Layer 3-4 Principles of Reliable data transfer r important in app., transport, link layers r top-10 list of important networking topics! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
5
Transport Layer 3-5 Principles of Reliable data transfer r important in app., transport, link layers r top-10 list of important networking topics! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
6
Principles of Reliable data transfer r Assumptions in our models: m packets arrive in order (Though some may be lost!) m unidirectional data transfer (from sending to receiving) r TCP does not assume in- order arrival r Most real connections are bi-directional. Same protocol, just more tedious r Transport layer divides a message into “segments” r We will use the more general term “packets” since the protocols we develop could be used at any level Transport Layer 3-6
7
rdt_rcv(): called when packet arrives on rcv-side of channel Transport Layer 3-7 Reliable data transfer: getting started send side receive side rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer udt_send(): called by rdt, to transfer packet over unreliable channel to receiver deliver_data(): called by rdt to deliver data to upper
8
Transport Layer 3-8 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 1 state 2 event causing state transition actions taken on state transition state: when in this “state” next state uniquely determined by next event event actions
9
Transport Layer 3-9 Rdt1.0: reliable transfer over a reliable channel r underlying channel perfectly reliable m no bit errors m no loss of packets m no flow control: receiver can receive as fast as sender sends r separate FSMs for sender, receiver: m sender sends data into underlying channel m receiver read data from underlying channel Wait for call from above packet = make_pkt(data) udt_send(packet) rdt_send(data) extract (packet,data) deliver_data(data) Wait for call from below rdt_rcv(packet) sender receiver
10
Rdt2.0: channel with bit errors r underlying channel may flip bits in packet m 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 Transport Layer 3-10
11
Rdt2.0: channel with bit errors r new mechanisms in rdt2.0 (beyond rdt1.0): m error detection receiver must detect when bit errors occur Similar to the UDP method Can correct some erros Requires extra bits Will consider these later m receiver feedback: control msgs (ACK,NAK) rcvr->sender m Retransmission A packet received in error at the receiver will be retransmitted by the sender Transport Layer 3-11
12
Transport Layer 3-12 rdt2.0: FSM specification Wait for call from above snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below sender receiver rdt_send(data)
13
Transport Layer 3-13 rdt2.0: operation with no errors Wait for call from above snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below rdt_send(data)
14
Transport Layer 3-14 rdt2.0: error scenario Wait for call from above snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below rdt_send(data)
15
Transport Layer 3-15 rdt2.0 has a fatal flaw! What happens if ACK/NAK corrupted? r sender doesn’t know what happened at receiver! r Can’t send a “did not receive ACK/NAK” message because the reply to that message might be corrupt in ad finitum r can’t just retransmit: possible duplicate r Improving checksum only works so far… Handling duplicates (used in TCP): r sender retransmits current pkt if ACK/NAK garbled r sender adds sequence number to each pkt r receiver discards (doesn’t deliver up) duplicate pkt Sender sends one packet, then waits for receiver response stop and wait
16
Transport Layer 3-16 rdt2.1: sender, handles garbled ACK/NAKs Wait for call 0 from above sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) Wait for ACK or NAK 0 udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) Wait for call 1 from above Wait for ACK or NAK 1
17
Transport Layer 3-17 rdt2.1: receiver, handles garbled ACK/NAKs Wait for 0 from below sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Wait for 1 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt)
18
Transport Layer 3-18 rdt2.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: receiver can not know if its last ACK/NAK received OK at sender
19
Transport Layer 3-19 rdt2.2: a NAK-free protocol r same functionality as rdt2.1, using ACKs 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
20
Transport Layer 3-20 rdt2.2: sender, receiver fragments Wait for call 0 from above sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) Wait for ACK 0 sender FSM fragment Wait for 0 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt) receiver FSM fragment
21
Transport Layer 3-21 rdt3.0: channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) m Problems: How to detect loss What to do when loss occurs m checksum, seq. #, ACKs, retransmissions will help resolve m but need new mechanism to detect 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 Alternating bit protocol
22
Transport Layer 3-22 rdt3.0 sender sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) Wait for ACK0 rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) Wait for call 1 from above sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop_timer udt_send(sndpkt) start_timer timeout udt_send(sndpkt) start_timer timeout rdt_rcv(rcvpkt) Wait for call 0from above Wait for ACK1 rdt_rcv(rcvpkt)
23
Transport Layer 3-23 rdt3.0 in action
24
Transport Layer 3-24 rdt3.0 in action
25
Transport Layer 3-25 Performance of rdt3.0 r rdt3.0 works, but performance stinks r ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet: m Last bit enters channel on senders side at L/R = 8 microsec m Takes 15 msec to get to receiver m Assuming ACK size can be ignored, takes 15msec to get ACK to sender m Time before sender can send second packet: 30.008 msec L= length of packet R = transmission rate d trans = delay for transmitting L= length of packet R = transmission rate d trans = delay for transmitting RTT/2
26
Transport Layer 3-26 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
27
Transport Layer 3-27 Performance of rdt3.0 r rdt3.0 works, but performance stinks r ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet: m U sender : utilization is the fraction of time sender busy sending m Sender is busy 2.7 hundredths of one percent of the time! m 1KB pkt every 30.008 msec -> 1KB/30.008x10 -6 sec = 33.3kB/sec = 266 kbps thruput over 1 Gbps link m network protocol limits use of physical resources! L= length of packet R = transmission rate L= length of packet R = transmission rate
28
Transport Layer 3-28 Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-to- be-acknowledged pkts m range of sequence numbers must be increased m buffering needed at sender and/or receiver r Two generic forms of pipelined protocols: go-Back-N, selective repeat
29
Transport Layer 3-29 Pipelining: increased utilization first packet bit transmitted, t = 0 senderreceiver RTT last bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK Increase utilization by a factor of 3!
30
Transport Layer 3-30 Pipelining Protocols Go-back-N: overview r sender: up to N unACKed pkts in pipeline r receiver: only sends cumulative ACKs m doesn’t ACK pkt if there’s a gap r sender: has timer for oldest unACKed pkt m if timer expires: retransmit all unACKed packets Selective Repeat: overview r sender: up to N unACKed packets in pipeline r receiver: ACKs individual pkts r sender: maintains timer for each unACKed pkt m if timer expires: retransmit only unACKed packet TCP uses a meld of both
31
Transport Layer 3-31 Go-Back-N (sliding window) Sender: r k-bit seq # in pkt header (arithmetic is modulo 2 k ) r “window” of up to N, consecutive unACKed pkts allowed r ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” m may receive duplicate ACKs (see receiver) r timer for each in-flight pkt r timeout(n): retransmit pkt n and all higher seq # pkts in window Why not infinite window? Flow control and congestion control
32
Transport Layer 3-32 GBN: sender extended FSM Wait start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) timeout rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base=1 nextseqnum=1 rdt_rcv(rcvpkt) && corrupt(rcvpkt) TCP has 32-bit seq no but seq no count bytes in the byte stream. We’ll see this later. Extended FSM: add variables and ops on the variables. Looks like a programming lang specification
33
GBN Sender: events r Responds to 3 types of events: m Invocation from above. If window is full, return Else create packet and send, update variables m Receipt of ACK Receipt of ACK with seq no n is cummulative, i.e., all packets up to and including n are ACK’d m Timeout event Sender sends all packets that have sent but not ACK’d If ACK received and there are still sent but not ACK’d messages, restart timer Transport Layer 3-33
34
Transport Layer 3-34 GBN: receiver extended FSM 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 Re-ACK pkt with highest in-order seq # Wait udt_send(sndpkt) default rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum)
35
GBN receiver r If packet with seq no n received correctly and in order, m Send ACK of n m Give packet to application r Otherwise, discard packet and resend ACK for most recently received in-order packet Transport Layer 3-35
36
GBN receiver r Why not buffer out-of-order packets r E.g., receive n + 1 but not n r But GBN will retransmit both n and n + 1 when n + 1 times out. r Why bother keeping n + 1? Transport Layer 3-36
37
Transport Layer 3-37 GBN in action Window size = 4
38
GBN problems r If window size and bandwidth-delay both large, there can be many packages in the pipeline m A single packet error causes many packages to be retransmitted unecessarily Transport Layer 3-38
39
Transport Layer 3-39 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 may have received ACKs for some of the packets in the window
40
Transport Layer 3-40 Selective repeat: sender, receiver windows Note that the sender and receiver windows may not be in sync! Why?
41
Transport Layer 3-41 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 Why? What can happen?
42
Transport Layer 3-42 Selective repeat in action Packets buffered until pkt2 rcvd
43
SR dilemma r Problem: lack of synchronization between sender & receiver windows. r Scenario 1 (next slide). Window size of 4, seq no. 0, 1, 2, 3 m Sender sends 3 packets, receiver receives. m Receiver window: 3, 0, 1 m All ACKs lost. Packet 0 times-out at sender. m Sender resends packet 0. m What happens at receiver? Transport Layer 3-43
44
SR dilemma r Scenario 2 (previous slide). Window size of 4, seq no. 0, 1, 2, 3 m Sender sends 3 packets, receiver receives. m Receiver window: 3, 0, 1 m All ACKs received by sender. m Sender window: 3, 0, 1 m Sender sends three packets (seq no. 3, 0, 1) m Packet 3 is lost, but packet 0 arrives. m What does the receiver do? r Both scenarios look the same from the receiver’s view! See next slide. Transport Layer 3-44
45
Transport Layer 3-45 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?
46
SR dilemma r Clearly the window size must be smaller than the sequence number size. r How much smaller? 1 won’t work? r Window size must be less than or equal to half the size of the sequence number space for SR protocols Transport Layer 3-46
47
Remaining assumption r Last remaining assumption: packets always arrive in order m Not realistic on internet m Manifestation: an old packet can turn up at any time. May not be in window. r How to handle? m Don’t reuse seq no. until sure that they can no longer be alive m Alive means some fixed max time m TCP assumes approx 3 minutes Transport Layer 3-47
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.