Re: [rtcweb] Prioritization

[Michael Welzl <[e-mail]>]

Hi,


>> The DSCP markings and how they might interact with this are just an
>> additional layer of uncertainty, primarily.
> Hence the note about "under a common congestion controller" - if DSCP
> markers are respected, having a common congestion controller covering
> different DSCP classes doesn't make much sense - they don't "see" the
> same network.
> 
> If they're not respected .... they could more usefully be grouped together.


This is the current version of the paragraph in draft-welzl-rmcat-coupled-cc-02 that relates to this matter (here, SBD means Shared Bottleneck Detection), and FGI = Flow Group Identifier - a number used to decide whether flows should be controlled together):

***

   SBD uses knowledge about the flows to determine which flows belong in
   the same Flow Group (FG), and assigns FGIs accordingly.  This
   knowledge can be derived from measurements, by considering
   correlations among measured delay and loss as an indication of a
   shared bottleneck, or it can be based on the simple assumption that
   packets sharing the same five-tuple (IP source and destination
   address, protocol, and transport layer port number pair) and having
   the same Differentiated Services Code Point (DSCP) in the IP header
   are typically treated in the same way along the path.  The latter
   method is the only one specified in this document: SBD MAY consider
   all flows that use the same five-tuple and DSCP to belong to the same
   FG.  This classification applies to certain tunnels, or RTP flows
   that are multiplexed over one transport (cf. [
transport-multiplex
]).
   In one way or another, such multiplexing will probably be recommended
   for use with rtcweb [
rtcweb-rtp-usage].
***

Any comments on this text?

Our plan is to write a separate complementary document that will describe a measurement-based SBD method. Both mechanisms are in the works and we'll submit them (or: are in the process of submitting them) to RMCAT.

Cheers,
Michael