Transport Layer 3- 1 Chapter 3 outline - PowerPoint Presentation

1. Transport Layer3-1Chapter 3 outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

2. Transport Layer3-2TCP reliable data transferTCP creates rdt service on top of IP’s unreliable servicepipelined segmentscumulative ackssingle retransmission timerretransmissions triggered by:timeout eventsduplicate ackslet’s initially consider simplified TCP sender:ignore duplicate acksignore flow control, congestion control

3. Transport Layer3-3TCP sender events:data rcvd from app:create segment with seq #seq # is byte-stream number of first data byte in segmentstart timer if not already running think of timer as for oldest unacked segmentexpiration interval: TimeOutInterval timeout:retransmit segment that caused timeoutrestart timer ack rcvd:if ack acknowledges previously unacked segmentsupdate what is known to be ACKedstart timer if there are still unacked segments

4. Transport Layer3-4TCP sender (simplified)waitfor eventNextSeqNum = InitialSeqNumSendBase = InitialSeqNumLcreate segment, seq. #: NextSeqNumpass segment to IP (i.e., “send”)NextSeqNum = NextSeqNum + length(data) if (timer currently not running) start timer data received from application aboveretransmit not-yet-acked segment with smallest seq. #start timertimeoutif (y > SendBase) { SendBase = y /* SendBase–1: last cumulatively ACKed byte */ if (there are currently not-yet-acked segments) start timer else stop timer } ACK received, with ACK field value y

5. Transport Layer3-5TCP: retransmission scenarioslost ACK scenarioHost BHost ASeq=92, 8 bytes of dataACK=100Seq=92, 8 bytes of dataXtimeoutACK=100premature timeoutHost BHost ASeq=92, 8 bytes of dataACK=100Seq=92, 8bytes of datatimeoutACK=120Seq=100, 20 bytes of dataACK=120SendBase=100SendBase=120SendBase=120SendBase=92

6. Transport Layer3-6TCP: retransmission scenariosXcumulative ACKHost BHost ASeq=92, 8 bytes of dataACK=100Seq=120, 15 bytes of datatimeoutSeq=100, 20 bytes of dataACK=120

7. Transport Layer3-7TCP ACK generation [RFC 1122, RFC 2581]event at receiverarrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKedarrival of in-order segment withexpected seq #. One other segment has ACK pendingarrival of out-of-order segmenthigher-than-expect seq. # .Gap detectedarrival of segment that partially or completely fills gapTCP receiver actiondelayed ACK. Wait up to 500msfor next segment. If no next segment,send ACKimmediately send single cumulative ACK, ACKing both in-order segments immediately send duplicate ACK, indicating seq. # of next expected byteimmediate send ACK, provided thatsegment starts at lower end of gap

8. Transport Layer3-8TCP fast retransmittime-out period often relatively long:long delay before resending lost packetdetect lost segments via duplicate ACKs.sender often sends many segments back-to-backif segment is lost, there will likely be many duplicate ACKs.if sender receives 3 ACKs for same data(“triple duplicate ACKs”), resend unacked segment with smallest seq #likely that unacked segment lost, so don’t wait for timeoutTCP fast retransmit(“triple duplicate ACKs”),

9. Transport Layer3-9Xfast retransmit after sender receipt of triple duplicate ACKHost BHost ASeq=92, 8 bytes of dataACK=100timeoutACK=100ACK=100ACK=100TCP fast retransmitSeq=100, 20 bytes of dataSeq=100, 20 bytes of data

10. Transport Layer3-10Chapter 3 outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

11. Transport Layer3-11TCP flow controlapplicationprocessTCP socketreceiver buffersTCPcodeIPcodeapplicationOSreceiver protocol stackapplication may remove data from TCP socket buffers …. … slower than TCP receiver is delivering(sender is sending)from senderreceiver controls sender, so sender won’t overflow receiver’s buffer by transmitting too much, too fastflow control

12. Transport Layer3-12TCP flow controlbuffered datafree buffer spacerwndRcvBufferTCP segment payloadsto application processreceiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segmentsRcvBuffer size set via socket options (typical default is 4096 bytes)many operating systems autoadjust RcvBuffersender limits amount of unacked (“in-flight”) data to receiver’s rwnd value guarantees receive buffer will not overflowreceiver-side buffering

