Scribd
Upload
179 views

Computer Networks Chapter 3 Transport Layer - Part I Notes

This document summarizes transport layer services and protocols. It discusses how transport protocols like TCP and UDP provide logical communication between application processes running on different hosts. TCP provides reliable, in-order delivery while UDP provides unreliable, unordered delivery. It also covers how transport layer protocols are multiplexed and demultiplexed to direct data to the appropriate application process using port numbers and IP addresses. The document then discusses principles of reliable data transfer, introducing concepts like checksums, acknowledgments, sequence numbers, timeouts and retransmissions that are used to build reliable data transfer protocols over unreliable channels. It also covers pipelined protocols like Go-back-N and Selective Repeat that improve throughput.

Uploaded by

derguenhart
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
179 views

Computer Networks Chapter 3 Transport Layer - Part I Notes

This document summarizes transport layer services and protocols. It discusses how transport protocols like TCP and UDP provide logical communication between application processes running on different hosts. TCP provides reliable, in-order delivery while UDP provides unreliable, unordered delivery. It also covers how transport layer protocols are multiplexed and demultiplexed to direct data to the appropriate application process using port numbers and IP addresses. The document then discusses principles of reliable data transfer, introducing concepts like checksums, acknowledgments, sequence numbers, timeouts and retransmissions that are used to build reliable data transfer protocols over unreliable channels. It also covers pipelined protocols like Go-back-N and Selective Repeat that improve throughput.

Uploaded by

derguenhart
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Transport-Layer services

Transport services and protocols


provide logical communication between app processes running on different hosts
transport protocols run in end systems
send side: breaks app message into segments, passes to network layer
rcv side: reassembles segments into messages, passes to app layer
more than one transport protocol available to apps
Internet: TCP and UDP

Transport vs. network layer


network layer:
logical communication between hosts

transport layer:
logical communication between processes

relies on & enhances, network layer services

Internet transport-layer protocols


UDP
unreliable, unorderd delivery
no frills extension of best effort IP

TCP
reliable, in-order delivery
congestion control
flow control
connection setup

services not availeble:

delay guarantees
bandwidth guarantees
Multiplexing and demultiplexing
Multiplexing/demultiplexing
Multiplexing
gatherng data from multiple sockets, enveloping data with header
Demultiplexing
delivering received segments to correct socket

How demultiplexing works


host recoives IP datagrams
each datagram has source IP address, destination IP address
each datagram carries 1 transport-layre segment
each segment has source, destination port number
host uses IP addresses & port numbers to direct segment to appropriate socket

Connectionless demultiplexing
When host receives UDP segment:
checks dest. port number in segment
directs UDP segment to socket with that port number
IP datagrams witch different source IP addresses and/or source port numbers
directed to same socket
UDP socket identified by two-tuble:
dest. IP address, dest. port number

Connection-oriented demux
TCP socket identified by 4-tuble:
source IP address
source port number
dest IP address
dest port number
recv host uses all four values to direct segment to appropriate socket
Server host may support many simultaneous TCP sockets:
each socket identified by its own 4-tuple
Web servers have different sockets for each connecting client
Connectionless transport: UDP
The Problem with TCP
TCP offers a reliable and easy to use transport protocol to programmers
Congestion control
Retransmissions etc.
However congestion control imposes transmission-rate constraints
If a traffic jam is detected on a path, sender decreases sending rate dramatically
Problem: One cannot switch off funcions of TCP ex. Congestion control

UDP: User Datagram Protocol


no frills, bare bones Internet transport protocol
best effort service, UDP segments may be:
lost
delivered ouf of order to app
connectionless:
no handshaking between UDP sender, receiver
each UDP segment handeld independently of others
often used for streaming multimedia apps
loss tolerant
rate senitive
other UDP uses
DNS
SNMP
reliable tronsfer over UDP: add reliability ot application layer
application-specific error recovery!
ex. ACK/NAK, retransmissions (non trivial)

