Computer NetworksICS 651

● Reliable Transmission● Sliding Window for Flow Control● Bandwidth-Delay product● TCP streams and push● TCP header● tcpdump and wireshark

Reliable Transmission

• IP is not reliable: packets may be lost, reordered, or corrupted

• corruption is handled by the TCP checksum

• for packet loss or reordering, use acknowledgements:

• each data packet must carry a sequence number

• the sequence number tells us if data is out of order

• for each data packet we receive, we send an empty (header only, no payload) acknowledgement packet stating that we got the data

• if no ack is received within a certain time, we need to retransmit that packet

TCP sequence and acknowledgement

• sequence and acknowledgement are 32-bit numbers• carried in every packet (except SYN only has a sequence number)• acks only sent in response to packets carrying data or SYN or FIN• acks are cumulative: ack i acknowledges all the data up to sequence number i - 1• sequence and ack numbers count bytes (+ SYN and FIN bits), not packets• useful e.g. with MTU discovery, retransmission of many

small packets consolidated into one larger packet • three duplicate acks are taken as a negative ack (NAK/NACK) inviting -- but not requiring -- retransmission

The need for Flow Control

• IP gives us ability to send end-to-end

• sequence and ack give us ability to reliably (modulo checksum) deliver data to application

• still missing: flow control, the ability to slow down the sender if the receiver is slow

• receiver buffers are limited

• why send if the receiver has no space?

TCP flow control

• with each ack, the receiver specifies how many more bytes past the ack the receiver is willing to accept

• the number of bytes is the window

• the window is sliding every time a new ack pushes its left edge to the right in sequence space

• the sender may have sent some of those bytes already -- because they were in the previous window

• when the sender exhaust the window, it must stop sending

TCP window

• the left edge of the TCP window is moved to the right by the receiver when it acknowledges new data

• the right edge of the TCP window is moved to the right by the receiver when it sends a window update

• the left edge of the TCP window is communicated to the sender by the acknowledgement number

• the right edge of the TCP window is communicated to the sender by the window field

TCP data transfer example

• A to B: seq 1, ack 1000000, window 100, 200 bytes of data

• A to B: seq 201, ack 1000000, window 100, 800 bytes of data

• B to A: seq 1000000, ack 201, window 1000, 0 bytes of data

• A to B: seq 1001, ack 1000000, window 100, 200 bytes of data

Zero windows

• suppose the window size is reduced to zero: receiver acks, and says it has a window size of zero, since all buffers are full

• later the receiver reopens the window by sending a new ack with a new window

• that ack is lost!

• deadlock: sender is waiting for window update, receiver is waiting for new data

• a sender with data to send, and a zero send window, must periodically send one byte past the window, to elicit an ack in response

Silly Window Syndrome• receiver will move right edge of window by a small amount when it receives a small amount of data• if sender is window-limited, it will then send a small segment• this is undesirable, because small segments have more overhead, and because the receiver is likely to expand the window soon• solution:• receiver must move right edge of window in increments of

at least 1 MSS or 1/2 the actual window, whichever is less• sender increment its send window in increments of at least

1 MSS or 1/2 the estimated receiver's window, whichever is less

• sender needs a timer so, when the timer expires, can send less than 1/2 the estimated window -- this avoids deadlock in case the estimate for the receiver's window is wrong (for example if the receiver's window got smaller)

Nagle Algorithm and sender SWS

• the usable window is the number of bytes I could send given the ack, window, and the next sequence number to send:

U = ack + wnd - nxt• D is the amount of data I am ready to send• to avoid SWS, the sender sends if it can send one full MSS, or at least 1/2 the (estimated) receive buffer:

min(D, U) >= MSS or min(D, U) >= rcvbuff / 2• Nagle suggests, for D < MSS, only sending if the window is large enough to send everything, and no acks are pending:

nxt = ack and D <= U• or send if there is data to send, when an override timeout• in-class exercise: what is the benefit of not sending when (a) the window is large enough to send everything, but (b) acks are pending? (i.e. if D < MSS and nxt != ack?)

Nagle Algorithm Overview

• two conflicting goals:

• send data as fast as possible, and

• don't send small packets, which have higher overhead (only significant if the network is busy/congested)

• solutions:

• always send if the network is not busy -- first packet when all that was sent before has been acked

• always send any maximum sized packet (either MSS, or at least 1/2 of the estimated receive window)

• otherwise wait a little while to send, until either one of the above holds, or a timer expires

