1 / 26

Ch 3. Transport Layer

Myungchul Kim mckim@icu.ac.kr. Ch 3. Transport Layer. Logical communication between application processes running on different hosts A network-layer protocol provides logical communication between hosts.

turner
Download Presentation

Ch 3. Transport Layer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Myungchul Kim mckim@icu.ac.kr Ch 3. Transport Layer

  2. Logical communication between application processes running on different hosts • A network-layer protocol provides logical communication between hosts. • A transport protocol can offer reliable data transfer service to an application even when the underlying network protocol is unreliable. • IP service model: best-effort delivery service • UDP: unregulated

  3. Fig 3.1

  4. Intermediate routers neither act on, nor recognize, any information that the transport layer may have added to the application messages. • Transport-layer multiplexing: extending host-to-host delivery to process-to-process delivery

  5. Multiplexing and Demultiplexing • Host-to-host delivery vs process-to-process delivery • Multiplexing • Demultiplexing • Transport-layer multiplexing • Sockets have unique identifiers • Each segment have special fields, port number fields, that indicate the socket to which the segment is to be delivered. • Port number: 16-bit number: from 0 to 65535, well-known port numbers from 0 to 1023. e.g., HTTP (80), FTP(21) • Fig 3.3

  6. A UDP socket is fully identified by a two-tuple consisting of a destination IP address and a destination port number. • Fig 3.4

  7. A TCP socket is identified by a 4-tuple: (source IP address, source port number, destination IP address, destination port number). • In contrast with UDP, two arriving TCP segments with different source IP addresses or source port numbers will be directed to two different sockets. • The HTTP server distinguishes the segments from the different clients by the source IP addresses and source port numbers. • Persistent HTTP vs Nonpersistent HTTP

  8. Fig 3.5

  9. UDP • Multiplexing and demultiplexing • Light error checking • The application is almost directly talking with IP. • Connectionless • No handshaking • Merits • No connection establishment -> no delay • No connection state • Small packet header overhead: TCP(20), UDP(8 bytes) • Finer application-level control over what data is sent, and when. • How about congestion due to UDP? • New mechanism to force all sources including UDP sources to perform adaptive congestion control. • Applications have built acknowledgements and retransmissions into the applications.

  10. Fig 3.6

  11. UDP segment structure • Fig 3.7 • UDP checksum • For error detection • UDP at the sender side performs the 1’s complement of the sum of all the 16-bit words in the segment. • At the receiver, all four 16-bit words are added, including the checksum. • If no errors, 111.111. If one of the bits is a zero, then errors. • No recovery from an error.

  12. Principles of Reliable Data Transfer • The transport layer, the link layer and the application layer • Fig 3.8

  13. Reliable data transfer over a Perfectly Reliable Channel: rdt1.0 • Separate FSM • Event/action • Initial state • Fig 3.9 • No difference between a unit of data and a packet • No feedback: reliable channel • No flow control

  14. Reliable data transfer over a Channel: rdt2.0 • Bits in a packet may be corrupted • All transmitted packets are received in the order in which they were sent. • Positive ack and negative ack • ARQ(Automatic Repeat reQuest) protocols • Capabilities handling the presence of bit errors: • Error detection • Receiver feedback: a 0 value indicate a NAK and a value of 1 could indicate an ACK • Retransmission

  15. Fig. 3.10

  16. Reliable data transfer over a Channel: rdt2.0 • When the receiver is in the wait-for-ACK-or-NAK state, it cannot get more data from the upper layer. • Stop-and-wait protocol • Drawbacks • The ACK or NAK packet could be corrupted. -> checksum • How the protocol should recover from errors in ACK or NAK packets. • A one-bit sequence number: allow the receiver to know whether the sender is sending the previously transmitted packet. • Since we are currently assuming a channel that does not lose packets, ACK and NAK packets do not themselves need to indicate the sequence number of the packet they are acknowledging. • When an out-of-order packet is received, the receiver sends a positive acknowledgement for the packet it has received. -> duplicate ACKs • When a corrupted packet is received, the receiver sends a negative acknowledgement.

  17. Fig. 3.11

  18. Fig. 3.12

  19. Reliable data transfer over a Lossy Channel with Bit Errors: rdt3.0 • How to detect packet loss and what to do when packet loss occurs • Use of checksuming, sequence numbers, ACK packets and retransmissions • Choose a time value such that packet loss is likely, although not guaranteed, to have happened. • Duplicate data packets. • A delayed ACK: with an acknowledgement field • Alternating-bit protocol

  20. Fig. 3.15

  21. Fig. 3.16

  22. Pipelined reliable data transfer protocols • RTT: 30msec between the coasts, ttrans = L/R = 8000bits/packet / 109 bits/sec = 8 microsec • Utilization of the channel: Usender = L/R / RTT + L/R = 0.00027 • Effective throughput = 267kbps on 1Gbps • Pipelining : the sender is allowed to send multiple packets without waiting for acknowledgements. • The range of sequence numbers must be increased. • The sender and receiver sides of the protocols may have to buffer more than one packet. • Go-Back-N and Selective Repeat approaches

  23. Go-Back-N (GBN) • No more than some max allowable number, N, of unacknowledged packets in the pipeline • Base: the seq number of the oldest unacknowledged packet • Nextseqnum: the smallest unused sequence number (= the seq number of the next packet to be sent) • Fig 3.19 • [0, base-1], [base, nextseqnum-1], [nextseqnum, base+N-1], [base+N, ] • Window size, sliding-window protocol

  24. EFSM of GBN sender • Invocation from above • Cumulative acknowledgement: all packets with a seq number up to and including n have been correctly received at the receiver. • A timeout event for the oldest transmitted but not yet acknowledged packet. • EFSM of GBN sender • The receiver discards out-of-order packets • The receiver need not buffer any out-of-order packets.

  25. Selective Repeat (SR) • When the window size and bandwidth-delay product are both large, many packets can be in the pipeline. • The sender retransmit only those packets that it suspects were received in error (were lost or corrupted) • The receiver individually acknowledge correctly received packets. • The sender will have already received ACKs for some of the packets in the window. • Synchronization between sender and receiver windows -> the window size must be less than or equal to half the size of the seq number space for SR protocols.

  26. Synchronization between sender and receiver windows -> the window size must be less than or equal to half the size of the seq number space for SR protocols.

More Related