The Transport Layer introduction fundamental problems in networking communicating reliably over an unreliable channel congestion and flow control setting up/tearing down a connection multiplexing and addressing fragmentation and reassembly quality of service implementation issues case studies: TCP, UDP, ATM, XTP Tannenbaum: 6.1, 3.3, 3.4, 3.5.1, 6.2, 6.3, 3.2, 6.4, 6.5 Ross/Kurose: 3

Transport Layer: many interesting issues many fundamentally important networking issues show up how to provide reliable communication over an unreliable channel why/how/when should a send restrain itself: flow and congestion control how to agree to communicate (and stop) in presence of lost, delayed, reordered messages how to deal with large data: fragmentation and reassembly how to guarantee performance when resources statistically shared

Transport Layer: services provided end-host to end-host delivery of data aspects of transport service: error detection and recovery: errors (lost or corrupted data) detected at receiver? Detected error corrected? timing: timing between data at sender preserved when delivered at receiver? framing: data unit boundaries (e.g., “message”) preserved? common transport service models: connectionless: datagram, no promises, error detection optional, no error recovery, no timing connection-oriented: error recovery, no timing circuit-like: timing preserved, no error recovery, optional error detection

Internet, OSI, ATM service models Note: why multiple protocols for same service? ATM: OSI:

Reliable Communication over an unreliable channel Goal: design a simple “reliable” data transfer protocol that: reliably delivers data between upper layer applications/protocols uses a network layer that is “unreliable”

Interaction with upper and lower layers sender upper layer: transport layer invoked from above by call to rdt_send(data) rdt: reliable data transfer data: to be delivered to receiver upper layer receiver upper layer: transport layer delivers data to upper layer via call to deliver_data(data) sender lower layer: call to udt_send(packet) will pass packet to lower layer udt: unreliable data transfer

Interaction with upper and lower layers receiver lower layer: delivers packet to transport layer via call to rdt_rcv(packet) Notes: data is unit of data crossing upper boundary packet is unit of data crossing lower boundary packet = data with some added fields

Reliable data transfer: medium assumptions Assumptions about network layer service underlying medium (network) connecting sender and receiver may have many links, routers, networks! can packets be lost, corrupted, delayed, reordered by network? A first set of media assumptions no loss, no corruption, no reordering

Reliable data transfer: medium assumptions A first try at a protocol (rdt1.0) rdt_send(data) { make_packet(packet,data); udt_send(packet); } rdt_rcv(packet) extract(packet,data); deliver_data(data);

How to specify a protocol? How to describe/specify a protocol? English (why a good/bad idea)? programming language or pseudocode (good/bad?) graph-based methods: Petri net models and finite state machines A finite state machine (FSM) consists of: set of states for each protocol entity each entity has its own set of states state “records” all relevant past history of entity entity response to each “event” in state must be uniquely defined set of labeled directed arcs between states represent changes in state arc labelling:

FSM for rdt1.0

A second set of media assumptions packets sent to network can be corrupted but neither lost nor reordered any part of packet can be corrupted corrupt(P), notcorrupt(P) return T if packet is (is not) corrupt Questions: how does rdt1.0 fail under new media assumptions? new protocol mechanisms required (rdt2.0) checksum ACK, NACK

Protocol rdt2.0

Q: will rdt2.0 always work given assumptions?

Protocol rdt2.1 approaches to fix rdt2.0 1. 2. 3.

Protocol rdt2.1: sender

Protocol rdt2.1: receiver

A third set of media assumptions packets sent to network layer can be lost, corrupted, but not reordered new protocol mechanisms required (rdt3.0): 1. 2. 3.

Protocol rdt3.0: sender

Operation of rdt3.0: no errors

Operation of rdt3.0: lost packets

The Alternating bit protocol protocol rdt3.0 known as Alternating Bit (AB) protocol stop and wait ARQ ARQ: automatic repeat/request half-duplex-like communication user of timers sequence numbers error detection bits required to provide reliable communication in presence of lost or corrupted packets Q: what if channel can reorder packets??

Pipelined error recovery protocols large bandwidth-delay product: propagation delays long with respect to packet transmission time e.g.: 1 Gbit/sec link, 1Kbyte packet implies 8 microsecs to transmit into wire t_trans = (8Kbits/packet)/(10**9 bits/sec) = 8 microsecs cross country speed of light propagation delay is 15 msecs channel utilization: fraction of time sender (channel at sender) is busy transmitting U_sender = 0.008msecs/30.016msecs = 0.000266 sender only busy .02% of time! Sender throughput is 266Kbits/sec even with 1G link protocol (not channel capacity) constrains performance (throughput)

Pipelined error recovery protocols solution to low throughput with long propagation delays: pipelining allow multiple unacknowledged packets to be in-transit between sender and receiver