Subject: [tsvwg] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02

From: Ben Campbell <[email-masked]>
Date: Sat, 9 Aug 2014 13:48:13 -0500

Hi,

The DART working group has started a last call for draft-ietf-dart-dscp-rtp-02, ending on August 22. This informational draft describes considerations for the use of DiffServ code points in situations where one multiplexes multiple RTP packet streams, and potentially other protocol streams, that share the same 5-tuple. 

Since this draft is likely of interest to several working groups, I would like to solicit additional reviews from participants of TSVWG, AVTCORE, MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feedback to the effect of "this is ready to progress") to the DART working group mailing list.

Thanks!

Ben.

Begin forwarded message:

> Resent-From: [email-masked]
> From: Ben Campbell <[email-masked]>
> Subject: WGLC: draft-ietf-dart-dscp-rtp-02
> Date: August 9, 2014 at 12:50:16 PM CDT
> Resent-To: [email-masked], [email-masked], [email-masked]
> To: [email-masked]
> Cc: [email-masked], [email-masked], Richard Barnes <[email-masked]>
> 
> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. It's available on the data tracker at the following URL:
> 
> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/
> 
> The WGLC will conclude on 22 August, 2014. Please send your comments to the authors and the DART mailing list. If you've reviewed it and think it's good to go, please say so.
> 
> Thanks!
> 
> Ben.
>

---

From: <[email-masked]>
Date: Mon, 11 Aug 2014 12:21:12 +0200

Hi David,

new EF related text has been added in the -01 version. I've copied 
in some text of RFC3246 related to EF remarking and policing below. 
My take:

. remarking of entire flows is an option, but no remarking of 
  packets exceeding EF capacity limits.
- looking at the EF jitter and delay properties, I doubt that 
  shaping is desirable. RFC3246 doesn't mention shaping as part 
  of EF conditioning. I personally wouldn't expect EF shaping 
  in sections where policing is applied. 
- dropping of packets exceeding EF capacity is a MUST, if I 
  interpret RFC3246 correctly.

I suggest to adapt the section of draft-dart-dscp to be more 
precise regarding the optional remarking of EF traffic and to 
remove shaping as a conditioning option if traffic is beyond 
the EF forwarding capacity limit. A Proposal for the final 
sentence:

...exceeds that capacity must be dropped. EF compliant flows may 
be remarked to a different DSCP.

All other new text indicated by the Diff version looks allright.

Regards,

Ruediger

draft-dart-dscp:

3. Expedited Forwarding (EF) [RFC3246] intended for inelastic	
   traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865]	
   is an admission controlled variant of the EF PHB. Both of these	
   PHBs are based on pre-configured limited forwarding capacity;	
   traffic that exceeds that capacity may be shaped, remarked to a	
   different DSCP, or dropped.

########################################

RFC3246 (three excerpts):

   Packets belonging to a single microflow within the EF aggregate
   passing through a device SHOULD NOT experience re-ordering in normal
   operation of the device.

   Packets marked for EF PHB MAY be remarked at a DS domain boundary
   only to other codepoints that satisfy the EF PHB.  Packets marked for
   EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS
   domain.

   If the EF PHB is implemented by a mechanism that allows unlimited
   preemption of other traffic (e.g., a priority queue), the
   implementation MUST include some means to limit the damage EF traffic
   could inflict on other traffic (e.g., a token bucket rate limiter).
   Traffic that exceeds this limit MUST be discarded.

-----Ursprüngliche Nachricht-----
Von: Dart [mailto:[email-masked]] Im Auftrag von Ben Campbell
Gesendet: Samstag, 9. August 2014 19:50
An: [email-masked]
Cc: Richard Barnes; [email-masked]; [email-masked]
Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02

Thanks!

Ben.

_______________________________________________
Dart mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dart

---

From: "Black, David" <[email-masked]>
Date: Mon, 11 Aug 2014 09:15:37 -0400

> the EF forwarding capacity limit.

Yes, something definitely needs to be done, as shaping excess
traffic is not consistent with the EF service.  In addition,
RFC 3246 recommends against (SHOULD NOT) remarking EF traffic
within a DS domain in one of the text excerpts that was in your
email, so remarking should not be mentioned as a possibility.
Further, RFC 3246 recommends that excess traffic SHOULD be
dropped (section 3):

   To protect itself against denial of service attacks, the edge of a DS
   domain SHOULD strictly police all EF marked packets to a rate
   negotiated with the adjacent upstream domain.  Packets in excess of
   the negotiated rate SHOULD be dropped.

