The Transport Layer. Why is there a transport layer? Addressing

Transcription

1 The Transport Layer Provides logical communication between processes network layer: data transfer between end systems transport layer: data transfer between processes Two types of transport service is available connection-oriented connectionless application transport network data link physical network data link network physical data link physical logical end-end transport network data link physical network data link physical network data link physical application transport network data link physical 2/6/2006 Transport Layer Issues 1 Why is there a transport layer? Historically the network layer was part of the communications subnet and is run by the carrier. The transport layer forms a boundary between the provider and user of the reliable transmission service Some make the following distinction: transport service provider (layers 1-4) transport service user (above 4) 2/6/2006 Transport Layer Issues 2 Addressing Transport addresses typically need to include more than a machine address Many names, but the idea is essentially the same (IP address, local port) (AAL, SAP) (NSAP, TSAP) One component the destination, the second identifies an end point destination 2/6/2006 Transport Layer Issues 3 1

2 Determining the End-Point How does one determine what end-point a service is installed on? One technique is to agree on a set of well-known end-points Service Name Port Echo 7 Daytime 13 Qotd 17 Ftp 21 Telnet 23 Smtp 25 Time 37 Nameserver 42 2/6/2006 Transport Layer Issues 4 Initial Connection Protocol Each machine wishing to offer services has a special process server The process server scans a series of ports looking for connections When a connection request is received, the process server starts the appropriate process to service the request In UNIX this is handled by inetd 2/6/2006 Transport Layer Issues 5 Name Server A special process, called a name server or sometimes a directory server, to solve the addressing problem Here clients ask the name server what end-point address the desired service is running on This requires services to register themselves with the name server 2/6/2006 Transport Layer Issues 6 2

3 Transport Protocols Transport protocols often need to make an unreliable channel appear to be error free Transport protocols typically deal with error control, sequencing, and flow control Issues that affect transport protocols routing connection establishment storage capacity on the net sophisticated buffering/flow control techniques 2/6/2006 Transport Layer Issues 7 Principles of Reliable data transfer 2/6/2006 Transport Layer Issues 8 Elementary Link Protocols Need to provide enable reliable delivery using an unreliable delivery All packets are received Packets are received in the correct order No duplicates what we send is what is received The discussion that follows is based on Computer Networks, by Tannenbaum 2/6/2006 Transport Layer Issues 9 3

