Transport (1)

Computer Networking and Applications

Transport Layer

Multiplexing/Demultiplexing

l ca gi lo

•  The Transport Layer is responsible for providing logical communica8on between processes. Uses the services of the Network Layer to (try) to transfer data between hosts. application transport network •  The TL relies on the services of the data link physical Network layer protocol, so it is limited in the services it can provide. •  TCP/IP provides d en

nd -e

conges8on ﬂow control TCP connec8on setup reliable, in-‐order delivery of data best eﬀort delivery UDP mul8plexing of data from several processes both

Source IP: C Dest IP: B source port: y dest. port: 80

port use: simple telnet app

Web client host A

network

application transport network

network

link

physical

host 2

host 3

32 bits source port #

TCP/UDP segment format

RFC 768

Web client host C

server B

source port:23 dest. port: x

P4

P2

transport

dest port #

other header fields Application data (message)

Computer Networking and Applications

Multiplexing/demultiplexing: examples source port: x dest. port: 23

application

©Kurose & Ross, 2002

Computer Networking and Applications

host A

P1 P1

P3

transport

host 1 application transport network data link physical

•  TCP/IP doesn t provide (although some other protocol suites do, and TCP/IP may in future) Reading: –  bandwidth or latency guarantees Kurose & Ross: Ch 3

application

= process

physical

t or sp an tr

–  –  –  –  –  –

= socket

Source IP: A Dest IP: B source port: x dest. port: 80

Source IP: C Dest IP: B source port: x dest. port: 80

Web server B port use: Web server

User Datagram Protocol (UDP)

•  no connec8on establishment (which can add delay) •  simple: no connec8on state at sender, receiver Length, in bytes of UDP •  small segment header segment, •  no conges8on control: UDP can including blast away as fast as desired header •  can add reliability at applica8on layer •  1 s complement checksum can be used to detect (but not correct) errors. (example) •  segments can be lost or delivered to applica8on out of order. •  each segment is independent of others.

32 bits source port #

dest port #

length

checksum

Application data (message) UDP segment format

©Kurose & Ross, 2002

Computer Networking and Applications

©Kurose & Ross, 2002

Computer Networking and Applications

Reliable Data Transfer •  Many applica8ons want reliable data transfer, so many transport layer protocols provide this. •  The service level of the underlying network may vary. Assume the TL needs to deal with errors and loss of data packets. •  Start with the assump8on of a reliable network and progressively add in mechanisms for dealing with errors… (on blackboard)

Reliable data transfer: getting started rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer

send side

udt_send(): called by rdt, to transfer packet over unreliable channel to receiver

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

receive side

rdt_rcv(): called when packet arrives on rcv-side of channel ©Kurose & Ross, 2002

Computer Networking and Applications

Computer Networking and Applications Rdt1.0: reliable transfer over a reliable channel

Reliable data transfer: getting started

We ll: •  incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) •  consider only unidirec8onal data transfer

•  underlying channel perfectly reliable –  no bit erros –  no loss of packets

•  separate FSMs for sender, receiver:

–  but control info will ﬂow on both direc8ons!

–  sender sends data into underlying channel –  receiver read data from underlying channel

•  use ﬁnite state machines (FSM) to specify sender, receiver event causing state transition actions taken on state transition state: when in this state next state uniquely determined by next event

state 1

state 2

event actions

©Kurose & Ross, 2002

Computer Networking and Applications Rdt2.0: channel with bit errors

©Kurose & Ross, 2002

Computer Networking and Applications

rdt2.0: FSM specification

•  underlying channel may ﬂip bits in packet –  recall: UDP checksum to detect bit errors

•  the ques8on: how to recover from errors: –  acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK –  nega6ve acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors –  sender retransmits pkt on receipt of NAK –  human scenarios using ACKs, NAKs?

•  new mechanisms in rdt2.0 (beyond rdt1.0): –  error detec8on –  receiver feedback: control msgs (ACK,NAK) rcvr-‐>sender

sender FSM

receiver FSM

©Kurose & Ross, 2002

Computer Networking and Applications

©Kurose & Ross, 2002

Computer Networking and Applications

rdt2.0: in action (no errors)

