Chapter 3 Transport Layer Tami Meredith. A protocol defines: 1. Message Format (Syntax) 2. Rules of Communication (Semantics) 3. Synchronisation and other.

CSCI 3421DATA COMMUNICATIONS

AND NETWORKING

Chapter 3Transport Layer

Tami Meredith

Layered Protocol ModelA protocol defines:

1. Message Format (Syntax)

2. Rules of Communication (Semantics)

3. Synchronisation and other application details (Implementation)

TCP/IP Protocol Suite

Logical Communication

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

Transport Services

Note: IP provides unreliable service1. 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

Multiplexing

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)

Sockets and Ports

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

UDP: “Unreliable” Data Transfer

User Datagram Protocol Bare-bones and minimal transport

protocol Adds almost nothing to IP Only fields (above IP)

1. Source port – 2 bytes2. Destination port – 2 bytes3. Segment length – 2 bytes4. Checksum – 2 bytes

Advantages

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

Users of UDP

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)

Reliability

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

Finite State Automata

States (circles) – must be in one Transitions (arrows) – taken when event

happens Deterministic – no choice when an event

occurs

TCP: Reliable Data Transfer

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

RDT 1.0

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 RequestedAction: 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

RDT 2: Stop and Wait

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

RDT 2.0

Issue: What if anACK or a NAKis corrupted?

Solutions

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

RDT 2.1

RDT 2.2

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

RDT 3

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!

Pipelining

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-N2. Selective Repeat

GBN

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

GBNn=4

Selective Repeat

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

TCP

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 – 3rd segment may have payload

MSS (Max Seg Size) = MTU (Data Link Layer) – TCP/IP Header Data = Maximum segment payload sizeSegments sent at own convenience (RFC 793)

TCP Segment

Sequence & ACK Numbers

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)

Timeouts [RFC6298]

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!

TCP Implementations

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 timer3. ACK received

TCP Operation (1)

TCP Operation (2)

Fast Retransmit (n=3)

Timeout Doubling

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

Flow Control

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

Window Size

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

3 Way Handshake

Closing a Connection

Causes of Congestion

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

Solutions

Network Assisted Congestion Control (Not possible since IP does not provide support)

1. Choke packet2. 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

TCP Principles

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