1 transport overview 10/7/2009. 2 outline recap r overview of transport layer r udp r reliable data...

1

Transport Overview

10/7/2009

2

Outline

Recap Overview of transport layer UDP Reliable data transfer, the stop-and-wait

protocol

3

Recap: P2P

The Lookup problem More generally, moving from a host-centric Internet to

a “data-centric” Internet supporting data persistency, availability, and authenticity

The scalability problem

Key Design Issues

Robustness: Resistant to churn and failures

Efficiency: A client has content that others need; otherwise, its upload capacity may not be utilized

Incentive: clients are willing to upload

Lookup problem

4

servers

C0

client 1

client 2

client 3

client n

C1

C2 C3

Cn

5

Recap: BitTorrent Robustness

Piece256KBBlock

16KB

File

421 3

Incomplete Piece

Piece: unit of information exchange among peersBlock: unit of download

A swarming protocol: peers exchange piece availability and request blocks from peers

10 0 1

BitTorrent: Incentive

Periodically (typically every 10 seconds) calculate data-receiving rates from all peers

Upload to (unchoke) the fastest

- constant number (4) of unchoking slots

- partition upload bw equally among unchoked

requests/interests

requests/interests

requests/interests

requests/interests

commonly referred to as “tit-for-tat” strategy

requests/interests

Optimistic Unchoking

Periodically select a peer at random and upload to it typically every 3 unchoking rounds (30

seconds)

Multi-purpose mechanism allow bootstrapping of new clients continuously look for the fastest peers

(exploitation vs exploration)

Block Availability

Request (local) rarest first achieves the fastest replication of rare pieces obtain something of value

Block Availability: Revisions

When downloading starts (first 4 pieces): choose at random and request them from the peers get pieces as quickly as possible obtain something to offer to others

Endgame mode defense against the “last-block problem”:

cannot finish because missing a few last pieces

send requests for missing sub-pieces to all peers in our peer list

send cancel messages upon receipt of a sub-piece

BitTorrent Fluid Analysis

Normalize file size to 1 x(t): number of downloaders (also known as

leechers) y(t): number of seeds in the system at time t. : the arrival rate of new requests. : the uploading bandwidth of a given peer. c: the downloading bandwidth of a given peer,

assume c ≥ μ. : the rate at which downloaders abort download. : the rate at which seeds leave the system. : indicates the effectiveness of downloader

sharing, η takes values in [0, 1].10

System Evolution

Solving steady state:

Define

11

System Evolution: Download Time T

Look at system state, # of downloaders that will finish download and become seed:

=>

12

BitTorrent: Summary

Very widely used mainline: written in Python Azureus and μTorrent: the

most popular Other popular clients: ABC,

BitComet, BitLord, BitTornado, Opera browser

Many explorations, e.g., BitThief BitTyrant

Better understanding is needed

requests/interests

requests/interests

requests/interests

requests/interests

requests/interests

Summary: P2P

Widely considered to be a key component for the next-generation Content distribution system

Many issues remaining, e.g., Streaming ISP/P2P integration …

14

15

Outline

Recap Overview of transport layer UDP Reliable data transfer, the stop-and-go

protocols

16

Transport Layer vs. Network Layer

Provide logical communication between app’ processes

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

Transport vs. network layer services: Network layer: data transfer

between end systems Transport layer: data transfer

between processes• relies on, enhances network

layer services

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

networkdata linkphysical



networkdata linkphysicalnetwork

data linkphysical

logical end-end transport

17

Transport Layer Services and Protocols Reliable, in-order delivery (TCP)

multiplexing reliability and connection setup congestion control flow control

Unreliable, unordered delivery: UDP multiplexing

Services not available: delay guarantees bandwidth guarantees

18

Transport Layer: Road Ahead Class 1:

transport layer services connectionless transport: UDP reliable data transfer using stop-and-wait

Class 2: sliding window reliability TCP reliability

• overview of TCP• TCP RTT measurement• TCP connection management

Class 3: principles of congestion control TCP congestion control; AIMD

Class 4: performance modeling; TCP variants the analysis and design framework for congestion

control

19

Outline

Recap Overview of transport layer UDP Reliable data transfer, the stop-and-go

protocols

UDP: User Datagram Protocol [RFC 768]Often used for

streaming multimedia apps loss tolerant rate sensitive

