Computer Networks and Applications COMP 3331/COMP 9331 Week 4

P2P + Transport Layer Part 1 Reading Guide: Chapter 2, 2.6 + Chapter 3, Sections 3.1 – 3.4

Announcements v 

Assignment 1 §  Non-CSE students MUST seek approval for alternate assignment by 22nd August (else we assume you do the regular one) §  Start ASAP – take baby steps §  Plagiarism - BE CAREFUL

v  v  v 

Are you solving sample questions? Are you reading prescribed sections from the textbook? Mid-session Exam in Week 6 (during Monday lecture) §  §  §  §  § 

Details will be available on website soon (Location, Instructions, …) All material covered from Week 1- Week 5 (including self-study) Closed book BYO Calculators More details next week 2

2. Application Layer: outline 2.1 principles of network applications § app architectures § app requirements

2.6 P2P applications 2.7 socket programming with UDP and TCP

2.2 Web and HTTP 2.3 FTP 2.4 electronic mail § SMTP, POP3, IMAP

2.5 DNS

3

Pure P2P architecture v  v  v 

no always-on server arbitrary end systems directly communicate peers are intermittently connected and change IP addresses

examples: § file distribution (BitTorrent) § Streaming (KanKan) § VoIP (Skype) 4

Overlay network v  A

network made up of “virtual” or logical links

v  Virtual

links map to one or more physical links (i.e. paths)

5

Self Study

File distribution: client-server vs P2P Question: how much time to distribute file (size F) from one server to N peers? § peer upload/download capacity is limited resource us: server upload capacity

file, size F

server uN dN

us

u1

d1

u2

d2

network (with abundant bandwidth)

di: peer i download capacity di ui ui: peer i upload capacity 6

Self Study

File distribution time: client-server v 

server transmission: must sequentially send (upload) N file copies: §  time to send one copy: F/us

us di network

§  time to send N copies: NF/us v 

F

ui

client: each client must download file copy

§  dmin = min client download rate §  min client download time: F/dmin

time to distribute F to N clients using client-server approach

Dc-s > max{NF/us,,F/dmin} increases linearly in N 7

Self Study

File distribution time: P2P v 

server transmission: must upload at least one copy §  time to send one copy: F/us v 

client: each client must download file copy

F

us di network

§  min client download time: F/dmin v 

ui

clients: as aggregate must download NF bits §  max upload rate (limiting max download rate) is us + Σui

time to distribute F to N clients using P2P approach

DP2P > max{F/us,,F/dmin,,NF/(us + Σui)}

increases linearly in N … … but so does this, as each peer brings service capacity 8

Self Study

Client-server vs. P2P: example client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us

Minimum Distribution Time

3.5 P2P Client-Server

3 2.5 2 1.5 1 0.5 0 0

5

10

15

20

25

30

35

N 9

P2P file distribution: BitTorrent v file divided into 256Kb chunks v peers in torrent send/receive file chunks tracker: tracks peers participating in torrent

torrent: group of peers exchanging chunks of a file

Alice arrives … … obtains list of peers from tracker … and begins exchanging file chunks with peers in torrent 10

.torrent files v  Contains

address of trackers for the file

§ Where can I find other peers? v  Contain

a list of file chunks and their cryptographic hashes § This ensures that chunks are not modified Title

End-systems that have it

House of Cards Season 4

124.45.66.128, 88.45.34.214

Walking Dead Season 6

111.111.111.111, 432.125.43.43

Game of Thrones Season 5

42.12.43.32

Better Call Saul Season 2

123.134.2.123

11

P2P file distribution: BitTorrent v 

peer joining torrent: §  has no chunks, but will accumulate them over time from other peers §  registers with tracker to get list of peers, connects to subset of peers (“neighbours”) while downloading, peer uploads chunks to other peers v  peer may change peers with whom it exchanges chunks v  churn: peers may come and go v  once peer has entire file, it may (selfishly) leave or (altruistically) remain in torrent v 

12

BitTorrent: requesting, sending file chunks requesting chunks: v 

v 

v 

at any given time, different peers have different subsets of file chunks periodically, Alice asks each peer for list of chunks that they have Alice requests missing chunks from peers, rarest first

sending chunks: tit-for-tat

Alice sends chunks to those four peers currently sending her chunks at highest rate

v 

§  other peers are choked by Alice (do not receive chunks from her) §  re-evaluate top 4 every10 secs

v 

every 30 secs: randomly select another peer, starts sending chunks §  “optimistically unchoke” this peer §  newly chosen peer may join top 4

13

BitTorrent: tit-for-tat (1) Alice “optimistically unchokes” Bob (2) Alice becomes one of Bob’s top-four providers; Bob reciprocates (3) Bob becomes one of Alice’s top-four providers

higher upload rate: find better trading partners, get file faster ! Original Research Paper on BitTorrent linked to lecture notes page

14

Getting rid of the server v  Distribute

the tracker information using a Distributed Hash Table (DHT)

v  A

DHT is a lookup structure

§ Maps keys to an arbitrary value § Works a lot like, well …. hash table

15

Recall: Hash Function v  Mapping

of any data to an integer

§ E.g. , md5sum, sha1, etc. § md5: 04c3416cadd85971a129dd1de86cee49

v  With

a good (cryptographic) hash

§ Hash values likely to be unique, although duplicates are possible § Very difficult to find collisions (hashes spread out) 16

Recall: Hash Table v  N

buckets

v  Key-value

bucket i

pair is assigned

§ i = HASH(key)%N v  Easy

to look up value based on key

v  Multiple

key-value pairs assigned to each bucket

17

Distributed Hash Table (DHT) v  DHT:

a distributed P2P database v  database has (key, value) pairs; examples: § key: TFN number; value: human name § key: file name; value: BT tracker peer(s) v  Distribute

the (key, value) pairs over the (millions of peers) v  a peer queries DHT with key § DHT returns values that match the key v  peers

can also insert (key, value) pairs 18

Challenges v  How

do we assign (key, value) pairs to nodes?

v  How

do we find them again quickly?

v  What

happens if nodes join/leave?

19

Q: how to assign keys to peers? v  basic

idea:

§ convert each key to an integer § Assign integer to each peer § put (key,value) pair in the peer that is closest to the key

20

DHT identifiers: Consistent Hashing v  assign integer identifier to each peer [0,2n-1] for some n-bit hash function

in range

§ E.g., node ID is hash of its IP address v  require

each key to be an integer in same range v  to get integer key, hash original key § e.g., key = hash(“House of Cards Season 4”) § this is why its is referred to as a distributed “hash” table

21

Assign keys to peers v  rule:

assign key to the peer that has the closest ID. v  common convention: closest is the immediate successor of the key. v  e.g., n=4; peers: 1,3,4,5,8,10,12,14; § key = 13, then successor peer = 14 § key = 15, then successor peer = 1

22

Circular DHT (1) 1 3

15

4 12

5 10

8

v  each

peer only aware of immediate successor and predecessor. v  “overlay network” 23

Circular DHT (2) 0001 0011

I am

Who’s responsible for key 1110 ?

1111 1110

0100

1110 1110

1100 1110

Define closest as closest successor

1110

0101

1110

1010

1000 24

Quiz: DHT Complexity v  Given

N nodes, what is the complexity (number of messages) of finding a value when each peer knows its successor? A.  O (log n) B. O (n) C. O (n2) D. O (2n)

25

Circular DHT with shortcuts 1

Who’s responsible for key 1110?

3 15 4 12

5 10

v  v  v 

8

each peer keeps track of IP addresses of predecessor, successor, short cuts reduced from 6 to 2 messages. possible to design shortcuts so O(log N) neighbours, O(log N) messages in query 26

Peer churn

handling peer churn:

1

v peers may v each peer

3

15

4 12

5 10

come and go (churn) knows address of its two

successors v each peer periodically pings its two successors to check aliveness v i f immediate successor leaves, choose next successor as new immediate successor

8

example: peer 5 abruptly leaves v peer 4 detects peer 5 departure; makes 8 its immediate successor; asks 8 who its immediate successor is; makes 8’s immediate successor its second successor. 27

Quiz: Peer Churn 1 3

15

4 12

5 10

v  What

8

happens to 5’s value?

§ A. Lost forever § B. Lost until 5 comes back § Still recoverable (how?)

28

Quiz: DHT v  Which

of the following is not true?

A.  DHT distributes portions of a hash table across peers. B.  The key corresponding to an object (e.g., movie) depends on the current number of peers. C.  Which peer is responsible for an object depends on the current number of peers.

29

More DHT info v  How

do nodes join?

v  How

does cryptographic hashing work?

v  How

much state does each node store?

Research Papers (on the lectures page): Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications Dynamo: Amazon’s Highly Available Key-value Store

30

DHT: Applications v 

v  v  v  v  v  v  v  v 

File sharing and backup [CFS, Ivy, OceanStore, PAST, Pastiche …] Web cache and replica [Squirrel, Croquet Media Player] Censor-resistant stores [Eternity] DB query and indexing [PIER, Place Lab, VPN Index] Event notification [Scribe] Naming systems [ChordDNS, Twine, INS, HIP] Distributed BitTorrent tracker [Kademlia, Vuze] Communication primitives [I3, …] Host mobility [DTN Tetherless Architecture]

31

Chapter 3: Transport Layer our goals: v 

understand principles behind transport layer services: §  multiplexing, demultiplexing §  reliable data transfer §  flow control §  congestion control

v 

learn about Internet transport layer protocols: §  UDP: connectionless transport §  TCP: connection-oriented reliable transport §  TCP congestion control

32

Transport Layer Outline 3.1 transport-layer services 3.2 multiplexing and demultiplexing 3.3 connectionless transport: UDP 3.4 principles of reliable data transfer

3.5 connection-oriented transport: TCP §  segment structure §  reliable data transfer §  flow control §  connection management

3.6 principles of congestion control 3.7 TCP congestion control

33

Transport layer v 

v 

Moving “down” a layer Current perspective: §  Application is the boss…. §  Usually executing within the OS Kernel §  The network layer is ours to command !!

34

Network layer (context) v 

v 

What it does: finds paths through network §  Routing from one end host to another

What it doesn’t: §  Reliable transfer: “best effort delivery” §  Guarantee paths §  Arbitrate transfer rates

v 

For now, think of the network layer as giving us an “API” with one function: sendtohost(data, host) §  Promise: the data will go to that (usually!!) 35

Transport services and protocols v 

v 

provide logical communication between app processes running on different hosts transport protocols run in end systems §  send side: breaks app messages into segments, passes to network layer §  rcv side: reassembles segments into messages, passes to app layer §  Exports services to application that network layer does not provide

application transport network data link physical

application transport network data link physical

36

Transport vs. network layer v  network

layer: logical communication between hosts v  transport layer: logical communication between processes § relies on, enhances, network layer services

READ THIS IN TEXT

household analogy: 12 kids in Ann’s house sending letters to 12 kids in Bill’s house: v  hosts = houses v  processes = kids v  app messages = letters in envelopes v  transport protocol = Ann and Bill who demux to inhouse siblings v  network-layer protocol = postal service

37

Why a transport layer? many application processes

mmedia ftp

telnet

browser

browser

Operating System

IP Drivers +NIC

Datalink Physical

Host A

Application Transport Network Datalink Physical

Host B 38

Why a transport layer? many application processes

Transport

IP

IP

Datalink Physical

Datalink Physical

Host A

ftp

telnet

Transport

HTTP server

mmedia ftp

telnet

browser

browser

Communication between processes at hosts

Communication between hosts (128.4.5.6 ßà162.99.7.56)

Host B 39

Quiz: Transport Layer Services How many of these services might we provide at the transport layer ? Which ?

Reliable transfers v  Error detection v  Error correction v  Bandwidth guarantees v 

Latency guarantees v  Encryption v  Message ordering v  Link sharing fairness v 

A: 4 or fewer B: 5 C: 6 D: 7 E: All 8 40

Transport Layer Outline 3.1 transport-layer services 3.2 multiplexing and demultiplexing 3.3 connectionless transport: UDP 3.4 principles of reliable data transfer

3.5 connection-oriented transport: TCP §  segment structure §  reliable data transfer §  flow control §  connection management

3.6 principles of congestion control 3.7 TCP congestion control

41

Multiplexing/demultiplexing multiplexing at sender: handle data from multiple sockets, add transport header (later used for demultiplexing)

demultiplexing at receiver: use header info to deliver received segments to correct socket

application application

P1

P2

application

P3

transport

P4

transport

network

transport

network

link

network

physical

link

link physical

socket process

physical

Note: The network is a shared resource. It does not care about your applications, sockets, etc. 42

How demultiplexing works v 

host receives IP datagrams §  each datagram has source IP address, destination IP address §  each datagram carries one transport-layer segment §  each segment has source, destination port number

v 

host uses IP addresses & port numbers to direct segment to appropriate socket

32 bits source port #

dest port #

other header fields

application data (payload)

TCP/UDP segment format

43

Connectionless demultiplexing v  recall:

created socket has host-local port #:

v  recall:

DatagramSocket mySocket1 = new DatagramSocket(12534);

v 

when host receives UDP segment: §  checks destination port # in segment §  directs UDP segment to socket with that port #

when creating datagram to send into UDP socket, must specify §  destination IP address §  destination port # IP datagrams with same dest. port #, but different source IP addresses and/ or source port numbers will be directed to same socket at dest 44

Connectionless demux: example DatagramSocket mySocket2 = new DatagramSocket (9157);

DatagramSocket serverSocket = new DatagramSocket (6428); application

application

DatagramSocket mySocket1 = new DatagramSocket (5775); application

P1

P3

P4

transport transport

transport

network

network

link

network

link

physical

link physical

physical source port: 6428 dest port: 9157

source port: 9157 dest port: 6428

source port: ? dest port: ?

source port: ? dest port: ? 45

Connection-oriented demux v 

TCP socket identified by 4-tuple: §  source IP address §  source port number §  dest IP address §  dest port number

v 

demux: receiver uses all four values to direct segment to appropriate socket

v 

server host may support many simultaneous TCP sockets: §  each socket identified by its own 4-tuple

v 

web servers have different sockets for each connecting client §  non-persistent HTTP will have different socket for each request

46

Revisiting TCP Sockets Server Process

Client Process

TCP handshake Client Socket

pipe

Welcoming, port X Socket Connection, port X Socket 1 Connection, port X Socket 2

Client Socket

Client Process

47

Connection-oriented demux: example application application

P4

P3

P5

application

P6

P3

P2

transport network

network

link

network

link

physical

link

physical

host: IP address A

transport

transport

server: IP address B source IP,port: B,80 dest IP,port: A,9157 source IP,port: A,9157 dest IP, port: B,80

three segments, all destined to IP address: B, dest port: 80 are demultiplexed to different sockets

physical

source IP,port: C,5775 dest IP,port: B,80

host: IP address C

source IP,port: C,9157 dest IP,port: B,80 48

Connection-oriented demux: example threaded server application application

P3

application

P4

P3

P2

transport network

network

link

network

link

physical

link

physical

host: IP address A

transport

transport

server: IP address B source IP,port: B,80 dest IP,port: A,9157 source IP,port: A,9157 dest IP, port: B,80

physical

source IP,port: C,5775 dest IP,port: B,80

host: IP address C

source IP,port: C,9157 dest IP,port: B,80 49

May I scan your ports? http://netsecurity.about.com/cs/hackertools/a/aa121303.htm v  v 

v 

Servers wait at open ports for client requests Hackers often perform port scans to determine open, closed and unreachable ports on candidate victims Several ports are well-known §  sender

76

rdt2.0: channel with bit errors v 

underlying channel may flip bits in packet §  checksum to detect bit errors

v 

v 

the question: how to recover from errors: §  acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK §  negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors §  sender retransmits pkt on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0): §  error detection §  feedback: control msgs (ACK,NAK) from receiver to sender 77

Self Study

rdt2.0: FSM specification rdt_send(data) sndpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && isACK(rcvpkt) Λ

sender

receiver rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 78

rdt2.0: operation with no errors rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && isACK(rcvpkt) Λ

Self Study

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 79

Self Study

rdt2.0: error scenario rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && isACK(rcvpkt) Λ

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 80

Global Picture of rdt2.0 sender

receiver data

NACK

Dotted line: erroneous transmission Solid line: error-free transmission

data

ACK

81

rdt2.0 has a fatal flaw! what happens if ACK/ NAK corrupted? v 

v 

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

handling duplicates: v 

v  v 

sender retransmits current pkt if ACK/NAK corrupted sender adds sequence number to each pkt receiver discards (doesn’t deliver up) duplicate pkt

stop and wait sender sends one packet, then waits for receiver response 82

Self Study

rdt2.1: sender, handles garbled ACK/NAKs rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && Wait for call 0 from above

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt)

Wait for ACK or NAK 0

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

Λ rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt)

Λ

Wait for ACK or NAK 1

Wait for call 1 from above

rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt)

83

Self Study

rdt2.1: receiver, handles garbled ACK/NAKs rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) Wait for 0 from below

Wait for 1 from below

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) 84

rdt2.1: discussion sender: v  seq # added to pkt v  two seq. #’s (0,1) will suffice. Why? v  must check if received ACK/NAK corrupted v  twice as many states §  state must “remember” whether “expected” pkt should have seq # of 0 or 1

receiver: v  must check if received packet is duplicate §  state indicates whether 0 or 1 is expected pkt seq # v 

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

85

Another Look at rdt2.1 sender

Dotted line: erroneous transmission Solid line: error-free transmission

receiver data (0)

waiting for 0

NACK

sending # 0

data (0

)

ACK data (0

)

Duplicate Packet Discard !!

ACK

sending #1

data (1

waiting for 1

)

waiting for 0 86

rdt2.2: a NAK-free protocol same functionality as rdt2.1, using ACKs only v  instead of NAK, receiver sends ACK for last pkt received OK v 

§  receiver must explicitly include seq # of pkt being ACKed v 

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

87

rdt2.2: Example

Dotted line: erroneous transmission Solid line: error-free transmission

sender

sending # 0

receiver data (0) ) ACK (0

data (1

sending #1 Duplicate ACK Resend old packet

) ACK (0

(imp

)

AK) lies a N

data (1

ACK (1

sending # 0

waiting for 0

waiting for 1

)

)

data (0

)

waiting for 0 88

Self Study

rdt2.2: sender, receiver fragments

rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || Wait for Wait for isACK(rcvpkt,1) ) ACK call 0 from 0 udt_send(sndpkt) above

sender FSM fragment

rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt)

Wait for 0 from below

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)

receiver FSM fragment

Λ

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt)

89

Quiz: RDT 2.2 with only NACKs v 

RDT 2.2 uses only ACKs and is robust against packet errors. Would it be possible to implement RDT 2.2 with only NACKs? A.  YES B.  NO Please explain your rationale

90

Quiz: Reliable Data Transfer v 

If packets (and ACKs and NACKs) could be lost, which of the following is true of rdt 2.1 (or 2.2)? A.  Reliable, in-order delivery is still achieved. B.  The protocol will get get stuck. C.  The protocol will continue making progress but may skip delivering some messages.

91

rdt3.0: channels with errors and loss new assumption: underlying channel can also lose packets (data, ACKs) §  checksum, seq. #, ACKs, retransmissions will be of help … but not enough

approach: sender waits “reasonable” amount of time for ACK v  v 

v 

retransmits if no ACK received in this time if pkt (or ACK) just delayed (not lost): §  retransmission will be duplicate, but seq. #’s already handles this §  receiver must specify seq # of pkt being ACKed requires countdown timer 92

Self Study

rdt3.0 sender rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer

rdt_rcv(rcvpkt)

Λ

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )

Λ

Wait for ACK0

Wait for call 0from above

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1)

timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)

stop_timer

stop_timer timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) )

Λ

Wait for ACK1

Wait for call 1 from above rdt_send(data)

rdt_rcv(rcvpkt)

Λ

sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer

93

rdt3.0 in action receiver

sender send pkt0 rcv ack0 send pkt1 rcv ack1 send pkt0

pkt0 ack0 pkt1 ack1 pkt0 ack0

(a) no loss

send pkt0 rcv pkt0 send ack0 rcv pkt1 send ack1 rcv pkt0 send ack0

receiver

sender

rcv ack0 send pkt1

pkt0 ack0

rcv pkt0 send ack0

pkt1

X

loss

timeout resend pkt1 rcv ack1 send pkt0

pkt1 ack1 pkt0 ack0

rcv pkt1 send ack1 rcv pkt0 send ack0

(b) packet loss 94

rdt3.0 in action receiver

sender send pkt0

pkt0

rcv ack0 send pkt1

ack0 pkt1 ack1

X

rcv pkt0 send ack0 rcv pkt1 send ack1

loss

timeout resend pkt1

pkt1

rcv ack1 send pkt0

ack1 pkt0 ack0

(c) ACK loss

rcv pkt1

(detect duplicate)

send ack1

receiver

sender send pkt0 rcv ack0 send pkt1

pkt0 ack0 pkt1 ack1

timeout pkt1 resend pkt1 rcv ack1 pkt0 send pkt0 ack1 rcv ack1 ack0 (do nothing)

rcv pkt0 send ack0 rcv pkt1 send ack1

rcv pkt1

(detect duplicate)

send ack1 rcv pkt0 send ack0

rcv pkt0 send ack0 (d) premature timeout/ delayed ACK 95

Quiz: RDT 3.0 Performance v 

Suppose we have a modest 8 Mbps link. Our RTT is 100ms, and we send 1024 byte (1K) segments. What is our link utilization with a stop-and-wait protocol such as RDT 3.0? A.  < 0.1 % B.  Approx. 0.1% C.  Approx 1% D.  1-10% E.  > 10% 96

rdt3.0: stop-and-wait operation sender

receiver

first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK

RTT

ACK arrives, send next packet, t = RTT + L / R

U sender =

L/R

1ms

= (100+1)ms= 0.01 (i.e. 1%) RTT + L / R

Bottom Line: network protocol limits use of physical resources! 97

Transport Part 1: Summary v 

v 

principles behind transport layer services: § multiplexing, demultiplexing § reliable data transfer UDP

v 

Next Week: §  Pipelined Protocols for reliable data transfer §  TCP •  TCP Flow Control •  TCF Connection Management •  TCP Congestion Control

Transport Layer

98