Movatterモバイル変換

Transport Layer Transport-layer services Multiplexing and demultiplexing Connectionless transport: UDP Principles of reliable data transfer Connection-oriented transport: TCP Principles of congestion control TCP congestion control Evolution of transport-layer functionalityCOMPSCI 453 Computer NetworksProfessor Jim KuroseCollege of Information and Computer SciencesUniversity of MassachusettsClass textbook:Computer Networking: A Top-Down Approach (8thed.)J.F. Kurose, K.W. RossPearson, 2020http://gaia.cs.umass.edu/kurose_ross

TCP: overview RFCs: 793,1122, 2018, 5681, 7323 cumulative ACKs pipelining:• TCP congestion and flow controlset window size connection-oriented:• handshaking (exchange of controlmessages) initializes sender,receiver state before data exchange flow controlled:• sender will not overwhelm receiver point-to-point:• one sender, one receiver reliable, in-order bytesteam:• no “message boundaries" full duplex data:• bi-directional data flow insame connection• MSS: maximum segment size

2. Reliable, In-Order ByteStream TCP provides:1. Reliable delivery:If a packet is lost or corrupted, TCP retransmits it.2. In-order delivery:Even if packets arrive out of order, TCP reorders thembefore delivering to the application.3. Byte stream:TCP treats all the data as one long stream of bytes, likethis: HELLO WORLD example.Each byte has a sequence number (used forreliability and ordering).So TCP is managing this long “stream of bytes,” notseparate packets.Transport Layer: 3-31. Point-to-PointTCP is point-to-point,meaning:One connection has exactlyone sender and one receiver.Example:When your browser connectsto a web serverthat’s one TCP connectionbetween your computer andthat server.(Unlike UDP, TCP doesn’t doone-to-many or broadcastcommunication.)ByteNumber1 2 3 4 5 6 7 ...Data H E L L O W ...

 4. MSS — Maximum SegmentSize MSS means Maximum SegmentSize — the largest chunk of data(in bytes) that TCP can send inone segment. Typical MSS ≈ 1460 bytes (forEthernet, since total frame =1500 bytes). Example:If MSS = 1000 bytes → TCPsends at most 1000 bytes ofuser data per segment.Transport Layer: 3-4 3. Full Duplex Data TCP allows full duplexcommunication — datacan flow in both directionssimultaneously. Example:While your browser issending a request to aweb server, the server canalso start sending databack at the same time.

6. Pipelining TCP allows multiple packets tobe sent before receiving anACK (unlike Stop-and-Wait).This improves efficiency. The number ofunacknowledged packets thatcan be in flight depends on thewindow size (defined by flowcontrol and congestion control).Transport Layer: 3-55. CumulativeAcknowledgments (ACKs)TCP uses cumulative ACKs,which means:The ACK number representsthe next byte expected by thereceiver.Example:If the receiver has receivedbytes 1–500, it will send ACK= 501,meaning “I got everything upto 500, now send me from501.”If packet 501–600 is lost, itkeeps sending ACK = 501 untilit gets that data.

8. Congestion Control (Network Side) Congestion control prevents thenetwork (not just the receiver) fromgetting overloaded.TCP automatically slows down whenit detects congestion. Main algorithms:• Slow Start• Congestion Avoidance• Fast Retransmit• Fast Recovery These help maintain fairness andstability in the Internet.Transport Layer: 3-67. Flow Control (Receiver Side) Flow control ensures thesender doesn’t overwhelmthe receiver. The receiver tells the senderhow much data it can handle— this is called the ReceiveWindow (rwnd). Example:If rwnd = 4000 bytes → sendercan send 4000 bytes totalbefore waiting for an ACK. This prevents the receiver’sbuffer from overflowing.

