INF4/MSc Computer Networking. Lectures 3-4 Transport layer protocols TCP/UDP automatic repeat request

Transcription

1 INF4/MSc omputer Networking Lectures 3-4 Transport layer protocols TP/UDP automatic repeat request

2 Transport services and protocols provide logical communication between app processes running on different hosts Multiplexing/demultiplexing transport protocols run in end systems send side: breaks app messages into segments, passes to network layer rcv side: reassembles segments into messages, passes to app layer network layer provides logical communication between hosts application transport network data link physical network data link physical logical end-end transport network data link physical network data link physical network data link physical network data link physical application transport network data link physical 2

3 Basic services of transport protocols Depends on what is offered by the network layer Error control build a reliable channel between two peers Flow control allow the receiver to regulate the flow of data Synchronization/time recovery for media streams (audio/video) they must be played back at the correct rate. Security: Privacy ensure no-one can read the information Integrity no-one can change what is transmitted uthentication verify the identity of sender/receiver Implementation efficiency: network/link utilisation Idle time Header overhead 3

4 Internet transport layer protocols: UDP Stands for User Datagram Protocol Unreliable, connectionless transport layer protocol Services beyond IP : demultiplexing and (optional) error checking Source Port Destination Port UDP Length UDP hecksum Data Port numbers added in the header» Identify the particular application in the given host Optional checksum on the whole datagram» 0 checksum value means no checksum wanted» a checksum calculated to be 0 has to be included as all s» IP checksum algorithm uses s complement arithmetic; so all s = 0 4

5 UDP (cont) The datagram padded out to a multiple of 6 bits for checksum calculation» but the padding not transmitted pseudo-header also included in the checksum calculation» and not transmitted with the datagram Source IP ddress Destination IP ddress Protocol = 7 UDP Length Permits a check that the datagram has reached the correct destination orrupted datagrams are discarded» no error message returned to source 5

6 Error control protocols What is needed: Error detection special data encoding, R, etc Timeouts timers, interrupts, reverse channel to receive acknowledgements, positive or negative utomatic Repeat Request (RQ) family of protocols Stop and wait Go back N Selective repeat ssumption (for now): channels are like wires, PDUs cannot arrive out-of-order Types of PDUs: Information transfer user data ontrol acknowledgements, etc. 6

7 Stop and wait Basic idea: Send ame Wait for acknowledgement of receipt If ack does not arrive by some reasonable time, re-transmit ame What can go wrong? Frame is lost or has errors cknowledgement is lost/garbled 7

8 Information ames must be numbered B Frame 0 Time-out Frame Frame Frame 2 Time B Frame 0 Time-out Frame Frame Frame 2 Time Neither transmitter nor receiver have a global view of the situation The transmitter cannot distinguish between a lost ame or lost ack it just retransmits the ame The receiver does not know if a ame is new or a retransmission Solution: the information ames are numbered 8

9 ck ames must be numbered too B Time-out Frame 0 Frame 0 Frame Frame 2 Time Premature timeouts may result in multiple acks for the same information ame The transmitter may misinterpret a duplicate ack as an ack for a subsequent ame If that ame is lost, the sender will never know about it Solution: cks are numbered too 9

10 Stop and wait (with sequencing numbers) Transmitter keeps track of the sequence number S last of the ame being sent plus the ame itself, in case it needs to be retransmitted Receiver keeps track only of the sequence number of the next ame it is expecting to receive, R next Sequence number cannot get too large Limited, fixed space in the header -bit sequence number adequate in this case ombination of S last and R next forms the state of the transmission link S last will be 0 or ; R next will be 0 or therefore four states : (0,0), (0,), (,0), (,) depending on which ame has been transmitted and which s received 0

11 Stop and wait: state machine Global State: (S last, R next ) (0,0) Error-ee ame 0 (0,) arrives at receiver for ame arrives at transmitter Error-ee ame (,0) arrives at receiver (,) for ame 0 arrives at transmitter One verified ame transmission corresponds to half a cycle in the FSM

12 Link utilisation The link is an important resource, its utilisation must be maximised First ame bit enters channel Last ame bit enters channel hannel idle while transmitter waits for arrives t B t First ame bit arrives at receiver Last ame bit arrives at receiver Receiver processes ame and prepares 2

13 Stop and wait: ame transmission time t 0 = total time to transmit ame t proc B t prop ame t f time t proc t prop t ack t 0 = = 2t 2t prop prop + + 2t 2t proc proc + + t f n f R + t + ack n R a bits/info ame bits/ ame channel transmission rate 3

