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

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 12 Jun 2014 15:39:11 +0200

Hi,

some remarks on draft-ietf-tsvwg-rtcweb-qos-00:

Sec. 2:
   The mitigation for such action is through an authorization mechanism.

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

Sec. 4:
   The below uses the concept of a media flow, however these are
   commonly not equivalent to a transport flow, i.e. as defined by a
   5-tuple (source address, destination address, source port,
   destination port, and protocol).

I think one should try to use definitions that do not depend
on the classifier type like 5-tuple, because as Brian already
mentioned, for IPv6 a 3-tuple (IPsrc, IPdst, Flow Label) may be
sufficient and header fields of the 5-tuple are not always accessible.
I liked the definition of microflow in DiffServ as being an
application-to-application flow of packets, usually being identified
by that well known 5-tuple. For elements within the network microflows
are usually the most fine grained distinction level for flows
(except when you apply multi-field classifier that do some DPI and
add the SSRC etc.).
(nit: is probably a word like "text" missing in the first cited sentence
above?)

Proper definitions for media flow, RTP session, transport flow etc.
may help to avoid confusion, so maybe one could try to combine
efforts with draft-york-dart-dscp-rtp-00?

Sec. 5:
   SHOULD use these values to mark the appropriate media packets.  More
   information on EF can be found in [RFC3246].  More information on AF
   can be found in [RFC2597].

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.

   The above table assumes that packets marked with CS1 is treated as
   "less than best effort".  However, the treatment of CS1 is
   implementation dependent.  If an implementation treats CS1 as other
   than "less than best effort", then the priority of the packets may be
   changed from what is intended.

BTW, there is no "less than best effort" PHB defined,
but a Lower Effort Per-Domain Behavior (PDB) in RFC 3662
(http://tools.ietf.org
/html/rfc3662). This RFC is also the source for the recommendation of
using the CS-1 codepoint for that purpose, so you may considering
referencing it.

   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?!

Regards,
 Roland

---

From: "Subha Dhesikan (sdhesika)" <[email-masked]>
Date: Wed, 18 Jun 2014 18:26:36 +0000

Roland, 

Thanks for your comments. Inline:

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Bless, Roland (TM)
Sent: Thursday, June 12, 2014 6:39 AM
To: [email-masked]
Cc: [email-masked]
Subject: [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00

Hi,

Sec. 2:

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.

Sec. 4:

I think one should try to use definitions that do not depend on the classifier type like 5-tuple, because as Brian already mentioned, for IPv6 a 3-tuple (IPsrc, IPdst, Flow Label) may be sufficient and header fields of the 5-tuple are not always accessible.
I liked the definition of microflow in DiffServ as being an application-to-application flow of packets, usually being identified by that well known 5-tuple. For elements within the network microflows are usually the most fine grained distinction level for flows (except when you apply multi-field classifier that do some DPI and add the SSRC etc.).
(nit: is probably a word like "text" missing in the first cited sentence
above?)

Proper definitions for media flow, RTP session, transport flow etc.
may help to avoid confusion, so maybe one could try to combine efforts with draft-york-dart-dscp-rtp-00?
SD:. There has been some discussion on the use of the word "media flow".  Between the webrtc group and tsvwg, these words are defined or being defined. I will further check on it.

Sec. 5:

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. 

BTW, there is no "less than best effort" PHB defined, but a Lower Effort Per-Domain Behavior (PDB) in RFC 3662 (http://tools.ietf.org /html/rfc3662). This RFC is also the source for the recommendation of using the CS-1 codepoint for that purpose, so you may considering referencing it.
SD: Sounds good. Will do.

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.  

Thanks again for the review of the draft.

Regards,
Subha

Regards,
 Roland

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 24 Jun 2014 10:30:24 +0200

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.

> EF packets on a given output interface must exceed their arrival rate at
> that interface over long and short time intervals - this is usually
> 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.

> 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