1 / 32

Transport Layer Issues in Computer Networks

This article discusses transport layer issues in computer networks, including communication between applications, multiplexing, addressing, connection-oriented vs connectionless protocols, quality of service, reliability, and congestion control.

gflorence
Télécharger la présentation

Transport Layer Issues in Computer Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Computer Networks2002/2003 Transport layer issues Johan Lukkien Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  2. Provided service • Communication between applications on disparate machines • add multiplexing to the network layer • need additional addressing to distinguish applications: ports, .... • Connection oriented / Connectionless • Quality (optional) • independent of required service • reliability. confidentiality • dependent of required service • quality of service: timeliness, bandwidth • in cooperation with required service • congestion control Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  3. Transport service • Must deal with • many concurrent transport connections • with many different machines • Provided interface available to application programmers • Balance • hide network level details • admit high performance • either network abstraction is with low cost • or network services are accessible Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  4. Packing TPDUs • TPDUs, also called segments • Minimal segment size: MSS – configured Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  5. Required service • Packets between machines • just send and receive to an addressed machine • general fault model: loss, duplication, out-of-order, delay • Possibly, entry points for quality control • specific functions, e.g., bandwidth reservation, connection setup • though the entire network layer then must support it! • over-dimensioning • idem • Note: usually, only the end-stations run the transport protocol • so, the TPDU’s are not interpreted in the network • Question: is this always the case? If not, what are the consequences? • all connection information is in the transport layer Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  6. Overview • Services • types • addressing • packet format • Connection control • setup and destroy • client and server roles • Communication control • feedback mechanisms • policies and mechanisms for acknowledgements, timeouts, flow control, buffering Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  7. Services • User datagram • datagram service between applications • just add multiplexing to basic packet network service • internet: UDP (user datagram protocol) • address: (machine, port) • includes multicasting, many-to-one • Reliable connection oriented service • between applications • add multiplexing and connections to basic network service, hiding the faults • internet: TCP (transmission control protocol) • point-to-point channel, identified by • (source mach., source port) – (dest. mach., dest. port) Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  8. UDP • Header • port: 0-65535 (0..1023: reserved, e.g. ftp, DNS) • length: includes header • checksum: (why?) – may be omitted • Uses • if connection orientation not needed • e.g. simple request/reply • if reliable streams are not needed • hence do not waste performance Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  9. The Real-Time Transport Protocol • Transport protocol on top UDP • Typical uses: multi-media • can use for multicasting (e.g. Internet radio) Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  10. Setting up a connection • Usually, an ‘active’ and a ‘passive’ partner • active: seeking contact – client • passive: awaiting contact – server • The client needs to know (where to find) the server • At least one partner must be active • in principle, two active partners would work Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  11. Provided interface • Operations to access a service: primitives • Minimal set: • must support client and server roles Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  12. State diagram • Transitions labeled in italics: through packet arrivals • Solid lines: client • Dashed lines: server Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  13. Berkeley Sockets • Standard interface for TCP Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  14. TCP addresses • A server waits at a fixed meeting point • e.g. an FTP server • If the connection is identified by just (machine, port) no machine can serve two similar tasks • e.g. two FTP sessions • For the client this problem does not exist • it just needs an unused port • A TCP connection is determined on both endpoints by • (src, src port, dst, dst port) Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  15. Congestion and flow control • Congestion control • the subnet must be able to carry the flow • effective and fair sharing • Flow control • sender and receiver issue • don’t flood the receiver • Note: flow control techniques (e.g., ‘shut up’) can be used to avoid or solve congestion Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  16. Congestion • What happens if traffic goes from a ‘wide’ into a ‘small’ link? (a source is ‘wide’) • delay per packet increases • hence retransmission occurs, possibly unneeded • packets are dropped • thus wasting all work along the path, also for others • chain of events into complete congestion • irrespective of buffer capacity or knowledge of the exact packets that got lost Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  17. Congestion control • Feedback cycle • measure, interpret, adjust • no single location to take action • Measurements • discarded packets, locally • lack of buffer space, length of queues • # timed-out packets • routers mark outgoing packets with local condition • Actions taken • inform source • ....increases load, slowed down by congestion • drop packets • policies: retain old (wine), or new (milk) Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  18. Relation to network uses Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  19. Congestion control at the endpoints • Measure congestion at sender • timeout • or retransmission request • Action • adjust transmission rate • maximal unacknowledged window: C (at least MSS) • Threshold T • round trip time: rtt • C/rtt is effective transmission rate • algorithm – slow start AIMD • reduce T until C/2 upon failure; set C to 1 MSS • upon ack, increase by 1 (= slow start: exponential growth) • upon reaching C reaching T: only increase linearly Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  20. Behavior • Roughly 75% of available bandwidth used • Convergence to fairness, if everybody cooperates • however, multiple TCPs increases share • “TCP-friendly” Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  21. TCP: some assigned ports Port Protocol Use 21 FTP File transfer 23 Remote login Telnet E-mail 25 SMTP 69 Trivial File Transfer Protocol TFTP Finger Lookup info about a user 79 80 World Wide Web HTTP POP-3 110 Remote e-mail access USENET news 119 NNTP Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  22. The TCP Segment Header Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  23. Pseudoheader • Included in the TCP checksum • Mix of layers Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  24. Sequence numbers • Needed when message order is important • sliding window protocols • (soft) state updates, e.g. router tables • Finite range: wrap-around • Dangers • long-lived messages • delayed duplicate messages • delayed acknowledgements • (replay attacks) • restart after failure • Approach: use aging • hop count • timestamp Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  25. Timestamping • Use synchronized clocks to put the time on a message • e.g. through an external reference clock • Define minimal packet life-time • Minimal time after packet traces have gone: T • Use a crash-resilient counter to generate sequence numbers • so a machine knows ‘where it was’ after a crash • wrap-around must not be possible within T • counter increment faster than send rate Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  26. Forbidden region • Forbidden region represents sequence numbers that might be used after a restart • can be entered from the bottom • fast transmission • or from the left • slow transmission • applications must check and resynchronize Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  27. Getting started: three-way handshake • CR denotes CONNECTION REQUEST. • Normal operation • Old CONNECTION REQUEST appearing out of nowhere • Duplicate CONNECTION REQUEST and duplicate ACK. Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  28. TCP Connection Establishment (a) TCP connection establishment in the normal case. (b) Call collision: single connection remains 6-31 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  29. TCP Transmission Policy • Flow control through specifying available window Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  30. Silly windows... Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  31. TCP Timer Management (a) Probability density of ACK arrival times in the data link layer. (b) Probability density of ACK arrival times for TCP • hence, dynamically determine timer value (e.g. double upon failure, linear decrease) Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

  32. Transactional TCP • E.g. using HTTP Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

More Related