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
Overview
• Motivation for PR Service
• SCTP Extensions – How?
• PR-SCTP Extension
• Some Examples
• Summary
3
Shades of Reliability
• Reliable (TCP/SCTP)
–
–
–
–
No-loss
In-order
No duplicates
Data integrity
• Partial Reliability (PR-SCTP)
– Controlled-loss
– In-order
• “Unreliable” (UDP) – No duplicates
– Data integrity
– Maybe loss
– Maybe unordered
– Maybe duplicates
4
– Data integrity (optional)
The anatomy of a loss event
Received & buffered
Received & delivered
Lost Chunk!!
Free buffer
• 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!
5
Partial Reliability
• Application defined controlled loss
– Sender can give up on a message
– We will call this “abandonment”
6
“Undo” or “Expire”
Application
GPS
Not PR-SCTP!!
transport
transport
Controlled loss / partial reliability
50
10 second video
5 frames/sec
50
acceptable
 3 frames/sec
unacceptable
< 3 frames/sec
…
10
9
8
…
10
9
8
7
6
5
4
5
3
3
Not PR-SCTP!!
9
7
1
50
retransmissions
…
10
5
3
2
1
1
Association Setup
• First part of using an extension is to negotiate it
during association setup (similar to TCP SACK)
INIT w/ Fwd TSN Supported
Forward TSN Supported
is Param Type 49152
Assigned by ICANN
INIT-ACK w/ Fwd TSN Supported
9
An Example – Actual PR-SCTP
Lifetimes
1
2
3
4
5
6
7
8
9
10
Delivery
1
2
2
2
2
2
2
3
4
5
3
3
3
4
10
6-10
10
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
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...
12
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
13
An Example – Actual PR-SCTP
Lifetimes
1
2
3
4
5
6
7
8
9
10
Delivery
1
2
2
2
2
2
2
3
4
5
3
3
3
4
10
6-10
14
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
5
6
2 acked
3 abandoned
Adv.Ack.Pt -> 4 abandoned
5
6
15
An Example – Actual PR-SCTP
Lifetimes
1
2
3
4
5
6
7
8
9
10
Delivery
1
2
2
2
2
2
2
3
4
5
3
3
3
4
10
6-10
16
An Example
2 acked
3 abandoned
Adv.Ack.Pt -> 4 abandoned
5 abandoned
6
2
3
4
Adv.Ack.Pt
6
acked
abandoned
abandoned
-> 5 abandoned
17
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??
18
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!!
Type
Flags
Length
Chunk Data
19
Introducing: Forward Cumulative TSN
Type = 192
Flags = 0x00
Length
New Cumulative TSN
Stream Sequence-1
...
Stream-1
Stream-n
Stream Sequence-n
•Chunk Type of 192 assigned by ICANN
•Sender-only chunk type!
20
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
21
Streams in Detail
•TCP Receive Buffer
0 123
Sequential Sequence (Byte) Numbers
•SCTP Receive/Reorder Buffers
Stream 1
0 1 2 1112
Stream 2
3 689
Stream 3
4 5 7 10
Sequential Stream Sequence (Chunk) Numbers
22
TSN vs Stream Seq. #
• TSN
– Used to ensure
reliability
• Stream Seq. #
– Used to provide
ordering
FDW-TSN Illustrated
Stream 2
1 3 8
2
7 9 10
Lifetimes
Stream 1
1
2
3
4
5
6
7
8
9
10
Delivery
1
2
3
4
5
3
3
Stream 3
7
9
10
2
2
2
2
2
3,8
4
6
4 5 6
10
24
Why stream info?
Type = 192
Flags = 0x00
Length
New Cumulative TSN = z
Stream-1
Stream Sequence = x
Stream-2
Stream Sequence = y
Since each chunk is reviewed at sender to
create Fwd-TSN, we pass that work to the
receiver!
25
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!
Questions/Comments/Flames?