Unit 3 Transport layer Departamento de Tecnología Electrónica Computer Networking Some of these slides are given as copyrighted material from: Computer

Unit 3Transport layer

Departamento deTecnología Electrónica

Computer NetworkingSome of these slides are given as copyrighted material from: Computer Networking: A

Top Down Approach ,5th edition.

Jim Kurose, Keith RossAddison-Wesley, April

2009.

Transport Layer 3-2

Unit 3: Transport LayerOur goals: Understanding the

principles behind transport layer services: multiplexing &

demultiplexing reliable data transfer flow control

learn about transport layer protocols in the Internet: UDP: connectionless transport TCP: connection-oriented

transport

Transport Layer 3-3

Unit 3.Overview

3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer3.5 Connection-oriented transport: TCP

segment structure reliable data transfer flow control connection management

Transport Layer 3-4

Transport services and protocols provide logical communication

between app processes running on different hosts

transport protocols run in end systems send side: breaks app

messages 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

applicationtransportnetworkdata linkphysical


logical end-end transport

Transport Layer 3-5

Transport Layer Services At the transmitter side (source), the transport layer accepts messages (A_PDU)

from the network applications and forms with them segments (T_PDU) that then it sends by using network layer services.

At the receiver side (destination), the transport layer receives segments from network layer and passes the user data that contains (messages) to the application layer.

sourceapplicationtransportnetworkdata linkphysical

destinationapplicationtransportnetworkdata linkphysical

networkdata linkphysical

data linkphysical

routerswitch

data linkphysical

switch

Application protocol

Transport protocol

Network protocol Network protocol

L.P.

P.P.L.P.

P.P.

L.P.

P.P.

L.P.

P.P.

L.P. = Data Link ProtocolP.P. = Physical Protocol

Transport Layer 3-6

Transport vs. network layer

network layer: provides a logical communication service between hosts Similar to postal service that sends a letter to a postal address

transport layer: extends the network service to provide a logical communication service between application processes It’s known as transport layer multiplexion and demultiplexion It relies on, enhances, network layer services

Transport Layer 3-7

Transport vs. network layer

Household analogy:Two houses with 10 kids in each one. They send letters among

them every week. processes = kids app messages = letters in envelopes hosts = houses transport protocol = Ann (in one house) and Bill (in the other

house) are responsible for picking up their brothers’ letters, sending them using the Postal Office, waiting for incoming letters and delivering them to their brothers

network-layer protocol = postal service

Transport Layer 3-8

Internet transport-layer protocols

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

UDP: unreliable, unordered delivery extension of “best-effort” IP

Not available services: Guaranteed delay Guaranteed bandwidth









logical end-end transport

Transport Layer 3-9

Unit 3. Overview.



Transport Layer 3-10

Multiplexing/demultiplexing

application

transport

network

link

physical

P1 application

transport

network

link

physical

application

transport

network

link

physical

P2P3 P4P1

host 1 host 2 host 3

= process= socket

delivering received segments (T_PDU)to correct socket, by using the header (T_PCI)

Demultiplexing at recv host:gathering data from multiplesockets, enveloping data (T_PDU) with header (T_PCI) (later used for demultiplexing)

Multiplexing at send host:


How demultiplexing works Network layer receives IP datagrams

(N_PDU) each N_PDU has source IP address,

destination IP address in its header (N_PCI)

each N_PDU carries 1 transport-layer segment (T_PDU)

Transport layer receives segments (T_PDU) each T_PDU carries in its T_PCI a source port number anda destination port number each T_PDU carries application user

data (T_UD)

source port # dest port #

32 bits

T_UD:application

data (message)

other header fieldsT_PCI

TCP/UDP segment (T_PDU) format

Destination host uses IP addresses & port numbers to direct the T_UD of the T_PDU to appropriate socket


Connectionless demultiplexing (UDP)

Create UDP sockets by using an specific host-local port number or using one unused:

DatagramSocket mySocket1 = new DatagramSocket(12534);

DatagramSocket mySocket2 = new DatagramSocket();

When source host creates the T_IDU to send into UDP socket, must specify (in T_ICI):

(dest IP address, dest port number)

when UDP protocol in destination host receives the segment (T_PDU): checks destination port

number in header segment (T_PCI)

directs user data (T_UD) of the T_PDU to UDP socket with that port number

Demux (UDP) doesn’t check source IP addresses and/or source port numbers


Connectionless demux (UDP) (cont)

DatagramSocket serverSocket = new DatagramSocket(6428);

ClientIP:B

P2

client IP: A

P1P1P3

serverIP: C

SP: 6428DP: 9157

SP: 9157DP: 6428

SP: 6428DP: 5775

SP: 5775DP: 6428

Source IP and source port allow P3 to identify the source process (P1 or P2) and return a message.

Local port #. If it’s a server process is mandatory

SP = Source port #DP = Destination port #


Connection-oriented demux (TCP)

TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number

recv host uses all four values (in N_PCI and T_PCI) to direct segment (T_PDU) to appropriate TCP socket

server host may support many simultaneous TCP sockets: each socket identified by its

own 4-tuple web servers have different

TCP sockets for each connecting client non-persistent HTTP will have

different socket for each request


Connection-oriented demux (TCP)

When creating TCP socket… … port number must be

indicated at the server. Port must be “listening”

ServerSocket WelcomeSocket = new ServerSocket(6789);

… server socket (IP & port) must be provided as T_ICI. Connection with server’s socket is established.