sender FSM

rdt2.0: in action (error scenario)

receiver FSM ©Kurose & Ross, 2002

sender FSM

receiver FSM ©Kurose & Ross, 2002

Computer Networking and Applications

Computer Networking and Applications rdt2.1: sender, handles garbled ACK/NAKs

rdt2.0 has a fatal flaw! What happens if ACK/NAK corrupted? •  •

sender doesn t know what happened at receiver! can t just retransmit: possible duplicate

What to do? •  •

sender ACKs/NAKs receiver s ACK/NAK? What if sender ACK/NAK lost? retransmit, but this might cause retransmission of correctly received pkt!

Handling duplicates: •  sender adds sequence number to each pkt •  sender retransmits current pkt if ACK/NAK garbled •  receiver discards (doesn t deliver up) duplicate pkt stop and wait Sender sends one packet, then waits for receiver response

©Kurose & Ross, 2002

Computer Networking and Applications rdt2.1: receiver, handles garbled ACK/NAKs

©Kurose & Ross, 2002

Computer Networking and Applications

rdt2.1: discussion Sender: •  seq # added to pkt •  two seq. # s (0,1) will suﬃce. Why? •  must check if received ACK/ NAK corrupted •  twice as many states –  state must remember whether current pkt has 0 or 1 seq. #

©Kurose & Ross, 2002

Computer Networking and Applications

•  note: receiver can not know if its last ACK/NAK received OK at sender

©Kurose & Ross, 2002

rdt3.0: channels with errors and loss

sender FSM

•  same func8onality as rdt2.1, using ACKs only •  instead of NAK, receiver sends ACK for last pkt received OK

•  duplicate ACK at sender results in same ac8on as NAK: retransmit current pkt

–  state indicates whether 0 or 1 is expected pkt seq #

Computer Networking and Applications

rdt2.2: a NAK-free protocol

–  receiver must explicitly include seq # of pkt being ACKed

Receiver: •  must check if received packet is duplicate

New assump8on: underlying Approach: sender waits channel can also lose packets reasonable amount of 8me for ACK (data or ACKs)

•  retransmits if no ACK received in this 8me •  if pkt (or ACK) just delayed (not lost): Q: how to deal with loss? –  retransmission will be –  sender waits un8l certain data or duplicate, but use of seq. # s already handles this ACK lost, then retransmits –  receiver must specify seq # of –  yuck: drawbacks? pkt being ACKed •  requires countdown 8mer –  checksum, seq. #, ACKs, retransmissions will be of help, but not enough

!

©Kurose & Ross, 2002

Computer Networking and Applications

rdt3.0 sender

rdt3.0 in action

©Kurose & Ross, 2002

Computer Networking and Applications

©Kurose & Ross, 2002

Computer Networking and Applications

Need for Pipelining •  1 Gbps link, 15 ms e-‐e prop. delay, 1KB packet:

rdt3.0 in action

Ttransmit =

8Kb/pkt = 8 microsec/packet 10**9 b/sec

8 microsec fraction of time = 0.00027 Utilization = U = sender busy sending = 30.008 msec 1KB pkt every 30 msec -> 33KB/sec thruput over 1 Gbps link network protocol limits use of physical resources!

©Kurose & Ross, 2002

Computer Networking and Applications

©Kurose & Ross, 2002

Computer Networking and Applications

go-Back-N

Selective Repeat

•  Sender

–  one 8mer –  on 8meout, retransmit all packets in window from last ACK + 1

•  Receiver –  cumula8ve ACK –  discard out of order packets

•  Example •  Advantages & disadvantages

Example (board) ©Kurose & Ross, 2002

©Kurose & Ross, 2002

Computer Networking and Applications

Selective Repeat - window size

RFCs 793, 1122, 1323, 2018, 2581

Example:

•  TCP is designed to provide the appearance of a reliable channel over the unreliable network layer (IP). •  In addi8on to the checksum and mul8plexing as provided by UDP, TCP also provides ﬂow control and conges8on control and a reliable connec8on. •  The channel, or connec6on, is not a virtual circuit. All state informa8on resides in the sending and receiving hosts, not in the routers. •  TCP deals with

