The Transport Layer Part 1
2 OVERVIEW Part 1 User Datagram Protocol Transmission Control Protocol ARQ protocols Part 2 TCP congestion control Mowgli XTP SCTP WAP
3 Transport Layer Protocols Connect applications Additional addressing to the network layer host addresses Provides services to the applications protocols Reliable datagram or byte stream delivery Or unreliable delivery
4 UDP UDP = User Datagram Protocol Defined in RFC-768 UDP packet syntax Source port Length Data Destination port UDP checksum Port is a 16-bit application identifier number. Checksum is calculated over both the header and the data. UDP checksum is optional.
5 UDP UDP datagram is encapsulated into an IP datagram. IP header UDP header UDP data Unreliable datagram-oriented transportation layer protocol offers little extra functionality besides port numbers simple, fast, light-weight, easy to implement Applications using UDP: DNS, Radius, NTP, SNMP
6 A UDP (DNS) Session Snoop 23 riku@mole $ dig a tapas.nixu.fi @194.197.118.20 ;; got answer: ;; QUESTIONS: ;; tapas.nixu.fi, type = A, class = IN ;; ANSWERS: tapas.nixu.fi. 3600 A 194.197.118.24 ;; AUTHORITY RECORDS: nixu.fi. 3600 NS ns2.tele.fi. nixu.fi. 3600 NS ns.nixu.fi. nixu.fi. 3600 NS ns.tele.fi. ;; ADDITIONAL RECORDS: ns2.tele.fi. 35619 A 193.210.19.190 ns.nixu.fi. 3600 A 193.209.237.29 ns.tele.fi. 555991 A 193.210.19.19 ns.tele.fi. 555991 A 193.210.18.18 ;; Total query time: 88 msec ;; FROM: mole.nixu.fi to SERVER: 194.197.118.20 ;; MSG SIZE sent: 31 rcvd: 175 24 riku@mole $
7 DNS Query, Ethernet Header ETHER: Packet 1 arrived at 11:19:24.80 ETHER: Packet size = 73 bytes ETHER: Destination = 8:0:20:74:f1:2c, Sun ETHER: Source = 0:0:3b:80:e:93, ETHER: Ethertype = 0800 (IP)
8 DNS Query, IP Header IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx.... = 0 (precedence) IP:...0... = normal delay IP:... 0... = normal throughput IP:....0.. = normal reliability IP: Total length = 59 bytes IP: Identification = 35734 IP: Flags = 0x4 (do not fragment) IP: Fragment offset = 0 bytes IP: Time to live = 255 seconds/hops IP: Protocol = 17 (UDP) IP: Header checksum = 7e65 IP: Source address = 194.197.118.22, mole.nixu.fi IP: Destination address = 194.197.118.20, jalopeno.nixu.fi IP: No options
9 DNS Query, UDP Header UDP: Source port = 38325 UDP: Destination port = 53 (DNS) UDP: Length = 39 UDP: Checksum = E34A
10 DNS Query, Headers and Data 0: 0800 2074 f12c 0000 3b80 0e93 0800 4500.. t.,..;...e. 16: 003b 8b96 4000 ff11 7e65 c2c5 7616 c2c5.;..@...~e..v... 32: 7614 95b5 0035 0027 e34a 000a 0100 0001 v...5.'.j... 48: 0000 0000 0000 0574 6170 6173 046e 6978...tapas.nix 64: 7502 6669 0000 0100 0100 u.fi... From now on only relevant portions of the headers will be displayed
11 DNS Reply Headers ETHER: Packet size = 217 bytes ETHER: Destination = 0:0:3b:80:e:93, ETHER: Source = 8:0:20:74:f1:2c, Sun ETHER: Ethertype = 0800 (IP) IP: Total length = 203 bytes IP: Flags = 0x4 (do not fragmnet) IP: Protocol = 17 (UDP) IP: Header checksum = 8ed6 IP: Source address = 194.197.118.20, jalopeno.nixu.fi IP: Destination address = 194.197.118.22, mole.nixu.fi UDP: Source port = 53 UDP: Destination port = 38325 UDP: Length = 183 UDP: Checksum = AD48
12 DNS Reply Headers and Data 0: 0000 3b80 0e93 0800 2074 f12c 0800 4500..;... t.,..e. 16: 00cb 7a95 4000 ff11 8ed6 c2c5 7614 c2c5..z.@...v... 32: 7616 0035 95b5 00b7 ad48 000a 8580 0001 v..5...h... 48: 0001 0003 0004 0574 6170 6173 046e 6978...tapas.nix 64: 7502 6669 0000 0100 01c0 0c00 0100 0100 u.fi... --- some reply data deleted --- 208: 087b db00 04c1 d212 124f.{...
13 TCP TCP = Transmission Control Protocol Defined in RFC-793 Connection-oriented, reliable, byte-stream service Application data is broken into segments, which are sent as IP datagrams. Features: Checksums, timeouts and flow control Segment reassembly in correct order, discarding duplicate packets Applications using TCP: SMTP, HTTP (WWW), NNTP (News),...
14 TCP Segment Format Source port number Destination port number Sequence number Acknowledgment number Hdrlen Reserv. Flags Window size TCP checksum Urgent pointer Options (if any) Data (if any) Ports identify source and destination applications. Sequence number identifies the first byte of the segment. Acknowledge number is the next expected sequence number for incoming data.
15 TCP Segment Format Flags URG validates the urgent pointer. ACK acknowledges the synchronization. PSH marks that the data buffer should be flushed to the receiving application. Sometimes considered outdated. RST resets the connection. SYN marks the synchronization phase of connection. FIN ends connection.
16 TCP Segment Format Window Size is the number of bytes the receiver is willing to accept Urgent pointer points to the last byte of urgent data. Urgent data feature is used, for example, when a user presses the interrupt key during a telnet session. Options contain often maximum segment size at the start of connection, options can be also used to discover path MTU or to set window scale factor.
17 TCP Data Flow Receiver sends acknowledgment for each segment. If a packet gets lost, timeout will ensure it s retransmitted Client Server waiting for ack packet gets lost retransmission ACK
18 TCP Data Flow Normally a sliding window technique The window size is changeable, default size is around couple dozen kilobytes depending on the implementation. waiting for ack Client packet 1 packet 2 packet 3 ACK 1 & 2 ACK 3 Server
19 Establishing a TCP Connection The three-way handshake active open Client SYN SYN + ACK ACK Server passive open
20 Closing a TCP Connection Client Server active close FIN ACK FIN ACK passive close There may be data between the middle ACK and FIN So called half-close is utilized by some applications. Client says I am done sending data but I still want to receive
21 TCP shortcomings Window size Maximum window size 64 kb Max bandwidth = max window size / round trip time Error handling TCP assumes that lost packets are lost due to network congestion Internet is built on high-quality fixed trunk connections and LANs The solution is to make the sending window smaller than maximum size On modern wireless networks data is often lost to radio errors The correct solution would be to resend the same data again as soon as possible Instead TCP starts to send slower
22 A Snooped SMTP Session 24 riku@mole $ telnet jalopeno 25 Trying 194.197.118.20... Connected to jalopeno. Escape character is '^]'. 220-jalopeno.nixu.fi ESMTP Sendmail 8.6.12/8.6.12 ready at Sat, 5 Oct 1996 11:24:29 +0300 220 ESMTP spoken here QUIT 221 jalopeno.nixu.fi closing connection Connection closed by foreign host. 25 riku@mole $
23 1. SYN Client->Server (Ethernet Header) ETHER: Packet 1 arrived at 10:58:0.62 ETHER: Packet size = 60 bytes ETHER: Destination = 8:0:20:74:f1:2c, Sun ETHER: Source = 0:0:3b:80:e:93, ETHER: Ethertype = 0800 (IP)
24 1. SYN Client->Server (IP Header) IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx.... = 0 (precedence) IP:...0... = normal delay IP:... 0... = normal throughput IP:....0.. = normal reliability IP: Total length = 44 bytes IP: Identification = 63629 IP: Flags = 0x4 (do not fragment) IP: Fragment offset = 0 bytes IP: Time to live = 255 seconds/hops IP: Protocol = 6 (TCP) IP: Header checksum = 1188 IP: Source address = 194.197.118.22, mole.nixu.fi IP: Destination address = 194.197.118.20, jalopeno.nixu.fi IP: No options
25 1. SYN Client->Server (TCP Header) TCP: Source port = 35620 TCP: Destination port = 25 (SMTP) TCP: Sequence number = 760886272 TCP: Acknowledgement number = 0 TCP: Data offset = 24 bytes TCP: Flags = 0x02 TCP:..0.... = No urgent pointer TCP:...0... = No acknowledgement TCP:... 0... = No push TCP:....0.. = No reset TCP:.....1. = Syn TCP: TCP: Window = 8760 TCP: Checksum = 0x17a1 TCP: Urgent pointer = 0......0 = No Fin TCP: Options: (4 bytes) TCP: - Maximum segment size = 1460 bytes
26 1. SYN Client->Server (SMTP Data) SMTP: "" From now on only relevant portions of the headers will be displayed
27 2. SYN+ACK Server->Client ETHER: Destination = 0:0:3b:80:e:93, ETHER: Source = 8:0:20:74:f1:2c, Sun ETHER: Ethertype = 0800 (IP) IP: Flags = 0x4 (do not fragment) IP: Protocol = 6 (TCP) IP: Source address = 194.197.118.20, jalopeno.nixu.fi IP: Destination address = 194.197.118.22, mole.nixu.fi TCP: Source port = 25 TCP: Destination port = 35620 TCP: Sequence number = 2371738143 TCP: Acknowledgement number = 760886273 TCP: Flags = 0x12 (ACK, SYN) TCP: Options: (4 bytes) TCP: - Maximum segment size = 1460 bytes SMTP: ""
28 3. ACK Client->Server ETHER: Destination = 8:0:20:74:f1:2c, Sun ETHER: Source = 0:0:3b:80:e:93, ETHER: Ethertype = 0800 (IP) IP: Flags = 0x4 (do not fragment) IP: Protocol = 6 (TCP) IP: Source address = 194.197.118.22, mole.nixu.fi IP: Destination address = 194.197.118.20, jalopeno.nixu.fi TCP: Source port = 35620 TCP: Destination port = 25 (SMTP) TCP: Sequence number = 760886273 TCP: Acknowledgement number = 2371738144 TCP: Flags = 0x10 (ACK) TCP: No options SMTP: ""
29 4. Data Server->Client ETHER: Destination = 0:0:3b:80:e:93, ETHER: Source = 8:0:20:74:f1:2c, Sun ETHER: Ethertype = 0800 (IP) IP: Flags = 0x4 (do not fragment) IP: Protocol = 6 (TCP) IP: Source address = 194.197.118.20, jalopeno.nixu.fi IP: Destination address = 194.197.118.22, mole.nixu.fi TCP: Source port = 25 TCP: Destination port = 35620 TCP: Sequence number = 2371738144 TCP: Acknowledgement number = 760886273 TCP: Flags = 0x18 (ACK, PSH) SMTP: "220-jalopeno.nixu.fi ESMTP Sendmail 8.6.12/8.6.12 ready"
30 5. Reply Client->Server ETHER: Destination = 8:0:20:74:f1:2c, Sun ETHER: Source = 0:0:3b:80:e:93, ETHER: Ethertype = 0800 (IP) IP: Flags = 0x4 (do not fragment) IP: Protocol = 6 (TCP) IP: Source address = 194.197.118.22, mole.nixu.fi IP: Destination address = 194.197.118.20, jalopeno.nixu.fi IP: No options TCP: Source port = 35620 TCP: Destination port = 25 (SMTP) TCP: Sequence number = 760886273 TCP: Acknowledgement number = 2371738258 TCP: Flags = 0x10 (ACK) SMTP: ""
31 6. Data Client->Server ETHER: Destination = 8:0:20:74:f1:2c, Sun ETHER: Source = 0:0:3b:80:e:93, ETHER: Ethertype = 0800 (IP) IP: Flags = 0x4 (do not fragment) IP: Protocol = 6 (TCP) IP: Source address = 194.197.118.22, mole.nixu.fi IP: Destination address = 194.197.118.20, jalopeno.nixu.fi TCP: Source port = 35620 TCP: Destination port = 25 (SMTP) TCP: Sequence number = 760886273 TCP: Acknowledgement number = 2371738258 TCP: Flags = 0x18 (ACK, PSH) SMTP: "QUIT\r\n"
32 7. Ack Server->Client (Containing Data) ETHER: Destination = 0:0:3b:80:e:93, ETHER: Source = 8:0:20:74:f1:2c, Sun ETHER: Ethertype = 0800 (IP) IP: Flags = 0x4 (do not fragment) IP: Protocol = 6 (TCP) IP: Source address = 194.197.118.20, jalopeno.nixu.fi IP: Destination address = 194.197.118.22, mole.nixu.fi TCP: Source port = 25 TCP: Destination port = 35620 TCP: Sequence number = 2371738258 TCP: Acknowledgement number = 760886279 TCP: Flags = 0x18 (ACK, PSH) SMTP: "221 jalopeno.nixu.fi closing connection\r\n"
33 8. Server Starts Closing ETHER: Destination = 0:0:3b:80:e:93, ETHER: Source = 8:0:20:74:f1:2c, Sun ETHER: Ethertype = 0800 (IP) IP: Protocol = 6 (TCP) IP: Source address = 194.197.118.20, jalopeno.nixu.fi IP: Destination address = 194.197.118.22, mole.nixu.fi TCP: Source port = 25 TCP: Destination port = 35620 TCP: Sequence number = 2371738299 TCP: Acknowledgement number = 760886279 TCP: Data offset = 20 bytes TCP: Flags = 0x11 (ACK, FIN) SMTP: ""
34 9. Client Acks Previous Data ETHER: Destination = 8:0:20:74:f1:2c, Sun ETHER: Source = 0:0:3b:80:e:93, ETHER: Ethertype = 0800 (IP) IP: Protocol = 6 (TCP) IP: Source address = 194.197.118.22, mole.nixu.fi IP: Destination address = 194.197.118.20, jalopeno.nixu.fi TCP: Source port = 35620 TCP: Destination port = 25 (SMTP) TCP: Sequence number = 760886279 TCP: Acknowledgement number = 2371738300 TCP: Flags = 0x10 (ACK) SMTP: ""
35 10. Client Starts Closing as Well ETHER: Destination = 8:0:20:74:f1:2c, Sun ETHER: Source = 0:0:3b:80:e:93, ETHER: Ethertype = 0800 (IP) IP: Protocol = 6 (TCP) IP: Source address = 194.197.118.22, mole.nixu.fi IP: Destination address = 194.197.118.20, jalopeno.nixu.fi TCP: Source port = 35620 TCP: Destination port = 25 (SMTP) TCP: Sequence number = 760886279 TCP: Acknowledgement number = 2371738300 TCP: Flags = 0x11 (ACK, FIN) SMTP: ""
36 11.Server Acks Closing ETHER: Destination = 0:0:3b:80:e:93, ETHER: Source = 8:0:20:74:f1:2c, Sun ETHER: Ethertype = 0800 (IP) IP: Flags = 0x4 (do not fragment) IP: Protocol = 6 (TCP) IP: Source address = 194.197.118.20, jalopeno.nixu.fi IP: Destination address = 194.197.118.22, mole.nixu.fi TCP: Source port = 25 TCP: Destination port = 35620 TCP: Sequence number = 2371738300 TCP: Acknowledgement number = 760886280 TCP: Flags = 0x10 (ACK) SMTP: ""
Automatic Repeat Request
38 Reliable Communications with Retransmission How to transport data units over an unreliable data link in a reliable way? End to End E.g.. TCP Hop by Hop E.g..X.25, HDLC Answer: ARQ Automatic Repeat Request ARQ is an abstract concept, not a protocol itself Used in many protocols for reliable transmission There are several different versions of the basic concept
39 Basic ARQ Data (SDUs) is divided/packaged to packets (PDUs) that contain a header and checksum These are called information frames There are also empty packets called control frames And there is a timeout mechanism Sender 1. A packet is sent 3. A packet is re-sent after a timeout Packets in transit 2. A packet is lost Receiver 4. A simple acknowledgment is sent Problem: what if a frame is received and acknowledged after the timeout at sender s end?
40 ARQ Sequence Numbers It is possible for the sender and receiver to get out of synchronization A problem that all protocols must address Sender and receiver can be synchronized by having a sequence number in each frame In theory one bit sequence number would be sufficient for stop-and-wait ARQ Stop-and-wait means that only one frame is in transmission at one time One bit sequence number is not sufficient if the network may duplicate frames Stop and wait is not very efficient in most cases Larger sequence numbers allow multiple frames to be in transit
41 ARQ Control Frames ACK, acknowledgment NAK, negative acknowledgment ENQ, enquiry
42 ARQ Stop-and-Wait Frame Loss Handling One frame is sent at a time Rule: the information (data transporting) frames are ACKed, control frames not When a frame is lost: 1) Sender retransmits after timeout or 2) ENQ is replied with the last frame sent Sender sends ENQ after timeout Receiver sends last ACK sent Enables re-synchronization
43 Go-Back-N ARQ Frame Loss Handling A sufficiently large sequence number and a sliding window are used Receiver ACKs only frames in sequence When an information frame is lost, it and all frames sent after it must be retransmitted Frame loss is recognized either from timeout or the receiver sends a NAK when it receives a frame out of sequence The receiver requires a buffer the size of one frame The sender has to have a buffer that holds all frames that have been transmitted but not ACKed If the ACK control frame is lost, a later ACK can replace it This increases the efficiency of bandwidth usage compared to stop-and-wait ARQ Latency is a problem for stop-and-wait ARQ TCP implements this
44 Selective Repeat ARQ Frame Loss Handling When the receiver receives a frame out of sequence, it sends a NAK for the missing frame and that frame only is resent More complex for the receiver, requires a larger receive buffer This is more efficient for channels with large error rates than Go-Back-N ARQ