Re: [rtcweb] [tram] Payload Types assignments

["Karl Stahl" <[e-mail]>]

Harald, 

 

I think my intention was misunderstood. It was not to change the DTLS/SCTP
structure or format of the data channel (It was to insert the traffic
bandwidth and type information between the UDP and DTLS headers.).

 

However, having dug deeper into the data channel (and also found the
quality/priority obstacles introduced by SCTP with the p2p file transfer
(see next email), a better way to introduce the traffic info would be to use
a new DTLS ContentType (e.g. 24 instead of current 23) where the content
would be the unencrypted traffic info (preferable the same as in the RTP
header extension[1]) followed by the SCTP as it is today (where it today
comes directly in the DTLS as the only content).:

 

TODAY:

Content Type: 23 (1 byte) content type 23 means “application data”

DTLS version:  0xfeff (2 byte)

Epoch: 0001 (2 byte)

Sequence number (e.g. 00 00 00 00 00 01) 6 byte

Length (e.g. 01 c0) 2 byte

Encrypted application data: ...... = the SCTP

 

SUGGESTION WITH ADDED TRAFFIC INFO FOR LOWER LEVELS: 

Content Type: 24 (1 byte) content type 24 meaning “application data preceded
by traffic info”

DTLS version:  0xfeff (2 byte)

Epoch: 0001 (2 byte)

Sequence number (e.g. 00 00 00 00 00 01) 6 byte

Length (e.g. 01 c0) 2 byte: length of the encrypted application data after
the new header extension

TRAFFIC INFO, Same as suggested for the RTP Header extension: 

Encrypted application data: ...... ...... = the SCTP unchanged

 

Shouldn’t this be doable?

(As you see from next email, this kind of information is also required to
make the data channel work, separating prioritized data chunks from a file
transfer data channel that must NOT be prioritized.)

 

/Karl

 

 

 

 

Från: rtcweb [mailto:[e-mail]] För Harald Alvestrand
Skickat: den 17 mars 2014 16:38
Till: [e-mail]
Ämne: Re: [rtcweb] [tram] Payload Types assignments

 

On 03/13/2014 10:02 AM, Karl Stahl wrote:

For the “mission to bring quality to real-time traffic over our best effort
Internet” I have started
<http://www.ietf.org/mail-archive/web/tram/current/msg00331.html>
http://www.ietf.org/mail-archive/web/tram/current/msg00331.html

[tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5
IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1] [2]

 

Hi Magnus,

 

With the response just sent to Pål
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html, skipping
all the QoS methods and functions that really does not belong here when
creating an “Interface to QoS”, I only see the suggestion of “data channel
information”, i.e. also marking each data channel packet with traffic
bandwidth and type information  to be relevant and interesting. I checked
with one of our developers and I think the same traffic information as for
RTP can be transferred in data channel packets as follows:

 

The RTP header has the following format (RFC 3550):

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |V=2|P|X|  CC   |M|     PT      |       sequence number         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           timestamp                           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           synchronization source (SSRC) identifier            |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            contributing source (CSRC) identifiers             |

   |                             ....                              |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            RFC5285 header extension ...                      |

   |     2 bytes Max Bandwidth     |   2 bytes Traffic Type        |

   |                             ....                              |

RTP Payload (often encrypted)

 

A Data Channel header could have the following format:

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   Data Channel Magic Cookie   |      (sequence number)        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           timestamp                           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           synchronization source (SSRC) identifier            |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            contributing source (CSRC) identifiers             |

   |                             ....                              |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            RFC5285 header extension ...                      |

   |     2 bytes Max Bandwidth     |   2 bytes Traffic Type        |

   |                             ....                              |

  DTLS Header 13 bytes

  SCTP

 

The RFC5285 header extension is not in a fixed position in any of these
cases, but still trivial to find (especially when in  a TURN flow). This
could be introduced in
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-5 

by making room for these bytes after the UDP header, but before the DTLS
header.

 

What do you think?



No.

We've chosen to make Data Channel a protocol within DTLS, and not use any
unencrypted headers for it. Neither does the data channel have any concept
resembling SSRC, CSRC or timestamp. Changing to an RTP-based format such as
the one you propose would be a drastic revision of the spec.

There's no reason to believe such a revision at this time has any traction
in the WG.