1 I nt ernet apps: t heir prot ocols and t ransport prot ocols - - PDF document

1

18 September 2001 Transport 1 1 Data Communications, Jonny Pettersson, UmU

Applicat ions and applicat ion-layer prot ocols

Applicat ion: communicat ing, dist ribut ed processes

❍ running in net work host s in

“user space”

❍ exchange messages t o

implement app

❍ e.g., email, f ile t r ansf er,

t he Web Applicat ion-layer prot ocols

❍ one “piece” of an app ❍ def ine messages

exchanged by apps and act ions t aken

❍ user services provided by

lower layer prot ocols

applicat ion t r anspor t net work dat a link physical applicat ion t r anspor t net work dat a link physical applicat ion t r anspor t net work dat a link physical

18 September 2001 Transport 1 2 Data Communications, Jonny Pettersson, UmU

What t ransport service does an app need?

Dat a loss

❒ some apps (e.g., audio) can

t oler at e some loss

❒ ot her apps (e.g., f ile

t ransf er, t elnet ) requir e 100% r eliable dat a t ransf er

Timing

❒ some apps (e.g., I nt ernet

t elephony, int eract ive games) require low delay t o be “ef f ect ive”

Bandwidt h

❒ some apps (e.g., mult imedia)

requir e minimum amount of bandwidt h t o be “ef f ect ive”

❒ ot her apps (“elast ic apps”)

make use of what ever bandwidt h t hey get

18 September 2001 Transport 1 3 Data Communications, Jonny Pettersson, UmU

Transport service requirement s of common apps

Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games financial apps Data loss no loss no loss loss-tolerant loss-tolerant loss-tolerant loss-tolerant no loss Bandwidth elastic elastic elastic audio: 5Kb-1Mb video:10Kb-5Mb same as above few Kbps up elastic Time Sensitive no no no yes, 100’s msec yes, few secs yes, 100’s msec yes and no

2

18 September 2001 Transport 1 4 Data Communications, Jonny Pettersson, UmU

I nt ernet apps: t heir prot ocols and t ransport prot ocols

Application e-mail remote terminal access Web file transfer streaming multimedia remote file server Internet telephony Application layer protocol smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietary (e.g. RealNetworks) NSF proprietary (e.g., Vocaltec) Underlying transport protocol TCP TCP TCP TCP TCP or UDP TCP or UDP typically UDP

18 September 2001 Transport 1 5 Data Communications, Jonny Pettersson, UmU

Transport Layer 1

Lect ur e goals:

❒ underst and some of t he

pr inciples behind t ransport layer services:

❍ mult iplexing/ demult iplex

ing

❍ r eliable dat a t r ansf er

❒ inst ant iat ion and

implement at ion of UDP in t he I nt ernet

❒ More next t ime…

Lect ur e Over view:

❒ t ransport layer services ❒ mult iplexing/ demult iplexing ❒ connect ionless t ransport : UDP ❒ pr inciples of reliable dat a

t ransf er

❒ Next lect ur e

❍ connect ion-or ient ed t r anspor t :

TCP

• r eliable t r ansf er
• f low cont r ol
• connect ion management

❍ pr inciples of congest ion cont r ol ❍ TCP congest ion cont r ol 18 September 2001 Transport 1 6 Data Communications, Jonny Pettersson, UmU

Transport services and prot ocols

❒ provide logical communicat ion

bet ween app’ processes running on dif f erent host s

❒ t ransport prot ocols run in

end syst ems

❒ t ransport vs net work layer

services:

❒ net work layer : dat a t r ansf er

bet ween end syst ems

❒ t ransport layer : dat a

t ransf er bet ween processes

❍ r elies on, enhances, net wor k

layer ser vices

applicat ion t r anspor t net work dat a link physical applicat ion t r anspor t net work dat a link physical net work dat a link physical net work dat a link physical net work dat a link physical net work dat a link physical net work dat a link physical

l

• g

i c a l e n d

• e

n d t r a n s p

• r

t

3

18 September 2001 Transport 1 7 Data Communications, Jonny Pettersson, UmU

Transport -layer prot ocols

I nt ernet t ransport services:

❒ reliable, in-order unicast

delivery (TCP)

❍ congest ion ❍ f low cont r ol ❍ connect ion set up

❒ unreliable (“best -ef f ort ”),