13. Transport Layer3-13Chapter 3 outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

14. Transport Layer3-14Connection Managementbefore exchanging data, sender/receiver “handshake”:agree to establish connection (each knowing the other willing to establish connection)agree on connection parametersconnection state: ESTABconnection variables:seq # client-to-server server-to-clientrcvBuffer size at server,client applicationnetworkconnection state: ESTABconnection Variables:seq # client-to-server server-to-clientrcvBuffer size at server,client applicationnetworkSocket clientSocket = newSocket("hostname","port number");Socket connectionSocket = welcomeSocket.accept();

15. Transport Layer3-15Q: will 2-way handshake always work in network?variable delaysretransmitted messages (e.g. req_conn(x)) due to message lossmessage reorderingcan’t “see” other side2-way handshake:Let’s talkOKESTABESTABchoose xreq_conn(x)ESTABESTABacc_conn(x)Agreeing to establish a connection

16. Transport Layer3-16Agreeing to establish a connection2-way handshake failure scenarios:retransmitreq_conn(x)ESTABreq_conn(x)half open connection!(no client!)client terminatesserverforgets xconnection x completesretransmitreq_conn(x)ESTABreq_conn(x)data(x+1)retransmitdata(x+1)acceptdata(x+1)choose xreq_conn(x)ESTABESTABacc_conn(x)client terminatesESTABchoose xreq_conn(x)ESTABacc_conn(x)data(x+1)acceptdata(x+1)connection x completesserverforgets x

17. Transport Layer3-17TCP 3-way handshakeSYNbit=1, Seq=xchoose init seq num, xsend TCP SYN msgESTABSYNbit=1, Seq=yACKbit=1; ACKnum=x+1choose init seq num, ysend TCP SYNACKmsg, acking SYNACKbit=1, ACKnum=y+1received SYNACK(x) indicates server is live;send ACK for SYNACK;this segment may contain client-to-server datareceived ACK(y) indicates client is liveSYNSENTESTABSYN RCVDclient stateLISTENserver stateLISTEN

18. Transport Layer3-18TCP 3-way handshake: FSMclosedLlistenSYNrcvdSYNsentESTABSocket clientSocket = newSocket("hostname","port number");SYN(seq=x)Socket connectionSocket = welcomeSocket.accept();SYN(x)SYNACK(seq=y,ACKnum=x+1)create new socket for communication back to clientSYNACK(seq=y,ACKnum=x+1)ACK(ACKnum=y+1)ACK(ACKnum=y+1)L

19. Transport Layer3-19TCP: closing a connectionclient, server each close their side of connectionsend TCP segment with FIN bit = 1respond to received FIN with ACKon receiving FIN, ACK can be combined with own FINsimultaneous FIN exchanges can be handled

20. Transport Layer3-20FIN_WAIT_2CLOSE_WAITFINbit=1, seq=yACKbit=1; ACKnum=y+1ACKbit=1; ACKnum=x+1 wait for serverclosecan stillsend datacan no longersend dataLAST_ACKCLOSEDTIMED_WAIT timed wait for 2*max segment lifetimeCLOSEDTCP: closing a connectionFIN_WAIT_1FINbit=1, seq=xcan no longersend but can receive dataclientSocket.close()client stateserver stateESTABESTAB

21. Transport Layer3-21Chapter 3 outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

22. Transport Layer3-22congestion:informally: “too many sources sending too much data too fast for network to handle”different from flow control!manifestations:lost packets (buffer overflow at routers)long delays (queueing in router buffers)a top-10 problem!Principles of congestion control

23. Transport Layer3-23Causes/costs of congestion: scenario 1 two senders, two receiversone router, infinite buffers output link capacity: Rno retransmissionmaximum per-connection throughput: R/2unlimited shared output link buffersHost Aoriginal data: lin Host Bthroughput: loutR/2R/2loutlinR/2delaylinlarge delays as arrival rate, lin, approaches capacity

24. Transport Layer3-24one router, finite buffers sender retransmission of timed-out packetapplication-layer input = application-layer output: lin = louttransport-layer input includes retransmissions : lin linfinite shared output link buffersHost Alin : original dataHost Bloutl'in: original data, plus retransmitted data‘Causes/costs of congestion: scenario 2

