1dt066 distributed information systems chapter 3 transport layer

Adapted from: Computer Networking, Kurose/Ross

1DT066Distributed Information Systems

Chapter 3Transport Layer

Adapted from: Computer Networking, Kurose/Ross Transport Layer 3-2

Our Goals: Transport Layer

principles of transport services

Internet transport layer protocols: UDP: connectionless

transport TCP: connection-

oriented reliable transport


Chapter 3, Transport, Outline3.1 Internet transport-layer services:

UDP & TCP3.3 connectionless transport: UDP3.4 principles of reliable data transfer3.5 connection-oriented transport: TCP

segment structure sequence number / ACK retransmission flow control connection establishment


Internet transport-layer protocols

unreliable, unordered delivery: UDP no-frills extension of

“best-effort” IP reliable, in-order

delivery (TCP) congestion control flow control connection setup

services not available: delay guarantees bandwidth guarantees

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

networkdata linkphysical







logical end-end transport

pp 211-217


TCP vs. UDP

Features TCP (Yes/No) UDP (Yes/No)

(1) Ordered packets Yes No

(2) Connectionless No Yes

(3) Reliable data delivery (no packet loss)

Yes No

(4) Flow control Yes No

(5) Congestion control Yes No

(6) delay guarantees No No

(7) bandwidth guarantees

No No

pp 224-230


UDP: User Datagram Protocol [RFC 768]

“no frills,” “bare bones” Internet transport protocol each UDP packet

(segment) handled independently of others

“best effort” service, UDP segments may be: lost delivered out-of-order

to app connectionless:

no handshaking between UDP sender, receiver

UDP is used by: streaming

multimedia apps (loss tolerant, but time sensitive)

name look-up services (e.g. the Domain Name Service protocol) Why?

apps that adds reliability (e.g. remote procedure calls)

apps that use specific error recovery (e.g. TV broadcast).

pp 224-230


Why is there a UDP

no connection establishment before sending data (which adds delay)

simple: no connection state at sender, receiver that has to be maintained.

no flow control: UDP can blast away segments as fast as desired without waiting for a receiver OK.

pp 244-


UDP: segment(data packet) header

source port # dest port #

32 bits

Applicationdata

(Payload)

UDP segment format

length checksum

length, in bytes of UDP segment,

including header

pp 224-230

To detect if there are bit errors in the

header & data sections

Header


Principles of reliable data transfer important in application, transport, link layers

top-10 list of important networking topics!

characteristics of unreliable channel will determine the complexity of a reliable data transfer protocol (rdt)

pp 230-233



Principles of reliable data transfer important in application, transport, link layers

top-10 list of important networking topics!

pp 224-230



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

Principles of reliable data transfer

pp 224-230


sender receiver

rcv pkt1

rcv pkt0

send ack0

send ack1

send ack0

rcv ack0

send pkt0

send pkt1

rcv ack1

send pkt0rcv pkt0

pkt0

pkt0

pkt1

ack1

ack0

ack0

(a) no loss

sender receiver

rcv pkt1

rcv pkt0

send ack0

send ack1

send ack0

rcv ack0

send pkt0

send pkt1

rcv ack1

send pkt0rcv pkt0

pkt0

pkt0

ack1

ack0

ack0

(b) packet loss

pkt1X

loss

pkt1timeout

resend pkt1

Example of a Reliable Data Transfer Protocol: Packet Loss

pp 238-241


rcv pkt1send ack1

(detect duplicate)

pkt1

sender receiver

rcv pkt1

rcv pkt0

send ack0

send ack1

send ack0

rcv ack0

send pkt0

send pkt1

rcv ack1

send pkt0rcv pkt0

pkt0

pkt0

ack1

ack0

ack0

(c) ACK loss

ack1X

loss

pkt1timeout

resend pkt1

rcv pkt1send ack1

(detect duplicate)

pkt1

sender receiver