Socket ClientSocket = new Socket(“ServerHostname", 6789);

… when the server receives a connection request from the client, server must accept connection. Connection is identified by the client socket (IP & port) and the server socket (IP & port)

Socket socketConnection = welcomeSocket.accept();

When destination host receives a T_PDU, it must check both source and destination ports in the Transport header (T_PCI). It also must check both source and destination IP addresses in the N_ICI. Then, it must send the user data (T_UD) to the correct application process.


Connection-oriented demux (TCP)Web server with several process

clientIP: B

P1

client IP: A

P1P2P4

serverIP: C

SP: 9157DP: 80

SP: 9157DP: 80

P5 P6 P3

D-IP:CS-IP: AD-IP:C

S-IP: B

SP: 5775DP: 80

D-IP:CS-IP: B

No problem if two clients process use the same

source port

No problem if two clients process use the

same source IPSP = Source port #DP = Destination port #S-IP = Source IP addressD-IP = Destination IP address


Connection-oriented demux (TCP): Threaded Web Server

P1

client IP: A

P1P2

serverIP: C

SP: 9157DP: 80

SP: 9157DP: 80

P4 P3

D-IP:CS-IP: AD-IP:C

S-IP: B

SP: 5775DP: 80

D-IP:CS-IP: B

SP = Source port #DP = Destination port #S-IP = Source IP addressD-IP = Destination IP address

Instead of one server process per each socket, there is a “thread” per socket and only

one process.

clientIP: B


Unit 3. Overview




UDP: User Datagram Protocol [RFC 768]

Very simple Internet transport protocol

“best effort” service, UDP segments (T_PDU) may be: lost delivered out of order to

app connectionless:

no handshaking between UDP sender and receiver

each UDP segment (T_PDU) handled independently of others

Why is there a UDP? no connection establishment

(which can add delay) simple: no connection state at

sender, receiver small segment header (T_PCI)


UDP: more…

often used for streaming multimedia apps loss tolerant rate sensitive

other UDP uses DNS SNMP

reliable transfer over UDP? It’s possible by adding reliability at application layer application-specific error

recovery!


32 bits

Applicationdata

(message)

UDP segment format (T_PDU)

length checksumT_PCI

T_UD

The header (T_PCI) only has 4 fields. Length, in bytes of the whole T_PDU, including header.

The header (T_PCI) only has 4 fields. Length, in bytes of the whole T_PDU, including header.


UDP checksum

Sender (simplified): treat T_PDU segment contents

as sequence of 16-bit integers checksum: addition of segment

contents with carryout, then 1’s complement

sender puts checksum value into UDP checksum field (T_PCI)

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? More later ….

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


Internet Checksum Example Note: when adding numbers, a carryout from the

most significant bit needs to be added to the result at the right-most position.

Example: add two 16-bit integers

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

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 11 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

carryout

sum (with carryout)checksum


Unit 3. Overview



Why is reliable transfer necessary? wrong PDUsInterferences in link transmission

can change transmitted bits. lost PDUs When packet queue is full incoming

packets are dropped. duplicated PDUs Communication failures make

already received PDUs be retransmitted.

How are these problems detected? wrong PDUsError checking mechanisms (included in

PCI). E.g. Checksum Most complex and reliable algoritms are used in

data link layer. lost and duplicated PDUsAdding “something” in the header (PCI) of

each PDU to distinguish it from the rest of the sent PDUs.

How are these problems resolved? RetransmissionSender transmits again the PDU that had

problems.

Important in application, transport and link layers top-10 list of important networking topics!

Principles of Reliable data transfer


General case of communication between peers entities in a same layer: To communicate to its peer entity, an entity sends the other a PDU makes

up a header (PCI) and, in general, user data (UD). Headers (PCI) contains protocol control information. In general, both entities transmit and receive user data. Bidirectional transfer of user data between peers entities.

Simplification of this general case: Makes easier the explanation of the principles of reliable data transfer. Suppose an unidirectional user data transfer. One of these peer entities is a transmitter (Tx) and the other is the

receiver (Rx). Tx transmits PDUs with PCI and UD (UD comes from the above layer). Rx receives PDUs with PCI and UD (UD goes to the above layer). Rx transmits PDUs that only contents PCI (without UD, only control info.) Bidirectional protocol control information transfer.



What types of PDU are used? Data PDU

Sent by the Tx Contents user data (UD) Contents protocol control information (PCI)

Control PDU Sent by the Rx Does not carry user data (UD) Contents only protocol control information (PCI)

It’s wrong to think that Tx doesn’t send control information and sends only data PDUs.

Data PDUs also carry control information.

It’s wrong to think that Tx doesn’t send control information and sends only data PDUs.

Data PDUs also carry control information.

Notice that



What does the header (PCI) content?The PCI of a data PDU contents information that allows:

Rx detecting if the data PDU has errors. Identifying the data PDU and distinguishing it from the others PDUs sent

by Tx.The PCI of a control PDU contents information that allows:

Tx detecting if the control PDU contents errors. Rx identifying a particular data PDU, and reports that the data PDU:

has been received OK by the Rx: ACK, acknowledgement, return receipt

Has not been received OK by the Rx: NAK, NACK, Negative acknowledgement, negative return receipt

Information in PCI that is for identifying a particular data PDU is called sequence number.

Information in PCI that is for identifying a particular data PDU is called sequence number.

Note



Principles of Reliable data transfer Tx basic operation:

The Tx entity in a particular layer forms a data PDU with UD and PCI and transmits it to the Rx.

Now, Tx waits for some time, known as time_out, until it receives a control PDU from the Rx. The control PDU indicates:

Data PDU received OK, with an ACK.o Tx doesn’t do anything

else. Data PDU received with

errors, with a NACK.o Tx retransmits the PDU.

If time_out expires before control PDU from Rx arrives, theno Tx retransmits the PDU.

Rx basic operation: When receiving a data PDU, Rx

entity in a layer: If the data PDU arrives OK,

it is mandatory that Rx sends Tx an ACK control PDU to notify it.

If the data PDU arrives with errors, it is optional that Rx sends Tx a NACK control PDU to notify it.

Q: How long should time_out be, as minimum?

Q: Does Rx pass always to the above layer the UD contained in a data PDU received OK?


Example 1. Tx sends only a PDU with UD and doesn’t send

the next until the transmission is sucessful. Rx only sends ACK control PDU.

Tx Rx

PDU 1

Time

Without errors

ACK 1PDU 2

ACK 2

PDU 3

ACK 3

PDU X

ACK X

dtransPDU

dtransack

PCI

Tx Rx

PDU 1

PDU 2

X

PDU 1

ACK 1

Time_out

Time_out

PDU 2

ACK 2

With errors

Lost PDU

wrong PDU

Principles of reliable data transfer


Example 2. Idem example 1.Rx also sends NACK control

PDU.Without errors.

Same behaviour as previous e.g.

Tx Rx

PDU 1

timePDU 2

XNACK 1

PDU 1

ACK 1

PDU 2

Time_out

ACK 2

With errors



The mechanism that guarantees a reliable data transfer is known as a stop-and-wait protocol

It’s not much efficient Tx must stop and wait for receiving the ACK before sending the next PDU.

Is it possible to measure transfer performance? To simplify, let’s suppose that:

Tx always has a ready PDU to send, There isn’t any error, Each PDU has L bytes of UD and 0 bytes of PCI, dtransack = 0.

Utilization of the Tx or channel (U tx) = fraction of time that Tx/channel is busy transmitting bits of the PDU.



Stop-and-wait protocol performance

First PDU bit sent, t = 0Last PDU bit sent, t = L/R

Tx Rx

RTT

First PDU bit received Last PDU bit received, send ACK

ACK received, t = RTT+L/RSend next PDU

U tx =

L / R

RTT + L / R

dtrans = L/R

Remember


The protocol works but its performance is poor Example: 1 Gbps link, RTT = 30 ms, PDU = 1KByte

ssb

pdukb

R

Ldtrans 8

/10

/89

1 PDU of 1KByte every 30,008 msec 33,3kByte/sec effective transfer rate in a 1 Gbps link

Protocol can limit the capabilities provided by the underlying network hardware!

Is it possible to improve it?

00027,0008,30

008,0

/

/

RLRTT

RLU tx

Stop-and-wait protocol performance


Protocols with pipelining Pipelining: Tx is allowed to send multiple PDUs (“in-flight”)

without waiting for acknowledgements (ACK), improving performance by far. Sequence numbers used in PCI must have enough range to distinguish

all in-transit PDUs. Buffers are needed in Tx and, sometimes, in Rx

Stop-and-wait Pipelining

PDU PDU

ACK

Note: We’ll study in depth this concept when studying TCP Transport Layer 3-34


Pipelining: increased utilization

Send bit 1 of 1st PDU, t = 0

Tx Rx

RTT

Send last bit of PDU, t = L / R

First bit of 1st PDU arrivesLast bit of 1st PDU arrives, send ACK

ACK received, send next PDU, the 4th, t = RTT + L / R

Last bit 2nd PDU arrives, send ACKLast bit 3rd PDU arrives, send ACK

U tx

= 0,024

30,008 = 0,0008

microseconds

3 * L / R

RTT + L / R =

Increase utilizationby a factor of 3!


Reliable data transfer service How does transport layer provide a reliable data transfer service to

the application layer?


Reliable data transfer service How does transport layer provide a reliable data transfer service to

the application layer?

Transport layer is above network layer that provides an unreliable data transfer service.


Reliable data transfer service Transport layer must implement a reliable data transfer protocol (rdt).

Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt). We’re going to experiment with different types of unreliable channels.