Other UDP usesDNSSNMP

source port # dest port #

32 bits

Applicationdata

(message)

UDP segment format

length checksumLength, in

bytes of UDP

segment,including

header

UDP Checksum

Sender: treat segment contents

as sequence of 16-bit integers

checksum: addition of segment contents to be zero

sender puts checksum value into UDP checksum field

Receiver: compute checksum of

received segment compute sum of segment

and checksum; check if sum zero NO - error detected YES - no error detected.

But maybe errors nonetheless?

Goal: end-to-end detection of “errors” (e.g., flipped bits) in transmitted segment

One’s Complement Arithmetic

UDP checksum is based on one’s complement arithmetic one’s complement was a common representation of

signed numbers in early computers

One’s complement representation bit-wise NOT for negative numbers example: assume 8 bits

• 00000000: 0• 00000001: 1• 01111111: 127 • 10000000: ?• 11111111: ?

addition: conventional binary addition except adding any resulting carry back into the resulting sum

• Example: -1 + 2

22

UDP Checksum: Algorithm

Example checksum:

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

wraparound

sumchecksum

- For fast implementation of computing UDP checksum, see http://www.faqs.org/rfcs/rfc1071.html

UDP Checksum: Coverage

Calculated over: A pseudo-header

IP Source Address (4 bytes)

IP Destination Address (4 bytes)

Protocol (2 bytes) UDP Length (2 bytes)

UDP header

UDP data

25

Outline

Recap Overview of transport layer UDP Reliable data transfer

26

Principles of Reliable Data Transfer Important in app., transport, link layers top-10 list of important networking topics!

Reliable Data Transfer

27

28

Reliable Data Transfer: Getting Started

sendside

receiveside

rdt_send(): called from above, (e.g., by app.)

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

receiver

rdt_rcv(): called from below; when packet arrives on rcv-side

of channel

deliver_data(): called by rdt to deliver data to

upper

29

Reliable Data Transfer: Getting StartedWe’ll: incrementally develop sender, receiver

sides of reliable data transfer protocol (rdt) consider only unidirectional data transfer

but control info will flow on both directions!

use finite state machines (FSM) to specify sender, receiver

state1

state2

event causing state transitionactions taken on state transition

state: when in this “state” next state

uniquely determined by

next event

eventactions

30

Outline

Review Overview of transport layer UDP Reliable data transfer

perfect channel

31

Rdt1.0: reliable transfer over a reliable channel

separate FSMs for sender, receiver: sender sends data into underlying channel receiver reads data from underlying channel

Wait for call from above packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packet,data)deliver_data(data)

Wait for call from

below

rdt_rcv(packet)

sender receiver

32

Potential Channel Errors

bit errors

loss (drop) of packets

reordering or duplication

Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt).

33

Outline

Recap Overview of transport layer UDP Reliable data transfer

o perfect channel channel with bit errors

34

Rdt2.0: Channel With Bit Errors

Underlying channel may flip bits in packet

New mechanisms in rdt2.0 (beyond rdt1.0): receiver error detection: recall: UDP checksum to

detect bit errors sender retransmission receiver feedback: control msgs (ACK,NAK) rcvr-

>sender• 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

35

rdt2.0: FSM Specification

Wait for data udt_send(sndpkt)

rdt_rcv(rcvpkt) && isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

Wait for data

extract(rcvpkt,data)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

sender

receiver

Wait for ACK or

NAK

