z End-to-End z Protocols z - TAUboaz/comnet/lec10.pdfpotentially deliver up and slide window Patt-Shamir Lecture 10 35 Sliding Window zSend Window zFixed length. zStarts at earliest

1

End-to-End Protocols

Patt-ShamirLecture 10 2

Where are we?What have we seen?

Technology to connect together a collection of computers

Direct links*Packet switchingInternet

What’s next?Extend host-to-host packet delivery to process-to-process communication channelTransport layer


End-to-End Service Model

Services that applications may needVirtualization: Multiple connections per host

Easy: multiplex by connection identifierCorrectness : What does this mean?

Reliable deliveryGuaranteed Quality of Service (QoS)

Performance: Flow controlNot enough to dump the data at the receiver


End-to-End Service Model

Build on “best effort” service provided by network layer (IP)

Messages sent from a host are delivered to another host, but messages may be…

Lost (or delivered after a long delay)reorderedduplicatedlimited in size


User Datagram Protocol (UDP)Thin wrapper around IP services

Service ModelUnreliable unordered datagram serviceAddresses multiplexing of multiple connections

Multiplexing 16-bit port numbers (some are “well-known”)

ChecksumValidate headerOptional in IPv4Mandatory in IPv6


UDP Header Format

Source Port Destination PortUDP Length UDP Checksum

0 8 16 31

Source IP AddressDestination IP Address

UDP Length0 17 (UDP)

0 8 16 31

Length includes 8-byte header and dataChecksum

Uses IP checksum algorithmComputed on header, data and pseudo header

7

Reliable Transmission


DefinitionSender has an input sequence (infinite)Receiver outputs a sequenceSafety: At any time, output is a prefix of the inputLiveness: Each input bit is eventually output

What do we have to implement this?Let’s consider a single physical link first


Reliable TransmissionAssume channel can delay, lose or corrupt packet,

but not reorder or duplicate themLiveness: If message is sent infinitely many times, it is eventually delivered

Simplification: error protection identifies valid and invalid packets ignore corruption

Tools we use:Acknowledgements: feedback from receiver to senderTimers


Can losses be completely transparent?

Formalize the notion of reliable delivery:Input: R has a message to send to SExecution: R and S exchange packets

The channel may lose some packets May assume only one packet can be lost

Requirement: When protocol terminates,R outputs the original message and haltsS halts


Can losses be completely transparent?

Theorem: Given a channel that may lose packets, there is no protocol that guarantees reliable delivery in a bounded number of steps.

Proof: By contradiction.Assume A is a correct protocol. Consider the execution of A that delivers using with the fewest messages without message drops

S R; R S; R S; S R; …; S RSay the last packet was from S to R. Consider the execution obtained by dropping that last packet.

X


Proof (cont.)1. S R; R S; S R; …; S R2. S R; R S; S R; …; S |R (last message dropped)

Execution 1 looks the same as 2 to S, so S halts in execution 2 as well.Since the protocol is correct, R must deliver in Execution 2. Now consider execution 3: just like execution 1, but S does not send the last packet.Execution 3 looks like execution 2 to R, so R delivers the message.Execution 3 is correct with one less packet sent and no losses, contradiction to minimality of execution 1!

QED


Solution 1: Stop & Wait

Sender’s algorithm:– Read frame from app– Repeat forever:

1. Send current frame2. Wait until ACK or TO3. If ACK: read new frame from app


Stop-and-Wait: delivered frame

Sender

Frame

ACK

Tim

eout

Tim

e

Receiver


Stop-and-Wait: Lost Frame

Sender

Tim

eout

Tim

e

Receiver

Frame

ACK

Frame

Tim

eout


Stop-and-Wait: Lost ACK

Sender

Tim

eout

Tim

e

Receiver

Frame

ACK

Tim

eout

Frame

ACK


Stop-and-Wait: Delayed Frame

Sender

Tim

eout

Tim

e

Receiver

Tim

eout

Frame

ACK

Frame

ACK


Problem: lost ACK

Sender can’t distinguish lost ACK from lost frame

Retransmission is bad if lost ACK (duplicate!) Advancing is bad if lost frame (missing frane!)

Should sender ACKs/NAKs receiver’s ACK/NAK?


Stop and Wait With Seq. #

Handling duplicates: sender adds sequence number to each pkt, rcvradds it to ACKsender retransmits pkt(sn) until gets ACK(sn)receiver discards (doesn’t deliver up) duplicate pkt

Sender: send pkt with current sns until gets ACK(sns), then sns++Receiver: when receive pkt(sns):

send ACK(sns)If sns > snr then snr++; deliver pkt; Patt-Shamir

Lecture 10 20

Stop and Wait: CorrectnessModel: Asynchronous computation

Execution: a sequenceglobal state -> action -> global state -> action-> global state …Actions:

Sendx(p): sender enters packet p to channel (x∈{s,r})Recvx(p): x gets packet p from channel Drop (p): channel drops packet p

