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 Reading:  Tannenbaum 6.1, 3.3, 3.4, 3.5.1, 6.2, 6.3, 3.2, 6.4, 6.5  Ross, Kurose

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” sending entity receiving entity reliable channel sending side receiving side data reliable data transfer protocol (send side) unreliable channel reliable data transfer protocol (receive side) packet rdt_send() deliver_data() rdt_rcv() udt_send() sending sidereceiving side data

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(pkt) will pass pkt to lower layer  udt: unreliable data transfer  receiver lower layer: delivers pkt to transport layer via call to rdt_rcv(pkt)

Notes:  data is unit of data crossing upper boundary  pkt is unit of data crossing lower boundary  pkt = 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

sending entity receiving entity reliable channel sending side receiving side data reliable data trasfer protocol (send side) unreliable channel reliable data trasfer protocol (receive side) packet rdt_send() deliver_data() rdt_rcv() udt_send() sending sidereceiving side data provided service service implementation

Reliable data transfer: medium assumptions A first try at a protocol (rdt1.0) rdt_send(data){make_packet(pkt,data);udt_send(pkt);}rdt_rcv(pkt){extract(pkt,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 labeling: event or action that caused transition action(s) taken on transition

FSM for rdt1.0 wait for call from above rdt_send(data (a) rdt1.0: sending side(b) rdt1.0: receiving side wait for call from below rdt_rcv(pkt) make_pkt(pkt,data) udt_send(pkt) extract(pkt,data) deliver_data(data)

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(pkt), notcorrupt(pkt) return T if pkt 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: sender

wait for call from above wait for ACK or NAK rdt_send(data) rdt_rcv(rcvpkt) && isNAK(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) data cksum NAK ACK compute checksum make_pkt(pkt,data,cksum)) udt_send(pkt) udt_send (rcvpkt)

Protocol rdt2.0: receiver

wait for call from below 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: will rdt2.0 always work given assumptions?

Protocol rdt2.1 approaches to fix rdt

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):

Protocol rdt3.0: sender

Operation of rdt3.0: no errors sender receiver send pkt0 rcv pkt0 send ACK0 rcv ACK0 send pkt1 rcv ACK1 send pkt0 rcv pkt0 send ACK0 rcv pkt1 send ACK1 pkt0 pkt1 pkt0 ACK0 ACK1 ACK0

Operation of rdt3.0: lost packets sender receiver send pkt0 rcv ACK0 send pkt1 pkt0 pkt1 ACK0 rcv pkt0 send ACK0 rcv ACK1 send pkt0 rcv pkt0 send ACK0 rcv pkt1 send ACK1 pkt0 ACK1 ACK0 X pkt1 timeout resend pkt1

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 =  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