TCP delayed acks

• a receiver does not know when the sender is going to send the next segment

• for fastest performance, a receiver should ack every segment

• in a two-way stream an ack is piggybacked on every data segment going in the other direction

• typically, in a one-way stream TCPs should send one ack packet for every two full-size segments

• a timer on the receiver should send an ACK for the latest data if it has not been acked within about 20ms.

Bandwidth-Delay product

• How big do I make the window?

• Suppose I have a small buffer of size s = 512, I could set the window to size s

• if I can send 100,000 bytes/second (800Kbps), and the round-trip delay is 10ms, I can only send 512 bytes 100 times per second, or at most 51,200 bytes/second

• if I set my window to the bandwidth-delay product, s = 100KB/s x 0.01s = 1,000 bytes, I can send at full speed

• this affects high-bandwidth applications (gigabit and 10-gig ethernet, microwave and light links) and high-latency applications (especially satellites)

TCP window scaling

• the window field in the TCP header is 16 bits, so the largest window is 65,535 bytes• this is not enough for full bandwidth on a 100ms (RTT) gigabit ethernet, with a bandwidth-delay product of 100Mb = 12.5MB• so TCP provides a window scaling option, sent with the SYN packet• the option only takes effect if both sides send a window scaling option with their SYN packet• if I send a window scale with a value of n, where 0 <= n <= 14, then I must divide the windows that I send by 2n

• correspondingly, if I receive a window scale with a value of n, then I must multiply the windows that I receive by 2n

• since n <= 14, the maximum window size is < 230 bytes• window scaling is defined in RFC 1323, "TCP Extensions for High Performance", which also provides protection against wrapped sequence numbers.

TCP Streams and Push

• TCP actually has a segmentation bit: PSH, or push

• when the application "pushes" the data, that information could be conveyed all the way to the application at the other end

• if TCP can coalesce several user segments (each with PSH) into one TCP segment, that TCP segment can only carry one PSH bit

• so passing PSH to the application is optional, and TCP has no record boundaries

• so push is an advisory bit only: it encourages TCP (and the application) to assume that the data must be sent (and presumably replied to) before more data will be sent

TCP header

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |C|E|U|A|P|R|S|F| | | Offset|Reservd|W|C|R|C|S|S|Y|I| Window | | | |R|E|G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TCP Header Format

TCP Header fields

• Source and Destination port: demultiplexing

• Sequence and acknowledgement: reliable delivery

• Data Offset: header size, options

• Window: flow control

• Checksum: correctness

• Urgent Pointer: "special place" in the data stream

TCP Header bits

• SYN: I want to establish a connection• FIN: I will never again send data on this connection• RST: kill this connection• PSH: immediate delivery of this data is probably a good idea• URG: the urgent pointer is valid• ACK: the acknowledgement field is valid (set in all but the first SYN packet)• ECE: this packet acknowledges a packet received with the IP "congestion experienced" bit set• CWR: the sender of this packet has reduced its congestion window• the last two bits will be discussed in the context of congestion control

tcpdump and wireshark

• tcpdump is a utility to look at all the packets on the network and print out the headers

• usually run as root

• wireshark (formerly known as Ethereal) is similar but (a) window-based, (b) newer

16:41:58.905998 maru.ics.hawaii.edu.14407 >

volcano.telnet: S 2671654129:2671654129(0)

win 512 [tos 0x10]

16:41:59.115893 volcano.telnet >

maru.ics.hawaii.edu.14407: R 0:0(0)

ack 2671654130 win 0

tcpdump example

16:47:02.285753 maru.1022 > volcano.ssh: S 185741093:185741093(0) win 512 16:47:02.495648 volcano.ssh > maru.1022: S 3829593384:3829593384(0) ack 185741094 win 16352 16:47:02.495648 maru.1022 > volcano.ssh: . ack 1 win 32120 (DF)16:47:07.183328 volcano.ssh > maru.1022: P 1:16(15) ack 1 win 16352 (DF)16:47:07.183328 maru.1022 > volcano.ssh: P 1:16(15) ack 16 win 32120 (DF) [tos 0x10]16:47:07.433203 volcano.ssh > maru.1022: P 16:292(276) ack 16 win 16352 (DF)16:47:08.502673 volcano.ssh > maru.1022: P 16:292(276) ack 16 win 16352 (DF)16:47:08.522663 maru.1022 > volcano.ssh: . ack 292 win 32120 (DF) [tos 0x10]