rcv pkt1

send ack0rcv ack0

send pkt1

send pkt0rcv pkt0

pkt0

ack0

(d) premature timeout/ delayed ACK

pkt1timeout

resend pkt1

ack1

send ack1

send pkt0rcv ack1

pkt0

ack1

ack0

send pkt0rcv ack1 pkt0

rcv pkt0send ack0ack0

rcv pkt0

send ack0(detect duplicate)

pp 238-241

Example of a Reliable Data Transfer Protocol: Ack loss


stop-and-wait operation

first packet bit transmitted, t = 0

sender receiver

Round Trip Time=RTT

last packet bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

pp 241-244


Pipelined protocols

pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged packets range of sequence numbers must be

increased buffering at sender and/or receiver

two generic forms of pipelined protocols: go-Back-N, selective repeat

pp 244-


Pipelining: increased utilization

first packet bit transmitted, t = 0

sender receiver

RTT

last bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

3-packet pipelining increases utilization by a factor of 3!

pp 241-244


Pipelined protocols: overviewGo-back-N: sender can have

up to N un-acked packets in pipeline

Receiver sends a cumulative ack Doesn’t ack packet

if there’s a gap sender has timer

for oldest un-acked packet when timer expires,

retransmit all un-acked packets

Selective Repeat: sender can have up

to N unack’ed packets in pipeline

receiver sends individual ack for each packet

sender maintains timer for each un-acked packet when timer expires,

retransmit only that unacked packet

pp 244-251


Go-Back-N: sender k-bit seq # in pkt header “window” of up to N, consecutive unack’ed pkts

allowed

ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may receive duplicate ACKs (see next slide)

timer for oldest in-flight pkt timeout(n): retransmit packet n and all higher seq

# pkts in windowpp 244-251


GBN in action

send pkt0send pkt1send pkt2send pkt3

(wait)

sender receiver

receive pkt0, send ack0receive pkt1, send ack1 receive pkt3, discard, (re)send ack1rcv ack0, send pkt4

rcv ack1, send pkt5

pkt 2 timeoutsend pkt2send pkt3send pkt4send pkt5

Xloss

receive pkt4, discard, (re)send ack1receive pkt5, discard, (re)send ack1

rcv pkt2, deliver, send ack2rcv pkt3, deliver, send ack3rcv pkt4, deliver, send ack4rcv pkt5, deliver, send ack5

ignore duplicate ACK

0 1 2 3 4 5 6 7 8

sender window (N=4)

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

pp 244-251


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

full duplex data: bi-directional data flow

in same connection MSS: maximum

segment size connection-oriented:

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

flow controlled: sender will not

overwhelm receiver

point-to-point: one sender, one

receiver reliable, in-order

byte steam: no “message

boundaries” pipelined:

TCP congestion and flow control set window size

pp 256-259


TCP segment structure


32 bits

applicationdata

(variable length)

sequence number

acknowledgement number

receive window

Urg data pointerchecksum

FSRPAUheadlen

notused

options (variable length)

URG: urgent data (generally not used)

ACK bit set: ACK seq. no valid

PSH: push data now(generally not used)

RST, SYN, FIN:connection

establishment bits(setup, teardown

commands)

# bytes receiver willingto accept

countingby bytes of data(not segments!)

Checksum(to detect erros)

pp 259-261


TCP seq. numbers, ACKssequence numbers:

byte stream “number” of first byte in segment’s data

acknowledgements:seq # of next byte expected from other side

cumulative ACKQ: how receiver handles out-of-order segmentsA: TCP spec doesn’t say, - up to implementor


sequence number


checksum

rwnd

urg pointer

incoming segment to sender

A

sent ACKed

sent, not-yet ACKed(“in-flight”)

usablebut not yet sent

not usable

window size N

sender sequence number space


sequence number


checksum

rwnd

urg pointer

outgoing segment from sender

pp 261-262