14 Stop and wait: efficiency Effective transmission rate: R 0 eff bits for header & R number of information bits delivered to destination n = = total time required to deliver the information bits f t 0 n o, Transmission efficiency: R eff R = n f n t0 R o = + n n a f + n n 2( t o f prop + t n f proc ) R. Effect of ame overhead Effect of ame Effect of Delay-Bandwidth Product 4

15 Stop and wait: Impact of transmission errors in efficiency Previous calculations assume error-ee transmission In presence of errors the effective bit rate drops P f probability of an error in a ame (data or ack) transmission verage number of retransmissions: /(-P f ) Total time to transfer ame becomes t n 0 f n a t = = (2t prop + 2t proc + + ) P R R P f Transmission efficiency multiplied (drops) by (-P f ) f Link error rate is usually quoted as probability of error for single bit 5

16 Go-back-N The source of Stop-and-Wait inefficiency is that it does not fill the channel with data Improve Stop-and-Wait by not waiting for an ack before sending the next packet i.e. pipeline the ame transmission Transmitter has a limited number of ames (called a window) that can be outstanding without acknowledgment : W s W s is chosen to allow the channel to be fully utilised Frames are numbered cks are also numbered 6

17 Example: Go-back-4 Go-Back-4: 4 ames are outstanding; so go back Time B 2 3 out of sequence ames R next When there are fewer than Ws- subsequent packets to send retransmissions are not triggered, since the window is not exhausted Need to associate a timer with every packet 7

18 Go-back-N: window size If there are m bits available in the header for sequencing, which is the largest possible value for W S? receiver must be able to determine unambiguously which ame has been received taking into account the wrapping around when count reaches 2 m M = 2 2 = 4, Go-Back - 4: Transmitter goes back Time B R next Receiver has R next = 0, but it does not know whether its for ame 0 was received, so it does not know whether this is the old ame 0 or a new ame 0 onclusion: W S <= 2 m - 8

19 Go-back-N with negative acknowledgments Go-Back-7: Transmitter goes back to ame time B N Out-of-sequence ames N with sequence number R next acknowledges all ames up to R next - and hints the transmitter that an error has been detected in ame R next Go-back-N with N, results in having the transmitter go back less than N ames, so speeds up error recovery 9

20 Selective-Repeat Go-back-N performs badly in noisy channels Retransmits more than the minimum required Selective-repeat improvements: Reception window is made larger so it accepts (error-ee) out-of-order ames Only individual ames are retransmitted More storage is required at the receiver omplexity is higher 20

21 Selective-Repeat: Operation example Time B 2 N Ns are not essential; speed-up the retransmission of a specific ame If N not used (or lost) a timeout will eventually cause retransmission The basic objective remains to advance the values of R next and S last by delivery of the oldest outstanding ame

22 Selective-Repeat: Window sizes Example: M=2 2 =4, Ws=3, Wr=3 Send Window Frame 0 resent {0,,2} {,2} {2} {.} Time Receive Window B 2 0 {0,,2} {,2,0} {2,0,} {0,,2} Old ame 0 accepted as a new ame because it falls in the receive window 22

23 Flow control protocols The receiver has limited buffer space to store ames If the transmitter sends data at a higher rate, the buffer can overflow and some of the transferred data will be dropped mechanism is needed so that the receiver can tell the transmitter to slow down (or stop) or speed-up again Implementation requires: Detection of potential buffer overflow reverse channel for flow control messages to transmitter Two types of ames: Information transfer user data Flow-control ames 23

24 X ON \ X OFF protocol threshold Information ame Transmitter Receiver Transmit X OFF Transmit Time on off off on B Time 2T prop Receiver must activate OFF signal while 2 T prop R bits still remain in buffer 24

25 Sliding window flow control The sliding window protocols can be used for flow control; set W s equal to receiver buffer size Transmitter can never send more than W s ames s slide window forward = permit transmission of new ames s are called credits in this case Flow control can be combined with error control in a sliding window RQ protocol Window size depends on bandwidth-delay product and size of receiver s buffer lternative: extend ame header with an extra field for control-flow credits; decouples credits om acks 25

26 End-to-end protocols Problems (only when lower layer provides datagram service) Packets arrive out of order Old packets (even om previous connections) reappear» The correct packet could be wrongly rejected as a duplicate Solution Packets have a maximum lifetime arefully selected initial sequence number» Implies agreement, implies connection establishment procedure Sequence number space is large, but legal windows are (relatively) small Wait for a reasonable time before re-establishing a connection End-to-end delays are subject to more variation How to select a reasonable timeout? 26

27 Sequence numbers ssume T is (a multiple of) maximum packet (and ack) lifetime Must ensure two packets (for the same pair of hosts and sockets) with same sequence number are never outstanding for a time difference of T Thus if they do, they must be duplicates of the same packet retransmitted Each computer has a timer (counter) Not synchronised. Synchronisation is very hard/expensive! Sequence numbers created om the timer Sequence space large, so for a single connection, wrap around time is much larger than T The two peers agree on an initial sequence number 27

