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 20041 Transport layer Computer Networks

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

3 Transport layer -- May 20043 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 20044 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 20045 Services  To upper layer oefficient, reliable, cost-effective service o2 kinds Connection oriented Connectionless

6 Transport layer -- May 20046 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 20047 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 20048 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 20049 Simple service: state diagram

10 Transport layer -- May 200410 Simple service: state diagram

11 Transport layer -- May 200411 Simple service: state diagram

12 Transport layer -- May 200412 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 200413 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 200414 Transport Layer  Services  Elements of transport protocol  Simple transport protocol  UDP  Remote Procedure Call (see Distributed Systems)  TCP

15 Transport layer -- May 200415 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 200416 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 200417 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 200418 etp: Addressing  Connection scenario

19 Transport layer -- May 200419 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 200420 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 200421 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 200422 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 200423 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 200424 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 200425 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 200426 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 200427 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 200428 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 200429 etp: Establishing a connection  Tomlinson - forbidden region

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

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

32 Transport layer -- May 200432 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 200433  Asymmetric: data loss etp: Releasing a connection

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

35 Transport layer -- May 200435  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 200436 etp: Releasing a connection RC

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

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

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

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

41 Transport layer -- May 200441 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 200442 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 200443 etp: Multiplexing  Upward: reduce number of network connections to reduce cost  Downward: increase bandwidth to avoid per connection limits

44 Transport layer -- May 200444 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 200445 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 200446 etp: Crash recovery  Illustration of problem: File transfer

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

48 Transport layer -- May 200448 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 200449  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 200450  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 200451  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 200452 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 200453 Example Transport Entity (1)

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

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

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

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

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

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

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

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

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

63 Transport layer -- May 200463 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 200464 Transport Layer  Services  Elements of transport protocol  Simple transport protocol  UDP  Remote Procedure Call (see Distributed Systems)  TCP

65 Transport layer -- May 200465 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 200466 TCP service model  …  send & receive buffers

67 Transport layer -- May 200467 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 200468 TCP header

69 Transport layer -- May 200469 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 200470 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 200471 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 200472 TCP connection management

73 Transport layer -- May 200473

74 Transport layer -- May 200474 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 200475 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 200476 TCP transmission policy

77 Transport layer -- May 200477

78 Transport layer -- May 200478 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 200479  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 200480 TCP transmission policy

81 Transport layer -- May 200481 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 200482 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 200483 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 200484 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 200485 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 200486 TCP congestion control

87 Transport layer -- May 200487 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 200488 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 200489 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 200490 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 200491 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 200492 TCP congestion control

93 Transport layer -- May 200493 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 200494 TCP timer management Data link layerTransport layer

95 Transport layer -- May 200495 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 200496 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 200497 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 200498 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 200499 Wireless TCP  Heterogeneous networks  Solutions? oRetransmissions can cause congestion in wired network

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

101 Transport layer -- May 2004101 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 2004102 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 2004103 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 2004104 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 2004105 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 2004106 Transport layer Computer Networks

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

Similar presentations

Ads by Google