The Transport Layer. Part 1

Transcription

1 The Transport Layer Part 1

2 2 OVERVIEW Part 1 User Datagram Protocol Transmission Control Protocol ARQ protocols Part 2 TCP congestion control Mowgli XTP SCTP WAP

3 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 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 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 6 A UDP (DNS) Session Snoop 23 riku@mole $ dig a ;; got answer: ;; QUESTIONS: ;; tapas.nixu.fi, type = A, class = IN ;; ANSWERS: tapas.nixu.fi A ;; AUTHORITY RECORDS: nixu.fi NS ns2.tele.fi. nixu.fi NS ns.nixu.fi. nixu.fi NS ns.tele.fi. ;; ADDITIONAL RECORDS: ns2.tele.fi A ns.nixu.fi A ns.tele.fi A ns.tele.fi A ;; Total query time: 88 msec ;; FROM: mole.nixu.fi to SERVER: ;; MSG SIZE sent: 31 rcvd: riku@mole $

7 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 8 DNS Query, IP Header IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx.... = 0 (precedence) IP: = normal delay IP: = normal throughput IP: = normal reliability IP: Total length = 59 bytes IP: Identification = 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 = , mole.nixu.fi IP: Destination address = , jalopeno.nixu.fi IP: No options

9 9 DNS Query, UDP Header UDP: Source port = UDP: Destination port = 53 (DNS) UDP: Length = 39 UDP: Checksum = E34A

10 10 DNS Query, Headers and Data 0: f12c b80 0e t.,..;...e. 16: 003b 8b ff11 7e65 c2c : b e34a 000a v...5.'.j... 48: e tapas.nix 64: u.fi... From now on only relevant portions of the headers will be displayed

11 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 = , jalopeno.nixu.fi IP: Destination address = , mole.nixu.fi UDP: Source port = 53 UDP: Destination port = UDP: Length = 183 UDP: Checksum = AD48

12 12 DNS Reply Headers and Data 0: b80 0e f12c ;... t.,..e. 16: 00cb 7a ff11 8ed6 c2c : b5 00b7 ad48 000a v..5...h... 48: e tapas.nix 64: c0 0c u.fi some reply data deleted : 087b db00 04c1 d f.{...

13 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 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 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 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 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 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 19 Establishing a TCP Connection The three-way handshake active open Client SYN SYN + ACK ACK Server passive open

20 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 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 22 A Snooped SMTP Session 24 riku@mole $ telnet jalopeno 25 Trying Connected to jalopeno. Escape character is '^]'. 220-jalopeno.nixu.fi ESMTP Sendmail / ready at Sat, 5 Oct :24: ESMTP spoken here QUIT 221 jalopeno.nixu.fi closing connection Connection closed by foreign host. 25 riku@mole $

23 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 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: = normal delay IP: = normal throughput IP: = normal reliability IP: Total length = 44 bytes IP: Identification = 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 = , mole.nixu.fi IP: Destination address = , jalopeno.nixu.fi IP: No options

25 25 1. SYN Client->Server (TCP Header) TCP: Source port = TCP: Destination port = 25 (SMTP) TCP: Sequence number = TCP: Acknowledgement number = 0 TCP: Data offset = 24 bytes TCP: Flags = 0x02 TCP: = No urgent pointer TCP: = No acknowledgement TCP: = No push TCP: = No reset TCP: = Syn TCP: TCP: Window = 8760 TCP: Checksum = 0x17a1 TCP: Urgent pointer = = No Fin TCP: Options: (4 bytes) TCP: - Maximum segment size = 1460 bytes

26 26 1. SYN Client->Server (SMTP Data) SMTP: "" From now on only relevant portions of the headers will be displayed

27 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 = , jalopeno.nixu.fi IP: Destination address = , mole.nixu.fi TCP: Source port = 25 TCP: Destination port = TCP: Sequence number = TCP: Acknowledgement number = TCP: Flags = 0x12 (ACK, SYN) TCP: Options: (4 bytes) TCP: - Maximum segment size = 1460 bytes SMTP: ""

28 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 = , mole.nixu.fi IP: Destination address = , jalopeno.nixu.fi TCP: Source port = TCP: Destination port = 25 (SMTP) TCP: Sequence number = TCP: Acknowledgement number = TCP: Flags = 0x10 (ACK) TCP: No options SMTP: ""

29 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 = , jalopeno.nixu.fi IP: Destination address = , mole.nixu.fi TCP: Source port = 25 TCP: Destination port = TCP: Sequence number = TCP: Acknowledgement number = TCP: Flags = 0x18 (ACK, PSH) SMTP: "220-jalopeno.nixu.fi ESMTP Sendmail / ready"

30 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 = , mole.nixu.fi IP: Destination address = , jalopeno.nixu.fi IP: No options TCP: Source port = TCP: Destination port = 25 (SMTP) TCP: Sequence number = TCP: Acknowledgement number = TCP: Flags = 0x10 (ACK) SMTP: ""

31 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 = , mole.nixu.fi IP: Destination address = , jalopeno.nixu.fi TCP: Source port = TCP: Destination port = 25 (SMTP) TCP: Sequence number = TCP: Acknowledgement number = TCP: Flags = 0x18 (ACK, PSH) SMTP: "QUIT\r\n"

32 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 = , jalopeno.nixu.fi IP: Destination address = , mole.nixu.fi TCP: Source port = 25 TCP: Destination port = TCP: Sequence number = TCP: Acknowledgement number = TCP: Flags = 0x18 (ACK, PSH) SMTP: "221 jalopeno.nixu.fi closing connection\r\n"

33 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 = , jalopeno.nixu.fi IP: Destination address = , mole.nixu.fi TCP: Source port = 25 TCP: Destination port = TCP: Sequence number = TCP: Acknowledgement number = TCP: Data offset = 20 bytes TCP: Flags = 0x11 (ACK, FIN) SMTP: ""

34 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 = , mole.nixu.fi IP: Destination address = , jalopeno.nixu.fi TCP: Source port = TCP: Destination port = 25 (SMTP) TCP: Sequence number = TCP: Acknowledgement number = TCP: Flags = 0x10 (ACK) SMTP: ""

35 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 = , mole.nixu.fi IP: Destination address = , jalopeno.nixu.fi TCP: Source port = TCP: Destination port = 25 (SMTP) TCP: Sequence number = TCP: Acknowledgement number = TCP: Flags = 0x11 (ACK, FIN) SMTP: ""

36 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 = , jalopeno.nixu.fi IP: Destination address = , mole.nixu.fi TCP: Source port = 25 TCP: Destination port = TCP: Sequence number = TCP: Acknowledgement number = TCP: Flags = 0x10 (ACK) SMTP: ""

37 Automatic Repeat Request

38 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 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 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 41 ARQ Control Frames ACK, acknowledgment NAK, negative acknowledgment ENQ, enquiry

42 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 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 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