Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00

[Gorry Fairhurst <[e-mail]>]

A few comments in-line, following on...

 > Hi Subha,
 >
 > thanks for you reply, see comments inline:
 >
 >> An authorization mechanism alone is probably not sufficient, because
 >> DS boundary nodes may need to police (e.g., remark/drop) incoming
 >> traffic according to some agreed/negotiated traffic profile for some
 >> of the PHBs, e.g., the EF PHB does not work properly if its traffic
 >> class is overloaded (see below).
 >>
 >> SD: Agreed. The previous line states: " Therefore, the DSCP value
 >> may be remarked at the network edge through policy to any other DSCP
 >> value, including best effort.".   There is already a mention that
 >> apckers may be remarked or dropped and any additional mitigation is
 >> outside the scope of this draft.
 >
 > Unfortunately, this doesn't address my comment. DSCP remarking by
 > provider policy is somewhat different from having policers installed
 > (e.g., a token bucket w/ marker and dropper) that perform traffic
 > conditioning according to some installed traffic profile. Static
 > remarking of DSCPs may be caused by using a different DCSP/PHB mapping
 > or lack of DiffServ support etc. which is slightly different.
 >

+1
I think if the draft recommends admission-controlled PHBs then the draft 
needs to be clear that these particular flows may not be carried over 
the path (in addition to could be remarked to another PHB), which may 
require sort of fall-back mechanism (that's probably easy to realise).

In addition though, these PHBs can (and seem likely to be) policed to a 
conformant rate. That will result in some form of loss (or remark), 
which suggests a congestion response (if the traffic is actually 
elastic), otherwise cease?

 >> The problem with using EF is that if too many EF marked packets are
 >> injected into a DS domain, they probably void the EF properties for
 >> other users within this domain (background is that the service rate of
 >> EF packets on a given output interface must exceed their arrival rate at
 >> that interface over long and short time intervals - this is usually
 >> checked by admission control before use and policing at DS boundary
 >> nodes during use). Therefore, maybe some discussion w.r.t. RFC5865
 >> http://tools.ietf.org/html/rfc5865 may be useful.

 >> SD: Agreed that admission control is very useful and relevant. This
 >> draft is intended for the selection and use of the right DSCP for
 >> webrtc media flows. There is a mention of over-subscription in the
 >> beginning.

 > Sure, however, my point was that simply injecting traffic marked with
 > a DSCP for a PHB that normally requires prior admission control is
 > somewhat problematic: either guarantees for already admitted flows
 > are violated or such traffic has to be dropped.

I see a potential problem here, if this becomes a default: If widely 
deployed using EF, the traffic will likely result in this DSCP being 
ignored/dropped (not given you EF properties0)or in breaking EF 
properties for other flows (which needs to be policed).

 >> If a packet enters a QoS domain that has no support for the above
 >> defined Data Types/Application (service) classes, then the network
 >> node at the edge will remark the DSCP value based on policies.
 >>
 >> Yes, but even if there is support for these classes traffic
 >> conditioning (e.g., remarking/dropping etc.) may be necessary and
 >> applied. Remarking to different PHBs may also lead to packet
 >> reordering within a media flow?!
 >
 >> SD: Remarking/dropping may occur, which is mentioned in the draft.

 > Same issue as above: remarking caused by a static DS domain policy
 > (PHBx -> PHBy) is different from remarking and other actions that
 > boundary nodes may perform for individual flows according to
 > traffic profiles.
 >
 > Regards,
 > Roland
 >
In short... there are different pathologies (per packet conditioning 
action) when you send packets using EF, for traffic that the network 
provider didn't provision. This is a different behavior to remarking 
because the DSCP or PHB was not supported at a boundary.

Gorry