I'll reword the dart draft text as follows:

OLD
       Both of these
       PHBs are based on pre-configured limited forwarding capacity;
       traffic that exceeds that capacity may be shaped, remarked to a
       different DSCP, or dropped.
NEW
       Both of these
       PHBs are based on pre-configured limited forwarding capacity;
       traffic in excess of that capacity is expected to be dropped.

Thanks for noticing this,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, August 11, 2014 6:21 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Subject: AW: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02
> 
> Hi David,
> 
> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. It's
> available on the data tracker at the following URL:
> 
> The WGLC will conclude on 22 August, 2014. Please send your comments to the
> authors and the DART mailing list. If you've reviewed it and think it's good
> to go, please say so.
> 
> Thanks!
> 
> Ben.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Aug 2014 08:13:02 +1200

Hi Ruediger,

>   interpret RFC3246 correctly.

Well, it seems to me to be a SHOULD, with the MUST that you cite
below being conditional on "a mechanism that allows unlimited
preemption of other traffic." So I would not be at all surprised
by deployments that support shaping and remarking. Also, there
are certainly implementations that are closer to RFC 2598 or
RFC 3248 and therefore less strict.

I think the draft should make it clear that there is likely to be
variation in actual behaviour for EF traffic that exceeds the nominal
rate. (Leaving aside the fact that without a string of matching SLAs
along the path, the nominal rate might not even be well defined.)

   Brian

> .

---

From: <[email-masked]>
Date: Tue, 12 Aug 2014 09:38:26 +0200

Hi Brian,

with EF I link an expectation of excess traffic being 
dropped.

A rate scheduler with single digit millisecond buffer 
depth and tail drop like behavior is not an issue. 
To me, that's a shaper configured to be EF compliant. 
If such a constraint is not desired then the text 
may say "if mapped to a non-EF PHB, excess traffic 
may be shaped". I'd like to ask for some explaining 
text if shaping of EF excess traffic is regarded 
as a property to be expected for this PHB.

If an AF class is used to transport EF, then any potential 
remarking should be done in a way avoiding re-ordering 
(i.e. remark to DSCPs within the same AF class only). 
There's no point in remarking excess EF traffic to a PHB 
which may cause reordering. I think that's what a text 
on remarking of EF should express, if remarking is 
kept as an option to be expected (I've not yet heard of 
such a deployment).

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Brian E Carpenter [mailto:[email-masked]] 
Gesendet: Montag, 11. August 2014 22:13
An: Geib, Rüdiger
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02

Hi Ruediger,

On 11/08/2014 22:21, [email-masked] wrote:
> Hi David,
> 
> new EF related text has been added in the -01 version. I've copied in 
> some text of RFC3246 related to EF remarking and policing below.
> My take:
> 

Well, it seems to me to be a SHOULD, with the MUST that you cite below being conditional on "a mechanism that allows unlimited preemption of other traffic." So I would not be at all surprised by deployments that support shaping and remarking. Also, there are certainly implementations that are closer to RFC 2598 or RFC 3248 and therefore less strict.

I think the draft should make it clear that there is likely to be variation in actual behaviour for EF traffic that exceeds the nominal rate. (Leaving aside the fact that without a string of matching SLAs along the path, the nominal rate might not even be well defined.)

   Brian

> 
> I suggest to adapt the section of draft-dart-dscp to be more precise 
> regarding the optional remarking of EF traffic and to remove shaping 
> as a conditioning option if traffic is beyond the EF forwarding 
> capacity limit. A Proposal for the final
> sentence:
> 
> ...exceeds that capacity must be dropped. EF compliant flows may be 
> remarked to a different DSCP.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Aug 2014 08:35:12 +1200

Hi Ruediger,

> with EF I link an expectation of excess traffic being 

In general I agree; but that only makes sense if there
is an agreement (or mechanism) to define the nominal rate,
and rate control of some kind at the source. (An IP phone
is in effect a rate controller, for example.)

> as a property to be expected for this PHB.

Yes, technically that's correct - but a shaper could be
inserted at the boundary between two DS domains, and for
the end-to-end user that will appear as a property of
the PHB.