❒ seq # s: 0, 1, 2, 3 ❒ window size=3 ❒ receiver sees no difference in two scenarios ❒ incorrectly passes duplicate data as new in (a)

–  Lost packets –  Re-‐ordered packets –  Delayed packets

Q: what is the relationship between seq# size and window size? 37 ©Kurose & Ross, 2002

Computer Networking and Applications

ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup,teardown commands) Internet checksum (as in UDP)

Seq #s and ACKs in TCP

32 bits source port #

counting by bytes of data (not segments!)

dest port #

sequence number acknowledgement number headnot UAP R S F rcvr window size len used checksum

•  TCP is a modiﬁed hybrid of go-‐back-‐N and selec8ve repeat. Cumula8ve ACKs. Only ACK up to correctly received segments.

Computer Networking and Applications

TCP segment structure URG: urgent data (generally not used)

TCP

# bytes rcvr willing to accept

ptr urgent data

Options (variable length) application data (variable length)

Seq. # s: –  byte stream number of first byte in segment s data ACKs: –  seq # of next byte expected from other side –  cumulative ACK –  Piggybacked in data packets Q: how receiver handles outof-order segments –  A: TCP spec doesn t say, - up to implementor

Host B

Host A User types C

Seq=4

timer seq 42 host ACKs receipt of echoed C

timer seq 43

2, ACK

=79, da

CK=4

79, A

Seq=

Seq=4

ytes d

ata

=100 ACK

2, 8 b

ytes d

ata

Seq=100 timeout Seq=92 timeout

timeout

2, 8 b

X loss Seq=9

Host A

Host B

Seq=9

100

lost ACK scenario

host ACKs receipt of C , echoes back C

=80

simple telnet scenario

time

©Kurose & Ross, 2002

How long should the timeout be?

Host B

Seq=9 2, 8 b ytes d Seq= ata 100, 20 by tes d ata 0 10 0 K= K=12 C A AC Seq=9 2, 8 b ytes d ata =1 CK

20

A

= ACK

time

C

Computer Networking and Applications

Retransmission Scenarios Host A

ta = 3, da

C

3, ACK

Computer Networking and Applications

ta =

time

•  Timer should 8me out only rarely. –  Ideally only when a segment is lost –  Prac8cally usually only when a segment is lost, may 8meout on some long delays; but not average delays.

•  The delay is expressed as a round trip 8me (RTT). Delay varies due to conges8on and path. We need an es8mate. Exponen8al Weighted Moving Average is used EstimatedRTT = (1 - x)*EstimatedRTT + x*SampleRTT! Typically, exis8ng es8mate is weighted more (x = 0.125)

•  To prevent delays from causing 8meouts too frequently, the 8mer takes into considera8on the devia8on from the average. Timeout = EstimatedRTT + 4 * Deviation ! Deviation=(1-x)*Deviation+x*|SampleRTT-EstimatedRTT|! •  Note that one ACK may acknowledge several segments, so calcula8ng the 8meout is non-‐trivial.

Computer Networking and Applications

TCP - flow control

Establishing a Connection

•  Flow control exists to prevent the sender from overwhelming the receiver. •  Receiving host informs sender of the receive window size in the header of TCP segments (ini8ally = receive buﬀer size) •  At sending host LastByteSent -‐ LastByteAcked <= Receive Window •  What if the receive buﬀer is full? Receive window = 0. How will the sender know when more space is available?

TL send buffer

Receiving process

TL receive buffer

segment

Computer Networking and Applications

client

–  Request connec8on –  Grant connec8on –  Acknowledge

server SYN(seq

SYN(Se

•  Ini8al sequence numbers of the sender and receiver are exchanged as part of the connec8on establishment. •  A SYN bit in the header is set to 1 for the ﬁrst two segments to indicate the set up. •  The third handshake is required to deal with duplicate segments/ACKs

= x)

q = y, AC

(Seq = x+1

K = x+1)

, ACK = y+1

)

Computer Networking and Applications