25. Transport Layer3-25idealization: perfect knowledgesender sends only when router buffers available finite shared output link bufferslin : original dataloutl'in: original data, plus retransmitted datacopyfree buffer space!R/2R/2loutlinCauses/costs of congestion: scenario 2 Host BA

26. Transport Layer3-26lin : original dataloutl'in: original data, plus retransmitted datacopyno buffer space!Idealization: known loss packets can be lost, dropped at router due to full bufferssender only resends if packet known to be lostCauses/costs of congestion: scenario 2 AHost B

27. Transport Layer3-27lin : original dataloutl'in: original data, plus retransmitted datafree buffer space!Causes/costs of congestion: scenario 2 Idealization: known loss packets can be lost, dropped at router due to full bufferssender only resends if packet known to be lostR/2R/2linloutwhen sending at R/2, some packets are retransmissions but asymptotic goodput is still R/2 (why?)AHost B

28. Transport Layer3-28Alinloutl'incopyfree buffer space!timeoutR/2R/2linloutwhen sending at R/2, some packets are retransmissions including duplicated that are delivered!Host BRealistic: duplicates packets can be lost, dropped at router due to full bufferssender times out prematurely, sending two copies, both of which are deliveredCauses/costs of congestion: scenario 2

29. Transport Layer3-29R/2loutwhen sending at R/2, some packets are retransmissions including duplicated that are delivered!“costs” of congestion: more work (retrans) for given “goodput”unneeded retransmissions: link carries multiple copies of pktdecreasing goodputR/2linCauses/costs of congestion: scenario 2 Realistic: duplicates packets can be lost, dropped at router due to full bufferssender times out prematurely, sending two copies, both of which are delivered

30. Transport Layer3-30four sendersmultihop pathstimeout/retransmitQ: what happens as lin and lin’ increase ?finite shared output link buffersHost AloutCauses/costs of congestion: scenario 3 Host BHost CHost Dlin : original datal'in: original data, plus retransmitted dataA: as red lin’ increases, all arriving blue pkts at upper queue are dropped, blue throughput g 0

31. Transport Layer3-31another “cost” of congestion: when packet dropped, any “upstream transmission capacity used for that packet was wasted!Causes/costs of congestion: scenario 3 C/2C/2loutlin’

32. Transport Layer3-32Approaches towards congestion controltwo broad approaches towards congestion control:end-end congestion control:no explicit feedback from networkcongestion inferred from end-system observed loss, delayapproach taken by TCPnetwork-assisted congestion control:routers provide feedback to end systemssingle bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM)explicit rate for sender to send at

33. Transport Layer3-33Case study: ATM ABR congestion controlABR: available bit rate:“elastic service” if sender’s path “underloaded”: sender should use available bandwidthif sender’s path congested: sender throttled to minimum guaranteed rateRM (resource management) cells:sent by sender, interspersed with data cellsbits in RM cell set by switches (“network-assisted”) NI bit: no increase in rate (mild congestion)CI bit: congestion indicationRM cells returned to sender by receiver, with bits intact

34. Transport Layer3-34Case study: ATM ABR congestion controltwo-byte ER (explicit rate) field in RM cellcongested switch may lower ER value in cellsenders’ send rate thus max supportable rate on pathEFCI bit in data cells: set to 1 in congested switchif data cell preceding RM cell has EFCI set, receiver sets CI bit in returned RM cellRM celldata cell

35. Transport Layer3-35Chapter 3 outline3.1 transport-layer services3.2 multiplexing and demultiplexing3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 principles of congestion control3.7 TCP congestion control

36. Transport Layer3-36TCP congestion control: additive increase multiplicative decreaseapproach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occursadditive increase: increase cwnd by 1 MSS every RTT until loss detectedmultiplicative decrease: cut cwnd in half after loss cwnd: TCP sender congestion window sizeAIMD saw toothbehavior: probingfor bandwidthadditively increase window size ……. until loss occurs (then cut window in half)time

37. Transport Layer3-37TCP Congestion Control: detailssender limits transmission:cwnd is dynamic, function of perceived network congestionTCP sending rate:roughly: send cwnd bytes, wait RTT for ACKS, then send more byteslast byteACKedsent, not-yet ACKed(“in-flight”)last byte sentcwndLastByteSent- LastByteAcked<cwndsender sequence number space rate~~cwndRTTbytes/sec

