reliable byte stream tcp
play

ReliableByte-Stream(TCP) Outline - PDF document

ReliableByte-Stream(TCP) Outline ConnectionEstablishment/Termination SlidingWindowRevisited FlowControl AdaptiveTimeout Spring2002 CS461 1 End-to-EndProtocols Underlyingbest-effortnetwork


  1. Reliable�Byte-Stream�(TCP) Outline Connection�Establishment/Termination Sliding�Window�Revisited� Flow�Control Adaptive�Timeout Spring�2002 CS�461 1 End-to-End�Protocols • Underlying�best-effort�network – drop�messages – re-orders�messages – delivers�duplicate�copies�of�a�given�message – limits�messages�to�some�finite�size – delivers�messages�after�an�arbitrarily�long�delay • Common�end-to-end�services – guarantee�message�delivery – deliver�messages�in�the�same�order�they�are�sent – deliver�at�most�one�copy�of�each�message – support�arbitrarily�large�messages – support�synchronization – allow�the�receiver�to�flow�control�the�sender – support�multiple�application�processes�on�each�host Spring�2002 CS�461 2 Simple�Demultiplexor�(UDP) • Unreliable�and�unordered�datagram�service • Adds�multiplexing • No�flow�control • Endpoints�identified�by�ports – servers�have� well-known ports – see� /etc/services on�Unix 0 16 31 • Header�format SrcPort DstPort Checksum Length Data • Optional�checksum – psuedo�header�+�UDP�header�+�data Spring�2002 CS�461 3 1

  2. TCP�Overview • Connection-oriented • Full�duplex • Byte-stream • Flow�control:�keep�sender� from�overrunning�receiver – app�writes�bytes – TCP�sends� segments • Congestion�control:�keep� – app�reads�bytes sender�from�overrunning� network Application�process Application�process Write Read … bytes … bytes TCP TCP Send�buffer Receive�buffer … Segment Segment Segment Transmit�segments Spring�2002 CS�461 4 Data�Link�Versus�Transport • Potentially�connects�many�different�hosts – need�explicit�connection�establishment�and�termination� • Potentially�different�RTT – need�adaptive�timeout�mechanism • Potentially�long�delay�in�network – need�to�be�prepared�for�arrival�of�very�old�packets • Potentially�different�capacity�at�destination� – need�to�accommodate�different�node�capacity • Potentially�different�network�capacity – need�to�be�prepared�for�network�congestion Spring�2002 CS�461 5 Segment�Format 0 4 10 16 31 SrcPort DstPort SequenceNum Acknowledgment HdrLen 0 Flags AdvertisedWindow Checksum UrgPtr Options�(variable) Data Spring�2002 CS�461 6 2

  3. Segment�Format�(cont) • Each�connection�identified�with�4-tuple: – (SrcPort,�SrcIPAddr,�DsrPort,�DstIPAddr) • Sliding�window�+�flow�control – acknowledgment,�SequenceNum,�AdvertisedWinow Data� (SequenceNum) Sender Receiver Acknowledgment�+ AdvertisedWindow • Flags – SYN,�FIN,�RESET,�PUSH,�URG,�ACK • Checksum – pseudo�header�+�TCP�header�+�data Spring�2002 CS�461 7 Connection�Establishment�and� Termination Active�participant Passive�participant (client) (server) SYN,�SequenceNum�=�x � y , � = m N u e n c e 1 q u + � e x S = � K , � t � C n A m e + � g N � d Y l e S w n o k A c ACK,�Acknowledgment�=�y +�1 Spring�2002 CS�461 8 State�Transition�Diagram CLOSED Active�open/SYN Passive�open Close Close LISTEN SYN/SYN�+�ACK Send/SYN SYN/SYN�+�ACK SYN_RCVD SYN_SENT ACK SYN�+�ACK/ACK Close/FIN ESTABLISHED Close/FIN FIN/ACK FIN_WAIT_1 CLOSE_WAIT FIN/ACK ACK�+�FIN/ACK ACK Close/FIN FIN_WAIT_2 CLOSING LAST_ACK Timeout�after�two� ACK ACK segment�lifetimes FIN/ACK TIME_WAIT CLOSED Spring�2002 CS�461 9 3

  4. Sliding�Window�Revisited Sending�application Receiving�application TCP TCP LastByteWritten LastByteRead LastByteAcked LastByteSent NextByteExpected LastByteRcvd • Sending�side • Receiving�side – LastByteAcked <�= – LastByteRead <� LastByteSent NextByteExpected – LastByteSent <�= – NextByteExpected <�= LastByteWritten LastByteRcvd�+1 – buffer�bytes�between� – buffer�bytes�between� LastByteAcked and� NextByteRead and� LastByteWritten LastByteRcvd Spring�2002 CS�461 10 Flow�Control • Send�buffer�size:� MaxSendBuffer • Receive�buffer�size:� MaxRcvBuffer • Receiving�side – LastByteRcvd - LastByteRead <�=� MaxRcvBuffer – AdvertisedWindow =� MaxRcvBuffer - ( NextByteExpected - NextByteRead ) • Sending�side – LastByteSent - LastByteAcked <�=� AdvertisedWindow – EffectiveWindow =� AdvertisedWindow - ( LastByteSent - LastByteAcked ) – LastByteWritten - LastByteAcked <�=� MaxSendBuffer – block�sender�if�( LastByteWritten - LastByteAcked )�+� y >� MaxSenderBuffer • Always�send�ACK�in�response�to�arriving�data�segment • Persist�when� AdvertisedWindow =�0 Spring�2002 CS�461 11 Silly�Window�Syndrome • How�aggressively�does�sender�exploit�open�window? Sender Receiver • Receiver-side�solutions – after�advertising�zero�window,�wait�for�space�equal�to�a� maximum�segment�size�(MSS) – delayed�acknowledgements Spring�2002 CS�461 12 4

  5. Nagle’s�Algorithm • How�long�does�sender�delay�sending�data? – too�long:�hurts�interactive�applications – too�short:�poor�network�utilization – strategies:�timer-based�vs�self-clocking • When�application�generates�additional�data – if�fills�a�max�segment�(and�window�open):�send�it – else • if�there�is�unack’ed�data�in�transit:�buffer�it�until�ACK�arrives • else:�send�it Spring�2002 CS�461 13 Protection�Against�Wrap�Around • 32-bit� SequenceNum Bandwidth Time�Until�Wrap�Around T1�(1.5�Mbps) 6.4�hours Ethernet�(10�Mbps) 57�minutes T3�(45�Mbps) 13�minutes FDDI�(100�Mbps) 6�minutes STS-3�(155�Mbps) 4�minutes STS-12�(622�Mbps) 55�seconds STS-24�(1.2�Gbps) 28�seconds Spring�2002 CS�461 14 Keeping�the�Pipe�Full • 16-bit� AdvertisedWindow Bandwidth Delay�x�Bandwidth�Product T1�(1.5�Mbps) 18KB Ethernet�(10�Mbps) 122KB T3�(45�Mbps) 549KB FDDI�(100�Mbps) 1.2MB STS-3�(155�Mbps) 1.8MB STS-12�(622�Mbps) 7.4MB STS-24�(1.2 Gbps) 14.8MB assuming�100ms�RTT Spring�2002 CS�461 15 5

  6. TCP�Extensions • Implemented�as�header�options • Store�timestamp�in�outgoing�segments • Extend�sequence�space�with��32-bit�timestamp� (PAWS) • Shift�(scale)�advertised�window Spring�2002 CS�461 16 Adaptive�Retransmission (Original�Algorithm) • Measure� SampleRTT for�each�segment�/�ACK�pair • Compute�weighted�average�of�RTT – EstRTT =� α x EstRTT +� β x SampleRTT – where� α + β =�1 − α between�0.8�and�0.9 − β between�0.1�and�0.2 • Set�timeout�based�on� EstRTT – TimeOut = 2 x EstRTT Spring�2002 CS�461 17 Karn/Partridge�Algorithm Sender Receiver Sender Receiver O r O i g r i g i n a i n l � a t r a l � t n s r a n m s i s m s i i s s o n i o n SampleR TT SampleR TT R e ACK t r a n s m i s s i o n R e t r a n s m i s s i o n ACK • Do�not�sample�RTT�when�retransmitting� • Double�timeout�after�each�retransmission� Spring�2002 CS�461 18 6

  7. Jacobson/�Karels�Algorithm • New�Calculations�for�average�RTT • Diff =� SampleRTT - EstRTT • EstRTT =�EstRTT +�( δ δ x Diff) δ δ • Dev�=�Dev�+� δ δ δ δ (�|Diff|�- Dev) – where� δ is�a�factor�between�0�and�1 • Consider�variance�when�setting�timeout�value • TimeOut =� µ x EstRTT +� φ x Dev – where� µ =�1�and� φ =�4 • Notes – algorithm�only�as�good�as�granularity�of�clock�(500ms�on�Unix) – accurate�timeout�mechanism�important�to�congestion�control�(later) Spring�2002 CS�461 19 7

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend