Presentation is loading. Please wait.

Presentation is loading. Please wait.

Transport layer -- May 20041 Transport layer Computer Networks.

Similar presentations


Presentation on theme: "Transport layer -- May 20041 Transport layer Computer Networks."— Presentation transcript:

1 Transport layer -- May Transport layer Computer Networks

2 Transport layer -- May Transport Layer  Services  Elements of transport protocol  Simple transport protocol  UDP  Remote Procedure Call (see Distributed Systems)  TCP

3 Transport layer -- May Layer overview application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport

4 Transport layer -- May Layer overview Host 1 Network layer Application layer Transport entity Host 2 Network layer Application layer Transport entity TPDU Transport addresses Network addresses

5 Transport layer -- May Services  To upper layer oefficient, reliable, cost-effective service o2 kinds Connection oriented Connectionless

6 Transport layer -- May Services  needed from network layer opacket transport between hosts orelationship network <> transport Hosts <> processes Transport service –independent network –more reliable Network –run by carrier –part of communication subnet for WANs

7 Transport layer -- May Simple service: primitives  Simple primitives: oconnect osend oreceive odisconnect  How to handle incoming connection request in server process?  Wait for connection request from client! olisten

8 Transport layer -- May Simple service: primitives listenWait till a process wants a connection connectTry to setup a connection sendSend data packet receiveWait for arrival of data packet disconnectCalling side breaks up the connection No TPDU Connection Request TPDU Data TPDU No TPDU Disconnect TPDU

9 Transport layer -- May Simple service: state diagram

10 Transport layer -- May Simple service: state diagram

11 Transport layer -- May Simple service: state diagram

12 Transport layer -- May Berkeley service primitives  Used in Berkeley UNIX for TCP  Addressing primitives:  Server primitives:  Client primitives: socket bind listen accept send + receive close connect send + receive close

13 Transport layer -- May Berkeley service primitives socket create new communication end point bind attach a local address to a socket listen announce willingness to accept connections; give queue size accept block caller until a connection request arrives connect actively attempt to establish a connection send send some data over the connection receive receive some data from the connection close release the connection

14 Transport layer -- May Transport Layer  Services  Elements of transport protocol  Simple transport protocol  UDP  Remote Procedure Call (see Distributed Systems)  TCP

15 Transport layer -- May Elements of transport protocols (etp)  Transport <> Data Link  Addressing  Establishing a connection  Releasing a connection  Flow control and buffering  Multiplexing  Crash recovery

16 Transport layer -- May etp: Transport <> data link  Physical channel <> subnet Explicit addressing Connection establishment Potential existence of storage capacity in subnet Dynamically varying number of connections

17 Transport layer -- May etp: Addressing  TSAP = transport service access point oInternet: IP address + local port oATM: AAL-SAPs  Connection scenario  Getting TSAP addresses?  From TSAP address to NSAP address?

18 Transport layer -- May etp: Addressing  Connection scenario

19 Transport layer -- May etp: Addressing  Connection scenario oHost 2 (server) Time-of-day server attaches itself to TSAP 1522 oHost 1 (client) Connect from TSAP 1208 to TSAP 1522 Setup network connection to host 2 Send transport connection request oHost 2 Accept connection request

20 Transport layer -- May etp: Addressing  Getting TSAP addresses? oStable TSAP addresses For key services Not for user processes –active for a short time –number of addresses limited oName servers to find existing servers map service name into TSAP address oInitial connection protocol

21 Transport layer -- May etp: Addressing  Getting TSAP addresses? oInitial connection protocol to avoid many waiting servers  one process server –waits on many TSAPs –creates requested server

22 Transport layer -- May etp: Addressing  From TSAP address to NSAP address? ohierarchical addresses address = –Examples: IP address + port Telephone numbers (<> number portability?) Disadvantages: –TSAP bound to host! oflat address space Advantages: –Independent of underlying network addresses –TSAP address not bound to host Mapping to network addresses: –Name server –broadcast

23 Transport layer -- May etp: Establishing a connection  Problem: delayed duplicates!  Scenario: oCorrect bank transaction connect data transfer disconnect oProblem: same packets are received in same order a second time! Recognized?

24 Transport layer -- May etp: Establishing a connection  Unsatisfactory solutions: othrowaway TSAP addresses need unlimited number of addresses? process server solution impossible oconnection identifier Never reused!  Maintain state in hosts  Satisfactory solutions

25 Transport layer -- May etp: Establishing a connection  Satisfactory solutions oEnsure limited packet lifetime (incl. Acks) oMechanisms prevent packets from looping + bound congestion delay hopcounter in each packet timestamp in each packet oBasic assumption If we wait a time T after sending a packet all traces of it (including Acks) are gone Maximum packet lifetime T

26 Transport layer -- May etp: Establishing a connection  Tomlinson’s method orequires: clock in each host Number of bits > number of bits in sequence number Clock keeps running, even when a hosts crashes oBasic idea: 2 identically numbered TPDUs are never outstanding at the same time!

27 Transport layer -- May etp: Establishing a connection  Tomlinson’s method oProblems to solve Selection of the initial sequence number for a new connection Wrap around of sequence numbers for an active connection Handle host crashes Never reuse a sequence number x within the lifetime T for the packet with x  Forbidden region

28 Transport layer -- May etp: Establishing a connection  Tomlinson’s method oInitial sequence number = lower order bits of clock oEnsure initial sequence numbers are always OK  forbidden region oWrap around Idle Resynchronize sequence numbers

29 Transport layer -- May etp: Establishing a connection  Tomlinson - forbidden region

30 Transport layer -- May etp: Establishing a connection  Tomlinson – three-way-handshake No combination of delayed packets can cause the protocol to fail

31 Transport layer -- May etp: Establishing a connection  Tomlinson – three-way-handshake

32 Transport layer -- May etp: Releasing a connection  2 styles: oAsymmetric Connection broken when one party hangs up Abrupt!  may result in data loss oSymmetric Both parties should agree to release connection How to reach agreement? Two-army problem Solution: three-way-handshake oPragmatic approach Connection = 2 unidirectional connections Sender can close unidirectional connection

33 Transport layer -- May  Asymmetric: data loss etp: Releasing a connection

34 Transport layer -- May  Symmetric: two-army-problem etp: Releasing a connection Simultaneous attack by blue army Communication is unreliable No protocol exists!!

35 Transport layer -- May  Three-way-handshake + timers oSend disconnection request + start timer RS to resend (at most N times) the disconnection request oAck disconnection request + start timer RC to release connection etp: Releasing a connection

36 Transport layer -- May etp: Releasing a connection RC

37 Transport layer -- May etp: Releasing a connection RS

38 Transport layer -- May etp: Flow control and buffering TransportData link connections, linesmany varying few fixed (sliding) window sizevaryingfixed buffer managementdifferent sizes?fixed size

39 Transport layer -- May etp: Flow control and buffering  Buffer organization

40 Transport layer -- May etp: Flow control and buffering  Buffer management: decouple buffering from Acks

41 Transport layer -- May etp: Flow control and buffering  Where to buffer? odatagram network sender oreliable network +Receiver process guarantees free buffers? No: for low-bandwidth bursty traffic sender Yes: for high-bandwidth smooth traffic receiver

42 Transport layer -- May etp: Flow control and buffering  Window size? oGoal: Allow sender to continuously send packets Avoid network congestion oApproach: maximum window size = c * r –network can handle c TPDUs/sec – r = cycle time of a packet measure c & r and adapt window size

43 Transport layer -- May etp: Multiplexing  Upward: reduce number of network connections to reduce cost  Downward: increase bandwidth to avoid per connection limits

44 Transport layer -- May etp: Crash recovery  recovery from network, router crashes? oNo problem Datagram network: loss of packet is always handled Connection-oriented network: establish new connection + use state to continue service  recovery from host crash? oserver crashes, restarts: implications for client? oassumptions: no state saved at crashed server no simultaneous events oNOT POSSIBLE Recovery from a layer N crash can only be done by layer N+1 and only if the higher layer retains enough status information.

45 Transport layer -- May etp: Crash recovery  Illustration of problem: File transfer: oSender: 1 bit window protocol: states S0, S1 packet with seq number 0 transmitted; wait for ack oReceiver: actions Ack packet Write data to disk Order?

46 Transport layer -- May etp: Crash recovery  Illustration of problem: File transfer

47 Transport layer -- May Transport Layer  Services  Elements of transport protocol  Simple transport protocol  UDP  Remote Procedure Call (see Distributed Systems)  TCP

48 Transport layer -- May Simple transport protocol  Service primitives: oconnum = LISTEN (local) Caller is willing to accept connection Blocked till request received oconnum = CONNECT ( local, remote) Tries to establish connection Returns identifier (nonnegative number) ostatus = SEND (connum, buffer, bytes) Transmits a buffer Errors returned in status ostatus = RECEIVE (connum, buffer, bytes) Indicates caller’s desire to get data ostatus = DISCONNECT (connum) Terminates connection

49 Transport layer -- May  Transport entity oUses a connection-oriented reliable network oProgrammed as a library package oNetwork interface ToNet(…) FromNet(…) Parameters: –Connection identifier (connum = VC) –Q bit: 1 = control packet –M bit: 1 = more data packets to come –Packet type –Pointer to data –Number of bytes of data Simple transport protocol

50 Transport layer -- May  Transport entity: packet types Simple transport protocol Network packetMeaning Call requestSent to establish a connection Call acceptedResponse to Call Request Clear RequestSent to release connection Clear confirmationResponse to Clear request DataUsed to transport data CreditControl packet to manage window

51 Transport layer -- May  Transport entity: state of a connection Simple transport protocol StateMeaning IdleConnection not established WaitingCONNECT done; Call Request sent QueuedCall Request arrived; no LISTEN yet Established SendingWaiting for permission to send a packet ReceivingRECEIVE has been done DisconnectingDISCONNECT done locally

52 Transport layer -- May Simple transport protocol  Transport entity: code oSee fig 6-20, p. 514 – 517 oTo read and study at home! oQuestions? Is it acceptable not to use a transport header? How easy would it be to use another network protocol?

53 Transport layer -- May Example Transport Entity (1)

54 Transport layer -- May Example Transport Entity (2)

55 Transport layer -- May Example Transport Entity (3)

56 Transport layer -- May Example Transport Entity (4)

57 Transport layer -- May Example Transport Entity (5)

58 Transport layer -- May Example Transport Entity (6)

59 Transport layer -- May Example Transport Entity (7)

60 Transport layer -- May Example Transport Entity (8)

61 Transport layer -- May Transport Layer  Services  Elements of transport protocol  Simple transport protocol  UDP  Remote Procedure Call (see Distributed Systems)  TCP

62 Transport layer -- May UDP  User Data Protocol oDatagram service between processes No connection overhead oUDP header: Ports = identification of end points

63 Transport layer -- May UDP  Some characteristics oSupports broadcasting, multicasting (not in TCP) oPacket oriented (TCP gives byte stream) oSimple protocol oWhy needed above IP?

64 Transport layer -- May Transport Layer  Services  Elements of transport protocol  Simple transport protocol  UDP  Remote Procedure Call (see Distributed Systems)  TCP

65 Transport layer -- May TCP service model  point-to-point oone sender, one receiver  reliable, in-order byte stream ono message/packet boundaries  pipelined & flow controlled owindow size set by TCP congestion and flow control algorithms  connection-oriented ohandshaking to get at initial state  full duplex data obi-directional data flow in same connection

66 Transport layer -- May TCP service model  …  send & receive buffers

67 Transport layer -- May TCP protocol  Three-way handshake to set up connections  Every byte has its own 32-bit sequence number oWrap around o32-bit Acks; window size in bytes  Segment = unit of data exchange o20-byte header + options + data oLimits for size 64Kbyte MTU, agreed upon for each direction oData from consecutive writes may be accumulated in a single segment oFragmentation possible  Sliding window protocol

68 Transport layer -- May TCP header

69 Transport layer -- May TCP header  source & destination ports (16 bit)  sequence number ( 32 bit)  Acknowledgement number (32 bit)  Header length (4 bits) in 32-bit words  6 flags (1 bit)  window size (16 bit) : number of bytes the sender is allowed to send starting at byte acknowledged  checksum (16 bit)  urgent pointer (16 bit) : byte position of urgent data

70 Transport layer -- May TCP header  Flags: oURG: urgent pointer in use oACK: valid Acknowledgement number oPSH: receiver should deliver data without delay to user oRST: reset connection oSYN: used when establishing connections oFIN: used to release connection  Options: oMaximum payload a host is willing to receive oScale factor window size oUse selective repeat instead of go back n

71 Transport layer -- May TCP connection management  Three-way handshake oInitial sequence number: clock based oNo reboot after crash for T (maximum packet lifetime=120 sec) oWrap around?  Connection identification oPair of ports of end points  Connection release oBoth sides are closed separately oNo response to FIN: release after 2*T oBoth sides closed: wait for time 2 * T

72 Transport layer -- May TCP connection management

73 Transport layer -- May

74 Transport layer -- May TCP connection management StateDescription ClosedNo connection is active or pending ListenThe server is waiting for an incoming call SYN rcvdA connection request has arrived; wait for ACK SYN sentThe application has started to open a connection EstablishedThe normal data transfer state FIN wait 1The application has said it is finished FIN wait 2The other side has agreed to release Timed waitWait for all packets to die off ClosingBoth sides have tried to close simultaneously Close waitThe other side has initiated a release Last AckWait for all packets to die off

75 Transport layer -- May TCP transmission policy  Window size decoupled from Acks (ex. next slides)  Window = 0  no packets except for oUrgent data o1 byte segment to send Ack & window size  Incoming user data may be buffered oMay improve performance: less segments to send  Ways to improve performance: oDelay acks and window updates for 500 msec oNagle’s algorithm oSilly window syndrome

76 Transport layer -- May TCP transmission policy

77 Transport layer -- May

78 Transport layer -- May TCP transmission policy  Telnet scenario: interactive editor reacting on each keystroke: One character typed  21 byte segment or 41 byte IP packet  (packet received) 20 byte segment with Ack  (editor has read byte) 20 byte segment with window update  (editor has processed byte; sends echo) 21 byte segment  (client gets echo) 20 byte segment with Ack  Solutions: odelay acks + window updates for 500 msec oNagle’s algorithm: Receive one byte from user; send it in segment Buffer all other chars till Ack for first char arrives Send other chars in a single segment Disable algorithm for X-windows applications (do not delay sending of mouse movements)

79 Transport layer -- May  Silly window syndrome oProblem: Sender transmits data in large blocks Receiver reads data 1 byte at a time oScenario: next slide oSolution: Do not send window update for 1 byte Wait for window update till –Receiver can accept MTU –Buffer is half empty TCP transmission policy

80 Transport layer -- May TCP transmission policy

81 Transport layer -- May TCP transmission policy  General approach: oSender should not send small segments Nagle: buffer data in TCP send buffer oReceiver should not ask for small segments Silly window: do window updates in large units

82 Transport layer -- May Principles of Congestion Control Congestion:  informally: “too many sources sending too much data too fast for network to handle”  different from flow control! = end-to-end issue!  manifestations: olost packets (buffer overflow at routers) olong delays (queue-ing in router buffers)  a top-10 problem!

83 Transport layer -- May Causes/costs of congestion: scenario  two senders, two receivers  one router, infinite buffers  no retransmission  large delays when congested  maximum achievable throughput

84 Transport layer -- May Approaches towards congestion control end-to-end congestion control:  no explicit feedback from network  congestion inferred from end-system observed loss, delay  approach taken by TCP Network-assisted congestion control:  routers provide feedback to end systems osingle bit indicating congestion (SNA, ATM) oexplicit rate sender should send at Two broad approaches towards congestion control:

85 Transport layer -- May TCP Congestion Control  How to detect congestion?  Timeout caused by packet loss: reasons oTransmission errors oPacked discarded at congested router : Rare Packet loss Hydraulic example illustrating two limitations for sender! for wired networks

86 Transport layer -- May TCP congestion control

87 Transport layer -- May TCP Congestion Control  How to detect congestion?  Timeout caused by packet loss: reasons oTransmission errors oPacked discarded at congested router : Rare Packet loss  congestion Approach: 2 windows for sender Receiver window Congestion window Minimum of 

88 Transport layer -- May TCP Congestion Control  end-end control (no network assistance)  transmission rate limited by congestion window size, Congwin, over segments:  w segments, each with MSS bytes sent in one RTT: throughput = w * MSS RTT Bytes/sec Congwin

89 Transport layer -- May TCP Congestion Control:  two “phases” oslow start ocongestion avoidance  important variables: oCongwin othreshold: defines threshold between two phases: slow start phase congestion control phase  “probing” for usable bandwidth: oideally: transmit as fast as possible ( Congwin as large as possible) without loss oincrease Congwin until loss (congestion) oloss: decrease Congwin, then begin probing (increasing) again

90 Transport layer -- May TCP Slow start  exponential increase (per RTT) in window size (not so slow!)  loss event: timeout (Tahoe TCP) and/or three duplicate ACKs (Reno TCP) initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) Slow start algorithm Host A one segment RTT Host B time two segments four segments

91 Transport layer -- May TCP Congestion Avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart Congestion avoidance 1 1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs

92 Transport layer -- May TCP congestion control

93 Transport layer -- May TCP timer management  How long should the timeout interval be? oData link: expected delay predictable oTransport: different environment; impact of Host Network (routers, lines) unpredictable  Consequences oToo small: unnecessary retransmissions oToo large: poor performance  Solution: adjust timeout interval based on continuous measurements of network performance

94 Transport layer -- May TCP timer management Data link layerTransport layer

95 Transport layer -- May TCP timer management  Algorithm of Jacobson: oRTT = best current estimate of the round-trip time oD = mean deviation (cheap estimator of the standard variance) o4? Less than 1% of all packets come in more than 4 standard deviations late Easy to compute Timeout = RTT + 4 * D

96 Transport layer -- May TCP timer management  Algorithm of Jacobson: oRTT =  RTT + (1 -  ) M  = 7/8 M = last measurement of round-trip time oD =  D + (1 -  )  RTT - M   Karn’s algorithm: how handle retransmitted segments? oDo not update RTT for retransmitted segments oDouble timeout Timeout = RTT + 4 * D

97 Transport layer -- May TCP timer management  Other timers: oPersistence timer Problem: lost window update packet when window is 0 Sender transmits probe; receivers replies with window size oKeep alive timer Check whether other side is still alive if connection is idle for a long time No response: close connection oTimed wait Make sure all packets are died off when connection is closed = 2 T

98 Transport layer -- May Wireless TCP & UDP  Transport protocols oIndependent of underlying network layer oBUT: carefully optimized for wired networks oAssumption: Packet loss caused by congestion Invalid for wireless networks: always loss of packets  Congestion algorithm: oTimeout ( = congestion)  slowdown  Solution for wireless networks: oRetransmit asap Wireless: Lower throughput – same loss  NO solution

99 Transport layer -- May Wireless TCP  Heterogeneous networks  Solutions? oRetransmissions can cause congestion in wired network

100 Transport layer -- May Wireless TCP  Solutions for heterogeneous networks oIndirect TCP +2 homogeneous connections –violates TCP semantics

101 Transport layer -- May Wireless TCP  Solutions for heterogeneous networks oSnooping agent at base station Cashes segments for mobile host Retransmits segment if ack is missing Removes duplicate acks Generates selective repeat requests for segments originating at mobile host Snooping agent Congestion algorithm may be invoked

102 Transport layer -- May Wireless UDP  UDP = datagram service  loss permitted no problems?  Programs using UDP expect it to be highly reliable  Wireless UDP: far from perfect!!!  Implications for programs recovering from lost UDP messages

103 Transport layer -- May Transactional TCP  How to implement RPC? oOn top of UDP? oYes if Request and reply fit in a single packet Operations are idempotent oOtherwise Reimplementation of reliability oOn top of TCP?

104 Transport layer -- May Transactional TCP How to implement RPC?  On top of UDP? oYes if Request and reply fit in a single packet Operations are idempotent oOtherwise Reimplementation of reliability  On top of TCP? oUnattractive because of connection set up  Solution: transactional TCP

105 Transport layer -- May Transactional TCP How to implement RPC?  On top of UDP? oProblems withreliability  On top of TCP? oOverhead of connection set up  Solution: transactional TCP oAllow data transfer during setup oImmediate close of stream

106 Transport layer -- May Transport layer Computer Networks


Download ppt "Transport layer -- May 20041 Transport layer Computer Networks."

Similar presentations


Ads by Google