The Transport Layer introduction fundamental problems in networking communicating reliably over...

The Transport LayerThe Transport Layer

introductionintroduction fundamental problems in networkingfundamental problems in networking communicating reliably over an unreliable communicating reliably over an unreliable

channelchannel congestion and flow controlcongestion and flow control setting up/tearing down a connectionsetting up/tearing down a connection multiplexing and addressingmultiplexing and addressing

fragmentation and reassemblyfragmentation and reassembly quality of servicequality of service implementation issuesimplementation issues case studies: TCP, UDP, ATM, XTPcase studies: TCP, UDP, ATM, XTPReading:Reading:

Tannenbaum 6.1, 3.3, 3.4, 3.5.1, 6.2, 6.3, 3.2, 6.4, Tannenbaum 6.1, 3.3, 3.4, 3.5.1, 6.2, 6.3, 3.2, 6.4, 6.5 6.5

Ross, Kurose 3.1 - 3.7Ross, Kurose 3.1 - 3.7

Transport Layer: many interesting Transport Layer: many interesting issuesissues

many fundamentally important networking issues many fundamentally important networking issues show up show up

how to provide reliable communication over an unreliable how to provide reliable communication over an unreliable channelchannel

why/how/when should a send restrain itself: flow and why/how/when should a send restrain itself: flow and congestion controlcongestion control

how to agree to communicate (and stop) in presence of how to agree to communicate (and stop) in presence of lost, delayed, reordered messageslost, delayed, reordered messages

how to deal with large data: fragmentation and reassemblyhow to deal with large data: fragmentation and reassembly how to guarantee performance when resources statistically how to guarantee performance when resources statistically

sharedshared

Transport Layer: services providedTransport Layer: services provided end-host to end-host delivery of dataend-host to end-host delivery of data aspects of transport service:aspects of transport service:

error detection and recovery:error detection and recovery: errors (lost or corrupted data) detected at errors (lost or corrupted data) detected at receiver? Detected error corrected?receiver? Detected error corrected?

timing:timing: timing between data at sender preserved when delivered at timing between data at sender preserved when delivered at receiver?receiver?

framing:framing: data unit boundaries (e.g., “message”) preserved? data unit boundaries (e.g., “message”) preserved? common transport service models:common transport service models:

connectionless:connectionless: datagram, no promises, error detection optional, no error datagram, no promises, error detection optional, no error recovery, no timingrecovery, no timing

connection-oriented:connection-oriented: error recovery, no timing error recovery, no timing circuit-like:circuit-like: timing preserved, no error recovery, optional error detection timing preserved, no error recovery, optional error detection

Internet, OSI, ATM service modelsInternet, OSI, ATM service models

Note: why multiple protocols for same service?Note: why multiple protocols for same service? ATM:ATM: OSI:OSI:

network arch. Service protocolsInternet connection-oriented TCP

connectionless UDPOSI connection-oriented TP0, TP1, TP2, TP3, TP4

connectionless CLTPATM circuit-like AAL1

connection-oriented AAL3/4, AAL5, assuredconnectionless AAL3/4, AAL5,

unassured

Reliable Reliable Communication over Communication over an unreliable channelan unreliable channel

Goal:Goal: design a design a simple “reliable” simple “reliable” data transfer data transfer protocol that:protocol that:

reliably delivers data reliably delivers data between upper layer between upper layer applications/protocolsapplications/protocols

uses a network layer uses a network layer that is “unreliable”that is “unreliable”

sendingentity

receivingentity

reliable channel

sending side receiving side

data data

reliable datatransfer protocol

(send side)

unreliable channel

reliable datatransfer protocol

(receive side)

packet packet

rdt_send()deliver_data()

rdt_rcv()udt_send()

sending side receiving side

datadata

Interaction with upper and lower layersInteraction with upper and lower layers

sender upper layersender upper layer: transport layer invoked from : transport layer invoked from above by call to above by call to rdt_send(data)rdt_send(data) rdt:rdt: reliable data transfer reliable data transfer data:data: to be delivered to receiver upper layer to be delivered to receiver upper layer

receiver upper layer:receiver upper layer: transport layer delivers transport layer delivers datadata to to upper layer via call to upper layer via call to deliver_data(data)deliver_data(data)

