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?

 

Please apply the thought that we must allow ISPs/NSPs to route the WebRTC
media to where it can be handled, by using TURN servers. A TURN server in a
QoS-box can then use the traffic info (max bandwidth and traffic type) found
in the extension header, to do whatever QoS method or function that is
appropriate for the specific network type (none discriminated). 

 

Regarding what to encode, I have several times suggested, e.g.

already October 22
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html 

 

A) The maximum bandwidth requirement: Two bytes could contain everything
from some bps for real-time text to Gbps for future 3D supersize
telepresence… on a logarithmic scale.

 

B) The quality characteristics for the stream, with the highest bit set to
1, we could allocate a bit each for quality type e.g: Best Effort, Audio,
Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video
streaming), Minimum Delay, Reliable Delivery, Prioritize X(2 bits),
Variation Y(2 bits), that could be combined as required to describe the
stream.

And with the highest bit set to 0, there could instead be a number for
special usage that does not fit the general description of the individual
bits.

 

Please provide what more you see required (for any QoS method/function for
any network type)!

 

/Karl

 

Footnotes:

 

[1] Please do not divert or confuse this with QoS methods in themselves
(like diffserve, bandwidth reservation, congestion control etc.) This is the
interface from the application to the network level, where all networks
types should be able to use the traffic information for QoS methods relevant
to the particular network.

 

[2] Here it is about recreation of the idea/intention of the RTP payload
type (PT) header that is not available for the network level anymore, by
instead having the application/browser filling the RTP header extension with
relevant traffic info that all IP network types can use. Here, similar
traffic type marking is suggested for the data channel.

 

 

-----Ursprungligt meddelande-----
Från: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] 
Skickat: den 25 februari 2014 09:40
Till: Karl Stahl
Kopia: rtcweb@ietf.org; tram@ietf.org
Ämne: Re: SV: [rtcweb] [tram] Payload Types assignments

 

Karl,

(As individual)

 

I also wish for more usable QoS mechanisms. However, I don't see that being
achieved by your proposal. In addition I agree with Colin about the issues
with putting the information in the RTP header extension. I would also note
that this would be very RTP specific, and not at all help with the data
channels multiple streams and their priorities. There might be data channel
information that is more crucial than any of the RTP media stream packets.

 

You are pushing for a small piece in the middle. A piece that will not help
with the more general issue of QoS. 

--- Not at all! I am pushing for "Interfacing to QoS" rather mixing the
application layer directly to lower level QoS methods like setting DSCP bits
etc..

 

How does the application and the multiple ISPs that carries the traffic
reach an agreement on what properties that can be provided, that the
application in this instance have the right to request those properties and
that any cost is correctly associated with the user or the user's agent in
regards to carrying the associated cost.

 

When it comes to setting DSCP from user land in the OS, that is restricted
due to the security implications. If those implications where resolved, then
OS could open up those interfaces.  There are many interlinked reasons why
things look like they do today. I don't believe in tugging on a single
random thread in ball of yarn and hope that it comes out without any knots
and ties on it.

 

Show me the framework for the QoS functions you have in mind that at least
has less issues than the currently deployed and take care of at least some
of the bigger issues. If that requires information in the RTP streams for
some reasons, then let us talk about how to best encoded it.

But, we need that framework first, the architecture that makes this a better
solution than the current Diffserv architecture or any other QoS
architecture.

 

Cheers

 

Magnus Westerlund

 

----------------------------------------------------------------------

Services, Media and Network features, Ericsson Research EAB/TXM

----------------------------------------------------------------------

Ericsson AB                 | Phone  +46 10 7148287

Färögatan 6                 | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | mailto:
<mailto:magnus.westerlund@ericsson.com> magnus.westerlund@ericsson.com

----------------------------------------------------------------------