PR-SCTP (Partially Reliable) Ethan M Giordano CISC865 TCP/IP & Upper Layer Protocols University of Delaware November 22, 2005 Some slides/graphics courtesy.

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

transport

Not 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

Lif

etim

es1234

1098

4

5

7

3

6

5

2

22

2

2

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

Lif

etim

es1234

1098

4

5

7

3

6

5

2

22

2

2

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

Lif

etim

es1234

1098

4

5

7

3

6

5

2

22

2

2

3

3

FWD TSN 4FWD TSN 5 4

10

17

An Example

2 acked 3 abandoned

Adv.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 3

FWD TSN 3

Delivery12

3,8

6L

ifet

imes

1234

1098

4

5

7

3

6

5

2

22

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?