At any time, state of system is state at hosts (counters) and two channels: sequence of packets


Stop and Wait: SafetyClaim 1 (safety): Sequence delivered by receiver is

a prefix of sequence submitted to senderProof: Prove a stronger invariant by induction.


Stop and Wait: SafetyConsider the sequence n1,n2,…nrs,snr,m1,m2,…msr,sns

Lemma: the sequence is non-decreasing, and sns- n1 ≤ 1, i.e., sequence is a*(a+1)* for some a.Proof: by induction on the actions.

Sender: sns rcvr: snrn1 n2 nrs

m1m2msr


Stop and Wait: SafetyInvariant: n1,n2,…nrs,snr,m1,m2,…msr,sns is non-

decreasing, and sns- n1 ≤ 1.Sends(p): msr=sns: just dup, check. Sendr(p): same.Rcvr(p): if m1=snr, just omit, check. Otherwise, by

induction, m1=snr+1, check.Rcvs(p): if n1=sns-1, omit. Ow: n1=sns, so by induction:

single value, so sns++ is ok.

Sender: sns rcvr: snrm1m2msr

nrsn2

n1Patt-Shamir

Lecture 10 24

Bounded Stop and Wait: Alternating Bit Protocol

Corollary: 0 ≤ sns-snr ≤ 1.Therefore, sufficient to have just last bit of sequence numbers!Proof idea: imagine unbounded sequence numbers for each execution of the one-bit protocol.

Note that we may have 1≤0.


Alternating Bit Protocol (S&W) State Diagram

Send: 0Expect: 0

Send: 1Expect: 0

Send: 1Expect: 1

Send: 0Expect: 1

Receive frame 0

Receive frame 1

Receive ACK 1

Receive ACK 0

Receive frame 0

Receive ACK 1


Stop and Wait: CorrectnessClaim 2 (liveness): if not all packets dropped, any

message is eventually delivered.Proof: need temporal logic to formalize.


Performance of Stop&WaitStop&Wait works, but performance stinks: only one outstanding packet at a time!example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:

Ttransmit = 8kb/pkt109 b/sec = 8 microsec

Utilization = U = = 8 microsec30.016 msec

fraction of timesender busy sending = 0.00015

1KB pkt every 30 msec -> 33kB/sec throughput over 1 Gbps linknetwork protocol limits use of physical resources!

Host A

HostB

15 ms

1 Gbps


Concurrent Logical Channels

Idea: Multiplex logical channels over a single link, run stop&wait on each logical channel

Can have many logical channels to ensure high utilization (can use mod to mux/demux)

POBLEM: packets may be received wildly out of order!

ls1ls2ls3ls4

lr1lr2lr3lr4

demuxbuffer


Sliding Window ProtocolSender maintains a sender window of packets “in progress.”

All preceding packets known to have been received by receiver, no subsequent packet yet sent by sender.

Receiver maintains a receiver window. All preceding packets already delivered. There’s nothing in front of the window.

data


The WindowsSender’s: controls parallelism.

Starts with first sent & unacknowledged packetFixed length: max. # outstanding packetssent pkt # ≤ first unacked # + sender window size

Receiver’s: reconstructs original order.Starts with the first missing packetFixed length: discard packets not in window.


