Scribd
Upload
10 views46 pages

Lecture-8-Transport Layer-Part-1

Uploaded by

jamashaima3
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
10 views46 pages

Lecture-8-Transport Layer-Part-1

Uploaded by

jamashaima3
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 46

Part 1

Transport Layer

Reliable Transport Protocols

Transport layer 1
Transport Layer
Chapter goals: Chapter Overview:
 understand principles  transport layer services
behind transport layer  multiplexing/demultiplexing
services:  connectionless transport: UDP
 multiplexing/demultiplexing
 principles of reliable data transfer
 reliable data transfer
 flow control  connection-oriented transport:
 congestion control
TCP
 reliable transfer
 flow control
 instantiation and
implementation in the  connection management
Internet  principles of congestion control
 TCP congestion control

Transport layer 2
4
Each layer solves a subset
of Ethernet Frame • Link layer: shares a physical
MAC addresses, CRC, etc. channel among several
transmitters/receivers
IP Packet
Ethernetproblems
IP addresses, TTL, etc. • Network layer: routes from
payload source to destination, along
TCP Segment many hops.
IP #, ack
Port #, sequence
payload • Transport layer:
HTTP#,Response
etc. • Creates connections/sockets
TCP
status code, used by apps.
payload etc.
content-type, • Multiplexing (>1 connection
per machine)
<html><body><h1 • Ordering, •
taerg yM> Acknowledgement, •Pacing
Transport services and protocols
 provide logical communication application
transport
between app’ processes network
running on different hosts data link network
physical data link
network
 implemented in end systems, data link
physical

but not in network routers physical


network
 transport vs network layer data link
physical network
services: data link
physical
 network layer: data transfer network
between end systems data link
physical
 transport layer: data
application
transfer between processes transport
• relies on, enhances, network
data link
network layer services physical

• Constrained by service
model of Network-layer Let’s look at a simple
protocol
analogy to see their
subtle differences
Transport layer 4
Transport Layer vs. Network Layer

hosts (also called end systems) = ?


processes = ?
application messages = ?
network layer protocol = ?
transport layer protocol = ?

Transport layer 5
Transport Layer vs. Network Layer
Their services are constrained by the
possible services that the postal service
provides

hosts (also called end systems) = houses


processes = cousins
application messages = letters in envelope
transport layer protocol = Uncle Sam and Uncle Bill
network layer protocol = postal service (including
mail persons)
It may so happen that their uncles
could get sick, and so other people
may take over – analogously, the
computer network may provide
Transport layer 6
multiple transport protocols
Transport Layer vs. Network Layer

Transport Layer Network Layer


❑ logical communication ❑ logical communication
between processes between end systems
❑ moves messages from application
process to the network layer and
vice-versa: Sending & Receiving
sides
❑ computer network can make
multiple transport layer protocols
available
• TCP
• UDP

❑ process-to-process ❑ host-to-host communication


communication

Transport layer 7
Logical Communication

sending receiving

• converts messages to 4-PDUs • receives 4-PDUs


Breaks down application messages • removes transport header
into smaller chunks + transport layer • reassembles the messages
header = 4-PDUs • passes to receiving
• Network Layer: Each 4-PDU encapsulated into a application process
Transport layer 8
3-PDU
Transport-layer protocols
Internet transport services: application
transport
1. reliable, in-order unicast network
data link network
delivery (TCP) physical data link
network physical
data link
 congestion physical
network
 flow control data link
physical network
 connection setup data link
physical
2. unreliable (“best-effort”), network
unordered unicast or data link
physical
multicast delivery: UDP
application
 services not available: transport
network
 real-time data link
physical
 bandwidth guarantees
 reliable multicast

Critical Function: Extend IP’s service from host-to-host delivery to


process-to-process delivery. Transport layer 9
Multiplexing/demultiplexing
Recall: segment - unit of data
Demultiplexing: delivering
exchanged between
received segments to
transport layer entities correct app layer processes
 aka TPDU: transport
protocol data unit
receiver
P3 P4
application-layer M M
data
application
segment P1 transport P2
header M
M network
application application
segment Ht M transport transport
network
Hn segment network

Transport layer 10
Multiplexing / demultiplexing
Multiplexing:
gathering data from multiple 32 bits
app processes, enveloping
data with header (later used source port # dest port #
for demultiplexing)
other header fields
multiplexing/demultiplexing:
 based on sender, receiver
port numbers, IP addresses
application
 source, dest port #s in
data
each segment (message)
 recall: well-known port
numbers for specific
applications TCP/UDP segment format

Ports: 0-1023 are well-known and restricted, complete list:


www.iana.org, RFC 3232 Transport layer 11
Multiplexing/demultiplexing: examples

source port: x Web client


host A dest. port: 23 server B host C