unordered unicast or mult icast delivery: UDP

❒ services not available:

❍ r eal-t ime ❍ bandwidt h guar ant ees ❍ r eliable mult icast

Application UDP TCP IP Link Physical

18 September 2001 Transport 1 8 Data Communications, Jonny Pettersson, UmU

End-t o-end pr ot ocol

Two f orces shapes t he end-t o-end prot ocol

❒ Applicat ions has demands on t he supplied

service

❒ Underlying net work prot ocol has limit at ions

18 September 2001 Transport 1 9 Data Communications, Jonny Pettersson, UmU applicat ion t ransport net work

M

P2

applicat ion t r anspor t net wor k

Mult iplexing/ demult iplexing

Recall: segment - unit of dat a exchanged bet ween t ransport layer ent it ies

❍ aka TPDU: t ransport

prot ocol dat a unit

r eceiver

Ht Hn

Demult iplexing: deliver ing received segment s t o cor rect app layer processes

segment

segment

M

applicat ion t r anspor t net wor k

P1

M M M

P3 P4

segment header applicat ion-layer dat a

4

18 September 2001 Transport 1 10 Data Communications, Jonny Pettersson, UmU

Mult iplexing/ demult iplexing

mult iplexing/ demult iplexing:

❒ based on sender, receiver

port numbers, I P addresses

❍ source, dest port # s in

each segment

❍ recall: well-known port

numbers f or specif ic applicat ions gat her ing dat a f rom mult iple app processes, enveloping dat a wit h header (lat er used f or demult iplexing)

sour ce por t # dest por t # 32 bit s

applicat ion dat a (message)

• t her header f ields

TCP/ UDP segment f ormat Mult iplexing:

18 September 2001 Transport 1 11 Data Communications, Jonny Pettersson, UmU

Port s

❒ 0 – 65535 ❒ Reser ved, well-known, RFC 1700: 0 - 1023

emil ~>ypcat services | more kip 2112/tcp # IP over kerberos acmaint_transd 901/udp kerberos_master 751/udp # Kerberos authentication kerberos-iv 750/udp kerberos kdc # Kerberos authentication--udp new-rwho 550/udp new-who # experimental kshell 544/tcp krcmd # and remote shell talk 517/udp netbios-ns 137/udp nntp 119/tcp usenet # Network News Transfer pop 110/tcp pop3 pop-3 # Post Office V.3 - RFC 1081 hostnames 101/tcp hostname # usually to sri-nic link 87/tcp ttylink http 80/tcp httpd telnet 23/tcp ftp 21/tcp echo 7/udp echo 4/ddp # AppleTalk Echo Protocol … 18 September 2001 Transport 1 12 Data Communications, Jonny Pettersson, UmU

Mult iplexing/ demult iplexing: examples

host A server B

sour ce por t : x dest . por t : 23 sour ce por t :23 dest . por t : x

port use: simple t elnet app Web client host A Web server B Web client host C

Sour ce I P: C Dest I P: B sour ce por t : x dest . por t : 80 Sour ce I P: C Dest I P: B sour ce por t : y dest . por t : 80

port use: Web server

Sour ce I P: A Dest I P: B sour ce por t : x dest . por t : 80

5

18 September 2001 Transport 1 13 Data Communications, Jonny Pettersson, UmU

UDP: User Dat agr am Pr ot ocol [RFC 768]

❒ “no f r ills,” “bare bones”

I nt ernet t ransport prot ocol

❒ “best ef f ort ” service, UDP

segment s may be:

❍ lost ❍ delivered out of order

t o app

❒ connect ionless:

❍ no handshaking bet ween

UDP sender , receiver

❍ each UDP segment

handled independent ly

• f ot hers

Why use UDP inst ead of TCP ?

❒ no connect ion

est ablishment (which can add delay)

❒ simple: no connect ion st at e

at sender, receiver

❒ small segment header ❒ no congest ion cont rol: UDP

can blast away as f ast as desired

18 September 2001 Transport 1 14 Data Communications, Jonny Pettersson, UmU

UDP: mor e

❒ of t en used f or

st r eaming mult imedia apps

❍ loss t olerant ❍ r at e sensit ive

❒ ot her UDP

uses (why?):

❍ DNS ❍ SNMP sour ce por t # dest por t # 32 bit s