TCP seq. numbers, ACKs

Usertypes

‘C’

host ACKsreceipt

of echoed‘C’

host ACKsreceipt of‘C’, echoesback ‘C’

simple telnet scenario

Host BHost A

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80

pp 261-262


TCP: retransmission scenarios

lost ACK scenario

Host BHost A

Seq=92, 8 bytes of data

ACK=100


Xtim

eo

ut

ACK=100

premature timeout

Host BHost A


ACK=100

Seq=92, 8bytes of data

tim

eo

ut

ACK=120


ACK=120

SendBase=100

SendBase=120

SendBase=120

SendBase=92

pp 268-272


TCP: retransmission scenarios

X

cumulative ACK

Host BHost A


ACK=100


tim

eo

ut


ACK=120


TCP flow controlapplication

process

TCP socketreceiver buffers

TCPcode

IPcode

application

OS

receiver protocol stack

application may remove data from

TCP socket buffers ….

… slower than TCP

receiver is delivering(sender is sending)

from sender

receiver controls sender, so sender won’t overflow receive’s buffer by transmitting too much, too fast

flow control

pp 276-278


TCP flow control

buffered data

free buffer spacerwnd

RcvBuffer

TCP segment payloads

to application process

receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segments RcvBuffer size set via

socket options (typical default is 4096 bytes)

many operating systems autoadjust RcvBuffer

sender limits amount of unacked (“in-flight”) data to receiver’s rwnd value

guarantees receive buffer will not overflow

receiver-side buffering

pp 276-278


TCP sliding window

Transport Layer 3-28

http://histrory.visualland.net/tcp_swnd.html

http://histrory.visualland.net/view.php?path=content/TCP/Simu/sm_1_Reliable_Transmit.show&type=show


Q: will 2-way handshake always work in network?

when variable delays retransmitted messages

(e.g. req_conn(x)) due to message loss?

message reordering can’t “see” other side

2-way handshake:

Let’s talk

OKESTAB

ESTAB

choose xreq_conn(x)

ESTAB

ESTABacc_conn(x)

Agreeing to establish a connection

pp 278-282


Agreeing to establish a connection

2-way handshake failure scenarios:

retransmitreq_conn(

x)

ESTAB

req_conn(x)

half open connection!(no client!)

client terminat

es

serverforgets x

connection x completes

retransmitreq_conn(

x)

ESTAB

req_conn(x)

data(x+1)

retransmitdata(x+1)

acceptdata(x+1)

choose xreq_conn(x)

ESTAB

ESTAB

acc_conn(x)

client terminat

es

ESTAB

choose xreq_conn(x)

ESTAB

acc_conn(x)

data(x+1) acceptdata(x+1)

connection x completes server

forgets x

pp 278-282


TCP 3-way handshake

SYNbit=1, Seq=x

choose init seq num, xsend TCP SYN msg

ESTAB

SYNbit=1, Seq=yACKbit=1; ACKnum=x+1

choose init seq num, ysend TCP SYNACKmsg, acking SYN

ACKbit=1, ACKnum=y+1

received SYNACK(x) indicates server is live;send ACK for SYNACK;

this segment may contain client-to-server data

received ACK(y) indicates client is live

SYNSENT

ESTAB

SYN RCVD

client state

LISTEN

server state

LISTEN

pp 278-282


FIN_WAIT_2

CLOSE_WAIT

FINbit=1, seq=y

ACKbit=1; ACKnum=y+1

ACKbit=1; ACKnum=x+1 wait for server

close

can stillsend data

can no longersend data

LAST_ACK

CLOSED

TIMED_WAIT

timed wait for 2*max

segment lifetime

CLOSED

TCP: closing a connection

FIN_WAIT_1 FINbit=1, seq=xcan no longersend but can receive data

clientSocket.close()

client state server state

ESTABESTAB

1dt066 distributed information systems chapter 3 transport layer

Documents