4 Utopia Assumptions Data transmission in one direction only The communication channel is assumed to be error free The receiver is assumed to be able to process all the input infinitely fast Just a simple example to get used to terminology 2/6/2006 Transport Layer Issues 10 Utopia Pseudo-code void sender(void) { frame s; // outbound frame packet p; // outbound packet while (true) { // Get something to send from_network_layer(&p); // Prepare for transmission s.info = p; // Send it to_physical_layer(&s); void receiver(void) { frame r; // inbound frame event_type event; // Not used while (true) { // Only possibility is // frame arrival wait_for_event(&event); // Get frame from_physical_layer(&r); // Pass to Network Layer to_network_layer(&r.info); 2/6/2006 Transport Layer Issues 11 Utopia in Action Frame A Frame B Packet C Frame C Packet C 2/6/2006 Transport Layer Issues 12 4

5 Stop & Wait Assumptions Data transmission in one direction only, from sender to receiver (but can send in both directions) The communication channel is assumed to be error free The receiver has only finite buffer capacity and a finite processing speed 2/6/2006 Transport Layer Issues 13 Stop & Wait Pseudo-code void sender(void) { frame s; // outbound frame packet p; // outbound packet event_type e; void receiver(void) { frame r; // inbound frame frame s; // ack frame event_type event; // Not used while (true) { // Get and send from_network_layer(&p); s.info = p; to_physical_layer(&s); // Wait for wait_for_event( &e ); while (true) { // Only possibility is // frame arrival wait_for_event(&event); // Get and pass up from_physical_layer(&r); to_network_layer(&r.info); // Send to_physical_layer( &s ); 2/6/2006 Transport Layer Issues 14 PAR Assumptions Data transmission in one direction only, from sender to receiver. The receiver has only finite buffer capacity and a finite processing speed. The communication channel is not assumed to be error free. Error recovery is done by error detection and retransmission of corrupted frames. The receiver sends an when the received frame is (considered) error-free a N when the received frame is corrupted Flow control can be achieved by sending nothing for a while. The sender must keep the transmitted frame in a buffer until it is acknowledged. 2/6/2006 Transport Layer Issues 15 5

6 PAR - Normal Frame A Frame B N Frame B ERROR 2/6/2006 Transport Layer Issues 16 PAR Lost Frame TIMEOUT Frame A Frame B Frame B ERROR 2/6/2006 Transport Layer Issues 17 Timeouts Sender waits for and times out and retransmits With time outs, Ns are not necessary But are usually more efficient Flow control is now based on time out Problem is that s can get lost too!! 2/6/2006 Transport Layer Issues 18 6

7 PAR Lost Frame A TIMEOUT Frame B Frame B 2/6/2006 Transport Layer Issues 19 Numbering Messages Assumptions Same as before Protocol Changes Sender maintains a one-bit counter Incremented when is received Value of counter placed in header Receiver Has one-bit counter (tells last frame received) Correct frame No error Right number 2/6/2006 Transport Layer Issues 20 PAR Lost Frame A:0 TIMEOUT Frame B:1 Frame B:1 DUPLICATE DISCARD 2/6/2006 Transport Layer Issues 21 7

8 Race Condition Frame A:0 TIMEOUT Frame B:1 Frame A:0 DUPLICATE DISCARD Packet C Frame C:1 DUPLICATE DISCARD 2/6/2006 Transport Layer Issues 22 Numbering s Assumptions Same as before Protocol Changes s are numbered as well Can be proved correct assuming No re-ordering of messages or s 2/6/2006 Transport Layer Issues 23 It Works!! TIMEOUT DUPLICATE DISCARD TIMEOUT Frame A:0 :0 Frame A:0 Frame B:1 :0 Frame B:1 :1 DUPLICATE DISCARD 2/6/2006 Transport Layer Issues 24 8

9 Simplex Transmission Layer 2 Sender A Data A B Control B A Layer 2 Receiver B Unidirectional data transmission 2/6/2006 Transport Layer Issues 25 Full Duplex Transmission Data A B Layer 2 Sender A Control B A Data B A Layer 2 Receiver B Control A B Seems silly to have two simplex channels 2/6/2006 Transport Layer Issues 26 Piggy-backed s Data A B Control A B Layer 2 Sender A Data B A Control B A Layer 2 Receiver B 2/6/2006 Transport Layer Issues 27 9

10 Stop & Wait Pseudo-code void sender(void) { frame f; int sent = 0; int expect = 0; while (true) { f.ack = 1 - expect; f.frame = sent; // Send 1 st to_physical_layer( &f ); frame from_physical_layer( &f ); if ( f.ack == sent &&!timeout ) { from_network_layer( &f.info ); to_send = 1 to_send; // Receive frame // Handle if ( f.seq == expect &&!timeout) { // Handle data to_network_layer( &f.info ); expect = 1 expect; 2/6/2006 Transport Layer Issues 28 Stop & Wait Pseudo-code void sender(void) { frame f; int sent = 1; int expect = 0; while (true) { from_physical_layer( &f ); if ( f.ack == sent &&!timeout ) { from_network_layer( &f.info ); to_send = 1 to_send; // Receive frame // Handle if ( f.seq == expect &&!timeout) { // Handle data to_network_layer( &f.info ); expect = 1 expect; f.ack = 1 - expect; f.frame = sent; // Send 1st frame to_physical_layer( &f ); 2/6/2006 Transport Layer Issues 29 Piggyback A sends (0, 1, A0) B gets (0, 1, A0) B sends(0, 0, B0) A gets (0, 0, B0) A sends(1, 0, A1) B gets (1, 0, A1) B sends(1, 1, B1) A gets (1, 1, B1) A sends(1, 0, A2) A gets (0, 0, B2) A sends(1, 0, A3) B gets (0, 1, A2) B sends(0, 0, B2) B gets (1, 0, A3) B sends(1, 1, B3) Notation: ( frame number, piggybacked, frame ) 2/6/2006 Transport Layer Issues 30 10

11 Lost Packet A sends (0, 1, A0) B gets (0, 1, A0) B sends(0, 0, B0) A gets (0, 0, B0) A sends(1, 0, A1) B gets (1, 0, A1) B sends(1, 1, B1) TIMEOUT A sends(1, 0, A1) A gets (1, 1, B1) A sends(0, 1, A2) B gets (1, 0, A1) B sends(1, 1, B1) B gets (0, 1, A2) B sends(0, 0, B2) Notation: ( frame number, piggybacked, frame ) 2/6/2006 Transport Layer Issues 31 Simultaneous Start A sends (0, 1, A0) B sends(0, 1, B0) B gets(0, 1, A0) B sends(0, 0, B0) A gets (0, 1, B0) A sends(0, 0, A0) B gets (0, 0, A0) B sends(1, 0, B1) A gets (0, 0, B0) A sends(1, 0, A1) A gets (1, 0, B1) A sends(1, 1, A1) B gets (1, 0, A1) B sends(1, 1, B1) B gets (1, 1, A1) B sends(0, 1, B2) Notation: ( frame number, piggybacked, frame ) 2/6/2006 Transport Layer Issues 32 Analysis L/b R 1 st bit of frame Last bit of frame (one bit long) Usage: (L/b) /( R + L/b) or L / ( L + Rb) Where L = length of the frame b = data rate R = round trip delay L/b = transmission R/2 = transit Bad if R >> (satellite) b >> (high speed) L << (small frame) 2/6/2006 Transport Layer Issues 33 11

12 More Outstanding? Why only 1 outstanding frame? Minimizes buffer size Wastes bandwidth Sliding windows protocols Basically what we have been looking at Except that multiple packets can be un-d How That is the window size 2/6/2006 Transport Layer Issues 34 Transmission Window for the first packet "slides" the window along to the next packet. The window partitions successfully transmitted waiting acknowledgements waiting to be transmitted 2/6/2006 Transport Layer Issues 35 Pipelined protocols Sender allows multiple, in-flight, yet-to-beacknowledged packets range of sequence numbers must be increased buffering at sender and/or receiver 2/6/2006 Transport Layer Issues 36 12

13 How to Handle Loss Assuming a window size greater than 1 What action do you take if you detect a packet loss Two general strategies Go back N Selective Repeat 2/6/2006 Transport Layer Issues 37 Go-Back-N Receiver s packets in order Discards unexpected packets Sender retransmits everything in window when detects loss of 2/6/2006 Transport Layer Issues 38 GBN in action 2/6/2006 Transport Layer Issues 39 13

14 Selective Repeat Receiver individually acknowledges all correctly received packets Buffers packets, as needed, for eventual in-order delivery to upper layer Sender only resends packets for which not received Sender timer for each uned packet Sender window N consecutive sequence # s 2/6/2006 Transport Layer Issues 40 Selective Repeat 2/6/2006 Transport Layer Issues 41 Selective repeat in action 2/6/2006 Transport Layer Issues 42 14

15 Selective Repeat: Dilemma Example: Seq # s: 0, 1, 2, 3 Window size=3 Receiver sees no difference in two scenarios! Incorrectly passes duplicate data as new in (a) Seq #s must be larger than window size 2/6/2006 Transport Layer Issues 43 Problems With Connections The crux of most of the problems are delayed duplicates Throwaway transport addresses Each connection has a unique address Server model cannot work Connection identifiers A unique number that identifies each connection What happens when a host crashes? Try killing old packets (aging) 2/6/2006 Transport Layer Issues 44 Restricting Packet Lifetime Packet lifetime can be restricted Restricted subnet design Hop counters Timestamps Not only do we need to kill packets, but any s of the packets as well T is some multiple of the true packet lifetime. After waiting T units all traces of the packet are gone 2/6/2006 Transport Layer Issues 45 15

16 Generating Sequence Numbers With packet lifetimes limited, it is possible to devise a way to generate sequence numbers safely Basic idea is to generate sequence numbers such that two identically numbered packets are never outstanding at the same time (for one connection) Equip each machine with a clock that never stops Takes on the form of a binary counter Incremented at regular intervals Number of bits equals/exceeds size of sequence number 2/6/2006 Transport Layer Issues 46 Generating Sequence Numbers At connection set up, the low order k bits of the clock are used as the initial sequence number. Each connection starts with a different sequence number Once the initial sequence number is picked, things work as before The sequence space is so large that by the time sequence numbers wrap, the old packets are long gone 2/6/2006 Transport Layer Issues 47 Host Crashes When a host crashes, and then restarts, it does not know where it was in the sequence space One solution is to require transport entities to be idle for T seconds after recovery to let all old packets dies off If T is large, as it would be in a complex internetwork, this strategy is unattractive. 2/6/2006 Transport Layer Issues 48 16

17 Example Let T = 60sec and the clock ticks once per second At time = 30secs, a packet is sent with with sequence number 80 (this is an existing connection, packet lives until time = 90secs) The machine crashes and restarts At time = 70secs, it reopens the connection, and uses initial sequence number 70 Within the next 15secs it sends packets At time=85secs two packets with sequence 80 exist 2/6/2006 Transport Layer Issues 49 Forbidden Regions We must prevent sequence numbers from being used for a time T before their potential use as initial sequence numbers The forbidden region indicates the illegal combinations of time and sequence number Before sending any packet, on any connection, the clock must be checked to be sure the packet is not in a forbidden region 2/6/2006 Transport Layer Issues 50 Problems The protocol can get into trouble if the host sends data too quickly on a newly opened connection This happens if the transmission rate is faster than the clock This means the maximum data rate on any connection is one packet per clock tick It also means the hosts must wait until the clock ticks before opening a connection after restart A short clock tick is desired 2/6/2006 Transport Layer Issues 51 17

18 Problems The protocol can also run into problems if the transmission rate is too slow At any data rate less than the clock rate, the sequence numbers will eventually run into the forbidden region from the left This is fixed by re-synchronizing the sequence numbers 2/6/2006 Transport Layer Issues 52 Establishing A Connection Sounds straight forward one side sends CONNECTION REQUEST other side sends CONNECTION ACCEPTED when originator gets the the connection is established Imagine creating a connection where all the packets are duplicated and you are transferring money!! 2/6/2006 Transport Layer Issues 53 Three Way Handshake The clock based approach solves the delayed duplicate problem, only if a connection has been established CR (seq=x) (seq=y, =x) DATA (seq=x, =y) 2/6/2006 Transport Layer Issues 54 18

19 Problems CR (seq=x) CR (seq=x) (seq=y, =x) (seq=y, =x) DATA (seq=y, =z) REJECT (=y) REJECT (=y) 2/6/2006 Transport Layer Issues 55 Releasing a Connection Releasing connections is easier than establishing one There are two styles of release: asymmetric symmetric Asymmetric release is abrupt and may result in data loss. A more sophisticated protocol is required to avoid data loss 2/6/2006 Transport Layer Issues 56 19