snkpkt = make_pkt(data, checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

36

rdt2.0: Operation with No Errors

Wait for data





udt_send(sndpkt)


udt_send(NAK)


Wait for ACK or

NAK

Wait for data

rdt_send(data)

37

rdt2.0: Error Scenario

Wait for data





udt_send(sndpkt)


udt_send(NAK)


Wait for ACK or

NAK

Wait for data

rdt_send(data)

38

Big Picture of rdt2.0sender

data (n)

receiver

data (n)

ACK

data (n+1)

waiting for N/ACK

waitingfor data

NACK

39

rdt2.0 is Incomplete!

What happens if ACK/NAK corrupted? Although sender receives feedback, but doesn’t

know what happened at receiver!

sender

data (n)waiting

for N/ACK ?

40

Two Possibilities

sender

data (n)

receiver

data (n)

waiting for

N/ACK waitingfor data

NACK

sender receiver

waiting for

N/ACK ACK

data (n+1)

data (n)

deliver

deliver

Wait for data udt_send(sndpkt)


sender

Wait for ACK or

NAK


rdt_send(data)


41

Handle Control Message CorruptionIt is always harder to deal with control

message errors than data message errors sender can’t just retransmit: possible duplicate

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

sender sends one packet, then waits for receiver response

stop and wait

42

rdt2.1b: Sender, Handles Garbled ACK/NAKs

Wait for pkt n from

above

Wait for ACK or

NAK

sndpkt = make_pkt(n, data, checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(n+1, data, checksum)udt_send(sndpkt)

rdt_send(data)

Wait for ACK or

NAK

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

Wait for pkt n+1 from

above

43

rdt2.1b: Receiver, Handles Garbled ACK/NAKs

Wait for n from below

Wait for n+1 from

below

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq(n, rcvpkt)

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

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && ! has_seq(n,rcvpkt)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)


44

rdt2.1b: Summary

Sender: seq # added to pkt must check if received ACK/NAK corrupted

Receiver: must check if received packet is duplicate

by checking if the packet has the expected pkt seq #

45

Another Look at rdt2.1bsender

data (n)

receiver

ACK

data 1 (n+1)

waiting for n

sending n

waiting n+1

sendingn+1

waiting for n+2

NACK

data (n)

data (n)

ACK

46

State Relationship of rt2.1b

s0 senders1 s2

receiverw0 w1 w2 w3

w3

first time

rcvs 0

first timercvsack 0

w0 w1 w2

W1: wait for data with seq. 1S1: sending data with seq. 1

State invariant:- When receiver’s state is waiting for seq #n, sender’s state can be sending either seq#n-1or seq#n

47

rdt2.1c: Sender, Handles Garbled ACK/NAKs: Using 1 bit

Wait for call 0 from

above

sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)

rdt_send(data)

Wait for ACK or

NAK udt_send(sndpkt)



rdt_send(data)


udt_send(sndpkt)




above

Wait for ACK or NAK 1

48

rdt2.1c: Receiver, Handles Garbled ACK/NAKs: Using 1 bit

Wait for 0 from below


rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt)

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





rdt_rcv(rcvpkt) && (corrupt(rcvpkt)


rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)



49

rdt2.1c: Discussion

Sender: state must

“remember” whether “current” pkt has 0 or 1 seq. #

Receiver: must check if

received packet is duplicate state indicates whether

0 or 1 is expected pkt seq #

50

A Flavor of Protocol Correctness Analysis: rdt2.1c Combined states of sender and channel Assume the sender always has data to send

0 0 00 0 N 0 1 A

1 1 11 0 A 1 1 N

sender state: sending 0 and waiting for ACK

channel state: packet seq#

corrupt ok corrupt

okok

corrupt

ok

receiver state: waiting for 0 0 1 0 0 1 N

corrupt

ok

1 0 0corrupt

1 0 N

corrupt

ok

51

rdt2.2: a NAK-free protocol

Same functionality as rdt2.1c, using ACKs only

Instead of NAK, receiver sends ACK for last pkt received OK receiver must explicitly include seq # of pkt being

ACKed

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

52

rdt2.2: Sender, Receiver Fragments


above


rdt_send(data)

udt_send(sndpkt)

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

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

Wait for ACK

0

sender FSMfragment



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

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

sndpkt=make_pkt(ACK,1, chksum)udt_send(sndpkt)

receiver FSMfragment

53

Outline

Review Overview of transport layer UDP Reliable data transfer

o perfect channelo channel with bit errors channel with bit errors and losses

54

rdt3.0: Channels with Errors and Loss

New assumption: underlying channel can also lose packets (data or ACKs) checksum, seq. #,

ACKs, retransmissions will be of help, but not enough

Q: how to deal with loss?

Approach: sender waits “reasonable” amount of time for ACK

requires countdown timer retransmits if no ACK

received in this time if pkt (or ACK) just delayed

(not lost): retransmission will be

duplicate, but use of seq. #’s already handles this

receiver must specify seq # of pkt being ACKed

55

rdt3.0 Sender

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

rdt_send(data)

Wait for

ACK0

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


above

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

rdt_send(data)


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


stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)


above

Wait for

ACK1

rdt_rcv(rcvpkt)