Reliable data transfer: getting started

senderside (Tx)

receiverside(Rx)

rdt_send(): called from above, (e.g., by app.). Passed data to

deliver to receiver upper layer

udt_send(): called by rdt,to transfer PDU over

unreliable channel to receiver

rdt_rcv(): called when PDU arrives on rcv-side of unreliable channel

deliver_data(): called by rdt to deliver data to upper

udt = Unreliable Data Transfer


Reliable data transfer: getting startedWe will: incrementally develop sender and receiver sides of

reliable data transfer protocol (rdt) consider only unidirectional data transfer (Tx Rx)

but control info may flow in both directions! use finite state machines (FSM) to specify sender,

receiver

state1

state2

event causing state transitionactions taken on state transition

state: when in this “state” next state uniquely determined by next

event

eventactions

Rdt protocol actually can be applied in any layer that must provide reliability, not only in transport layer.

Rdt protocol actually can be applied in any layer that must provide reliability, not only in transport layer.

Note


rdt1.0: reliable transfer over a reliable channel

The most simple case. It’s not realistic. underlying channel perfectly reliable

no bit errors no loss of PDUs

separate FSMs for sender, receiver: sender sends PDUs into underlying channel (to the below layer) receiver read data from underlying channel (from the below layer)

Wait for call from

above packet = make_pkt(data)udt_send(packet)

rdt_send(data)