sender lower layer:sender lower layer: call to call to udt_send(pudt_send(pkkt)t) will pass will pass pktpkt to lower layer to lower layer udt:udt: unreliable data transfer unreliable data transfer

receiver lower layer:receiver lower layer: delivers delivers pktpkt to transport layer to transport layer via call to via call to rdt_rcv(pkt)rdt_rcv(pkt)

Notes:Notes: datadata is unit of data crossing upper boundary is unit of data crossing upper boundary pktpkt is unit of data crossing lower boundary is unit of data crossing lower boundary pktpkt = = datadata with some added fields with some added fields

Reliable data transfer: medium Reliable data transfer: medium assumptionsassumptions

Assumptions about network layer serviceAssumptions about network layer service underlying medium (network) connecting sender and underlying medium (network) connecting sender and

receiver may have many links, routers, networks!receiver may have many links, routers, networks! can packets be lost, corrupted, delayed, reordered by can packets be lost, corrupted, delayed, reordered by

network?network?

A first set of media assumptionsA first set of media assumptions no loss, no corruption, no reorderingno loss, no corruption, no reordering

sendingentity

receivingentity

reliable channel

sending side receiving side

data data

reliable datatrasfer protocol

(send side)

unreliable channel

reliable datatrasfer protocol(receive side)

packet packet

rdt_send()deliver_data()

rdt_rcv()udt_send()

sending side receiving side

datadata

provided service

service implementation

Reliable data transfer: medium Reliable data transfer: medium assumptionsassumptions

A first try at a protocol (rdt1.0)A first try at a protocol (rdt1.0)

rdt_send(data) rdt_send(data) { { make_packet(pkt,data); make_packet(pkt,data);

udt_send(pkt);udt_send(pkt);

} }

rdt_rcv(pkt) rdt_rcv(pkt) {{extract(pkt,data);extract(pkt,data);

deliver_data(data);deliver_data(data);}}

How to specify a protocol?How to specify a protocol?

How to describe/specify a protocol?How to describe/specify a protocol? English (why a good/bad idea)?English (why a good/bad idea)? programming language or pseudocode programming language or pseudocode

(good/bad?)(good/bad?) graph-based methods: Petri net models and graph-based methods: Petri net models and

finite state machinesfinite state machines

A finite state machine (FSM) consists of:A finite state machine (FSM) consists of: set of statesset of states for each protocol entity for each protocol entity

each entity has its each entity has its ownown set of states set of states state “records” all relevant past history of entitystate “records” all relevant past history of entity entity response to each “event” in state must be entity response to each “event” in state must be

uniquely defineduniquely defined

set of labeled directed arcsset of labeled directed arcs between states between states represent changes in staterepresent changes in state arc labeling:arc labeling:

event or action that caused transitionevent or action that caused transitionaction(s) taken on transitionaction(s) taken on transition

FSM for rdt1.0FSM for rdt1.0

wait forwait forcall fromcall from

aboveabove

rdt_send(data

(a) rdt1.0: sending side (b) rdt1.0: receiving side

wait forwait forcall fromcall from

belowbelow

rdt_rcv(pkt)make_pkt(pkt,data)

udt_send(pkt)extract(pkt,data)deliver_data(data)

A second set of media assumptionsA second set of media assumptions

packets sent to network can be corrupted but packets sent to network can be corrupted but neither lost nor reorderedneither lost nor reordered

any part of packet can be corruptedany part of packet can be corrupted corrupt(corrupt(pktpkt), notcorrupt(), notcorrupt(pktpkt)) return T if return T if

pkt is (is not) corruptpkt is (is not) corrupt

Questions:Questions: how does rdt1.0 fail under new media assumptions?how does rdt1.0 fail under new media assumptions? new protocol mechanisms required (rdt2.0)new protocol mechanisms required (rdt2.0)

checksumchecksum ACK, NACKACK, NACK

Protocol rdt2.0: senderProtocol rdt2.0: sender

wait forwait forcall fromcall from

aboveabove

wait forwait forACK orACK or

NAKNAK

rdt_send(data)

rdt_rcv(rcvpkt)

&& isNAK(rcvpkt)

rdt_rcv(rcvpkt)

&& isACK(rcvpkt)data cksum

NAK

ACK

compute checksummake_pkt(pkt,data,cksum))

