Presentation on theme: "PR-SCTP (Partially Reliable) Ethan M Giordano CISC865 TCP/IP & Upper Layer Protocols University of Delaware November 22, 2005 Some slides/graphics courtesy."— Presentation transcript:
PR-SCTP (Partially Reliable) Ethan M Giordano CISC865 TCP/IP & Upper Layer Protocols University of Delaware November 22, 2005 Some slides/graphics courtesy of: Dr. Paul Amer, Jana Iyengar
Some quick background… RFC 3758 May 2004 Implemented technology Designed in part by Dr. Philip Conrad of our department
3 Overview Motivation for PR Service SCTP Extensions – How? PR-SCTP Extension Some Examples Summary
5 The anatomy of a loss event Received & delivered Received & buffered Free buffer Lost Chunk!! What happens to blue chunks while red one is missing? –Waiting! What if blue chunks are time sensitive? –Application is waiting on information that is already available!
6 Partial Reliability Application defined controlled loss –Sender can give up on a message –We will call this “abandonment”
“Undo” or “Expire” Application GPS transport Not PR-SCTP!!
Controlled loss / partial reliability acceptable 3 frames/sec unacceptable < 3 frames/sec 10 second video 5 frames/sec … … 10 … retransmissions Not PR-SCTP!!
9 Association Setup First part of using an extension is to negotiate it during association setup (similar to TCP SACK) INIT w/ Fwd TSN Supported INIT-ACK w/ Fwd TSN Supported Forward TSN Supported is Param Type Assigned by ICANN
10 An Example – Actual PR-SCTP FWD TSN 3 Delivery Lifetimes FWD TSN 4 FWD TSN
PR-SCTP Sender can artificially advance the expected TSN value of the receiver –Accomplished by sending a Forward-TSN Receiver then makes available all received data up to this new point and then continues on
12 Message Abandonment An “abandoned” chunk is one which the sender has marked as such for various possible reasons –Expired lifetime without being ACK'd –Explicit decision from upper layer Once abandoned: –Treated as ACK'd and not outstanding –Does not count toward expanding cwnd! –Need to notify the receiver...
13 Notifying the Receiver The heart of the PR extension Send a Forward Cumulative TSN –Otherwise receiver would forever be expecting this chunk which is not coming! But a Fwd-TSN could be lost!! –SACK's from the receiver generate Fwd-TSN's
14 An Example – Actual PR-SCTP FWD TSN 3 Delivery Lifetimes FWD TSN 4 FWD TSN
15 An Example Adv.Ack.Pt = new variable for PR that tracks where we want the receiver to be expecting. On arrival of a SACK, if Sack.CumAck < Adv.Ack.Pt then Adv.Ack.Pt = Sack.CumAck 2 acked Adv.Ack.Pt -> 3 abandoned 4 abandoned acked 3 abandoned Adv.Ack.Pt -> 4 abandoned 5 6
16 An Example – Actual PR-SCTP FWD TSN 3 Delivery Lifetimes FWD TSN 4 FWD TSN
18 RULE If after moving Adv.Ack.Pt it is greater than the SACK.CumAck the sender must send a Fwd-TSN How is the Fwd-TSN constructed??
19 How does one extend a protocol? Designers allowed 8 bits for the chunk type —256 chunk types!! —Base protocol uses 13 types —That's 243 types for extensions!! FlagsLength Chunk Data Type
20 Introducing: Forward Cumulative TSN Type = 192LengthFlags = 0x00 New Cumulative TSN Stream-1 Stream-n Stream Sequence-1 Stream Sequence-n... Chunk Type of 192 assigned by ICANN Sender-only chunk type!
21 FWD-TSN Construction The basic piece of information is the new CUMULATIVE TSN for the receiver to use Plus an entry for each affected stream Stream data waits in a reorder buffer at the receiver This information in the Fwd-TSN makes it simple for the receiver to know which chunks to now deliver
25 Why stream info? Type = 192LengthFlags = 0x00 New Cumulative TSN = z Stream-1 Stream-2 Stream Sequence = x Stream Sequence = y Since each chunk is reviewed at sender to create Fwd-TSN, we pass that work to the receiver!
RFC – What it defines… “Timed reliability” –All of the examples with lifetime used this Can we think of others?? –Of course…. –RFC gives guidelines for their creation!