extract (packet,data)deliver_data(data)

Wait for call from

below

rdt_rcv(packet)

sender (Tx) receiver (Rx)

In FSMs, PDUs are called packets.In FSMs, PDUs are called packets.Note


rdt2.0: channel with bit errors underlying channel may change bits in packet

checksum 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 new mechanisms in rdt2.0 (beyond rdt1.0):

error detection receiver feedback: control PDUs (ACK,NAK) rcvrsender


rdt2.0: FSM specification

Wait for call from

above

sndpkt = make_pkt(data, checksum)udt_send(sndpkt)

extract(rcvpkt,data)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

Wait for ACK or

NAK

Wait for call from

belowsender (Tx)

receiver (Rx)rdt_send(data)

Both, Tx & Rx, use udt_send() to send their PDUs through

the unreliable channel

implemented by the below layer.

Both, Tx & Rx, wait for event rdt_rcv() that

delivers a PDU from the below layer (unreliable).


rdt2.0: operation with no errors

Wait for call from

above

snkpkt = make_pkt(data, checksum)udt_send(sndpkt)




udt_send(sndpkt)


udt_send(NAK)


Wait for ACK or

NAK

Wait for call from

below

rdt_send(data)


rdt2.0: error scenario

Wait for call

from above

snkpkt = make_pkt(data, checksum)udt_send(sndpkt)




udt_send(sndpkt)


udt_send(NAK)


Wait for ACK or

NAK

Wait for call from

below

rdt_send(data)


rdt2.0 serious fail

What happens if a control PDU (ACK or NAK) corrupted?

Tx doesn’t know if it has received an ACK or a NACK as the control PDU has errors!

Tx doesn’t know how data PDU arrived at Rx

can’t retransmit: possible duplicate

Handling duplicates: Tx retransmits current PDU if

control PDU (ACK/NAK) has errors

Tx adds sequence number in PCI to each PDU

Rx discards (doesn’t deliver up) duplicate PDUs

Tx sends one PDU, then waits for receiver response


rdt2.1: sender, handles garbled ACK/NAKs

Wait for call 0 from

above

sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)

rdt_send(data)

Wait for ACK or NAK

0 udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )


rdt_send(data)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)


above

Wait for ACK or NAK

1


rdt2.1: receiver, handles garbled ACK/NAKs

Wait for 0 from below

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)



extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)


rdt2.1: discussion

Sender: seq # added to PDUs two seq. #’s (0,1) will

suffice. Why? must check if received

control PDU (ACK/NAK) corrupted

twice as many states state must “remember”

whether “current” PDU has 0 or 1 seq. #

Receiver: must check if received

PDU is duplicate state indicates whether 0 or

1 is expected PDU seq # note: receiver can not

know if its last ACK/NAK received OK at sender


rdt2.2: a NAK-free protocol

same functionality as rdt2.1, using ACKs only instead of NAK, Tx sends ACK for last PDU received OK

Rx must explicitly include seq # of data PDU being ACKed (in PCI of all control PDUs, ACK)

duplicate ACK at Tx results in same action as NAK: retransmit current PDU (not recognize yet)


rdt2.2: sender, receiver fragments

Wait for call 0 from above


rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)

Wait for ACK

0

sender FSMfragment


extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)


rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

receiver FSMfragment


rdt3.0: channels with errors and loss

New assumption: underlying channel can also lose PDUs (data or control -ACKs) checksum, seq. #, ACKs,

retransmissions will be of help, but not enough

New approach: Tx waits “reasonable” amount of

time for ACK (time_out) Tx retransmits if no ACK received in

this time if data PDU (or control, ACK) just

delayed (not lost): retransmission will be

duplicate, but use of seq. #’s already handles this

Rx must specify seq # of data PDU being ACKed (in PCI of ACK)

requires countdown timer to detect if time_out expires


rdt3.0 sender (Tx)

sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)

Wait for

ACK0

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )


above

sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)


rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,0) )


stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

Wait for call 0from

above

Wait for

ACK1

rdt_rcv(rcvpkt)

Design receiver FSM for the rdt3.0 protocol

Exercise


rdt3.0 in action


rdt3.0 in action


Unit 3. Overview




TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

full duplex data: bi-directional data flow in

same connection MSS: maximum segment

size (UDs) connection-oriented:

handshaking (exchange of control msgs) inits sender, receiver state before data exchange

flow control: sender will not overwhelm

receiver

point-to-point: one sender, one receiver

reliable, in-order byte stream: no “message boundaries”

(A_PDUs) pipelined:

TCP congestion and flow control set window size (maximum PDUs # in-flight)

send & receive buffers

socketdoor

T C Psend buffer

T C Preceive buffer

socketdoor

segm ent

applicationwrites data

applicationreads data


TCP segment structure (T_PDU)


32 bits

applicationdata

(variable length)

sequence number

acknowledgement numberReceive window

Urg data pnterchecksum

FSRPAUheadlen

notused

Options (variable length)

URG: urgent data (generally not used)

ACK: ACK #valid

PSH: push data now(generally not used)

RST, SYN, FIN:connection estab(setup, teardown

commands)

# bytes rcvr willingto accept

countingby bytes of data(not segments!)

Internetchecksum

(as in UDP)

T_PCI

T_UD


TCP seq. #’s and ACKs (I)Sequence number: Assigned number for the first byte of a TCP segment that is sent to the other

peer entity. Initial value is set in a random way by each entity peer when connection is

initiated. Increased when segments containing PDUs are sent.ACK number: Points out the sequence number which is expected to be received by the

other peer entity. All the previous bytes are acknowledged (cumulative ACK ).

Q: How does the rcv manage disordered segments? A: TCP specification leaves it to the implementer.


TCP seq. #’s and ACKs (II)Host A Host B

Seq=42, ACK=79, data = ‘hello!’

Seq=79, ACK=48, data = ‘HELLO!’

Seq=48, ACK=85

User types‘hello!’,

applicationsend it to theremote host

host ACKsreceipt

of ‘HELLO!’

host ACKsreceipt of

‘hello’ & sendsback a ‘HELLO!’

message

time

simple “uppercase” scenario

The hosts have sent the ACK in their data PDU (“piggybacking”) in the two first segments.

Note


TCP Round Trip Time and Timeout

Q: how to set up the TCP timeout value?

longer than RTT but RTT varies

too short: premature timeout unnecessary

retransmissions too long: slow reaction

to segment loss

Q: how to estimate RTT? SampleRTT: measured time from

segment transmission until ACK Retransmissions are ignored

SampleRTT may vary, so a more stable RTT value is desirable. EstimatedRTT is calculated as

the average of several recent measurements, not just current SampleRTT



EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

Exponential weighted moving average influence of past sample decreases exponentially fast typical value: = 0.125


Example RTT estimation:RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT



Setting the timeout EstimatedRTT plus “safety margin”

large variation in EstimatedRTT -> larger safety margin A first estimation of SampleRTT deviation from EstimatedRTT:

TimeoutInterval = EstimatedRTT + 4*DevRTT

DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|

(typically, = 0.25)

Then set timeout interval:


Unit 3. Overview




TCP reliable data transfer

TCP creates rdt service over IP’s unreliable service

pipelined segments, several segments “in-flight”

cumulative acks TCP uses single

retransmission timer

retransmissions are triggered by: timeout events duplicate acks

Initially, a simplified TCP sender is considered : ignores duplicate acks ignores flow control,

congestion control


TCP sender events:data rcvd from app: Create segment with seq

# seq # is byte-stream

number of first data byte in segment

start timer if not already running (think of timer as for oldest unacked segment)

expiration interval: TimeOutInterval

timeout: retransmit segment that

caused timeout restart timer Ack rcvd: If acknowledges

previously unacked segments update what is known to be

acked start timer if there are

outstanding segments


TCP sender (simplified) NextSeqNum = InitialSeqNum SendBase = InitialSeqNum while (true) { switch(event)

event: data received from application above create TCP segment with data and sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP /* Below layer, unreliable, sends segment to Rx */ NextSeqNum = NextSeqNum + length(data)

event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer

event: ACK received, with ACK field value of y if (y > SendBase) { /* If not-yet-adcknowledged data are being acknowleged */ SendBase = y /* Update indicator not-yet-acknowledged data*/

stop timer if (NextSeqNum > SendBase) /* There are currently not-yet-acknowledged data */ start timer } } /* end of infinite loop */

Every data byte with seq# less than SendBase is acknowledged cumulatively. The ones that have greater or equal seq # are not yet acknowledged.

NextSeqNum points to “not sent” data.

Rx sends ack for all data with seq # less than y.


TCP: retransmission scenarios (I)

Host A

Seq=100, 20 bytes data

ACK=100

timepremature timeout scenario

Host B


ACK=120


Seq=

92 ti

meo

ut

ACK=120

Host A


ACK=100

loss

timeo

ut

lost ACK scenario

Host B

X


ACK=100

time

Seq=

92 ti

meo

utSendBase

= 100

SendBase= 120

SendBase= 120

SendBase= 100


TCP retransmission scenarios (II)Host A


ACK=100

loss

timeo

ut

Cumulative ACK scenario

Host B

X


ACK=120

time

SendBase = 120

Doesn’t expire

Tim

e_ou

t Sec

=92

Timer with the “recommended” timeout would have expired before ACK=120 arrived.So, on a retransmission only, Tx will use a timeout that is longer that the recommended one (double for first retransmission, quadruple for second one, ….), which make it easy to produce cumulative ACKs.

Tim

e_ou

t Sec

=92


TCP ACK generation [RFC 1122, RFC 2581]

Event at Receiver

Arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed

Arrival of in-order segment withexpected seq #. One other segment has ACK pending

Arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected

Arrival of segment that partially or completely fills gap

TCP Receiver action

Delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK

Immediately send single cumulative ACK, ACKing both in-order segments

Immediately send duplicate ACK, indicating seq. # of next expected byte

Immediate send ACK, that corresponds to the arrived segment


TCP: Fast Retransmission

time-out period is often quite long: long delay before resending

lost packet detect lost segments via

duplicate ACKs. sender often sends many

segments back-to-back if segment is lost, there will

likely be many duplicate ACKs.

if sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: fast retransmit: resend

segment before timer expires

TCP doesn’t use NAKs, so Rx can not notify that a segment is

missing.

Note

Host A Host B

Resend 2nd segment

time

Tim

e_ou

t 2nd

seg

men

t

Doesn’t expire

TCP: Fast retransmission

TX receives, three times, a duplicate ACK for first segment data. So it supposses that the second segment was missing and resend fastly it again, before timer expires.

Arriving these three segment out of order makes Rx send a duplicate ACK per one of them inmediately, acknowledging first segment data.

ACK

Duplicate ACK

Duplicate ACK

Duplicate ACK

Transport Layer

3-73


event: ACK received, with ACK field value of y if (y > SendBase) { /* If not-yet-adcknowledged data are being acknowleged */

SendBase = y /* Update indicator not-yet-acknowledged data*/

stop timer if (NextSeqNum > SendBase) /*There are currently not-yet-acknowledged segments*/

start timer } else { /*It’s a duplicated ACK for already acknowledged segment*/

increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y /*Fast retransmission*/

start timer }

TCP: Fast retransmitThis is the ACK reception event in the simplified TCP Tx.

This part is for giving sender TCP more “intelligence” and knows to react if receives 3 duplicated ACKs, by doing fast retransmission for not-already acknowledged segment.


Unit 3. Overview




TCP Flow Control receive side of TCP

connection has a receive buffer:

speed-matching service: matching the sender’s rate to the receiving app’s drain rate

app process may be slow at reading from buffer

sender shall not overflowreceiver’s buffer by

transmitting too much, too fast

flow control

RcvBuffer

RcvWindow

Free space in TCP buffer

TCP data in buffer, waiting for being read by

app

Data from IP

Application process

Variable size

Fixed size


TCP Flow control: how it works

Suppose TCP receiver discards out-of-order segments, so they don’t take up the RcvBuffer.

Free space in buffer: RcvWindow = RcvBuffer-[LastByteRcvd – LastByteRead]

RcvBuffer

RcvWindow


TCP data in buffer, waiting for being reading

by app

Data from IP

Application process

Variable size

Fixed size

This difference is the taken up space



rcvr announces free space in buffer by including value of RcvWindow in header segments (T_PCI)

sender limits unACKed data to RcvWindow Guarantees RcvBuffer is not overflown

RcvBuffer

RcvWindow


TCP data in buffer, waiting for being reading

by app

Data from IP

Application process

Variable size

Fixed size

RcvWindow value of T_PCI is related with ACK# value of T_PCI.

When Tx receives a segment, ckecks the ACK# value and RcvWindow value to know the range of seq # matching to data that is autorized to have not-already-acked:


From ACK#to (ACK# + RcvWindow – 1)

Source port # Dest. Port #

Application data(variable length)

Sequence #

ACK #RcvWindow

Urg. Data Pointerchecksum

FSRPAUHead.length

notused

Options (variable length)

T_PC

IT_

UD

Segment format (T_PDU)



Unit 3. Overview



TCP Connection Management

Recall: TCP sender and receiver establish a “connection” before exchanging segments that carry user data.

During the connection phase, both of them have to initialize TCP variables: seq. #s Receiver and transmitter buffers (both in client and server) Flow control info (e.g. RcvWindow)

client: connection initiator

Socket clientSocket = new Socket("hostname","port number"); server: listening and contacted by client Socket connectionSocket = welcomeSocket.accept();


client

SYN, SeqNum=client_isn(not carrying ACK neither DATA)

server

SYN, SeqNum=server_isn, ACK=client_isn+1 (not carrying DATA)

SeqNum=client_isn+1, ACK=server_isn+1 (not usually carryingDATA)

Three way handshake

timetime

TCP Connection Management

Transport Layer

3-82

In TCP_PDUs flow, if a flag is active, it is indicated in the labels (except ACK, which is implicit).

Note

Three-way handshake:Step 1: Client sets up initial values for all TCP variables (buffers, initial sequence number,

etc.)- Then, it sends a SYN segment to the server: Doesn’t carry data. Specifies the initial seq # (client_isn). Carries SYN bit set to one. It is considered as the first byte of the data stream of the

TCP connection.Step 2: when receiving SYN segment, server initialize TCP buffers and variables and

sends a (SYN-ACK segment) to the TCP client:

Has the same characteristics of client SYN segment but specifying the server initial seq # (server_isn).

Acknowledges the client’s SYN segment.Step 3: Client receives the SYN-ACK segment from the server and responds sending an ACK

segment: acknowledges the server’s SYN-ACK segment. May content user data, although it ‘s not usual.

Transporte 3-83

TCP Connection Management: Establishment


TCP Connection Management: Closing a connection

FIN segment has FIN bit set to 1. It is the last byte of the TCP connection data stream.

TCP entity that sends a FIN segment can not send data anymore but can receive.

client

FIN

server

ACK

ACK

FIN

socketClient.close();

socketConnection.close();

Closed connection

timed

wai

t

Both client and server may start connection close.

Note


Step 1: client app closes connection by socketClient.close(); sends a TCP FIN segment to server.

Step 2: server receives FIN, replies with ACK.

Step 3: server app closes connection by socketConnection.close(); sends FIN to client.

Step 4: client receives FIN, replies with ACK.

Enters “timed wait” - will respond with ACK to received FINs

When “timed wait” expires, TCP client considers the connection is closed (releasing buffers and others resources related to the connection).

Step 5: server receives ACK. Connection closed (releasing buffers…).


Transport Layer

3-86


Previous steps with some minor modifications are the same to close the connection if: Server takes the lead to close the connection and run socketConexion.close();

Both client and server, decide, simultaneously, to close the connection and run at the same time socketCliente.close(); and socketConexion.close();

Connections have to be closed inmediately when a RST segment is received (RST bit set to 1). RESET segment is sent only in some special cases and it is not the usual way to close the connection.

Transport Layer

3-87

TCP Connection Management: Lifecycle

CLOSING

LAST_ACK CLOSE_WAIT

ESTABLISHEDLISTEN

FIN_WAIT_2

TIME_WAIT

FIN_WAIT_1SYN_RCVD

SYN_SENT

CLOSED

Life of a TCP connection: It is the sequence of TCP states of a TCP connection.

The next state machine shows 11 posible states and the diferent transitions among states.

Transport Layer

3-88


CLOSING

LAST_ACK CLOSE_WAIT

ESTABLISHEDLISTEN

FIN_WAIT_2

TIME_WAIT

FIN_WAIT_1SYN_RCVD

SYN_SENT

CLOSED

CLOSED is a fictitious state. It is the connection state before creating it, and after closing it completely. In this state, the connection doesn’t exist yet or has already stopped existing.

CLOSED is the initial and the final state of a connection

CLOSED

Transport Layer

3-89


CLOSING

LAST_ACK CLOSE_WAIT

ESTABLISHEDLISTEN

FIN_WAIT_2

TIME_WAIT

FIN_WAIT_1SYN_RCVD

SYN_SENT

CLOSED

When the connection is in ESTABLISHED state TCP entities can interchange segment containing data.

Thus, client and server’s goal is passing from CLOSED to ESTABLISHED, send and receive data and go back to CLOSED state again.

ESTABLISHED

Transport Layer

3-90


In green, the transitions of a typical client lifecycle. In red, the transitions of a typical server lifecycle. Black transitions are posible but not usual.

CLOSING

LAST_ACK CLOSE_WAIT

ESTABLISHEDLISTEN

FIN_WAIT_2

TIME_WAIT

FIN_WAIT_1SYN_RCVD

SYN_SENT

CLOSED


The first transition in a typical client clifecycle goes from CLOSED state to SYN_SENT state.

It happens when a “Client app starts a connection”. Event is issued.

“Send SYN segment” action is associated to it.

ESTABLISHED

FIN_WAIT_2

TIME_WAIT

FIN_WAIT_1

SYN_SENT

CLOSED



Possible combinations “event/action” of the transitions of a typical client lifecycle.

ESTABLISHED FIN_WAIT_2

TIME_WAIT

FIN_WAIT_1

SYN_SENT

CLOSED

Transporte 3-92

Client app initiates a connection

Send SYN segment

SYN-ACK segment is received

Send ACK for SYN

Pass twice MSL time

Send nothing

ACK for FIN is received

Send nothing

App initiates close connection

Send FIN segment

Send ACK for FIN

FIN segment is received


LAST_ACK CLOSE_WAIT

ESTABLISHEDLISTEN

SYN_RCVD

CLOSED

Transport Layer

3-93

The first transition for typical server lifecycle goes from CLOSED state to LISTEN state.

It happens when server app creates a welcome socket and remains waiting for connection from clients.

There aren’t any associated actions to the first transition.


Possible combinations “event/action” of the transitions of a typical server lifecycle.

CLOSED

Transport Layer

3-94

Server app creates welcome socket

SYN segment is received

Send ACK-SYN segment

ACK for FIN is received

Send nothing

Send ACK for FIN

FIN segment is received

LAST_ACK

CLOSE_WAIT

ESTABLISHED

LISTEN

SYN_RCVD

Send nothing

ACK for SYN is received

Send nothing

App initiates close connection

Send FIN segment


Unit 3: Summary principles behind transport

layer services: multiplexing, demultiplexing reliable data transfer flow control

instantiation and implementation in the Internet UDP TCP

Next: leaving the network

“edge” (application, transport layers)

into the network “core”

PROBLEMS AND EXERCISES

Computer Networking – Unit 3: Transport layer

Departamento deTecnología Electrónica

Transport Layer 96

Pr1: port numbers

Transport layer 2-97

Suppose that client A initiates a TCP connection to a Web server called S. Naerly simultaneously, client B also initiates a TCP connection to S.

a) Indicate possible source and destination port numbers for:1. Segments sent from A to S