Applicat ion dat a (message) UDP segment f ormat

lengt h checksum Lengt h, in byt es of UDP segment , including header

18 September 2001 Transport 1 15 Data Communications, Jonny Pettersson, UmU

Reliable t ransf er over UDP

❒ add reliabilit y at applicat ion layer

❍applicat ion-specif ic er ror recover!

❒ applicat ion using UDP is responsible f or

handling of :

❍ lost messages ❍ duplicat e messages ❍ delays ❍ unor der ed deliver y ❍ lost cont act

6

18 September 2001 Transport 1 16 Data Communications, Jonny Pettersson, UmU

UDP checksum (RFC 1071)

Sender:

❒ t reat segment cont ent s

as sequence of 16-bit int egers

❒ checksum: addit ion (1’s

complement sum) of segment cont ent s

❒ sender put s checksum

value int o UDP checksum f ield

Receiver:

❒ comput e checksum of

received segment

❒ check if comput ed checksum,

including checksum f ield, equals all 1´ s:

❍ NO - error det ect ed ❍ YES - no er ror det ect ed.

But maybe errors nonet hless? More lat er … .

Goal: det ect “er rors” (e.g., f lipped bit s) in t r ansmit t ed segment

18 September 2001 Transport 1 17 Data Communications, Jonny Pettersson, UmU

UDP checksum (more)

❒ t he checksum is comput ed over

❍ UDP

header

❍ payload ❍ pseudo header

• used t o ver if y endconnect ions

❒ why cont rol errors in several layers?

Source IP Address 16 31 Destination IP Address UDP Length Protocol

18 September 2001 Transport 1 18 Data Communications, Jonny Pettersson, UmU

Pr inciples of Reliable dat a t r ansf er

❒ import ant in app., t r ansport , link layers ❒ t op-10 list of import ant net working t opics! ❒ charact erist ics of unr eliable channel will det ermine

complexit y of reliable dat a t ransf er prot ocol (rdt )

7

18 September 2001 Transport 1 19 Data Communications, Jonny Pettersson, UmU

Reliable dat a t ransf er: get t ing st art ed

send side receive side

rdt_send(): called f r om above, (e.g., by app.). Passed dat a t o deliver t o r eceiver upper layer udt_send(): called by r dt , t o t r ansf er packet over unr eliable channel t o r eceiver rdt_rcv(): called when packet arr ives on r cv-side of channel deliver_data(): called by rdt t o deliver dat a t o upper

18 September 2001 Transport 1 20 Data Communications, Jonny Pettersson, UmU

Reliable dat a t ransf er: get t ing st art ed

We’ll:

❒ increment ally develop sender, receiver sides of

r eliable dat a t ransf er pr ot ocol (r dt )

❒ consider only unidir ect ional dat a t ransf er

❍ but cont rol inf o will f low on bot h direct ions!

❒ use f init e st at e machines (FSM) t o specif y

sender , r eceiver

st at e 1 st at e 2

event causing st at e t r ansit ion act ions t aken on st at e t r ansit ion st at e: when in t his “st at e” next st at e uniquely det er mined by next event event act ions

18 September 2001 Transport 1 21 Data Communications, Jonny Pettersson, UmU

Rdt 1.0: reliable t r ansf er over a reliable channel

❒ underlying channel perf ect ly reliable

❍ no bit er ros ❍ no loss of packet s

❒ separat e FSMs f or sender , r eceiver :

❍ sender sends dat a int o underlying channel ❍ receiver r ead dat a f rom underlying channel

8

18 September 2001 Transport 1 22 Data Communications, Jonny Pettersson, UmU

Rdt 2.0: channel wit h bit errors

❒ under lying channel may f lip bit s in packet

❍ recall: checksum t o det ect bit er rors

❒ t he quest ion: how t o r ecover f r om er ror s:

❍ acknowledgement s (ACKs): r eceiver explicit ly t ells sender

t hat pkt received OK

❍ negat ive acknowledgement s (NAKs): receiver explicit ly

t ells sender t hat pkt had errors

❍ sender ret ransmit s pkt on receipt of NAK ❍ human scenar ios using ACKs, NAKs?

❒ new mechanisms in rdt2.0 (beyond rdt1.0):

❍ er ror det ect ion ❍ receiver f eedback: cont rol msgs (ACK,NAK) rcvr->

sender