28 Sequence numbers - Problems rashes cause problem: which was the last sequence number? Expensive solution: wait for T before doing anything lternatively, impose further restrictions on sequence numbers The current timer (= potential initial seq number) determines a set of sequence numbers (in existing connections) that should not be used. Sequence number Forbidden region T Forbidden region T Time Rate of actual sequence numbers cannot be steeper than the timer Fast timers needed Eventually will enter the forbidden region on the right 28

29 End-to-end retransmission timeout Timeout depends on round trip time (RTT): time om when segment is sent to when is received Round trip time (RTT) across a network (esp. Internet) is highly variable Routes vary and can change in mid-connection Traffic fluctuates Timeout too short: excessive number of retransmissions Timeout too long: recovery too slow daptive estimation of RTT used in TP Measure RTT each time received: τ n α = 7/8 typical t RTT (new) = α t RTT (old) + ( α) τ n 29

30 Timeout using RTT variability RTT (milliseconds) time (seconnds) SampleRTT Estimated RTT Estimate variance σ 2 of RTT variation Estimate for timeout: t out = t RTT + k σ RTT If RTT highly variable, timeout increase accordingly If RTT nearly constant, timeout close to RTT estimate 30

31 TP: Overview RFs: 793, 22, 323, 208, 258 point-to-point: one sender, one receiver reliable, in-order byte steam: no message boundaries pipelined: TP congestion and flow control set window size send & receive buffers Transmitter pplication byte stream segments pplication byte stream Receiver full duplex data: bi-directional data flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) init s sender, receiver state before data exchange flow controlled: sender will not overwhelm receiver Send buffer s Receive buffer 3

32 TP segment structure URG: urgent data (generally not used) : # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) head len 32 bits source port # dest port # sequence number acknowledgement number not used checksum U P R S F application data (variable length) Receive window Urg data pnter Options (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept 32

33 onnection Establishment Three-way handshake Host Host B SYN, Seq_no = x SYN, Seq_no = y,, ck_no = x+ Seq_no = x+,, ck_no = y+ sends connection request to B» SYN=; initial sequence number = x B acknowledges connection request» =; SYN=; initial sequence number = y; next data byte expected=x+» s SYN consumes the first sequence number acknowledges the request om B» =; sequence number = x+; next data byte expected=y+» on receipt at B, connection is established 33

34 onnection Termination There is no protocol that can do this 00% safely! The two army problem: the side that sends the last message cannot know if it has been received at the other side The final message (ack) is allowed to be lost 34

35 TP onnection Termination Each end of a TP connection terminates independently Host receives the for the last data, it sends a segment with FIN Host B receives the FIN segment, informs its application that the other entity has terminated its connection and s the FIN Host B can still transmit in the other direction until it has finished Host B eventually also sends a FIN segment Host receives FIN, replies with and goes into a wait state Starts a TIME-WIT timer set to 2 x maximum segment lifetime» st MSL accounts for time a segment in one direction can remain in the network»2 nd MSL accounts for the transit time of the reply The only valid segment that can arrive in this interval is a retransmission of the FIN segment (e.g. if the was lost)» if a FIN retransmission is detected, the is retransmitted and the timer restarted Wait state means old session segments are gone before termination 35

36 Reading Tanenbaum onnection establishment for sequence numbers 36

37 Playout schedule Packet rrivals Packet Playout T playout Select a playout time greater than max delay through network Setup a large enough buffer Start playout Packet timestamp helps determine when is should be played 37

38 Playout schedule 38

39 Synchronisation is essential Time Send times rrival times Playout times Receiver too slow; buffer fills and overflows Time Receiver too fast buffer starvation Many late packets T playout time T playout time Time Receiver speed just right T playout time 39

40 Timing Recovery for Synchronous Services Synchronous source sends periodic information blocks Network output not periodic Network pplications that involve voice, audio, or video can generate a synchronous information stream Information carried by equally-spaced fixed-length packets Network multiplexing & switching introduces random delays Packets experience variable transfer delay Jitter (variation in interpacket arrival times) also introduced Timing recovery re-establishes the synchronous nature of the stream 40

41 lock recovery Timestamps inserted in packet payloads indicate when info was produced t 4 t 3 t 2 t Timestamps + - Buffer for information blocks Error signal dd Smoothing filter ounter djust equency Playout command Recovered clock ounter attempts to replicate transmitter clock Frequency of counter is adjusted according to arriving timestamps Jitter introduced by network causes fluctuations in buffer & in local clock 4