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

["Bless, Roland (TM)" <[e-mail]>]

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.

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

> 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