z End-to-End z Protocols z - TAUboaz/comnet/lec10.pdfpotentially deliver up and slide window...
Transcript of z End-to-End z Protocols z - TAUboaz/comnet/lec10.pdfpotentially deliver up and slide window...
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
Patt-ShamirLecture 10 3
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
Patt-ShamirLecture 10 4
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
Patt-ShamirLecture 10 5
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
Patt-ShamirLecture 10 6
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
Patt-ShamirLecture 10 8
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
Patt-ShamirLecture 10 9
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
Patt-ShamirLecture 10 10
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
Patt-ShamirLecture 10 11
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
Patt-ShamirLecture 10 12
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
Patt-ShamirLecture 10 13
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
Patt-ShamirLecture 10 14
Stop-and-Wait: delivered frame
Sender
Frame
ACK
Tim
eout
Tim
e
Receiver
Patt-ShamirLecture 10 15
Stop-and-Wait: Lost Frame
Sender
Tim
eout
Tim
e
Receiver
Frame
ACK
Frame
Tim
eout
Patt-ShamirLecture 10 16
Stop-and-Wait: Lost ACK
Sender
Tim
eout
Tim
e
Receiver
Frame
ACK
Tim
eout
Frame
ACK
Patt-ShamirLecture 10 17
Stop-and-Wait: Delayed Frame
Sender
Tim
eout
Tim
e
Receiver
Tim
eout
Frame
ACK
Frame
ACK
Patt-ShamirLecture 10 18
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?
Patt-ShamirLecture 10 19
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
Patt-ShamirLecture 10 21
Stop and Wait: SafetyClaim 1 (safety): Sequence delivered by receiver is
a prefix of sequence submitted to senderProof: Prove a stronger invariant by induction.
Patt-ShamirLecture 10 22
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
Patt-ShamirLecture 10 23
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.
Patt-ShamirLecture 10 25
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
Patt-ShamirLecture 10 26
Stop and Wait: CorrectnessClaim 2 (liveness): if not all packets dropped, any
message is eventually delivered.Proof: need temporal logic to formalize.
Patt-ShamirLecture 10 27
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
Patt-ShamirLecture 10 28
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
Patt-ShamirLecture 10 29
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
Patt-ShamirLecture 10 30
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.
Patt-ShamirLecture 10 31
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
Patt-ShamirLecture 10 32
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: ∞
Patt-ShamirLecture 10 33
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
Patt-ShamirLecture 10 34
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
Patt-ShamirLecture 10 35
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
Patt-ShamirLecture 10 36
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
Patt-ShamirLecture 10 38
The Sequence NumbersFact: Data is unbounded; sequence numbers aren’tMust know: What is the minimal size of the seq.# space?
Patt-ShamirLecture 10 39
Few sequencenumbersExample:
seq #’s: 0, 1, 2, 3window size=3
receiver sees no difference in two scenarios!Must err in one of them
Patt-ShamirLecture 10 40
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
Patt-ShamirLecture 10 41
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
Patt-ShamirLecture 10 42
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!
Patt-ShamirLecture 10 44
GBN inaction
N=4
Patt-ShamirLecture 10 45
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
Patt-ShamirLecture 10 46
Selective repeat: sender, receiver windows
Patt-ShamirLecture 10 47
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
Patt-ShamirLecture 10 48
Selective repeat in action
Patt-ShamirLecture 10 49
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
Patt-ShamirLecture 10 50
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
Patt-ShamirLecture 10 51
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
Patt-ShamirLecture 10 52
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
Patt-ShamirLecture 10 53
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
Patt-ShamirLecture 10 54
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
Patt-ShamirLecture 10 55
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
Patt-ShamirLecture 10 56
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
Patt-ShamirLecture 10 57
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