Sliding Window ProtocolView: a stream of data packets (with seq.#)

Stop&Wait: one outstanding at a timeM concurrent channels: up to M outstanding packets at a time, but arbitrary position in stream

Sliding window idea: up to M outstanding packets, from a particular interval called the sliding window

data


WindowsSender’s window: How many different packets can the sender send at once?

S&W: 1Concurrent Channel: ∞

Receiver’s window: How many different packets is the receiver waiting for?

S&W: 1Concurrent Channel: ∞


Keeping the Pipe Full

ReceiverSender

Frame

ACK

Tim

e

Frame

ACKFrame

ACKFrame

ACK

FrameFrame

ACK

FrameFrame

ReceiverSender

FrameFrame

FrameACKACK

Window

size

Full throughput when window is large enough and no losses


The protocolAll packets, ACKs have sequence numbers.Sender:

When ACK arrives: mark, potentially slide window and send new packetsWhen sending packets: set timerWhen timer expires retransmit

Receiver:When packet arrives: if within window and OK, send ACK; potentially deliver up and slide window


Sliding WindowSend Window

Fixed length.Starts at earliest unacknowledged frameOnly frames in window are active

Time

Sent and acknowledged

Sent and not acknowledged

Available, outside send window Unavailable


Sliding WindowReceive Window

Fixed length. Starts at earliest frame not receivedOnly frames in window accepted

Recieved and acknowledged

Received and not acknowledged

Received, outside receive window Not yet received

Time


The Sequence NumbersFact: Data is unbounded; sequence numbers aren’tMust know: What is the minimal size of the seq.# space?


Few sequencenumbersExample:

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

receiver sees no difference in two scenarios!Must err in one of them


Sequence Number Size

Recall: Sender’s window starts with first sent & unackedReceiver’s window starts with the first missing

Windows can cover an interval of length SWS+RWSTherefore, need at least SWS+RWS seq. numbers

SWackedunsent

RW

Sender’s window size +receiver’s


Window SizeSender’s objective: keep the pipe full

window size ≥ bandwidth × 2(end-to-end delay)But: big windows may cause trouble on failure

Receivers objective: accept out-of-sequence packetsWindow can be as large as possible

Subject to space constraints, sequence number space sizeVariants:

Stop&Wait: Sender and Receiver window sizes = 1Go Back N (GBN): sender’s = N, Receiver’s = 1Selective Repeat: sender’s = Receiver’s = N


Go-Back-N

Idea: cumulative acks. ACK(s) means all packets up to, including seq # s, were received

Sender:Set timer for each sent packettimeout(s): retransmit packet s and all higher seq # pkts in window

Receiver:May send multiple ACKs Patt-Shamir

Lecture 10 43

GBN: protocolsender

Always has N packets “in transit”, each with a timeout for ACKWindow starts past largest ACKOn timeout of lowest seqno packet in window, retransmit current window (and reset timers)

receiver simple:Always send ACK for correctly-received packet with highest in-order seq #

may generate duplicate ACKsneed only remember expectedseqnum

Data: Expected packet: Deliver up Out-of-order: discard (don’t buffer) -> no receiver buffering!


GBN inaction

N=4


Selective Repeatreceiver individually acknowledges each correctly received packets

stores packets, as needed, for eventual in-order delivery to upper layer

sender only resends unACKed or NAKed packetssender maintains timer for each packet, but sends only the one that times out

sender windowN consecutive seq #’sagain limits seq #s of sent, unACKed pkts


Selective repeat: sender, receiver windows


Selective repeat

data from above :Store in bufferif in window, send pkt

timeout(s):resend pkt s, restart timer

ACK(s) in [sendbase,sendbase+N):

mark pkt s as ACKedif s smallest unACKed pkt

advance window base to next unACKed seq #send unsent pkts in new window

senderIf pkt s in [rcvbase, rcvbase+N)

send ACK(s)Store in bufferIf in-order:

deliver up to first not-yet-received pktadvance window to first not-yet-received pkt

otherwise:ignore

receiver


Selective repeat in action


Efficiency of Go-back-N vs. Selective Repeat

Simplified model:any packet is lost with probability pACKs never lost (get upper bound)selective repeat:

sender knows exactly what receiver needsGo-back-N

Each packet loss costs N retransmissions


Selective Repeat: Simplified Analysis

Idea: count how many times each packet is transmittedTSR = #transmissions of a pktTSR is a geometrically distributed random variable, with parameter (1-p)Hence, its expected value is 1/(1-p)e.g.:

if p = 0.2, then E[TSR] = 1.25


Go Back N : Simplified Analysis

Let TGBN be expected #transmissions per delivery in GBNWhen a frame is lost, N frames are transmitted, and hence It follows that


Summary: ARQ Algorithm ClassificationThree Types:

Stop-and-Wait: SWS = 1 RWS = 1Go-Back-N: SWS = N RWS = 1Selective Repeat: SWS = N RWS = M

Usually M = N

Selective Repeat

Go-Back-NStop-And-Wait


Roles of a Sliding Window Protocol

Reliable delivery on an unreliable linkCore function

Preserve delivery orderControlled by the receiver

Flow controlAllow receiver to throttle sender

Separation of ConcernsMust be able to distinguish between different functions that are sometimes rolled into one mechanism


Forward Error Correction (FEC)Alternative to ARQ algorithmsIdea:

Error correction instead of error detectionUse redundancy (codes) to avoid retransmission: fix errors first (forward) rather than afterward (backward)

WhyVery high latency connectionsDifficult for retransmission


TCP Sliding Window ProtocolSequence numbers

Indices into byte streamACK sequence number

Actually next byte expected as opposed to last byte receivedAdvertised window

Enables dynamic receive window sizeReceive buffers

Data ready for delivery to application until requestedOut-of-order data out to maximum buffer capacity

Sender buffersUnacknowledged dataUnsent data out to maximum buffer capacity


TCP Sliding Window Protocol –Sender Side

LastByteAcked <= LastByteSentLastByteSent <= LastByteWrittenBuffer bytes between LastByteAcked and LastByteWritten

First unacknowledged byte Last byte sent

Data available, but outside window

Maximum buffer size

Advertised window


TCP Sliding Window Protocol –Receiver Side

LastByteRead < NextByteExpectedNextByteExpected <= LastByteRcvd + 1Buffer bytes between NextByteRead and LastByteRcvd

Next byte to be read by application

Next byte expected (ACK value)

Buffered, out-of-order data

Maximum buffer size

Advertised window

Documents

z End-to-End z Protocols z - TAUboaz/comnet/lec10.pdfpotentially deliver up and slide window Patt-Shamir Lecture 10 35 Sliding Window zSend Window zFixed length. zStarts at earliest