La couche transport dans l'internet (la suite TCP/IP) C. Pham RESO-LIP/INRIA Université Lyon 1 http://www.ens-lyon.fr/~cpham Basé sur les transparent de Shivkumar Kalyanaraman
La couche transport dans l'internet La couche Transport (couche 4) est composé de 2 protocoles: TCP (RFC 793) et UDP (RFC 768) TCP mode connecté fiable contrôle de la congestion sélection sur le champ protocol du packet IP UDP TCP ICMP UDP mode datagramme non fiable IP data Cours de C. Pham, Univ. Lyon 1
Ports standards Cours de C. Pham, Univ. Lyon 1 SMTP: 25, HTTP: 80, Telnet: 23 FTP control: 20, FTP transfer: 21 DNS: 53
UDP checksum Goal: detect errors (e.g., flipped bits) in transmitted segment Sender: treat segment contents as sequence of 16-bit integers checksum: addition (1 s complement sum) of segment contents sender puts checksum value into UDP checksum field In reality some IP header fields are included w/ the UDP segment for checksumming. Receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonetheless? More in chap 5 on stronger error detection methods Cours de C. Pham, Univ. Lyon 1
UDP Checksum Example Consider three 16-bit words: 0110011001100110 0101010101010101 0000111100001111 (1 s complement) sum of first two 16-bit words is: 1011101110111011 Adding the third word to the above sum gives: 1100101011001010 1 s complement of this sum => invert 0 s and 1 s 0011010100110101 (this is the checksum field) If no errors, sum of all four 16-bit words (incl. Checksum) will be all 1s, I.e., 1111111111111111 Cours de C. Pham, Univ. Lyon 1
TCP: scenarios de retransmission Host A Host B Host A Host B t imeout Seq=92, 8 bytes data X loss ACK=100 Seq=92, 8 bytes data Seq=100 t imeout Seq=92 t imeout Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=100 ACK=120 Seq=92, 8 bytes data ACK=100 ACK=120 time ACK perdu Cours de C. Pham, Univ. Lyon 1 time timeout prématuré, ACKs cumulés
TCP Window Flow Control: Coté émetteur fenêtre Envoyés et accusés Envoyés mais pas accusés Pas encore envoyé Prochain à envoyer Cours de C. Pham, Univ. Lyon 1
Window Flow Control: Coté récepteur Source Port Port Packet Sent Dest. Dest. Port Port Sequence Number Acknowledgment HL/Flags Window D. D. Checksum Urgent Urgent Pointer Options.. Packet Received Source Port Port Dest. Dest. Port Port Sequence Number Acknowledgment HL/Flags Window D. D. Checksum Urgent Urgent Pointer Options.. App write acknowledged sent to be sentoutside window Cours de C. Pham, Univ. Lyon 1
How to estimate RTT? RTT = prop + queuing delay Queuing delay highly variable So, different samples of RTTs will give different random values of queuing delay Q: how to estimate RTT? SampleRTT (M): measured time from segment transmission until ACK receipt M will vary wildly use several recent measurements, not just current SampleRTT to calculate "AverageRTT" (A) A (1-x)*A + x*m and then set RTO=Rβ, x=0.1 (old version) Cours de C. Pham, Univ. Lyon 1 slide modified by C. Pham
Round Trip Time and Timeout (II) New version (Jacobson, 1988) constant multiple of the mean is not good better use mean and variance Setting the RTO timeout Err=M-A A A+gErr, g=1/8 D D+h( Err -D), h=1/4 RTO = A+ 4D In 1988, Jacobson specified 2D, but corrected it into 4D in 1990 Cours de C. Pham, Univ. Lyon 1 slide added by C. Pham Example A=0, D=3s and RTO=A+2D initially. So RTO 1 =6s If M=1.5s for 1st segment Err=1.5-0=1.5 A=0+O.125*1.5=O.1875 D=3+0.25( 1.5-3)=2.625 RTO 2 =0.1875+4*2.625=10.6875
Timer Granularity Many TCP implementations set RTO in multiples of 200,500 or 1000ms Why? Avoid spurious timeouts RTTs can vary quickly due to cross traffic Delayed-ack timer can delay valid acks by up to 200ms Make timers interrupts efficient What happens for the first couple of packets? Pick a very conservative value (seconds) Can lead to stall if early packet lost Cours de C. Pham, Univ. Lyon 1
connection establisment Client Server Client request connection SYN 1415531521:145531521(0) mss<1024> SYN 1823083521:1823083521(0) ACK 1415531522, mss(1024> serveracks receipt of SYN, sends back SYNACK client ACKs receipt of SYNACK ACK 1823083522 Trace obtained with tcpdump showing seq#:implied_seq#(ndata) Cours de C. Pham, Univ. Lyon 1 slide added by C. Pham
Evolutions de TCP 1975 Three-way handshake Raymond Tomlinson In SIGCOMM 75 1974 TCP described by Vint Cerf and Bob Kahn In IEEE Trans Comm 1982 TCP & IP RFC 793 & 791 1983 BSD Unix 4.2 supports TCP/IP 1984 Nagel s algorithm to reduce overhead of small packets; predicts congestion collapse 1986 Congestion collapse observed 1987 Karn s algorithm to better estimate round-trip time 1988 Van Jacobson s algorithms congestion avoidance and congestion control (most implemented in 4.3BSD Tahoe) 1990 4.3BSD Reno fast retransmit delayed ACK s 1975 1980 1985 1990
TCP dans les années 1990s 1994 T/TCP (Braden) Transaction TCP 1996 SACK TCP (Floyd et al) Selective Acknowledgement 1993 TCP Vegas (Brakmo et al) real congestion avoidance 1994 ECN (Floyd) Explicit Congestion Notification 1996 Hoe Improving TCP startup 1996 FACK TCP (Mathis et al) extension to SACK 1993 1994 1996
This document was created with Win2PDF available at http://www.daneprairie.com. The unregistered version of Win2PDF is for evaluation or non-commercial use only.