38. Transport Layer3-38TCP Slow Start when connection begins, increase rate exponentially until first loss event:initially cwnd = 1 MSSdouble cwnd every RTTdone by incrementing cwnd for every ACK receivedsummary: initial rate is slow but ramps up exponentially fastHost Aone segmentRTTHost Btimetwo segmentsfour segments

39. Transport Layer3-39TCP: detecting, reacting to lossloss indicated by timeout:cwnd set to 1 MSS; window then grows exponentially (as in slow start) to threshold, then grows linearlyloss indicated by 3 duplicate ACKs: TCP RENOdup ACKs indicate network capable of delivering some segments cwnd is cut in half window then grows linearlyTCP Tahoe always sets cwnd to 1 (timeout or 3 duplicate acks)

40. Transport Layer3-40Q: when should the exponential increase switch to linear? A: when cwnd gets to 1/2 of its value before timeout. Implementation:variable ssthresh on loss event, ssthresh is set to 1/2 of cwnd just before loss eventTCP: switching from slow start to CA

41. Transport Layer3-41Summary: TCP Congestion Controltimeoutssthresh = cwnd/2cwnd = 1 MSSdupACKcount = 0retransmit missing segment Lcwnd > ssthreshcongestionavoidance cwnd = cwnd + MSS (MSS/cwnd)dupACKcount = 0transmit new segment(s), as allowednew ACK.dupACKcount++duplicate ACK fastrecovery cwnd = cwnd + MSStransmit new segment(s), as allowedduplicate ACKssthresh= cwnd/2cwnd = ssthresh + 3retransmit missing segmentdupACKcount == 3timeoutssthresh = cwnd/2cwnd = 1 dupACKcount = 0retransmit missing segment ssthresh= cwnd/2cwnd = ssthresh + 3retransmit missing segmentdupACKcount == 3cwnd = ssthreshdupACKcount = 0New ACKslow starttimeoutssthresh = cwnd/2 cwnd = 1 MSSdupACKcount = 0retransmit missing segment cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s), as allowednew ACKdupACKcount++duplicate ACKLcwnd = 1 MSSssthresh = 64 KBdupACKcount = 0NewACK!NewACK!NewACK!

42. Transport Layer3-42TCP throughputavg. TCP thruput as function of window size, RTT?ignore slow start, assume always data to sendW: window size (measured in bytes) where loss occursavg. window size (# in-flight bytes) is ¾ Wavg. thruput is 3/4W per RTTWW/2avg TCP thruput = 34WRTTbytes/sec

43. Transport Layer3-43TCP Futures: TCP over “long, fat pipes”example: 1500 byte segments, 100ms RTT, want 10 Gbps throughputrequires W = 83,333 in-flight segmentsthroughput in terms of segment loss probability, L [Mathis 1997]:➜ to achieve 10 Gbps throughput, need a loss rate of L = 2·10-10 – a very small loss rate!new versions of TCP for high-speedTCP throughput = 1.22.MSSRTTL

44. Transport Layer3-44fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/KTCP connection 1bottleneckroutercapacity RTCP FairnessTCP connection 2

45. Transport Layer3-45Why is TCP fair?two competing sessions:additive increase gives slope of 1, as throughout increasesmultiplicative decrease decreases throughput proportionally RRequal bandwidth shareConnection 1 throughputConnection 2 throughputcongestion avoidance: additive increaseloss: decrease window by factor of 2congestion avoidance: additive increaseloss: decrease window by factor of 2

46. Transport Layer3-46Fairness (more)Fairness and UDPmultimedia apps often do not use TCPdo not want rate throttled by congestion controlinstead use UDP:send audio/video at constant rate, tolerate packet lossFairness, parallel TCP connectionsapplication can open multiple parallel connections between two hostsweb browsers do this e.g., link of rate R with 9 existing connections:new app asks for 1 TCP, gets rate R/10new app asks for 11 TCPs, gets R/2

47. Transport Layer3-47Chapter 3: summaryprinciples behind transport layer services:multiplexing, demultiplexingreliable data transferflow controlcongestion controlinstantiation, implementation in the InternetUDPTCPnext:leaving the network “edge” (application, transport layers)into the network “core”