source port:23
dest. port: x
Source IP: C Source IP: C
Dest IP: B Dest IP: B
source port: y source port: x
port use: simple telnet app dest. port: 80 dest. port: 80

Source IP: A
Dest IP: B
source port: x
Web
Web client dest. port: 80 server B
host A
port use: Web server

How does a Web Server allow for multiple clients connecting to


Transport layer 12
it at the same time if it’s using TCP?
UDP: User Datagram Protocol [RFC 768]
 “no frills,” “bare bones” TCP – 20 bytes, UDP – 8 bytes
Internet transport protocol
Why is there a UDP?
 “best effort” service, UDP
segments may be:  no connection establishment
(which can add delay)
 lost
 simple: no connection state
 delivered out of order to
at sender, receiver
app
 small segment header
 connectionless:
 no congestion control: UDP
 no handshaking between
can blast away as fast as
UDP sender, receiver
desired
 each UDP segment
handled independently of
others

Additional functionalities are implemented by the application


Transport layer 13
UDP: more
For segment error checking

 often used for streaming 32 bits


multimedia apps source port # dest port #
Length, in
 loss tolerant
bytes of UDP length checksum
 rate sensitive segment,
 other UDP uses (why?): including
header
 DNS
 SNMP Application
 reliable transfer over UDP: data
add reliability at application (message)
layer
 application-specific error
recover! UDP segment format

Transport layer 14
UDP checksum

Goal: detect “errors” (e.g., flipped bits) in transmitted


segment

Sender: Receiver:
 treat segment contents as  compute checksum of received
sequence of 16-bit integers segment
 checksum: addition (1’s  check if computed checksum
complement sum) of segment equals checksum field value:
contents  NO - error detected
 sender puts checksum value  YES - no error detected.
into UDP checksum field But maybe errors
nonetheless? More later ….

Transport layer 15
UDP checksum example:
 Three packets of 16 bits  The 1’s complement of
each ‘r’ is:
 0110011001100110  0011010100110101
 0101010101010101  at destination, the sum
 0000111100001111 of four packets should
 adding the three, calling be:
it ‘r’:  1111111111111111
 1100101011001010  If the packet is
 Send the four packets, damaged:
the original three and  1111101111111111
1’s complement of ‘r’ to (zeros!!)
destination

Why provide for error checking? No guarantee that it is provided in


Transport layer 16
all of the links between source and destination
Checksum is a simple way to detect data7
corruption
• Break the data into a sequence of 16-bit integers
• Add the integers
• Wrap the carry-out bits to the least-significant
position.
• Finally, invert the result.
1 1 1 0 0 1 1 0 0 1 1 0 0 11 0
1 1 0 1 0 1 0 1 0 1 0 1 0 10 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 01 1

1 0 1 1 1 0 1 1 1 0 1 1 1 10 0
0 1 0 0 0 1 0 0 0 1 0 0 0 0 1layer 1
Transport 17
Reliable Transport
Protocols

Transport layer 18
TCP provides streamingconnections to apps
1
0

TCP is usually implemented by the OS. An OS library handles the


following:
• Ordering:
• Data must be packetized (chunked) by the sender and reassembled
by receiver
• Reassembly is done in the proper order, regardless of delivery
order.
• Acknowledgement: (almost, but not exactly “reliability”)
• Delivery of each packet is acknowledged, so lost packets can be
retransmitted.
• Pacing:
• Sender adjusts packet send rate so neither receiver nor network
are overwhelmed.
• Avoid filling up queues and dropping packets. Transport layer 19
Principles of Reliable data transfer
 important in application, transport and link layers
 top-10 list of important networking topics!

 characteristics of unreliable channel will determine complexity of


reliable data transfer protocol (rdt)
Transport layer 20
Principles of Reliable data transfer
 important in application, transport and link layers
 top-10 list of important networking topics!

 characteristics of unreliable channel will determine complexity of


reliable data transfer protocol (rdt)
Transport layer 21
Rdt1.0: reliable transfer over a reliable
channel
 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

