1. Chapter 3 Transport Layer Tami Meredith

2. A protocol defines: 1. Message Format (Syntax) 2. Rules of Communication (Semantics) 3. Synchronisation and other application details (Implementation)

4.  Applications send each other messages; e.g., http request, http response  Transport layer ensures these messages into pieces called segments (sometimes called datagrams when UDP is used)  The transport layer exists only in end-systems  Network layer handles the intermediate systems  Application layer: communication between processes  Transport layer: communication between hosts

5.  Note: IP provides unreliable service 1. Reliable data transfer  In correct order  Error free 2. Congestion control (prevent links getting swamped or overloaded) 3. Multiplexing and de-multiplexing of multiple (application/process-level) communications

6.  Multiplexing: Collecting the messages from each port/application-socket and combining them into a single data stream  Demultiplexing: Taking the incoming segments and separating them by port/application- socket  Transport layer messages thus have source port number and destination port number fields (port number is NOT a socket id)

7. 1. UDP uses destination host and destination port to route  Packets from different hosts all arrive at the same socket  UDP socket defined by destination host:port 2. TCP builds a connection between two processes and thus the source info is also needed  Packets from different hosts go to different ports  TCP socket defined by both source and destination host:port

8.  User Datagram Protocol  Bare-bones and minimal transport protocol  Adds almost nothing to IP  Only fields (above IP) 1. Source port – 2 bytes 2. Destination port – 2 bytes 3. Segment length – 2 bytes 4. Checksum – 2 bytes

9.  Finer grained application control – no congestion control, re-ordering, acknowledgements etc., just quick fast simple transmission attempts  No connection overhead, construction, take- down, or state maintenance  Minimal packet overhead, little extra data to transmit

10.  Remote file servers using NFS  Network management (SNMP) – since SNMP run when network is in stressed state  Name translation (DNS) – so common it must be fast  Routing (RIP) – frequent updates, lost data not significant  Streaming multimedia/telephony using proprietary application protocols - avoids overhead of congestion control (reliability is performed at the application level instead)

11.  Reliability should exist on an end-to-end level and this is properly done at the highest level (not the lowest)  Even if IP does not detect an error, data could be corrupted when being transferred from the modem to the socket’s memory  Calculating the checksum (RFC 1071)  Sum all 16 bit words with overflow wrap around  Take 1’s complement  Using the checksum  Add the checksum to the sum of all 16 bit words which should generate 11…11

12.  States (circles) – must be in one  Transitions (arrows) – taken when event happens  Deterministic – no choice when an event occurs

13. 1. All bits arrive (i.e. none are lost) 2. In the order they were sent (i.e., not reordered) 3. As they were sent (i.e., unflipped)  This is difficult to do!  One of the fundamental challenges of networking

14.  Assumes underlying channel is error free and can send data as fast as it is produced  Two finite state machines exist (Fig 3.9): 1. Sender  state1: Wait for a send Event: Send Requested Action: Make packet and sent it, go to state1 2. Receiver  StateA: Wait for an incoming packet  Event: Packet Arrives  Action: Remove header and deliver it, go to stateA

15.  Assumes that all packets are received (none are lost)  Packets may be corrupted (bit errors)  Positive acknowledgements: received OK, ACK  Negative acknowledgements: not understood, NAK  Often known as ARQ (Automatic Repeat reQuest) protocols

17.  Introduce a new packet, RPT, “Repeat last ACK or NAK”  Replace checksum with ECC protocol (but doesn’t work later when we consider lost packets)  Add a sequence number so that we can resend last packet and treat garbled ACK as NAK

19.  Alternative to RDT 2.1 except that NAK not used  If a packet is corrupted, the ACK of the last correctly received packet is sent  Need to add sequence numbers to ACK  Still handles the same issues – garbled packets only, not loss tolerant  Not really any simpler – Is {ACK0, ACK1} different from {ACK, NAK} but builds framework for RDT 3

20.  Channel now permitted to lose packets and garble them  Sender retransmits when no ACK received in a timely manner (uses a countdown timer)  Also considers that packets can be duplicated  Puts burden of work on the sender (alternatives which focus on the receiver are also possible)  No ACK = Packet lost/delayed, ACK lost/delayed  Uses checksums, sequence numbers, timers, ACK, and NAK  Known as an alternating bit protocol  Problem is that it is stop and wait – tooooo slow!

22.  Utilisation of connection using stop and wait is very low, often down around 1%!  Pipelining permits a burst of packets to be sent until such time as an ACK is expected  Requires more buffering  Multiple parts could be lost  Protocols more complicated  Two basic approaches used 1. Go-Back-N 2. Selective Repeat

23.  Also known as a sliding window protocol  N is the window size (number of packets that have not been ACK’d)  Sequence numbers now needed in headers  ACK is used for cumulative acknowledgement  When timer expires all unacknowledged packets are resent  Provides some rudimentary congestion control

27.  If n is large and the first packet is lost, GBN can require many packets to be resent and waste bandwidth – only the missing packets need to be resent  Selective repeat addresses this issue

29.  Connection oriented  Not a persistent physical connection but an endhost-to-endhost logical connection  Point-to-point – not multicast  Full duplex – both endhosts can transmit simultaneously  Three way (3 segments) handshake for connection establishment – 3 rd segment may have payload

32.  Sequence number = byte offset (into entire message) of the first byte of payload data  Acknowledgement number = sequence number (offset) of the next byte expected  Cumulative acknowledgement (like GBN)  When an out of order packet arrives, it is NOT required that the packet is kept (but it almost always is)

33.  How long do we wait before doing a retransmit?  Needs to be longer than the RTT (round trip time)  Estimated RTT is a exponential weighted moving average (most recent packets have more weight)  DevRTT is the deviation that segments can show  Timeout = EstimatedRTT + 4 * DevRTT  Start at 1 second  ONLY 1 TIMER!

34.  No one “right” way to implement TCP  Various implementations exist due to the freedom allowed by the RFC  The text gives one correct and possible implementation  Event Based: 1. Send (App. Layer provides data) 2. Timeout by timer 3. ACK received

36. Fast Retransmit (n=3)

37.  The timeout is doubled in duration every time a timer expiry event occurs  Intervals grow exponentially after every retransmission  Helps perform congestion control since retransmission is probably due to congestion

38.  Matching send rate to the rate at which the receiver is receiving  Trying to avoid receivers buffer from overflowing  Is influenced by congestion but is NOT the same thing  Uses the Receive Window field of the header  Not static – changes constantly

39.  Window is the amount of spare room in the buffer  Reading moves data from buffer to application  = BufSize – [data in buffer]  = BufSize – [LastByteRcvd – LastByteRead]  Sender must also account for packets “in transit” (sent but not acknowledged)  If window = 0, still send one byte data packets to force a response containing an updated window size

42.  Large queuing delays as packet arrival nears link capacity  Retransmissions to compensate for lost packets due to buffer overflow  Unneeded retransmissions due to large delays (and subsequent timeouts)  Wasted bandwidth for packets that don’t make it all the way to the destination

43.  Network Assisted Congestion Control (Not possible since IP does not provide support) 1. Choke packet 2. Congestion field set by router  End-to-end Congestion Control (TCP approach)  Presence of congestion is inferred and each application acts independently to reduce it

44.  A lost segment implies congestion  ACK indicates reception and sending rate can be increased  Cyclical Probing  Increase rate until loss occurs  Decrease rate because loss occurs  Go back to increasing …  Three components to algorithm:  Slow start  Congestion avoidance  Fast recovery