2. Segments sent from B to S

3. Segments sent from S to A

4. Segments sent from S to B

b) If A and B are in diferent hosts, could source port number from A to S be the same that from B to S?

c) What happens if client process A and B are in the same host?

Pr2: port numbers


Look at the connections that the clients have initiated with the Web server and answer the questions:

P1

ClientIP: A

P1P2P4

Web ServerIP: C

SP: 9157DP: 80

SP: 9157DP: 80

P5 P6 P3

D-IP: CS-IP: A

D-IP: CS-IP: B

SP: 5775DP: 80

D-IP: CS-IP: B

client IP: B

SP = Source port #DP = Destination port #S-IP = Source IP addressD-IP = Destination IP address

Pr2: port numbers (II)

Transport Layer

3-99

What are the source and destination port number values in the segments flowing from the server to the clients’ processes?

What are the IP addresses (source and destination) of N_PDUs carrying these transport-layer segments?

Pr3: checksum

Transport Layer

3-100

UDP and TCP use 1s complement for their checksums. Suppose you have the following three 16-bit words:

1110000001010010 1101010100101111 0010101110101111

What is the 1s complement of the sum of these 16-bit words? Receiver adds the three words to the received checksum. If the

result of the addition, in binary, contains some zero, the receiver realizes there is some error in some bit, is it right?