18 September 2001 Transport 1 23 Data Communications, Jonny Pettersson, UmU

r dt 2.0: FSM specif icat ion

sender FSM r eceiver FSM

18 September 2001 Transport 1 24 Data Communications, Jonny Pettersson, UmU

r dt 2.0: in act ion (no er r or s)

sender FSM r eceiver FSM

9

18 September 2001 Transport 1 25 Data Communications, Jonny Pettersson, UmU

r dt 2.0: in act ion (er r or scenar io)

sender FSM r eceiver FSM

18 September 2001 Transport 1 26 Data Communications, Jonny Pettersson, UmU

rdt 2.0 has a f at al f law!

What happens if ACK/ NAK corrupt ed?

❒ sender doesn’t know what

happened at receiver!

❒ can’t j ust r et r ansmit :

possible duplicat e

What t o do?

❒ sender ACKs/ NAKs

receiver’s ACK/ NAK? What if sender ACK/ NAK lost ?

❒ ret ransmit , but t his might

cause ret ransmission of cor rect ly r eceived pkt !

Handling duplicat es:

❒ sender adds sequence

number t o each pkt

❒ sender ret ransmit s curr ent

pkt if ACK/ NAK garbled

❒ receiver discards (doesn’t

deliver up) duplicat e pkt Sender sends one packet , t hen wait s f or receiver response st op and wait

18 September 2001 Transport 1 27 Data Communications, Jonny Pettersson, UmU

rdt 2.1: sender, handles garbled ACK/ NAKs

10

18 September 2001 Transport 1 28 Data Communications, Jonny Pettersson, UmU

rdt 2.1: receiver, handles garbled ACK/ NAKs

18 September 2001 Transport 1 29 Data Communications, Jonny Pettersson, UmU

rdt 2.1: discussion

Sender:

❒ seq # added t o pkt ❒ t wo seq. # ’s (0,1) will

suf f ice. Why?

❒ must check if received

ACK/ NAK corrupt ed

❒ t wice as many st at es

❍ st at e must “r emember”

whet her “cur rent ” pkt has 0 or 1 seq. #

Receiver:

❒ must check if received

packet is duplicat e

❍ st at e indicat es whet her

0 or 1 is expect ed pkt seq # ❒ not e: receiver can not

know if it s last ACK/ NAK received OK at sender

18 September 2001 Transport 1 30 Data Communications, Jonny Pettersson, UmU

r dt 2.2: a NAK-f r ee pr ot ocol

❒ same f unct ionalit y as

rdt 2.1, using ACKs only

❒ inst ead of NAK,

r eceiver sends ACK f or last pkt received OK

❍ receiver must explicit ly

include seq # of pkt being ACKed ❒ duplicat e ACK at

sender r esult s in same act ion as NAK: r et ransmit cur r ent pkt sender FSM

!

11

18 September 2001 Transport 1 31 Data Communications, Jonny Pettersson, UmU

rdt 3.0: channels wit h er rors and loss

New assumpt ion: under lying channel can also lose packet s (dat a

• r ACKs)

❍ checksum, seq. # , ACKs,

ret ransmissions will be

• f help, but not enough

Q: how t o deal wit h loss?

❍ sender wait s unt il

cert ain dat a or ACK lost , t hen ret ransmit s

❍ drawbacks?

Appr oach: sender wait s “r easonable” amount of t ime f or ACK

❒ ret ransmit s if no ACK

received in t his t ime

❒ if pkt (or ACK) j ust delayed

(not lost ):

❍ ret ransmission will be

duplicat e, but use of seq. # ’s alr eady handles t his

❍ receiver must specif y seq

# of pkt being ACKed

❒ requir es count down t imer

18 September 2001 Transport 1 32 Data Communications, Jonny Pettersson, UmU

r dt 3.0 sender

18 September 2001 Transport 1 33 Data Communications, Jonny Pettersson, UmU

r dt 3.0 in act ion

12

18 September 2001 Transport 1 34 Data Communications, Jonny Pettersson, UmU

r dt 3.0 in act ion

18 September 2001 Transport 1 35 Data Communications, Jonny Pettersson, UmU

Per f or mance of r dt 3.0

❒ r dt 3.0 wor ks, but perf or mance st inks ❒ example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet : Tt r ansmit = 8kb/ pkt 10** 9 b/ sec = 8 microsec Ut ilizat ion = U = = 8 microsec 30.016 msec f ract ion of t ime sender busy sending = 0.00027

