Computer Networks 20022003 Transport layer issues Johan Lukkien

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

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 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 2

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 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 3

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

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 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 5

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 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 6

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) 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 7

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 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 8

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

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 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 10

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

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

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

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 port) 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 14

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 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 15

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 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 16

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) 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 17

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

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 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 19

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

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

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

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

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 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 24

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 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 25

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 11/26/2020 Johan J. Lukkien, j. j. lukkien@tue. nl TU/e Computer Science, System Architecture and Networking 26

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

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

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

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

TCP Timer Management (a) Probability density of ACK arrival times in the data link layer. (b) Probability density of ACK arrival times for TCP – 11/26/2020 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 31

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