Is it possible that a 1-bit error will go undetected? Propose a particular example for a non-detectable error.

Pr4: Channel utilization

Transport Layer

3-101

Pipeline protocols improve the performance of stop-and-wait protocols.

Suppose a Tx and a Rx with a 1Gbps link, 30ms RTT, 1500 bytes PDUs and header size equal to zero (negligible size in comparison to the data size).

How many data PDUs have to be “in-flight” for a channel utilization of 95%?

Pr5: Control over T_PDU content

Transport Layer

3-102

It was said that an application may choose UDP for a transport protocol as UDP offers finer application control (than TCP) of what data is sent in a segment, and when.

a) Why does an application have more control of what data is sent in a segment?

b) Why does an application have more control on when the segment is sent?

Pr6

Transport Layer

3-103

Suppose a client application protocol which is sending an only PDU of 1000 bytes, using transport reliable service. Server application replies with a 100 bytes PDU.

Make a diagram of TCP_PDU flow. Label active flags, point out seq numbers, ACK numbers, and the number of bytes of the TCP_DU. Also point out the size (bytes) of every TCP_PDU. Suppose there are no options for TCP, and initial sequence numbers (ISN) of 1000 for the client, and 3000 for the server.

Pr7: MSS

Transport Layer

3-104

Consider transferring an enormous file of L bytes from Host A to Host B. Assume a MSS of 536 bytes.