56

rdt3.0 in Action

Question to think about: How to determine a good timeout value?

57

rdt3.0 in Action

58

rdt3.0sender

data 0 (n-1)

receiver

data 0 (n-1)

ACK for 0 (n-1)

data 1 (n)

waiting for 0(n-1)

sending 0 (n-1)

waiting for 1(n)

sending 1(n) waiting

for 0(n+1)

ACK for 0 (n-1)

State consistency:

When receiver’s state is waiting n, the state of the sender is either sending for n-1 or sending for n

When sender’s state is sending for n, receiver’s state is waiting for n or n + 1

59

rdt3.0: Stop-and-Wait Operation

first packet bit transmitted, t = 0

sender receiver

RTT

last packet bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

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

What is Usender: utilization – fraction of time sender busy sending?

Assume: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet

60

Performance of rdt3.0

rdt3.0 works, but performance stinks Example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:

Ttransmit

= 8kb/pkt10**9 b/sec

= 8 microsec

1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link

network protocol limits use of physical resources !

U sender

= .008

30.008 = 0.00027

microseconds

L / R

RTT + L / R =

L (packet length in bits)R (transmission rate, bps)

=

61

A Summary of Questions

How to improve the performance of rdt3.0?

What if there are reordering and duplication?

How to determine the “right” timeout value?

63

Sliding Window Protocols: PipeliningPipelining: sender allows multiple, “in-flight”, yet-to-

be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver

Two generic forms of pipelined protocols: go-Back-N, selective repeat

64

Pipelining: Increased Utilization

first packet bit transmitted, t = 0

sender receiver

RTT

last bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

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

last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

U sender

= .024

30.008 = 0.0008

microseconds

3 * L / R

RTT + L / R =

increase utilizationby a factor of 3!

Question: a rule-of-thumb window size?

65

Go-Back-nSender: k-bit seq # in pkt header “window” of up to W, consecutive unack’ed pkts allowed

ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” note: ACK(n) could mean two things: I have received upto

and include n, or I am waiting for n timer for the packet at base timeout(n): retransmit pkt n and all higher seq # pkts in

window

W

66

GBN: Sender Extended FSM

Waitstart_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum < base+W) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else block sender

if (new packets ACKed) { advance base; if (more packets waiting) send more packets}if (base == nextseqnum) stop_timerelse start_timer for the packet at new base


base=1nextseqnum=1


67

GBN: Receiver Extended FSM

ACK-only: always send ACK for correctly-received pkt with highest in-order seq # need only remember expectedseqnum

out-of-order pkt: discard (don’t buffer) -> no receiver buffering! re-ACK pkt with highest in-order seq # may generate duplicate ACKs

Wait

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum)

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

expectedseqnum=1sndpkt = make_pkt(expectedseqnum,ACK,chksum)

68

GBN inAction

windowsize = 4

69

Discussion: Efficiency of Go-Back-n

Assume window size W

Assume each packet is lost with probability p

On average, how many packets do we send for each data packet?

70

Selective Repeat

Sender window Window size W: W consecutive unACKed seq #’s

Receiver individually acknowledges correctly received pkts buffers pkts as needed, for eventual in-order

delivery to upper layer ACK(n) means received packet with seq# n only buffer size at receiver: window size

Sender only resends pkts for which ACK not received sender timer for each unACKed pkt

71

Selective Repeat: Sender, Receiver Windows

W

W

72

Selective Repeat

data from above : unACKed packets is less

than window size W, send; otherwise block app.

timeout(n): resend pkt n, restart timer

ACK(n) in [sendbase,sendbase+W-1]:

mark pkt n as received update sendbase to the

first packet unACKed

senderpkt n in [rcvbase, rcvbase+W-

1]

send ACK(n) if (out-of-order)

mark and buffer pkt nelse /*in-order*/

deliver any in-order packets

otherwise: ignore

receiver

73

Selective Repeat in Action

74

Discussion: Efficiency of Selective Repeat

Assume window size W

Assume each packet is lost with probability p

On average, how many packets do we send for each data packet?

75

State Invariant: Window Location

Go-back-n (GBN)

Selective repeat (SR)

sender window

receiver window

sender window

receiver window

76

Window Location Go-back-n (GBN)

Selective repeat (SR)

sender window

receiver window

sender window

receiver window

Q: what relationship between seq # size and

window size?

77

Selective Repeat: Seq# Ambiguity

Example: seq #’s: 0, 1, 2, 3 window size=3

receiver sees no difference in two scenarios!

incorrectly passes duplicate data as new in (a)

78

Sliding Window Protocols:Go-back-n and Selective Repeat

Go-back-n Selective Repeat

data bandwidth: sender to receiver(avg. number of times a pkt is transmitted)

ACK bandwidth (receiver to sender)Relationship between M (the number of seq#) and W (window size)

Buffer size at receiver

Complexity

p: the loss rate of a packet; M: number of seq# (e.g., 3 bit M = 8); W: window size

More efficient Less efficient

M > W M ≥ 2W

1 W

Simpler More complex

Less efficient

ppwp

11

More efficient

p11

79

Question: What is Initial Seq#?

sender receiver

ACK for 0accept

data 0

80

Question: What is Initial Seq#?

To avoid the scenario, a sender should not reuse a seq# before it is sure the packet has left the network

sender receiver

ACK for 0 (n)accept

data 0 (transfer $1000 to B)

data 0 (transfer $1000 to B)

accept?

81

Outline

Recap Sliding window protocols

Go-back-n Selective repeat

Connection management

82

Connection Management: Objective

Agree on initial sequence numbers a sender will not reuse a seq# before it is sure

that all packets with the seq# are purged from the network

• the network guarantees that a packet too old will be purged from the network: network bounds the life time of each packet

To avoid waiting for the seq# to start a session, use a larger seq# space

• needs connection setup so that the sender tells the receiver initial seq#

Agree on other initial parameters

83

Three Way Handshake (TWH) [Tomlinson 1975]

Host A

SYN(seq=x)

Host B

ACK(seq=x), SYN(seq=y)

ACK(seq=y)

DATA(seq=x+1)

SYN: indicates connection setup

accept data only afterverified x is the init. seq

accept?

84

Scenarios with Duplicate Request

Host A Host B


REJECT(seq=y)

SYN(seq=x)

accept?

no suchrequest

reject

85

Three Way Handshake (TWH) [Tomlinson 1975]

To ensure that the other side does want to send a request

Host A

SYN(seq=x)

Host B


ACK(seq=y)

DATA(seq=x+1)

Host A Host B


REJECT(seq=y)

SYN(seq=x)

accept?

no suchrequest

reject

ACK(seq=z)

86

Connection Close

Objective of closure handshake: each side can release

resource and remove state about the connection

client

I am done. Are you done too?

server

I am done too. Goodbye!

init. close

close

close

release resource?

release resource?

release resource?

87

General Case: The Two-Army Problem

The two blue armies need to agree on whether or not they will attack the white army. They achieve agreement by sending messengers to the other side. If they both agree, attack; otherwise, no. Note that a messenger can be captured!

88

Four Way Teardown

Host A

FIN

Host B

ACK

ACK

FIN

close

close

closedall states removed

tim

ed w

ait

- can retransmit the ACKif its ACK is lost closed

A->B closed

A->B closed

all states removed

propose closeA->B

propose closeB->A

89

A Summary of Questions

How to improve the performance of rdt3.0? sliding window protocols

What if there are duplication and reordering? network guarantee: max packet life time transport guarantee: not reuse a seq# before

life time seq# management and connection

management How to determine the “right”

parameters?

90

Backup Slides

91

Reordering and Duplication

Out-of-order and/or duplicated packets could be accepted by the receiver if not handled correctly

There are many solutions each with its own pitfalls

Internet solution: for each connection (sender-receiver pair), ensuring that two identically numbered packets are never outstanding at the same time network bounds the life time of each packet a connection will not reuse a seq# before it is sure that all

packets with the seq# are purged from the network• seq. number space should be large enough to not limit

transmission rate• needs connection setup so that the sender tells the receiver initial

seq#

92

Scenarios with Duplicate Request/Reply

Host A Host B


REJECT(seq=y)

SYN(seq=x)

accept?

no suchrequest

reject

ACK(seq=z)

93

Backup Slides

1 transport overview 10/7/2009. 2 outline recap r overview of transport layer r udp r reliable data...

Documents

peers upload

system state

data persistency

datacentric internet

number of downloaders

given peer

transport overview1072009

peer listsend