UDP checksum

Goal: detect errors e.g., flipped bits in transmitted segment

Sender:

treat segment contens as sequence of 16-bit integers


checksum: addition 1'complement sum of segment contens
sender puts checksum value into UDP checksum field

Receiver:

compute checksum of received segment


check if computed checksum equals checksum field value:
NO - error detected
YES - no error detected, But maybe errors nonetheless?

Why error detection in the first place?

Link Layer provides CRC! (Ethernet)

No guarantee for:

link to link reliability e.g. non ethernet


memory error detection on routers

IP is designed to run on any layer 2 protocol

End to end error detection is safety measure

UDP does not recover from errors

Principles of reliable data transfer


Reliable data franfer: getting started
We'll:

incrementally develop sender, receiver sides of reliable data tansfer protocol (rdt)
consider only unidirectional data transfer
but control info will flow on both directions!
use finite state machine (FSM) so specify sender, receiver
Use generic term packet rather than segment

Finite State Machine


FSM is a model of behavior composed of a finite number of
states
transitions between states on events
actions taken upon events
Necessary to define the behavior of our protocol, prior to implementation

Rdt1.0: reliable transfer over a reliable channel


Assumption: underlying channel perfectly reliable
no bit errors
no loss of packets
separate FSMs for sender, receiver:
sender sends data into underlying channel
receiver read data from underlying channel

Rdt2.0 channel with bit errors


underlying channel may flip bits in packet
checksum to detect bit errors
the question: how to recover from errors?
acknowledgments (ACKs): receiver explicitly tells sender that pkt received OK
negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had
errors
sender retransmits pkt on receipt of NAK
new mechanisms in rdt2.0(beyond rdt1.0)
error detection
receiver feedback: control msgs (ACK, NAK) rcvr -> sender
Automatic Repeat reQuest type of protocol (ARQ)

What happens if ACK/NAK corrupted?


sender doesn't know what happend at receiver!
can't just retransmit: possible duplicate

Handling duplicates:
sender retransmits current pkt if ACK/NAK garbled
sender adds sequence number to eacht pkt
receiver discards (doesn't deliver up) duplicate pkt

Using only ACK + Sequence:


We can discard NAK packets, by using only ACK + Seq.#
duplicate ACK at sender results in same action as NAK: retransmit current pkt
rdt2.2: discussion
Sender:

seq # added to pkt


two seq. #'s (0,1) will suffice. Why?
must check if received ACK corrupted
twice as many states

- state must remember whether current pkt has 0 or 1 seq. #

Receiver:
must check if received packet is duplicate
state indicates whether 0 or 1 is expected pkt seq #
note: receiver can not know if its last ACK received OK at sender

rdt3.0: channels with errors and loss


New assumption: underlying channel can also lose packets(data or ACKs)

checksum, seq. #, ACKs, retransmissions will be of help, but not enough

Approach: sender waits reasonable amount of time for ACk


retransmits if no ACK received in this time
if pkt (or ACK) just delayed (not lost)
retransmission will be duplicate, but use of seq. #'s already handles this
receiver must specify seq. # of pkt being ACKed
requires countdown timer
rdt3.0 works, but performance stinks
1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link

Pipelined protocols
Pipelining: sender allows multiple, in-flight, yet-to-be-acknowledged pkts

- range of sequence numbers must be increased

- buffering at sender and/or receiver

Two generics forms of pipelined protocols: go-Back-N, selective repeat

Go-back-N: big picture:


Sender can have up to N unacked packets in pipeline
Rcvr only sends cumulative acks
Doesn's ack packet if there's a gap
Sender has timer for oldest unacked packet
If timer expires, retransmit all unacked packets

Selective Repeat: big pic


Sender can have up to N unacked packets in pipeline
Rcvr acks individual packets
Sender maintains timer for each unacked packet
When timer expires, retransmit only unack packet

You might also like