Overview

• TCP header fields
• TCP Connections
• Alternating Bit Protocol

TCP header fields

• Source and destination ports: 16-bits each, with source and destination IP, uniquely identify the connection
• Sequence number: 32-bit unique identification number of the first byte in the packet
• Acknowledgement number: 32-bit unique identification number of byte we are acknowledging (if ACK flag is set). Generally, every segment but the first has the ACK flag set.
• Data Offset (header size, in 32-bit words words)

More TCP header fields

• Flags, including ACK, RST (reset the connection), SYN (setup a new connection), FIN (request to close the connection), URG (urgent data present)
• SYN and FIN are both counted (as one byte) in the sequence number
• window (measured in bytes), indicates how much more data past the acknowledgement number you may send: used for flow control
• checksum
• urgent pointer: if there is any "urgent" data (URG flag set, indicating out-of-band data), it is at the position in the packet indicated by the urgent pointer
• options if any

TCP connections

• all connections are bidirectional
• each byte sent in each direction has a sequence number
• sender in each direction picks initial sequence number
• sequence/ack number wraps after reaching 2^{32}
• connections can be closed independently in each direction
• a connection in which the endpoints don't agree on sequence numbers (or in case of other errors) can be reset, closed unilaterally by one side
• if I send 1,000,000 bytes of data in one operation, and even if my receiver is willing to receive them all at once, TCP may deliver only a few at a time (no segment boundaries)

TCP Connection Establishment

• Three-Way Handshake
• "connect" side sends a packet with the SYN bit on, indicating its initial sequence number
• "accept" side sends a packet with the SYN and the ACK bits on, indicating its initial sequence number and confirming receipt of the other's packet
• "connect" side sends a packet with the ACK bit on, confirming receipt
• timers on both sides will retransmit any packet that is not acked.

TCP Connection Teardown

• Independent shutdown on each side
• when done sending data, either side can send a packet with the FIN bit set, indicating it will send no more data.
• when the second side send FIN, we close the connection
• FIN packets are acknowledged
• last ack problem: who is responsible for recovering from a lost FIN packet? If we sent the first FIN, we must wait (generally about 60 seconds) in case other side retransmits its FIN packet

Retransmission Algorithms

• keep a copy of the data we send
• ack received packets
• detect the packet/ack loss (usually by timeout on receipt of acks)
• retransmit lost packets (or packets whose ack was lost)

Types of Acknowledgements

• cumulative (ack everything up to this sequence number, e.g. TCP)
• non-cumulative (ack this packet)
• negative (I need this specific packet)

Alternating Bit protocol

• single bit sequence/ack number
• only one possible outstanding (unacked) packet
• on receipt of packet s, send ack s
• if outstanding packet has sequence s:
  • ignore acks 1-s
  • ack s allows us to send next packet with sequence 1-s

Correctness of ABP

1. if network is FIFO,
2. any ack 1-s we receive is for the last packet
3. any ack s we receive is for the current packet, and
4. when we receive an ack s, there can be no ack 1-s left in the network.
5. therefore, any future ack 1-s must be for future packets, and
6. acks will be matched to packets