a) What is the maximum value of L, so that TCP sequence numbers are run out of? Recall that the TCP sequence number field has 4 bytes.

Note: MSS is the maximum size of user data carried by any segment in a TCP connection. In SYN segment, using TCP options header, each TCP entity informs the other about MSS. The smaller is used.

Pr7: MSS (II)

Transporte 3-105

b) For the value of L obtained in (a), how long does it takes to transmit the file?

Suppose that a total of 66 bytes of transport, network, and data-link header are added to each segment. The packet is sent out over a 155 Mbpslink. Ignore flow control and congestion control so A can pump out the segments back to back and continuously.

Pr8.

Transporte 3-106

Suppose that a client application protocol is sending an only PDU of 100 bytes using the reliable transport service on the internet. Server app replies with a 100-byte PDU.

Make a diagram of TCP_PDU flow. Label active flags, point out seq numbers, ACK numbers, and the number of bytes of the TCP_DU. Also point out the size (bytes) of every TCP_PDU. Suppose there are no options for TCP, and initial sequence numbers (ISN) are 0 at both client and server. MSS is 536.

Pr9: seq # and ACK

Transport Layer

3-107

Host A and B are using a TCP connection. Host B has already received from A bytes up to byte 126. Then, Host A sends two back-to-back segments to Host B. Both segments have 70 and 50 bytes of data, respectively. In the first segment, the sequence number is 127, the source port number is 302, and the destination port number is 80. Host B sends an acknowledgement whenever it receives a segment from Host A.

• In the second segment sent from Host A to B, which are the sequence number, source port number, and destination port number?

• Consider that the first segment arrives before the second segment. For the acknowledgement of the first arriving segment, which is the acknowledgment number, the source port number, and the destination port number?

Pr9: seq # and ACK (II)

Transport Layer

3-108

c) Now, consider that the first segment arrives before the second segment. For the acknowledgement of the first arriving segment, which is the acknowledgment number, the source port number, and the destination port number?

d) Suppose the two segments sent by A arrive in order at B. The first acknowledgement is lost and the second acknowledgement arrives after the first timeout interval. Draw a time diagram, showing all the segments and acknowledgements that were sent. (Assume there is no additional packet loss.) For each segment in your figure, provide the sequence number and the number of bytes of data; for each acknowledgement that you add, provide the acknowledgement number.

Pr10: TCP flow control

Transport Layer

3-109

Host A and B are directly connected with a 100 Mbps link. There is a TCP connection between both hosts. Host A is

sending an enormous file over this connection to Host B. Host A can send its application data into its TCP socket at a rate

as high as 120 Mbps Host B can read out of its TCP receive buffer at a maximum rate

of 60 Mbps. Describe the effect of TCP flow control on host A’s application

layer rate in sending data through its TCP socket.

P11: estimated RTT

Transport Layer

3-110

We discussed about TCP needs to estimate a value for RTT, in order to know how long it has to wait for an ACK.

To estimate the RTT, TCP uses SampleRTT values. SampleRTT is the time between a segment sending and the arrival of its ACK.

However, TCP does not use the SampleRTT associated to the retransmitted segments.

Why do you think TCP avoids measuring the SampleRTT for retransmitted segments?

Pr12: variables in pipelining

Transport Layer

3-111

What is the relationship between the variable SendBase of TCP transmitter and the variable LastByteRcvd of TCP receiver?

Pr13: variables in pipelining

Transport Layer

3-112

What is the relationship between the variable LastByteRcvd of TCP receiver and the variable y of TCP sender?

Pr14: fast retransmission

Transport Layer

3-113

TCP waits until it has received three duplicate ACKs before performing a fast retransmission.

When receiving three duplicate ACKs for a segment, TCP does a fast retransmission of the segment, as it is supposed lost. Retransmission does not waiting for timer expiring.

Why do you think the TCP designers chose not to perform a fast retransmission after the first duplicate ACK for a segment is received?

Pr15: flow control


Host A is sending an huge file to Host B over a TCP connection. Over this connection, no packet is loss and timers never expire. Transmission rate of the link connecting Host A to the Internet is R bps. Suppose that the process in Host A is capable of sending data into its

TCP socket at a rate of S bps, where S = 10·R. Furthermore, suppose that the TCP receiving buffer is large enough to

hold the entire file. The sender’s buffer can hold only one percent of the file.

What would prevent the process in Host A from continuously passing data to its TCP socket at rate S bps? TCP flow control? TCP congestion control? Or anything else? Discuss it.

Documents

Unit 3 Transport layer Departamento de Tecnología Electrónica Computer Networking Some of these slides are given as copyrighted material from: Computer