udt_send(pkt)

udt_send(rcvpkt)

Protocol rdt2.0: receiverProtocol rdt2.0: receiver

wait forwait forcall fromcall from

belowbelow

extract(rcvpkt,data)

rdt_rcv(rcvpkt)&&corrupt(rcvpkt)

data cksum

NAK

ACK

udt_send(NAK)

deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) &&notcorrupt(rcvpkt)

Q:Q: will rdt2.0 always work given will rdt2.0 always work given assumptions?assumptions?

Protocol rdt2.1Protocol rdt2.1

approaches to fix rdt2.0approaches to fix rdt2.0

1.1.

2.2.

3.3.

Protocol rdt2.1: senderProtocol rdt2.1: sender

Protocol rdt2.1: receiverProtocol rdt2.1: receiver

A third set of media assumptionsA third set of media assumptions

packets sent to network layer can be lost, packets sent to network layer can be lost, corrupted, but not reorderedcorrupted, but not reordered

new protocol mechanisms required (rdt3.0):new protocol mechanisms required (rdt3.0):

1.1.

2.2.

3.3.

Protocol rdt3.0: senderProtocol rdt3.0: sender

Operation of rdt3.0: no errorsOperation of rdt3.0: no errors

sender receiver

send pkt0rcv pkt0send ACK0

rcv ACK0send pkt1

rcv ACK1send pkt0

rcv pkt0send ACK0

rcv pkt1send ACK1

pkt0

pkt1

pkt0

ACK0

ACK1

ACK0

Operation of rdt3.0: lost packetsOperation of rdt3.0: lost packets

sender receiver

send pkt0

rcv ACK0send pkt1

pkt0

pkt1

ACK0rcv pkt0send ACK0

rcv ACK1send pkt0

rcv pkt0send ACK0

rcv pkt1send ACK1

pkt0

ACK1

ACK0

X

pkt1timeoutresend pkt1

The Alternating bit protocolThe Alternating bit protocol protocol rdt3.0 known as Alternating Bit (AB) protocolprotocol rdt3.0 known as Alternating Bit (AB) protocol stop and wait ARQstop and wait ARQ

ARQ: automatic repeat/requestARQ: automatic repeat/request

half-duplex-like communicationhalf-duplex-like communication user ofuser of

timerstimers sequence numberssequence numbers error detection bitserror detection bits

required to provide reliable communication in presence of lost required to provide reliable communication in presence of lost or corrupted packetsor corrupted packets

Q:Q: what if channel can what if channel can reorderreorder packets?? packets??

Pipelined error recovery protocolsPipelined error recovery protocols large bandwidth-delay product: propagation delays long with large bandwidth-delay product: propagation delays long with

respect to packet transmission timerespect to packet transmission time e.g.: 1 Gbit/sec link, 1Kbyte packet implies 8 microsecs to e.g.: 1 Gbit/sec link, 1Kbyte packet implies 8 microsecs to

transmit into wiretransmit into wire t_trans = (8Kbits/packet)/(10**9 bits/sec) = 8 microsecst_trans = (8Kbits/packet)/(10**9 bits/sec) = 8 microsecs

cross country speed of light propagation delay is 15 msecscross country speed of light propagation delay is 15 msecs channel utilization: fraction of time sender (channel at sender) is channel utilization: fraction of time sender (channel at sender) is

busy transmittingbusy transmitting U_sender = 0.008msecs/30.016msecs = 0.000266U_sender = 0.008msecs/30.016msecs = 0.000266 sender only busy .02% of time!sender only busy .02% of time! Sender throughput is 266Kbits/sec even with 1G linkSender throughput is 266Kbits/sec even with 1G link

protocol (not channel capacity) constrains performance protocol (not channel capacity) constrains performance (throughput)(throughput)

Pipelined error Pipelined error recovery recovery protocolsprotocols

solution to low throughput solution to low throughput with long propagation with long propagation delays: pipelining allow delays: pipelining allow multiple multiple unacknowledged unacknowledged packets to be in-transit packets to be in-transit between sender and between sender and receiverreceiver