10. Flow Controlled Thesender will not overwhelm thereceiver.TCP adjusts its sending ratebased on:•Receiver’s buffer capacity(flow control)•Network congestion(congestion control)That’s why TCP is often called“reliable and self-adjusting.”Transport Layer: 3-7 9. Connection-Oriented(Handshake) TCP is connection-oriented,meaning it establishes aconnection before sendingdata.This is done using a 3-wayhandshake:1.SYN: Sender requestsconnection2.SYN-ACK: Receiver agrees3.ACK: Sender confirms After this, both sides are readyto exchange data.This handshake initializessequence numbers, buffers,and states.

TCP segment structuresource port # dest port #32 bitsnotused receive window flow control: # bytesreceiver willing to acceptsequence numbersegment seq #: countingbytes of data into bytestream(not segments!)applicationdata(variable length)data sent byapplication intoTCP socketAacknowledgement numberACK: seq # of next expectedbyte; A bit: this is an ACKoptions (variablelength)TCP optionsheadlenlength (of TCP header)checksumInternet checksumRST, SYN, FIN: connectionmanagementFSRUrg data pointerPUC EC, E: congestion notification

TCP sequence numbers, ACKsSequence numbers:• byte stream “number” offirst byte in segment’s datasource port # dest port #sequence numberacknowledgement numberchecksumrwndurg pointeroutgoing segment from receiverAsentACKedsent, not-yet ACKed(“in-flight”)usablebut notyet sentnotusablewindow sizeNsender sequence number spacesource port # dest port #sequence numberacknowledgement numberchecksumrwndurg pointeroutgoing segment from senderAcknowledgements:• seq # of next byte expectedfrom other side• cumulative ACK

TCP sequence numbers, ACKshost ACKs receiptof echoed ‘C’host ACKs receipt of‘C’,echoes back ‘C’simple telnet scenarioHost BHost AUser types‘C’Seq=42, ACK=79, data = ‘C’Seq=79, ACK=43, data = ‘C’Seq=43, ACK=80

TCP round trip time, timeoutQ: how to set TCP timeoutvalue? longer than RTT, but RTT varies! too short: premature timeout,unnecessary retransmissions too long: slow reaction tosegment lossQ: how to estimate RTT? SampleRTT:measured timefrom segment transmission untilACK receipt• ignore retransmissions SampleRTT will vary, wantestimated RTT “smoother”• average several recentmeasurements, not just currentSampleRTT

TCP round trip time, timeoutEstimatedRTT = (1- )*EstimatedRTT + *SampleRTT exponential weighted moving average (EWMA) influence of past sample decreases exponentially fast typical value:  = 0.125RTT: gaia.cs.umass.edu to fantasia.eurecom.fr1001502002503003501 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106time (seconnds)RTT(milliseconds)SampleRTT Estimated RTTRTT(milliseconds)RTT: gaia.cs.umass.edu to fantasia.eurecom.frsampleRTTEstimatedRTTtime(seconds)

TCP round trip time, timeout timeout interval: EstimatedRTT plus “safety margin”• large variation in EstimatedRTT: want a larger safety marginTimeoutInterval = EstimatedRTT + 4*DevRTTestimated RTT “safety margin”* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|(typically,  = 0.25) DevRTT: EWMA of SampleRTT deviation from EstimatedRTT:

TCP Sender (works based on events)event: data received from application•The application (like a browser or email app) givesdata to TCP to send.•TCP creates a segment (packet) to send that data.•TCP adds a sequence number (seq#) →This number shows the byte number of the firstbyte of data in that segment.(So, it helps the receiver keep everything in order.)•TCP starts a timer — but only if it’s not alreadyrunning.•The timer is for the oldest segment that has beensent but not yet acknowledged (ACKed).•The TimeOutInterval is the time TCP waits for anACK before it decides to retransmit.event: timeout• If the timer runs out (no ACK receivedin time), TCP assumes the segment islost.•It retransmits that segment — theone that caused the timeout.•Then it restarts the timer again.event: ACK received•The receiver sends an ACK to confirm it receiveddata.•When the sender gets this ACK, it checks:•Does this ACK cover (acknowledge) any data thatwas still unacknowledged?If yes those segments are now considered→successfully delivered.•TCP then updates its record of which bytes havebeen acknowledged.•If there are still some unacknowledgedsegments, TCP keeps the timer running (orrestarts it).•If everything is acknowledged, it stops the timer.

TCP Receiver: ACK generation [RFC 5681]Event at receiverarrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKedarrival of in-order segment withexpected seq #. One othersegment has ACK pendingarrival of out-of-order segmenthigher-than-expect seq. # .Gap detectedarrival of segment thatpartially or completely fills gapTCP receiver actiondelayed ACK. Wait up to 500msfor next segment. If no next segment,send ACKimmediately send single cumulativeACK, ACKing both in-order segmentsimmediately send duplicate ACK,indicating seq. # of next expected byteimmediate send ACK, provided thatsegment starts at lower end of gap

TCP: retransmission scenarioslost ACK scenarioHost BHost ASeq=92, 8 bytes of dataSeq=92, 8 bytes of dataACK=100XACK=100timeoutpremature timeoutHost BHost ASeq=92, 8bytes of dataACK=120timeoutACK=100ACK=120SendBase=100SendBase=120SendBase=120Seq=92, 8 bytes of dataSeq=100, 20 bytes of dataSendBase=92send cumulativeACK for 120

TCP: retransmission scenarioscumulative ACKcovers for earlier lostACKHost BHost ASeq=92, 8 bytes of dataSeq=120, 15 bytes of dataSeq=100, 20 bytes of dataXACK=100ACK=120

TCP fast retransmitHost BHost AtimeoutACK=100ACK=100ACK=100ACK=100XSeq=92, 8 bytes of dataSeq=100, 20 bytes ofdataSeq=100, 20 bytes of dataReceipt of three duplicate ACKsindicates 3 segments receivedafter a missing segment – lostsegment is likely. So retransmit!if sender receives 3 ACKs forsame data (“triple duplicateACKs”), resend unACKedsegment with smallest seq # likely that unACKed segmentlost, so don’t wait for timeoutTCP fast retransmit

TCP flow controlapplicationprocessTCP socketreceiver buffersTCPcodeIPcodereceiver protocol stackQ: What happens if networklayer delivers data faster thanapplication layer removesdata from socket buffers?Network layerdelivering IP datagrampayload into TCPsocket buffersfrom senderApplication removingdata from TCP socketbuffers

TCP flow controlapplicationprocessTCP socketreceiver buffersTCPcodeIPcodereceiver protocol stackQ: What happens if networklayer delivers data faster thanapplication layer removesdata from socket buffers?from senderApplication removingdata from TCP socketbuffersreceive windowflow control: # bytesreceiver willing to accept

TCP flow controlapplicationprocessTCP socketreceiver buffersTCPcodeIPcodereceiver protocol stackQ: What happens if networklayer delivers data faster thanapplication layer removesdata from socket buffers?receiver controls sender, sosender won’t overflowreceiver’s buffer bytransmitting too much, too fastflow controlfrom senderApplication removingdata from TCP socketbuffers

TCP flow control TCP receiver “advertises” free bufferspace in rwnd field in TCP header• RcvBuffer size set via socketoptions (typical default is 4096 bytes)• many operating systems autoadjustRcvBuffer sender limits amount of unACKed(“in-flight”) data to received rwnd guarantees receive buffer will notoverflowbuffered datafree buffer spacerwndRcvBufferTCP segment payloadsto application processTCP receiver-side buffering

TCP flow control TCP receiver “advertises” free bufferspace in rwnd field in TCP header• RcvBuffer size set via socketoptions (typical default is 4096 bytes)• many operating systems autoadjustRcvBuffer sender limits amount of unACKed(“in-flight”) data to received rwnd guarantees receive buffer will notoverflowflow control: # bytes receiver willing to acceptreceive windowTCP segment format

TCP connection managementbefore exchanging data, sender/receiver “handshake”: agree to establish connection (each knowing the other willing to establish connection) agree on connection parameters (e.g., starting seq #s)connection state: ESTABconnection variables:seq # client-to-serverserver-to-clientrcvBuffer sizeat server,clientapplicationnetworkconnection state: ESTABconnection Variables:seq # client-to-serverserver-to-clientrcvBuffer sizeat server,clientapplicationnetworkSocket clientSocket =newSocket("hostname","port number");Socket connectionSocket =welcomeSocket.accept();

Agreeing to establish a connectionQ: will 2-way handshake alwayswork in network? variable delays retransmitted messages (e.g.req_conn(x)) due to message loss message reordering can’t “see” other side2-way handshake:Let’s talkOKESTABESTABchoose xreq_conn(x)ESTABESTABacc_conn(x)

2-way handshake scenariosconnectionx completeschoose xreq_conn(x)ESTABESTABacc_conn(x)data(x+1) acceptdata(x+1)ACK(x+1)No problem!

2-way handshake scenariosESTABretransmitreq_conn(x)req_conn(x)clientterminatesserverforgets xconnectionx completeschoose xreq_conn(x)ESTABESTABacc_conn(x)acc_conn(x)Problem: half openconnection! (no client)

2-way handshake scenariosclientterminatesESTABchoose xreq_conn(x)ESTABacc_conn(x)data(x+1) acceptdata(x+1)connectionx completes serverforgets xProblem: dup dataaccepted!data(x+1)retransmitdata(x+1)acceptdata(x+1)retransmitreq_conn(x)ESTABreq_conn(x)

TCP 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 containclient-to-server datareceived ACK(y)indicates client is liveSYNSENTESTABSYN RCVDClient stateLISTENServer stateLISTENclientSocket = socket(AF_INET, SOCK_STREAM)serverSocket = socket(AF_INET,SOCK_STREAM)serverSocket.bind((‘’,serverPort))serverSocket.listen(1)connectionSocket, addr = serverSocket.accept()clientSocket.connect((serverName,serverPort))

A human 3-way handshake protocol1. On belay?2. Belay on.3. Climbing.

Closing a TCP connection client, server each close their side of connection• send TCP segment with FIN bit = 1 respond to received FIN with ACK• on receiving FIN, ACK can be combined with own FIN simultaneous FIN exchanges can be handled

Transport Layer Transport-layer services Multiplexing and demultiplexing Connectionless transport: UDP Principles of reliable data transfer Connection-oriented transport: TCP Principles of congestion control TCP congestion control Evolution of transport-layer functionalityCOMPSCI 453 Computer NetworksProfessor Jim KuroseCollege of Information and Computer SciencesUniversity of MassachusettsClass textbook:Computer Networking: A Top-Down Approach (8thed.)J.F. Kurose, K.W. RossPearson, 2020http://gaia.cs.umass.edu/kurose_rossVideo: 2020, J.F. Kurose, All Rights ReservedPowerpoint: 1996-2020, J.F. Kurose, K.W. Ross, All Rights Reserved

TCP: Transport Control Protocol segment structure reliable data transfer sequence numbers ACKs timers

TCP sender (simplified)Transport Layer: 3-35waitforeventNextSeqNum = InitialSeqNumSendBase = InitialSeqNumLretransmit not-yet-ackedsegment with smallestseq. #start timertimeoutif (y > SendBase) {SendBase = y/* SendBase–1: last cumulatively ACKed byte */if (there are currently not-yet-acked segments)start timerelse stop timer}ACK received, with ACK field value ycreate segment, seq. #: NextSeqNumpass segment to IP (i.e., “send”)NextSeqNum = NextSeqNum + length(data)if (timer currently not running)start timerdata received from application above

Movatterモバイル変換

Change Language

3.5_TCP_video_slides_discover_rdt_protocol.pptx

Embed presentation

Recommended

More Related Content

Similar to 3.5_TCP_video_slides_discover_rdt_protocol.pptx

Recently uploaded

3.5_TCP_video_slides_discover_rdt_protocol.pptx

Editor's Notes