Terminating a Connection •  It is equally important to have an agreed termina8on of a connec8on –  need to guarantee that all data has been delivered in both direc8ons •  Such a guarantee is not possible (but assurance can be given with a high probability) –  consider the problem in the diagram below –  the blue armies (on the hills) are to amack the red army (in the valley) –  the blue armies need to guarantee a coordinated amack

Terminating a connection in TCP •  8meouts at client and server guarantee that the connec8on will eventually be closed on both sides. •  8med wait increases the chance of server receiving a ﬁnal ACK

client

server

closing

FIN

AC K

closing

FIN

timed wait

Sending process

•  TCP connec8ons are established by a 3-‐way handshake.

ACK

closed

Computer Networking and Applications

Congestion

Reasons to avoid Congestion

•  Conges8on can occur within the network. Too many sources and/ or too much data being sent for the routers.

•  Throughput is capped at routers. Sending at higher rates has no Host A λ : original data beneﬁt. •  Conges8on increases average delay. in

Host B

λ

in1

λ

in2

•  Can result in –  packet loss (buffer overflows) –  high delays (queuing in buffer)

λ router buffering

λout

unlimited shared output link buffers

out

•  Retransmission of packets, dropped or delayed, adds overhead to network. For delayed packets, this is wasted overhead. •  When a packet is dropped, the eﬀort of earlier routers, is wasted. •  Performance degrades exponen8ally as conges8on level approaches capacity. We want to avoid reaching this state!

Computer Networking and Applications

TCP congestion control - Tahoe 1988

Approaches to avoiding congestion •  Network layer assisted –  Routers provide explicit feedback of conges8on and/or available rate. –  ATM-‐ABR, Explicit Conges8on No8ﬁca8on (TCP/IP -‐ proposed)

•  End-‐to-‐end –  End systems amempt to infer conges8on based on packet acknowledgment 8mes, etc. –  Current TCP/IP implementa8ons

•  Network layer assisted increases complexity of routers •  End-‐to-‐end may make an incorrect inference of conges8on (e.g. in mobile networks)

Computer Networking and Applications

•  Vegas -‐ 1995 –  detect conges8on before packet loss.

cwnd window size (in segments)

–  Fast retransmit •  3 duplicate ACKs -‐ retransmit immediately –  Fast recovery •  3 duplicate ACKs -‐ stay in conges8on avoidance, don't re-‐enter slow start

–  Initially CongWin = 1 Maximum Segment Size (MSS)! –  Set a threshold, Thresh = 65535 bytes! –  While CongWin <= Thresh! •  Send a segment! •  If ACK is received before timeout,  CongWin = CongWin + 1 MSS! Slow Start •  If timeout occurs,  Thresh = 1/2 min(ReceiveWin, CongWin), CongWin = 1 MSS! –  While CongWin > Thresh! •  Send a segment! Congestion•  If ACK is received before timeout,  CongWin = CongWin + MSS * MSS/CongWin! Avoidance •  If timeout occurs  Thresh = 1/2 min(ReceiveWin, CongWin), CongWin = 1 MSS!

Computer Networking and Applications

TCP Congestion Control - open issues

TCP Congestion Control & extensions •  Extensions •  Reno -‐ 1990

•  In addi8on to the Receive Window (for ﬂow control) the senders rate is also controlled by a Conges8on Window LastByteSent - LastByteAcked <= min (ReceiveWin, CongWin) •  Determining the conges8on window

TCP Reno

•  Under conges8on condi8ons, TCP provides fair sharing of available throughput –  When a segment is not ACK’ed, the Threshold of senders will converge Send1 = 20/2 = 10 Send2 = 10/2 = 5 –  Only fair if each applica8on has same number of TCP streams open!

ssthresh

•  TCP doesn’t spend much 8me in slow start (due to exponen8al increase) unless –  Transmission rates are high rela8ve to latency (not gerng enough ACKs back to grow window size) –  Object being sent is small (not enough 8me to escape slow start)

TCP Tahoe

Transmission round

•  Somewhat problema8c for the web. •  UDP is osen used to avoid TCP conges8on control. This will be a problem if UDP traﬃc becomes more prevalent. •  TCP conges8on control is s8ll an ac8ve area of research with many varia8ons on the basic Reno protocol.

Turn static files into dynamic content formats.

Create a flipbook