PR-SCTP (Partially Reliable)

Ethan M GiordanoCISC865TCP/IP & Upper Layer ProtocolsUniversity of DelawareNovember 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

4

Shades of Reliability• Reliable (TCP/SCTP)

– No-loss– In-order– No duplicates– Data integrity

• “Unreliable” (UDP)– Maybe loss– Maybe unordered– Maybe duplicates– Data integrity

(optional)

• Partial Reliability (PR-SCTP)

– Controlled-loss– In-order– No duplicates– Data integrity

5

The anatomy of a loss event

Received & delivered

Received & buffered

Free bufferLost 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”

ApplicationGPS

transport

transportNot PR-SCTP!!

Controlled loss / partial reliability

acceptable 3 frames/sec

unacceptable < 3 frames/sec

10 second video 5 frames/sec

… 12310 8 7 6 45950

35…50 10

… 1350 10 89 5

179

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 Supportedis Param Type 49152

Assigned by ICANN

10

An Example – Actual PR-SCTP

FWD TSN 3

Delivery12

3

6-10

Life

times

1234

1098

4

5

7

3

6

5

2

22

22

3

3

FWD TSN 4FWD TSN 5 4

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

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

Delivery12

3

6-10

Life

times

1234

1098

4

5

7

3

6

5

2

22

22

3

3

FWD TSN 4FWD TSN 5 4

10

15

An ExampleAdv.Ack.Pt = new variable for PR that tracks where we want the receiver to be expecting. On arrival of a SACK, ifSack.CumAck < Adv.Ack.Pt then Adv.Ack.Pt = Sack.CumAck

2 ackedAdv.Ack.Pt -> 3 abandoned 4 abandoned 5 6

2 acked 3 abandoned

Adv.Ack.Pt -> 4 abandoned 5 6

16

An Example – Actual PR-SCTP

FWD TSN 3

Delivery12

3

6-10

Life

times

1234

1098

4

5

7

3

6

5

2

22

22

3

3

FWD TSN 4FWD TSN 5 4

10

17

An Example 2 acked

3 abandonedAdv.Ack.Pt -> 4 abandoned 5 abandoned 6

2 acked 3 abandoned 4 abandoned

Adv.Ack.Pt -> 5 abandoned 6

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!!

Flags Length

Chunk Data

Type

20

Introducing: Forward Cumulative TSN

Type = 192 LengthFlags = 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

22

Streams in Detail•TCP Receive Buffer

0 1 2 3

Sequential Sequence (Byte) Numbers

•SCTP Receive/Reorder Buffers

0 1 2

3 6 8 9

4 5 107

1112Stream 1

Stream 2

Stream 3

Sequential Stream Sequence (Chunk) Numbers

TSN vs Stream Seq. #

• TSN– Used to ensure

reliability

• Stream Seq. #– Used to provide

ordering

24

FDW-TSN Illustrated

Stream 2

Stream 1

Stream 3FWD TSN 3

Delivery12

3,8

6Li

fetim

es

1234

1098

4

57

3

6

5

222

22

3

3

FWD TSN 4FWD TSN 54

10

1 3

2

4

7

5

8

9

6

10

7910

25

Why stream info?Type = 192 LengthFlags = 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!

Questions/Comments/Flames?