Transport layer 22
Rdt2.0: channel with bit errors
Occurs during transmission, propagation and buffering

 underlying channel may flip bits in packet


 recall: UDP checksum is used to detect bit errors

 the question: how to recover from errors:


 acknowledgements (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
 human scenarios: message dictation using ACKs, NAKs?
 new mechanisms in rdt2.0 (beyond rdt1.0):
 error detection
 receiver feedback: control msgs (ACK,NAK) rcvr->sender
 retransmission Transport layer 23
rdt2.0: FSM specification

sender FSM receiver FSM


Transport layer 24
rdt2.0 has a fatal flaw!
What happens if ACK/NAK
gets corrupted? Handling duplicates:
 sender adds sequence
 sender doesn’t know what
happened at receiver! number to each pkt
 sender retransmits current
 It can’t just retransmit: there’s a
possibility of duplication pkt if ACK/NAK garbled
 receiver discards (doesn’t
What to do? deliver up) duplicate pkt
 sender ACKs/NAKs receiver’s
ACK/NAK? However, what if stop and wait protocol
the sender’s ACK/NAK gets Sender sends one packet,
lost? then waits for receiver’s
 retransmit, but this might cause response
retransmission of correctly
received pkt!
Transport layer 25
rdt3.0: channels with bit errors and loss
Alternating bit Protocol

New assumption: underlying


channel can also lose packets
(data or ACKs)
 checksum, seq. #, ACKs,
retransmissions will be of help,
but not enough
Q: how to deal with loss?
 sender waits until certain data or
ACK lost, then retransmits
 yuck: drawbacks?

Transport layer 26
rdt3.0 sender

Approach: sender waits for a “reasonable”


amount of time for an ACK
 retransmit if no ACK is received within this period
 if pkt (or ACK) just delayed (not lost):
 retransmission would cause packet duplication,
but use of seq. #’s already handles this
 receiver must specify seq # of pkt being ACKed
 requires countdown timer

Put the burden of detecting and recovering from


lost packets to the sender
Transport layer 27
Transport layer 28
Transport layer 29
Transport layer 30
End of Session

Transport layer 31
1
Performance of stop and wait 5

• Eg., An ISP’s fiber link from New Jersey to San Jose, CA:
1 Gbps link, 15 ms propagation delay, 1 kByte packet size:

RTT = 2 * (Propagation Delay + Transmission Time)


1 kByte * 8 bit/Byte
T transmit = = 8 microsec
10**9 b/sec

• RTT = 2* (15ms + 0.008 ms) = 30.01 ms


• Throughput=Length of frame/Total time
• Effective throughput is just 1 kByte * 8 bit/Byte / 30.01
ms = 250 kbps
• Utilization = Transmission time / Total time.
• 0.008 ms/30.01 ms = 0.000267
1
Stop and wait 6

illustration
send receiv
first packet bit er er
transmitted, t = 0 last
packet bit transmitted, t = L
/R
All this first packet bit arrives
time is RT last packet bit arrives,
idle and T send ACK
wasted.
ACK arrives,
send next
packet, t = RTT
+L/R
Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-to-
be-acknowledged packets
 range of sequence numbers must be defined
 buffering at sender and/or receiver

 Two generic forms of pipelined protocols:


Go-Back-N and Selective Repeat Transport layer 34
Pipelined protocols

Transport layer 35
Go-Back-N

Transport layer 36
Go-Back-N
Sender is allowed to transmit up to N unACKed
packets

Uses a window of size N = value that limits the number


of outstanding unACKed packets – for Flow control

Keeps track of the different sub-intervals in the range


of SEQ numbers using: N, base and nextseqnum.

Sender:
base
Sequence
Number Space
Defined in packet
header, with k-bit
sequence #
nextseqnum
nextseqnum
nextseqnum
nextseqnum
nextseqnum
nextseqnum
nextseqnum
nextseqnum Transport layer 37
Go-Back-N in action

Expected sequence num=2

Transport layer 38
Go-Back-N in action

N=4

Expected sequence num=2

Transport layer 39
Selective Repeat

 Receiver: individually acknowledges all correctly


received pkts
 buffers pkts, as needed, for eventual in-order delivery to
upper layer

 Sender: only resends pkts for which ACK was not


received
 one timer for each unACKed pkt

 Sender Window:
 N consecutive Seq #’s
 again limits seq #s of sent, unACKed pkts

Transport layer 40
Selective Repeat: sender, receiver windows

Transport layer 41
Selective repeat in action

Corrections needed for this slide!

Transport layer 42
Selective repeat in action

ACK1 rcvd, pkt5 sent


0123456789
Pkt5 rcvd, buffered, ACK5 sent
Pkt2 TIMEOUT, 0123456789
pkt2 resent
0123456789 Pkt2 rcvd, pkt2,pkt3,pkt4,pkt5
ACK3 rcvd, delivered, ACK2 sent
nothing sent 0123456789
Transport layer 43
0123456789
Selective repeat dilemma:
retransmission or new packet?
Example:
 seq #’s: 0, 1, 2, 3
 window size=3
 receiver sees no
difference between
two scenarios!
 incorrectly passes
duplicate data as new
in (Fig. a)
Q: what relationship
between seq # size
and window size?

A window size= (size of


Seq # Space-1) won’t
work
Transport layer 44
Figurative Curtain
Selective repeat: dilemma
Setting the Window Size

Size _ of _ Sequence _ Number _ Space


W
2

To account for possible packet duplication due to


SEQ # assigning, packets are not allowed to “live” more than
3 min. (TCP Extensions for high speed networks) in the
network. Transport layer 45
Transport layer 46

You might also like