> which may cause reordering. 

I fully agree.

> I think that's what a text 

Yes. I'm not advocating such behaviour; my point is only
that EF may not always be strictly conformant to RFC 3246.

   Brian

---

From: Dave Taht <[email-masked]>
Date: Tue, 12 Aug 2014 16:56:51 -0700

This is also of some interest to me at least, and perhaps some members
of the AQM working group who are working out weighted fair queuing and
wred like approaches to these needs.

Anyway, I do try to track thinking in this area in the ongoing
development of cerowrt's sqm system, which has pluggable modules for
all the known aqm and fq schedulers, and a three tier system modeled
on wondershaper for managing traffic,
which uses what diffserv markings that I have observed make sense...

Some relevant links:

http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die

http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310

http://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management

Missing from this discussion so far is what is actually deployed out
there... I am only familiar with stuff like the above as an
egress/ingress queue management system...

AND: in the case of linux based wireless routers, none of the AF
codepoints are respected explicitly, and how the codepoints are mapped
are described by 802.11e - and that is far more about scheduling
priority for airtime rather than drop probability.

It is kind of hard to wrap your head around how 802.11e actually
works, but, this is a start:

http://en.wikipedia.org/wiki/IEEE_802.11e-2005#Enhanced_distributed_channel_access_.28EDCA.29

In linux wifi at least:

CS0, CS3 are mapped into the BE hw queue
CS1, CS2 are mapped into the BK hw queue
CS4, CS5 are mapped into the VI hw queue
CS6, CS7 are mapped into the VO  hw queue

Bit patterns for the other classes to whatever extent they map into
CSX are mapped into the underlying hardware queue.

I am not saying this is an optimal state of affairs, (as notably VO
should be as completely disabled as possible in the 802.11n and ac
age), and am very interested in how other OSes (ios, osx, windows),
and router/switch OSes do it, but the wireless scheduling aspect of
all these codepoints does not seem to be well touched upon.

On a personal note I tend to think that having 17+ ways to slice up
traffic is about 13 or 14 too many, particularly those targetting a
drop probability. When you have drop rates well below a few percentage
points, adding another percentage point of granularity seems futile.

Lastly, there is also an implementation issue in linux presently in
that doing extensive diffserv classification basically requires
one iptables or tc rule per class, which is inefficient.  Someone (not
me!) doing some code for doing diffserv saner there would go a long
way...

On Sat, Aug 9, 2014 at 11:48 AM, Ben Campbell <[email-masked]> wrote:
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

---

From: <[email-masked]>
Date: Wed, 13 Aug 2014 08:39:36 +0200

Hi Brian,

we are in agreement in most points. 

Of course a provider could shape EF traffic on an 
interconnection. This may not be a solution which 
I favor, but it is possible. 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Brian E Carpenter [mailto:[email-masked]] 
Gesendet: Dienstag, 12. August 2014 22:35
An: Geib, Rüdiger
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: AW: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02

Hi Ruediger,

On 12/08/2014 19:38, [email-masked] wrote:
> Hi Brian,
> 
> with EF I link an expectation of excess traffic being dropped.

In general I agree; but that only makes sense if there is an agreement (or mechanism) to define the nominal rate, and rate control of some kind at the source. (An IP phone is in effect a rate controller, for example.)

> 
> A rate scheduler with single digit millisecond buffer depth and tail 
> drop like behavior is not an issue.
> If such a constraint is not desired then the text may say "if mapped 
> to a non-EF PHB, excess traffic may be shaped". I'd like to ask for 
> some explaining text if shaping of EF excess traffic is regarded as a 
> property to be expected for this PHB.

Yes, technically that's correct - but a shaper could be inserted at the boundary between two DS domains, and for the end-to-end user that will appear as a property of the PHB.

> If an AF class is used to transport EF, then any potential remarking 
> should be done in a way avoiding re-ordering (i.e. remark to DSCPs 
> within the same AF class only).
> There's no point in remarking excess EF traffic to a PHB which may 
> cause reordering.

I fully agree.

> on remarking of EF should express, if remarking is kept as an option 
> to be expected (I've not yet heard of such a deployment).

Yes. I'm not advocating such behaviour; my point is only that EF may not always be strictly conformant to RFC 3246.

   Brian