❍ 1KB pkt every 30 msec ->

33kB/ sec t hroughput over 1 Gbps link

❍ net work prot ocol limit s use of physical resources! 18 September 2001 Transport 1 36 Data Communications, Jonny Pettersson, UmU

Pipelined pr ot ocols

P ipelining: sender allows mult iple, “in-f light ”, yet -t o- be-acknowledged pkt s

❍ range of sequence numbers must be increased ❍ buf f er ing at sender and/ or receiver

❒ Two gener ic f or ms of pipelined pr ot ocols: go-Back-N,

select ive r epeat

13

18 September 2001 Transport 1 37 Data Communications, Jonny Pettersson, UmU

Go-Back-N

Sender:

❒ k-bit seq # in pkt header ([0, 2K-1]) ❒ “window” of up t o N, consecut ive unack’ed pkt s allowed ❒ ACK(n): ACKs all pkt s up t o, including seq # n - “cumulat ive ACK”

❍ may receive duplicat e ACKs (see receiver)

❒ t imer f or each in-f light pkt ❒ t imeout (n): ret ransmit pkt n and all higher seq # pkt s in window

18 September 2001 Transport 1 38 Data Communications, Jonny Pettersson, UmU

GBN: sender ext ended FSM

18 September 2001 Transport 1 39 Data Communications, Jonny Pettersson, UmU

GBN: receiver ext ended FSM

receiver simple:

❒ ACK-only: always send ACK f or correct ly-r eceived

pkt wit h highest in-or der seq #

❍ may generat e duplicat e ACKs ❍ need only remember expectedseqnum

❒ out -of -or der pkt :

❍ discard (don’t buf f er) ->

no receiver buf f ering!

❍ ACK pkt wit h highest in-order seq #

14

18 September 2001 Transport 1 40 Data Communications, Jonny Pettersson, UmU

GBN in act ion

18 September 2001 Transport 1 41 Data Communications, Jonny Pettersson, UmU

Select ive Repeat

❒ receiver individually acknowledges all corr ect ly

received pkt s

❍ buf f ers pkt s, as needed, f or event ual in-order delivery

t o upper layer ❒ sender only r esends pkt s f or which ACK not

received

❍ sender t imer f or each unACKed pkt

❒ sender window

❍ N consecut ive seq # ’s ❍ again limit s seq # s of sent , unACKed pkt s 18 September 2001 Transport 1 42 Data Communications, Jonny Pettersson, UmU

Select ive repeat : sender, receiver windows

15

18 September 2001 Transport 1 43 Data Communications, Jonny Pettersson, UmU

Select ive repeat

dat a f r om above :

❒ if next available seq # in

window, send pkt

t imeout (n):

❒ resend pkt n, rest art t imer

ACK(n) in [sendbase,sendbase+N]:

❒ mark pkt n as received ❒ if n smallest unACKed pkt ,

advance window base t o next unACKed seq #

sender pkt n in [r cvbase, r cvbase+N-1]

❒ send ACK(n) ❒ out -of -order: buf f er ❒ in-order: deliver (also

deliver buf f ered, in-or der pkt s), advance window t o next not -yet -received pkt

pkt n in [r cvbase-N,r cvbase-1]

❒ ACK(n)

• t her wise:

❒ ignor e

receiver

18 September 2001 Transport 1 44 Data Communications, Jonny Pettersson, UmU

Select ive r epeat in act ion

18 September 2001 Transport 1 45 Data Communications, Jonny Pettersson, UmU

Select ive repeat : dilemma

Example:

❒ seq # ’s: 0, 1, 2, 3 ❒ window size=3 ❒ receiver sees no

dif f erence in t wo scenarios!

❒ incor rect ly passes

duplicat e dat a as new in (a) Q: what relat ionship bet ween seq # size and window size?

16

18 September 2001 Transport 1 46 Data Communications, Jonny Pettersson, UmU

Summary

❒ t ransport layer services ❒ mult iplexing/ demult iplexing ❒ connect ionless t ransport : UDP ❒ principles of reliable dat a t ransf er ❒ sliding window prot ocols

❍ go-back-N ❍ selct ive r epeat

❒ ”Frågest und på f redag”