Subject: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

From: James Polk <[email-masked]>
Date: Tue, 16 Jul 2013 01:07:59 -0500

(as an author)

Toerless and I put together a draft about legacy rate-adaptation 
based only on loss vs. what RMCAT is looking to (for RTCWEB), which 
is based on delay and loss.  Here's the URL.

http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt

It's more raw than we had in mind, but we believe this is necessary, 
based on implementation experience and what users and customers have 
in their networks, or are planning on having in their networks soon.

James & Toerless

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Tue, 16 Jul 2013 13:36:05 +0000

TSVWG Members,

I should have copied you on my email to the RMCAT mailer below.

I strongly support the creation of a new DSCP for transports in which their congestion control can adapt based on delay.

The current ID in support of this (http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt ) is a work in progress, but a step in the right direction.

It is a given that the ability of the eventual RMCAT adaptation mechanisms to achieve low delay will be function of the other dominant traffic it is competing against. If the dominant competing traffic DEPENDS on loss, the RMCAT packets are held hostage to being delayed by the bottleneck queue delay maximum.

Thus, whenever possible, it will be preferable for RMCAT flows to compete with other congestion control transports that adapt on delay. Even this may not get us to the desired low-delay goals when a portion of the traffic has long RTTs (i.e., adaptation control loops that are long in time), or for links that have a highly-time varying capacity,  but it will help for a lot of common bottleneck topologies (e.g., slowly time-varying access bufferbloat).

It is my hope that this topic has some discussion time in the Berlin Transport WG (not the specific codepoint to be chosen, but rather the need for one).

Off Soapbox,

Michael Ramalho, Ph.D.

-----Original Message-----
From: Michael Ramalho (mramalho) 
Sent: Tuesday, July 16, 2013 9:06 AM
To: [email-masked]
Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

RMCAT Design Team,

The draft Lars references below is a formal request for a DSCP dedicated to "RMCAT-only (or other nice delay-based cc) traffic".

It will take a while to become socialized ... and we can progress our RMCAT work in the interim.

Michael Ramalho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eggert, Lars
Sent: Tuesday, July 16, 2013 5:26 AM
To: WG WG
Cc: [email-masked]
Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

Possibly of interest to RMCAT.

Begin forwarded message:

> From: James Polk <[email-masked]>
> Subject: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ
> Date: July 16, 2013 8:07:59 GMT+02:00
> To: <[email-masked]>
> 
> (as an author)
> 
> Toerless and I put together a draft about legacy rate-adaptation based only on loss vs. what RMCAT is looking to (for RTCWEB), which is based on delay and loss.  Here's the URL.
> 
> It's more raw than we had in mind, but we believe this is necessary, based on implementation experience and what users and customers have in their networks, or are planning on having in their networks soon.
> 
> James & Toerless
>

---

From: "Cheng-Jia Lai (chelai)" <[email-masked]>
Date: Tue, 16 Jul 2013 18:36:31 +0000

Same here... I feel it makes sense to create a new DSCP / CS4 for transport of video flows that have rate adaptive behaviors and/or intra-flow preferential drop priorities as indicated in the I-D. The service provided by the network may thus be considered new, i.e. different from what exists in AF4x, so IMHO, using a new or reusing CS4 service class adds clarity for the user applications.

Regards,
CJ

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Ramalho (mramalho)
Sent: Tuesday, July 16, 2013 6:36 AM
To: [email-masked]
Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

TSVWG Members,

Off Soapbox,

Michael Ramalho, Ph.D.

-----Original Message-----
From: Michael Ramalho (mramalho) 
Sent: Tuesday, July 16, 2013 9:06 AM
To: [email-masked]
Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

RMCAT Design Team,

Michael Ramalho

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 16 Jul 2013 20:46:54 +0000

I read the draft and thank you for addressing this need. It does a good job of making the case for the need to differentiate the DSCP assignments of delay-and-loss-based vs. just-loss-based rate-adaptive video applications. While I do not agree with some of the finer points in the draft, including the statement in section 3 that AF4x traffic in general is inelastic/fixed bitrate, I completely agree that this traffic is largely loss sensitive and yet often relies on loss based adaption.
The assignment of a new service class and the proposal for CS4 and CS4-Discardable for rate-adaptive video makes sense to me. At the same time, it is important to re-designate AF4x as you describe in order to match the reality of today's deployments and avoid future confusion.
I look forward to seeing this work progress as it offer an incentive for applications to embrace congestion control algorithms such as those being developed in RMCAT without fearing they will be overrun by non-delay adaptive traffic.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> James Polk (jmpolk)
> Sent: Monday, July 15, 2013 11:08 PM
> To: [email-masked]

---

From: James Polk <[email-masked]>
Date: Tue, 16 Jul 2013 16:06:38 -0500

At 03:46 PM 7/16/2013, Charles Eckel (eckelcu) wrote:
>I read the draft and thank you for addressing this need. It does a 
>good job of making the case for the need to differentiate the DSCP 
>assignments of delay-and-loss-based vs. just-loss-based 
>rate-adaptive video applications. While I do not agree with some of 
>the finer points in the draft, including the statement in section 3 
>that AF4x traffic in general is inelastic/fixed bitrate,

Charles

Thank you for the quick review!

If we authors gave the impression that all AF4X marked traffic is 
inelastic and uses the 'same' fixed bitrates, we apologize. However, 
each AF4X flow from a given codec - be it audio or video - in today's 
implementations, pretty much use the same bitrate per flow (not the 
same bitrate for each flow). Do you agree with this clarification, or 
would you like to offer substitute/replacement text in the offending section?

James

>  I completely agree that this traffic is largely loss sensitive and 
> yet often relies on loss based adaption.
>The assignment of a new service class and the proposal for CS4 and 
>CS4-Discardable for rate-adaptive video makes sense to me. At the 
>same time, it is important to re-designate AF4x as you describe in 
>order to match the reality of today's deployments and avoid future confusion.
>I look forward to seeing this work progress as it offer an incentive 
>for applications to embrace congestion control algorithms such as 
>those being developed in RMCAT without fearing they will be overrun 
>by non-delay adaptive traffic.
>
>Cheers,
>Charles
>
>

---

From: James Polk <[email-masked]>
Date: Tue, 16 Jul 2013 16:10:12 -0500

At 08:36 AM 7/16/2013, Michael Ramalho (mramalho) wrote:
>I strongly support the creation of a new DSCP for transports in 
>which their congestion control can adapt based on delay.
>
>The current ID in support of this 
>(http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt 
>) is a work in progress, but a step in the right direction.

Michael

Thank you for the quick review.

The draft isn't very long (under 8 pages currently), and it is a work 
in progress - but do you have text or just points that this draft 
needs to cover that it doesn't currently?

James

>It is a given that the ability of the eventual RMCAT adaptation 
>mechanisms to achieve low delay will be function of the other 
>dominant traffic it is competing against. If the dominant competing 
>traffic DEPENDS on loss, the RMCAT packets are held hostage to being 
>delayed by the bottleneck queue delay maximum.
>
>Thus, whenever possible, it will be preferable for RMCAT flows to 
>compete with other congestion control transports that adapt on 
>delay. Even this may not get us to the desired low-delay goals when 
>a portion of the traffic has long RTTs (i.e., adaptation control 
>loops that are long in time), or for links that have a highly-time 
>varying capacity,  but it will help for a lot of common bottleneck 
>topologies (e.g., slowly time-varying access bufferbloat).
>
>It is my hope that this topic has some discussion time in the Berlin 
>Transport WG (not the specific codepoint to be chosen, but rather 
>the need for one).
>
>Off Soapbox,
>
>Michael Ramalho, Ph.D.
>
>The draft Lars references below is a formal request for a DSCP 
>dedicated to "RMCAT-only (or other nice delay-based cc) traffic".
>
> > It's more raw than we had in mind, but we believe this is 
> necessary, based on implementation experience and what users and 
> customers have in their networks, or are planning on having in 
> their networks soon.
> >
> > James & Toerless
> >

---

From: James Polk <[email-masked]>
Date: Tue, 16 Jul 2013 16:11:27 -0500

CJ

I'll ask you the same question I just asked Michael, the draft isn't 
very long (under 8 pages currently), and it is a work in progress - 
but do you have text or just points that this draft needs to cover 
that it doesn't currently?

James

At 01:36 PM 7/16/2013, Cheng-Jia Lai (chelai) wrote:
>Same here... I feel it makes sense to create a new DSCP / CS4 for 
>transport of video flows that have rate adaptive behaviors and/or 
>intra-flow preferential drop priorities as indicated in the I-D. The 
>service provided by the network may thus be considered new, i.e. 
>different from what exists in AF4x, so IMHO, using a new or reusing 
>CS4 service class adds clarity for the user applications.
>
>Regards,
>CJ
>
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 16 Jul 2013 23:32:31 +0000

> From: James Polk (jmpolk)
> Sent: Tuesday, July 16, 2013 2:07 PM
> To: Charles Eckel (eckelcu); [email-masked]
> Cc: James Polk (jmpolk)
> Subject: RE: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for
> DiffServ
> 

I think video codec implementations in the AF4X class today often have variable bit rates; however, those variations are primarily due to the amount of motion and sometimes as an adaptation to loss. The latter is what is important in this discussion. Video codecs will continue to have variable bit rates in accordance with the amount of motion, but if aligned with the output of RMCAT, they will adapt based on delay as well as loss. 

Cheers,
Charles

> > http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-
> service-
> > > classes-00.txt
> > >

---

From: James Polk <[email-masked]>
Date: Tue, 16 Jul 2013 18:40:29 -0500

At 06:32 PM 7/16/2013, Charles Eckel (eckelcu) wrote:
>I think video codec implementations in the AF4X class today often 
>have variable bit rates; however, those variations are primarily due 
>to the amount of motion and sometimes as an adaptation to loss. The 
>latter is what is important in this discussion. Video codecs will 
>continue to have variable bit rates in accordance with the amount of 
>motion, but if aligned with the output of RMCAT, they will adapt 
>based on delay as well as loss.

Thanks - we'll include those points in the next version.

James

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 17 Jul 2013 03:23:11 +0000

I support something like what this draft proposes, to segregate RMCAT (and potentially other delay-adaptive traffic) from other traffic which does not adapt to delay trends (and therefore incurs maximum queue delay for all traffic in its queue). Of course, this only helps when such queue segregation is available in the network, but effective active queue management is not available (otherwise there would be no delay signals for delay-adaptive traffic to act on).

An open question in my mind, that I think this draft needs to address, is whether all delay-adaptive traffic should share the same queue/DSCP, or whether we need different queues/DSCPs for different delay-adaptive protocols/applications (for example, RMCAT vs. LEDBAT).

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James Polk (jmpolk)
Sent: Tuesday, July 16, 2013 5:11 PM
To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert (eckert); Michael Ramalho (mramalho); [email-masked]; [email-masked]
Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

CJ

James

---

From: [email-masked]
Date: Wed, 17 Jul 2013 07:50:09 +0100

I think the question of sharing diffserv is important, and my current
suggestion is that RMCAT should use one or at most two DSCPs and design a
CC that works well within the class - however this does not absolve RMCAT
from also having to work in the Internet without this class. This will
likely be the main use-case!

Although the proposal could help these applications - the IETF can not
somehow mandate this is universally deployed - and even if the DSCP(s)
were universally recognised, it would still be aggregated within some
networks and on L2 technologies that support fewer classes than DSCP
markings.

It would be interesting to know if others think we should be considering
more DSCPs for this?

Gorry

> I support something like what this draft proposes, to segregate RMCAT (and
> potentially other delay-adaptive traffic) from other traffic which does
> not adapt to delay trends (and therefore incurs maximum queue delay for
> all traffic in its queue). Of course, this only helps when such queue
> segregation is available in the network, but effective active queue
> management is not available (otherwise there would be no delay signals for
> delay-adaptive traffic to act on).
>
> An open question in my mind, that I think this draft needs to address, is
> whether all delay-adaptive traffic should share the same queue/DSCP, or
> whether we need different queues/DSCPs for different delay-adaptive
> protocols/applications (for example, RMCAT vs. LEDBAT).
>
> Mo
>
> To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert (eckert);
> Michael Ramalho (mramalho); [email-masked]; [email-masked]

---

From: Michael Welzl <[email-masked]>
Date: Wed, 17 Jul 2013 17:59:10 +0200

+1

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 17 Jul 2013 14:26:29 -0400

> An open question in my mind, that I think this draft needs to address, is whether all delay-adaptive traffic should share the same queue/DSCP, or whether we need different queues/DSCPs for differen…

Given that everything in the same queue will measure the same
delays, it seems to me like separating flows into queues would
be based on the relative target delays of the flows (tunable
per-flow) and NOT the algorithm used (as you say, RMCAT vs LEDBAT).

It is not wise, in my opinion, to have algorithm-specific DSCPs.
The DSCPs need to indicate the desired forwarding behavior, and
not what version of code the end-host runs.

-- 
Wes Eddy
MTI Systems

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 17 Jul 2013 19:00:23 +0000

Agreed. I should have clarified in my RMCAT vs. LEDBAT example that the key difference (for queue dynamics) is the target delay of near-zero vs. 100 ms. (Near-zero is debatable to mean anything well below 100 ms. I've heard 50, 25, and even 0 mentioned as potential targets in RMCAT.)

Mo

-----Original Message-----
From: Wesley Eddy [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 2:26 PM
To: Mo Zanaty (mzanaty)
Cc: James Polk (jmpolk); Cheng-Jia Lai (chelai); Toerless Eckert (eckert); Michael Ramalho (mramalho); [email-masked]; [email-masked]
Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

-- 
Wes Eddy
MTI Systems

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Jul 2013 07:55:46 +1200

> It would be interesting to know if others think we should be considering

If you mean "more" in the sense of defining new PHBs, I sincerely hope
not. Diffserv works best with a small set of highly differentiated
PHBs. Also, in order to get cross-domain agreements on DSCP assignments,
the fewer there are the better.

    Brian

---

From: "Cheng-Jia Lai (chelai)" <[email-masked]>
Date: Wed, 17 Jul 2013 20:22:08 +0000

I think it would be good if Section 5.1 can include some specification or recommendation how a video flow's packets should be classified into CS4 and CS4-Discardable and how they will be dropped preferentially at congestion. Although AF4x has already specified how to do this by different drop probabilities, it might not be suitable since I-frame, IDR, or other important packets (e.g. in-band signals or supplementary metadata) can still be dropped by probability (smaller though) before all discardable P frames in the same video flow are dropped.

In addition, maybe it should cover some fairness requirements, i.e. how the video rate adaptive behaviors can expect to see packet drops w.r.t. contention, which IMHO should encourage video endpoints to generate more discardable P-frame or other lower priority packets, even at congestion. If possible, this should also try to avoid global synchronization, i.e. all video-encoders to generate I-frame/IDR at the same time (even after they reduce rate, they still need to recover the lost video) when CS4 / CS4-Discardable queue is congested and drops packets from all of them.

Regards,
CJ

-----Original Message-----
From: James Polk (jmpolk) 
Sent: Tuesday, July 16, 2013 2:11 PM
To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert (eckert); Michael Ramalho (mramalho); [email-masked]; [email-masked]
Subject: RE: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

CJ

James

---

From: James Polk <[email-masked]>
Date: Wed, 17 Jul 2013 15:37:34 -0500

CJ

These are good suggestions for the next version. I thank you for 
offering them. I agree that s5.1 is underspecified, and will be 
expanded next version along the lines of your 1st paragraph below, as well.

James

At 03:22 PM 7/17/2013, Cheng-Jia Lai (chelai) wrote:
>I think it would be good if Section 5.1 can include some 
>specification or recommendation how a video flow's packets should be 
>classified into CS4 and CS4-Discardable and how they will be dropped 
>preferentially at congestion. Although AF4x has already specified 
>how to do this by different drop probabilities, it might not be 
>suitable since I-frame, IDR, or other important packets (e.g. 
>in-band signals or supplementary metadata) can still be dropped by 
>probability (smaller though) before all discardable P frames in the 
>same video flow are dropped.
>
>In addition, maybe it should cover some fairness requirements, i.e. 
>how the video rate adaptive behaviors can expect to see packet drops 
>w.r.t. contention, which IMHO should encourage video endpoints to 
>generate more discardable P-frame or other lower priority packets, 
>even at congestion. If possible, this should also try to avoid 
>global synchronization, i.e. all video-encoders to generate 
>I-frame/IDR at the same time (even after they reduce rate, they 
>still need to recover the lost video) when CS4 / CS4-Discardable 
>queue is congested and drops packets from all of them.
>
>Regards,
>CJ
>
>
>To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert 
>(eckert); Michael Ramalho (mramalho); [email-masked]; [email-masked]

---

From: James Polk <[email-masked]>
Date: Wed, 17 Jul 2013 15:46:00 -0500

>the fewer there are the better.

Brian - while I agree less is more manageable, but less what? Isn't 
'the less' or "... a small set..." you're referring to actually about 
treatment aggregates, defined by RFC 5127 (where similar PHBs are 
aggregated into 'treatment aggregates' to all be treated the same 
where we have big pipes)? Treatment Aggregates would see all of the 
above video traffic in the same individual treatment aggregate, 
solving the issue you bring up that _not_ any more treatment 
aggregates are defined.

James

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Jul 2013 11:17:24 +1200

On 18/07/2013 08:46, James Polk wrote:
> Brian - while I agree less is more manageable, but less what? Isn't 'the
> less' or "... a small set..." you're referring to actually about
> aggregated into 'treatment aggregates' to all be treated the same where
> we have big pipes)? Treatment Aggregates would see all of the above
> video traffic in the same individual treatment aggregate, solving the
> issue you bring up that _not_ any more treatment aggregates are defined.

Yes, I agree entirely.

   Brian

>> >> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of
>> >> James Polk (jmpolk)
>> (eckert);
>> >> Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs.
>> loss-only
>> >> rate-adaptive for DiffServ
>> >>
>> >> CJ
>> >>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 18 Jul 2013 02:26:10 -0400

Charles,

The current use of AF4x is fairly inelastic.  Few video endpoints implement
algorithms to dynamically adjust the bit-rate in the face of potential loss.
Part of the reason is that to do that properly, one needs the work the rmcat
WG is doing.

So, I agree with the argument that we need something that is different than
AF4x for what AF4x was originally intended.  It simply a practical problem
trying to change existing equipment to do something different.

At any rate, it needs a good debate.

Paul

> Charles Eckel (eckelcu)
> Sent: Tuesday, July 16, 2013 4:47 PM
> To: James Polk (jmpolk); [email-masked]
> Subject: Re: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for
> DiffServ
> 
> I read the draft and thank you for addressing this need. It does a good
> job of making the case for the need to differentiate the DSCP assignments
> of delay-and-loss-based vs. just-loss-based rate-adaptive video
> applications. While I do not agree with some of the finer points in the
> draft, including the statement in section 3 that AF4x traffic in general
> is inelastic/fixed bitrate, I completely agree that this traffic is
> largely loss sensitive and yet often relies on loss based adaption.
> The assignment of a new service class and the proposal for CS4 and CS4-
> Discardable for rate-adaptive video makes sense to me. At the same time,
> it is important to re-designate AF4x as you describe in order to match the
> reality of today's deployments and avoid future confusion.
> I look forward to seeing this work progress as it offer an incentive for
> applications to embrace congestion control algorithms such as those being
> developed in RMCAT without fearing they will be overrun by non-delay
> adaptive traffic.
> 
> Cheers,
> Charles
> 
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 18 Jul 2013 02:29:23 -0400

Charles,

> I think video codec implementations in the AF4X class today often have
> variable bit rates; however, those variations are primarily due to the
> amount of motion and sometimes as an adaptation to loss.

Right, that's the issue.  Trying to shove rmcat traffic into the same bucket
will be problematic, I think.

> The latter is
> what is important in this discussion. Video codecs will continue to have
> variable bit rates in accordance with the amount of motion, but if aligned
> with the output of RMCAT, they will adapt based on delay as well as loss.

That's the discussion that needs to be had.

Paul

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 18 Jul 2013 06:41:28 +0000

+1

Lars

---

From: Michael Welzl <[email-masked]>
Date: Thu, 18 Jul 2013 13:58:40 +0200

Hi everyone,

I'm still working off my email backlog, and in doing so I got a bit confused about the various drafts and views in this space. Since the issue of interactions with congestion control was also mentioned, I'll try to give a general comment here:

First, about the stuff quoted below, it surprises me that we're even debating algorithm-specific DSCPs - it should be rather obvious that we don't want that?! I thought that the discussion is:
a) 1 DSCP for rtcweb
vs.
b) multiple DSCPs for rtcweb (in which case I was thinking of e.g. video / audio / data rather than algorithms)

I have seen various emails that indicate agreement that we should have at least one DSCP for rtcweb in general. The reason that was given is that rmcat's congestion control will prefer to not be exposed to TCP-like non-delay-based traffic (even though it should be able to work reasonably well in the presence of such traffic too). As many others, I totally agree.

So let's move on to the next question, which is: should we have multiple DSCPs (for multiple traffic classes) or not. Well, there are several pro's and con's here - surely more than I list below, but these are the ones I'd like to lay out because of the coupled-cc stuff we're contributing to rmcat:

Con's of multiple DSCPs:
- 1 DSCP is simpler.
- Whatever the DSCPs achieve, for traffic from a single source going across the same shared bottleneck, coupled congestion control can probably do a better job  (*)  < ===  but see this footnote!

Pro's of multiple DSCPs:
- coupled congestion control only applies to traffic from one host. In other words, protecting your latency-critical audio from your own data transfer doesn't help you against the rtcweb data transfer that a family member generates in your home, as (s)he sends his file across the same shared bottleneck.

(*) Footnote: coupled congestion control should really only be applied when we can be pretty sure that the traffic under control traverses the same shared bottleneck. One simple way to achieve that for rtcweb is to say that all traffic going from the same source to the same destination shares the same bottleneck, but this only applies if "source" and "destination" includes the port number, i.e. if traffic is multiplexed over the same 5-tuple ***AND IF IT SHARES THE SAME DSCP*** (so here we have the DSCP constraint). Due to the amount of traffic on their list I find it hard to track rtcweb, but it seems to me that it's not guaranteed that all rtcweb traffic will indeed be multiplexed in this fashion. Moreover, such shared bottleneck detection is rather limiting - it's also quite possible that traffic from the same source to multiple destinations traverses the same shared bottleneck (typically the source's access link), but this method would then only apply coupled congestion control across flows towards the same destination.

From the above, it seems clear that we're better off using measurement-based shared bottleneck detection anyway, and we're working on that. Note that any measurement-based mechanism will have to look at correlations to determine if traffic shares the same queue, and therefore such a method should discover that flows which carry different DSCPs do *not* share the same bottleneck. Thus, it would automatically do the right thing.

To summarize, it seems that using multiple DSCPs for rtcweb can help, but creates a conflict with something that we shouldn't really rely on for coupled congestion control. Therefore, it probably isn't really a big problem from a congestion control point of view. I think that simplicity is perhaps a more important argument for only one DSCP.

My 2 cents.

Cheers,
Michael

---

From: "Black, David" <[email-masked]>
Date: Thu, 18 Jul 2013 10:03:20 -0400

<WG chair hat off>

I have a couple of requests to help focus the discussion:

(1) Please focus on service classes and PHBs.  An important reason
 is that the proposal in the draft that started this discussion is
to repurpose an existing DSCP, namely CS4.  Asking for a "new DSCP"
is premature, and this is yet more rationale for why "CS4" should
never have been used as a service class name in that draft.

(2) Can we generalize beyond rtcweb/rmcat to look at the traffic
behavior involved?  This is not the first time that adaptive transport
techniques that strive for low queue occupancy have arisen - Data
Center TCP is another example, which is based on enhanced ECN signaling:

	http://simula.stanford.edu/~alizade/Site/DCTCP.html

I assume that people like Michael and Lars are already very familiar
with DCTCP, so that link's included for everyone else :-).

If we can figure out what's going on here beyond "rtcweb/rmcat needs
its own queue", the draft I would really like to see for Vancouver is
the PHB specification for this.  That might be a variant of EF that
allows or requires adaptive response by endpoints, or it might be
something completely new.  While I recall at least talk about writing
a PHB spec for less-than-best-effort adaptive traffic (e.g., ledbat),
I don't recall that as having gone anywhere.

Thanks,
--David

> Michael Welzl
> Sent: Thursday, July 18, 2013 7:59 AM
> To: Eggert, Lars
> Cc: [email-masked]; Mo Zanaty (mzanaty); [email-masked]; Michael Ramalho
> (mramalho); James Polk (jmpolk)
> Subject: Re: [tsvwg] [rmcat] FW: Fwd: Submitted ID on delay vs. loss-only
> I'm still working off my email backlog, and in doing so I got a bit confused
> about the various drafts and views in this space. Since the issue of
> interactions with congestion control was also mentioned, I'll try to give a
> general comment here:
> 
> First, about the stuff quoted below, it surprises me that we're even debating
> algorithm-specific DSCPs - it should be rather obvious that we don't want
> that?! I thought that the discussion is:
> a) 1 DSCP for rtcweb
> vs.
> I have seen various emails that indicate agreement that we should have at
> least one DSCP for rtcweb in general. The reason that was given is that
> rmcat's congestion control will prefer to not be exposed to TCP-like non-
> delay-based traffic (even though it should be able to work reasonably well in
> the presence of such traffic too). As many others, I totally agree.
> 
> So let's move on to the next question, which is: should we have multiple DSCPs
> (for multiple traffic classes) or not. Well, there are several pro's and con's
> here - surely more than I list below, but these are the ones I'd like to lay
> out because of the coupled-cc stuff we're contributing to rmcat:
> 
> Con's of multiple DSCPs:
> - 1 DSCP is simpler.
> - Whatever the DSCPs achieve, for traffic from a single source going across
> the same shared bottleneck, coupled congestion control can probably do a
> better job  (*)  < ===  but see this footnote!
> 
> Pro's of multiple DSCPs:
> - coupled congestion control only applies to traffic from one host. In other
> words, protecting your latency-critical audio from your own data transfer
> doesn't help you against the rtcweb data transfer that a family member
> generates in your home, as (s)he sends his file across the same shared
> bottleneck.
> 
> 
> (*) Footnote: coupled congestion control should really only be applied when we
> can be pretty sure that the traffic under control traverses the same shared
> bottleneck. One simple way to achieve that for rtcweb is to say that all
> traffic going from the same source to the same destination shares the same
> bottleneck, but this only applies if "source" and "destination" includes the
> port number, i.e. if traffic is multiplexed over the same 5-tuple ***AND IF IT
> SHARES THE SAME DSCP*** (so here we have the DSCP constraint). Due to the
> amount of traffic on their list I find it hard to track rtcweb, but it seems
> to me that it's not guaranteed that all rtcweb traffic will indeed be
> multiplexed in this fashion. Moreover, such shared bottleneck detection is
> rather limiting - it's also quite possible that traffic from the same source
> to multiple destinations traverses the same shared bottleneck (typically the
> source's access link), but this method would then only apply coupled
> congestion control across flows towards the same destination.
> 
> From the above, it seems clear that we're better off using measurement-based
> shared bottleneck detection anyway, and we're working on that. Note that any
> measurement-based mechanism will have to look at correlations to determine if
> traffic shares the same queue, and therefore such a method should discover
> that flows which carry different DSCPs do *not* share the same bottleneck.
> Thus, it would automatically do the right thing.
> 
> To summarize, it seems that using multiple DSCPs for rtcweb can help, but
> creates a conflict with something that we shouldn't really rely on for coupled
> congestion control. Therefore, it probably isn't really a big problem from a
> congestion control point of view. I think that simplicity is perhaps a more
> important argument for only one DSCP.
> 
> My 2 cents.
> 
> Cheers,
> Michael
> 
>

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Thu, 18 Jul 2013 14:52:02 +0000

Michael (Welzl),

I think you have summarized the discussion well except, perhaps, for an implicit assumption on how rmcat flows will (or can) be used within a singular WebRTC session (we really need to standardize what we mean by stream, flow, session, association and other transport protocol naming conventions).

Before I add commentary to your excellent email summary (with "MAR:" below), let me state a few points.

Point 1: I have presumed that the rmcat congestion control algorithm (hopefully codified into an actual protocol specification someday) would be applied to the MEDIA stream(s) within the WebRTC session. This is because non-streams WITHIN a WebRTC session can have different (and sometimes conflicting) requirements or characteristics.

Point 2: Your "cross-flow" congestion control point is a very good one, but one that is out-of-scope for RMCAT as I read the charter (Lars and Mirja can comment). Existing experience with conferencing sessions that have both real-time, semi-real-time (e.g., "screen share" where a display of  scrolling screen can be delayed for a few 100 milliseconds) and non-real time elastic (e.g., background transfer) within them OVER A SINGULAR BOTTLENECK have shown that it is necessary under congestion to PACE information in the non-real time components of those streams in order for that the real-time streams not be impaired. So your point is well taken, but out-of-scope. More below.

Michael (Ramalho)

-----Original Message-----
From: Michael Welzl [mailto:[email-masked]] 
Sent: Thursday, July 18, 2013 7:59 AM
To: Eggert, Lars
Cc: Wesley Eddy; Toerless Eckert (eckert); [email-masked]; Mo Zanaty (mzanaty); [email-masked]; Michael Ramalho (mramalho); James Polk (jmpolk); Cheng-Jia Lai (chelai)
Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

Hi everyone,

MAR: I think that is the point that started the thread. It is my only (individual, not WG) request to tsvwg.

Con's of multiple DSCPs:
- 1 DSCP is simpler.

Pro's of multiple DSCPs:

MAR: This is not within scope of RMCAT or TSVWG as I see it. It is likely within scope of WebRTC if they choose to look at it - and they can punt to TSVWG or RMCAT to include in their charters if they desire.

>From the above, it seems clear that we're better off using measurement-based shared bottleneck detection anyway, and we're working on that. Note that any measurement-based mechanism will have to loo…

MAR: Thankfully, for the shared bottleneck problem you are considering here, the WebRTC (sub) stream which is causing the undue congestion relative to the total WebRTC stream (sometimes called "self-induced" congestion) can sense it quickly. So it is not clear to me that having a congestion measurement apparatus shared by all flows in a WebRTC session (which would appear to be the optimal solution if information flows between the flows were well specified and instantaneous) is actually better in practice.

MAR: Independent of your conclusion (and thank you for making it so clear), I believe it to be out of scope for RMCAT. I would suggest that these issues be brought to WebRTC.

My 2 cents.

Cheers,
Michael

On Jul 18, 2013, at 8:41 AM, "Eggert, Lars" <[email-masked]> wrote:

>> The DSCPs need to indicate the desired forwarding behavior, and not 
>> what version of code the end-host runs.
> 
> +1
> 
> Lars

---

From: Michael Welzl <[email-masked]>
Date: Fri, 19 Jul 2013 11:37:06 +0200

Hi,

See in line below -

> Point 1: I have presumed that the rmcat congestion control algorithm (hopefully codified into an actual protocol specification someday) would be applied to the MEDIA stream(s) within the WebRTC ses…

I assume that you mean "non-media-streams" with "non-streams"?

Anyway: non-media streams are out of scope for rmcat, but as a technical eventual decision, it would be bad to not apply rmcat congestion control to *all* the traffic that shares a bottleneck. I know there are more, but I think we all agree that one key requirement for RMCAT congestion control is low delay. We're not going to get low delay if the browser we're dealing with for rtcweb uses e.g. a loss-based congestion control (for data) in addition to a delay-based congestion control (for media) across the same bottleneck - that's exactly the situation we'd like to avoid. Even if we have multiple individual delay-minimizing rtcweb flows, they will compete for bandwidth on the bottleneck that they share, which inevitably causes more queue growth than necessary. 2 flows of whatever mechanism you can come up with create more queue growth than 1, so we should strive to avoid that sort of competition.

I'm arguing that this would be best design-wise, but I'd also say we don't have to worry about rtcweb data streams for now, they are indeed out of scope for RMCAT. Yet, even if we want to minimize the delay for media streams only, ignoring the possibility of a data channel, then we're still better off if we combine the media streams' congestion controllers whenever we can.

I might have been sloppy in talking about coupled congestion control being applied to both data and media when, at this point, in the RMCAT context, we should probably ignore data - sorry!

> Point 2: Your "cross-flow" congestion control point is a very good one, but one that is out-of-scope for RMCAT as I read the charter (Lars and Mirja can comment). Existing experience with conferencing

I'm sure it's not. We're really re-iterating a pre-BOF discussion here; there was uniform agreement that we'd need such congestion control coupling, culminating in this text bits in the charter:

"The working group will:  (..) - Develop a mechanism for identifying shared bottlenecks between groups of
flows, and means to flexibly allocate their rates within the aggregate hitting
the shared bottleneck."

"Deliverables: (..) - Identifying and controlling groups of flows as a Proposed Standard RFC"

"Milestones:  (..) 
Jan 2014	
Adopt first WG draft on identifying and controlling groups of flows

Jul 2014	
Submit identifying and controlling groups of flows to IESG for Standards Track publication"

> sessions that have both real-time, semi-real-time (e.g., "screen share" where a display of  scrolling screen can be delayed for a few 100 milliseconds) and non-real time elastic (e.g., background transfer) within them OVER A SINGULAR BOTTLENECK have shown that it is necessary under congestion to PACE information in the non-real time components of those streams in order for that the real-time streams not be impaired. So your point is well taken, but out-of-scope. More below.

Pacing is surely one possible way of doing it. Anyway I don't see a conflict here.
Also more below….

> MAR: This is not within scope of RMCAT or TSVWG as I see it. It is likely within scope of WebRTC if they choose to look at it - and they can punt to TSVWG or RMCAT to include in their charters if t…

The "data transfer" bit isn't in scope, but coupled congestion control is. So my example wasn't quite ideal, all you need to do is to replace "latency-critical audio" with e.g. "high priority audio" and "data transfer" with e.g. "low priority video" in my "Pro's of multiple DSCPs" sentence above.

> MAR: Thankfully, for the shared bottleneck problem you are considering here, the WebRTC (sub) stream which is causing the undue congestion relative to the total WebRTC stream (sometimes called "sel…

We'll hopefully be able to show some results in Berlin that will convince you that this is indeed better in practice.
As for the information flow between flows being well specified, we're trying to address this here:
http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-01
and this document needs some discussion, so please take a look and comment!

As for the information flow between flows being instantaneous, at least for now, we're working with the notion that a flow only needs to talk to our coupling entity (which we call "Flow State Exchange (FSE)") whenever it updates it sending rate as a result of its own congestion control, and the FSE does *not* need to immediately notify all other flows. So, the constraint regarding "instantaneous" information flow is quite relaxed - we did this because a design goal of ours was to minimize the changes required to applications already implementing one or another form of congestion control.

> MAR: Independent of your conclusion (and thank you for making it so clear), I believe it to be out of scope for RMCAT. I would suggest that these issues be brought to WebRTC.

I do hope that I have now convinced you that shared bottleneck detection and congestion control coupling are in scope, and only my mentioning of "data" was out of scope (even though I do think that  including the data channel, at some point in the future, would lead to better overall behavior anyway).

Cheers,
Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Jul 2013 08:08:46 +1200

On 19/07/2013 21:37, Michael Welzl wrote:
>> I think you have summarized the discussion well except,
>> perhaps, for an implicit assumption on how rmcat flows will
>> (or can) be used within a singular WebRTC session (we
>> really need to standardize what we mean by stream, flow,
>> session, association and other transport protocol naming
>> conventions).
>> 
>> Before I add commentary to your excellent email summary
>> (with "MAR:" below), let me state a few points.
>> 
>> Point 1: I have presumed that the rmcat congestion control
>> algorithm (hopefully codified into an actual protocol
>> specification someday) would be applied to the MEDIA
>> stream(s) within the WebRTC session. This is because
>> non-streams WITHIN a WebRTC session can have different (and
>> sometimes conflicting) requirements or characteristics.
> 
> Anyway: non-media streams are out of scope for rmcat, but as
> a technical eventual decision, it would be bad to not apply
> rmcat congestion control to *all* the traffic that shares a
> bottleneck. I know there are more, but I think we all agree
> that one key requirement for RMCAT congestion control is low
> delay. We're not going to get low delay if the browser we're
> dealing with for rtcweb uses e.g. a loss-based congestion
> control (for data) in addition to a delay-based congestion
> control (for media) across the same bottleneck - that's
> exactly the situation we'd like to avoid. 

I'm rather confused. As I understand things, this is by
definition a situation you can't avoid in the Internet, since
the mix of traffic at any point, including at a bottleneck, is
completely arbitrary. What you have just described is *exactly*
why our scaleable QoS model (diffserv) defines qualitatively
different per-hop behaviours, so that a delay-based PHB can
coexist with a loss-based PHB at the same interface. Needless to
say, there is no free lunch, which is why the default PHB (for
all unclassified traffic) gets no guarantees at all.

Wishing that it was different cannot make it different - delay-
sensitive traffic competes with loss-sensitive traffic, because
that's how the world works.

> Even if we have
> multiple individual delay-minimizing rtcweb flows, they will
> compete for bandwidth on the bottleneck that they share,
> which inevitably causes more queue growth than necessary. 2
> flows of whatever mechanism you can come up with create more
> queue growth than 1, so we should strive to avoid that sort
> of competition.
> 
> I'm arguing that this would be best design-wise, but I'd also
> say we don't have to worry about rtcweb data streams for now,
> they are indeed out of scope for RMCAT. Yet, even if we want
> to minimize the delay for media streams only, ignoring the
> possibility of a data channel, then we're still better off if
> we combine the media streams' congestion controllers whenever
> we can.

That is definitely true - if you have N streams that need the
same PHB, running them as a single behaviour aggregate is always
better.

> 
> I might have been sloppy in talking about coupled congestion
> control being applied to both data and media when, at this
> point, in the RMCAT context, we should probably ignore data -
> sorry!

Do you mean ignore it, or simply regard it as background traffic
that will soak up all resources that media traffic doesn't use?
I think those are two rather different things.

    Brian

---

From: ken carlberg <[email-masked]>
Date: Fri, 19 Jul 2013 16:39:29 -0400

> that's how the world works.

there is actually some middle ground.  Traffic engineering exists and is used to do some measure of segmentation of flows -- particularly in access networks that are more prone to congestion than transit backbones.  And TE tends to get even more pronounced in "walled gardens"*.  The issues to keep in mind is that your mileage may very depending on the providers, and you can't count on it existing throughout the Internet -- its a jungle out there and one has to consider/accept the worst case scenario of an arbitrary traffic mix. 

-ken

* a fair amount of folks don't consider "walled gardens" as part of the Internet, or of concern to the IETF.  I'll acknowledge the viewpoint, and respectfully disagree by keeping in mind the original phrase "an internetwork of networks".

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Fri, 19 Jul 2013 21:32:51 +0000

Hi Michael,

A few more comments below, identified with "MAR2:".

Before I begin, let's say we are also re-visiting an email thread of a few weeks ago. I should have been more clear about the "cross-stream" part. We agreed in my July 5 email (and your reply to it) that all applications ON A GIVEN HOST could know about each other (what we called Case 1 - same source address with potentially different destination addresses). However the case of a shared bottleneck created by applications on different hosts (what we called Case 2 - having different source addresses) you agreed was out-of-scope.

Now apparently you are calling "Case 2" back in scope when referring to "*all* the traffic that shares a bottleneck" (your quote and your emphasis). That is the part I disagree with.

Michael Ramalho

-----Original Message-----
From: Michael Welzl [mailto:[email-masked]] 
Sent: Friday, July 19, 2013 5:37 AM
To: Michael Ramalho (mramalho)
Cc: Eggert, Lars; Wesley Eddy; Toerless Eckert (eckert); [email-masked]; Mo Zanaty (mzanaty); [email-masked]; James Polk (jmpolk); Cheng-Jia Lai (chelai)
Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

Hi,

See in line below -

MAR2: Duh. Yeah. Sorry.

Anyway: non-media streams are out of scope for rmcat, but as a technical eventual decision, it would be bad to not apply rmcat congestion control to *all* the traffic that shares a bottleneck.

MAR2: But "*all* traffic that shares a bottleneck"  includes the traffic from other hosts too! You previously agreed (on July 5) all those other flows are out of scope!

MAR2: If you meant "all the traffic IN A SPECIFIC WebRTC session" (i.e., both media and non-media streams), then I agree.

MAR2: Let's please try to differentiate the cases (or equivalently, precisely specify the subset of the bottleneck traffic you are considering).

I know there are more, but I think we all agree that one key requirement for RMCAT congestion control is low delay. We're not going to get low delay if the browser we're dealing with for rtcweb uses e.g. a loss-based congestion control (for data) in addition to a delay-based congestion control (for media) across the same bottleneck - that's exactly the situation we'd like to avoid. Even if we have multiple individual delay-minimizing rtcweb flows, they will compete for bandwidth on the bottleneck that they share, which inevitably causes more queue growth than necessary.

MAR2: Yes, two independent control loops not knowing of each other could contribute to a doubling of the queue that one alone could do with bad timing. Join the design team meetings to specify the experiments you want to see.

2 flows of whatever mechanism you can come up with create more queue growth than 1, so we should strive to avoid that sort of competition.

> Point 2: Your "cross-flow" congestion control point is a very good 
> one, but one that is out-of-scope for RMCAT as I read the charter 
> (Lars and Mirja can comment). Existing experience with conferencing

"The working group will:  (..) - Develop a mechanism for identifying shared bottlenecks between groups of flows, and means to flexibly allocate their rates within the aggregate hitting the shared bottleneck."

"Milestones:  (..) 
Jan 2014	

Jul 2014	

MAR2: We have been down this road before (on July 5). My comment was in response to your "all traffic" comment. By my reading, your draft AND the RMCAT charter exclusively deals with flows emanating from a given host, and therefore limited in scope to ONLY THAT SUBSET of "all traffic hitting the shared bottleneck" that came from a given host. Q.E.D.

MAR2: I stand behind my statement that it is outside the scope of RMCAT to consider "cross-flow" information from flows from a multiplicity of hosts that could have contributed traffic to the bottleneck.

MAR2: Perhaps we need to tighten the words in the charter so that they mean the same thing to everyone ;-).

Also more below....

> Cc: Wesley Eddy; Toerless Eckert (eckert); [email-masked]; Mo Zanaty 
> (mzanaty); [email-masked]; Michael Ramalho (mramalho); James Polk 
> (jmpolk); Cheng-Jia Lai (chelai)
> loss-only rate-adaptive for DiffServ
> 
> Hi everyone,
> 
> b) multiple DSCPs for rtcweb (in which case I was thinking of e.g. 
> video / audio / data rather than algorithms)
> 

MAR2: You haven't convinced me that coupled congestion control across different hosts are in scope yet - because your own document at its present version number does not address the entire scope of the problem. Reasonable people can disagree. See you in Berlin.

Cheers,
Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Jul 2013 11:12:20 +1200

On 20/07/2013 08:39, ken carlberg wrote:
> there is actually some middle ground.  Traffic engineering exists and is used to do some measure of segmentation of flows -- particularly in access networks that are more prone to congestion than transit backbones.

Absolutely, but of course to do any kind of dynamic TE you need
to be able to classify traffic somehow.

>  And TE tends to get even more pronounced in "walled gardens"*.  The issues to keep in mind is that your mileage may very depending on the providers, and you can't count on it existing throughout the Internet -- its a jungle out there and one has to consider/accept the worst case scenario of an arbitrary traffic mix. 

Exactly. Whatever we do to improve matters inside a walled
garden must not make things worse in that jungle.

> * a fair amount of folks don't consider "walled gardens" as part of the Internet, or of concern to the IETF.  I'll acknowledge the viewpoint, and respectfully disagree by keeping in mind the origin…

I hesitate to keep banging on about the diffserv model, but I
think it's a realistic paradigm, and it definitely assumes
walled gardens as far as QoS is concerned (called "diffserv
domains"). You can slice and dice the problem as much as you
want, but I think we're stuck with the inter-domain model
boiling down to best effort, in the absence of pairwise SLAs
between competing providers.

   Brian

---

From: Michael Welzl <[email-masked]>
Date: Sat, 20 Jul 2013 09:18:21 +0200

Hi,

My apologies to everyone whose time I have wasted by not being clear enough: this all seems to be a big misunderstanding.
I am *not* calling "Case 2" back in scope and I really only meant coupled congestion control for traffic from a single host.

Note this bit from my first email in this discussion:
**
Pro's of multiple DSCPs:
- coupled congestion control only applies to traffic from one host. In other words, protecting your latency-critical audio from your own data transfer doesn't help you against the rtcweb data transfer that a family member generates in your home, as (s)he sends his file across the same shared bottleneck.
**

A few things are somewhat off here: as we already discussed, I shouldn't have mentioned "data transfer"; probably worse, the notion of "protecting" is misleading, because what I really meant is that you cannot use coupled congestion control to protect one flow against another when that other doesn't originate from the same host.

(then again, the first sentence was quite clear?!  "coupled congestion control only applies to traffic from one host.")
Anyway, sorry again to everyone I have confused.

As for joining the design team discussions, the usual time of the telco doesn't work for me, but I plan to be at the design team meeting in Berlin.

Cheers,
Michael

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Fri, 26 Jul 2013 16:15:53 +0200

On 2013-07-17 20:26, Wesley Eddy wrote:
> It is not wise, in my opinion, to have algorithm-specific DSCPs. The 
> DSCPs need to indicate the desired forwarding behavior, and not what 
> version of code the end-host runs. 
+1

BR

-- 

Zahed

==================================================
ANM ZAHEDUZZAMAN SARKER

Ericsson AB
Multimedia Technologies
Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43
[email-masked]
www.ericsson.com

==================================================

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Fri, 26 Jul 2013 15:07:41 +0000

All,

While I agree with Wes, we all need to ask the following question:

What happens if the action of your congestion control CAUSES you not to have the PHB you desire under congestion?

I don't think we asked ourselves that question in this way before.

Let me state it a different way. If you have AF4X traffic and your network is traffic engineered such that ALL the endpoints putting stuff in AF4X is guaranteed (in some sense via CAC or some other bandwidth management arrangement) to fit within the BW allowed for all the AF4X traffic ... then all is OK. That is how a lot of enterprise use of AF4X is designed.

But what if the AF4X traffic comes from endpoints that do not have such a CAC/BWM arrangement ... and the endpoints desiring AF4X PHB keep increasing their rate until loss occurs. Well, if the AF4X queue is long enough, then NONE of the AF4X traffic will have the desired PHB!

That is the rub. The endpoints "want" a certain PHB ... but if there is a bottleneck at a point and the CC of the endpoints all adapt based on loss ... then the traffic won't get the PHB it desires (it will "self-congest" itself).

So while I agree that we ought not to request a new DSCP per new CC protocol/algorithm ... we need to answer this question.

[I know I will regret sending this email.]

Michael Ramalho

-----Original Message-----
From: Zaheduzzaman Sarker [mailto:[email-masked]] 
Sent: Friday, July 26, 2013 10:16 AM
To: Wesley Eddy
Cc: Mo Zanaty (mzanaty); Toerless Eckert (eckert); [email-masked]; [email-masked]; Michael Ramalho (mramalho); James Polk (jmpolk); Cheng-Jia Lai (chelai)
Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

+1

BR

-- 

Zahed

Ericsson AB
Multimedia Technologies
Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43

---

From: Scott Brim <[email-masked]>
Date: Fri, 26 Jul 2013 11:52:18 -0400

The endpoints want a particular defined service or PDB.  One part of
delivering that is the per-hop behaviors.  They can't deliver a service
alone.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Jul 2013 08:54:45 +1200

> delivering that is the per-hop behaviors.  They can't deliver a service

There are two aphorisms that apply here:

1. Queueing theory wins every time.

2. There is no such thing as free lunch.

I'm not trying to be funny. As Michael observes, if there isn't enough
capacity for the offered load, no queueing discipline can fix the problem.
Well-designed PHBs can make things better for a fraction of the traffic,
but only if there's a sufficient background of BE traffic to be dropped
or delayed when necessary.

And if you overload the AF4X queue at a given point, it will inevitably
end up behaving like a BE queue.

That's why the diffserv model includes the need for admission control.

   Brian

---

From: Michael Welzl <[email-masked]>
Date: Sat, 27 Jul 2013 08:33:44 +0200

On Jul 26, 2013, at 10:54 PM, Brian E Carpenter <[email-masked]> wrote:

[..]

> That's why the diffserv model includes the need for admission control.

+1, exactly my thinking when I read Michael Ramalho's message.

So, with rtcweb planning to use DSCPs just because the application decides to do so, rtcweb steps away from this usage of DiffServ, and yes you get prioritization between classes, but any form of guarantees for go out of the window.

I always assumed that ISPs would protect DiffServ traffic that needs to get a certain PHB by having their ingress routers scratch the DSCP for all other traffic (e.g. everything that didn't do admission control). If they don't, they better do now… and that would pretty much eliminate the problem, I think: rtcweb would then get priorities applied between its own flows wherever it can, and it won't harm anything that needs to be protected - in such situations, the network just defaults to putting all the rtcweb stuff in the same BE class, and not much harm is being done, I think rtcweb was meant for the BE Internet from day 1 anyway.

Problem solved?

Cheers,
Michael

---

From: Scott Brim <[email-masked]>
Date: Sat, 27 Jul 2013 15:30:56 +0200

On 07/27/13 09:35, Kenneth Carlberg allegedly wrote:
> well, be it right or wrong, industry long ago expanded the model so that
> one can have a case of only the application deciding the code point

I don't mind the application deciding the codepoint, but the app still
needs to understand that the network will (should, anyway) do traffic
conditioning, and have a plan for adapting to it.

Scott (at the Pullman)

---

From: Dave Taht <[email-masked]>
Date: Sat, 27 Jul 2013 11:14:22 -0700

On Fri, Jul 26, 2013 at 11:33 PM, Michael Welzl <[email-masked]> wrote:
> I always assumed that ISPs would protect DiffServ traffic that needs to get a certain PHB by having their ingress routers scratch the DSCP for all other traffic (e.g. everything that didn't do admission control). If they don't, they better do now…

What I observe is the only diffserv marking with e2e survivability on
ipv4 is CS1. Everything else gets re-marked. IPv6 has thus far

That said, there is a great deal of internal-to-site traffic that
might benefit, and if the bottleneck gateway from that site is
respecting some markings you have some hope in case of congestion to
the outside.

Where it might matter some more is on wifi, although the current (vs
expected) results of 802.11e, at least on Linux, is dismal, without
admission control. (aggregation works much better)

Given that the only marking I see consistently respected is BE and BK,
I can suggest a couple things for rtcweb - when an browser is running
rtcweb it could try to open less flows than normal for other tasks,
and it could also signal e2e intent by dropping the classification to
CS1 on things like tabs loading in the background.

>and that would pretty much eliminate the problem, I think: rtcweb would then get priorities applied between its own flows wherever it can, and it won't harm anything that needs to be protected - in such situations, the network just defaults to putting all the rtcweb stuff in the same BE class, and not much harm is being done, I think rtcweb was meant for the BE Internet from day 1 anyway.

One of the things I like very much about rtcweb is that traffic inside
your own domain - a call from upstairs to downstairs - STAYS inside
your own network, so IF CS4/CS5 classification is used, over wifi, you
would see this traffic drop into the underused hardware wifi VI queue.
Whether or not this would be a good thing would require some
testing...

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Dave Taht <[email-masked]>
Date: Sat, 27 Jul 2013 12:18:47 -0700

> ipv4 is CS1. Everything else gets re-marked. IPv6 has thus far

"escaped much of the same fate." Sorry, thinko. Some experiments with
mosh on ipv4 set to AF42 by default showed a couple middleboxes that
would drop such-marked packets after a few seconds, btw. So I'd argue
that even attempting to use classification should be dynamic and fall
back to BE in case of a failure of connectivity.

JG recently posted a summary of our thinking about latency management
in general which I hope could inform this debate somewhat:

http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/

-- 
Dave Täht

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Jul 2013 08:44:19 +1200

> conditioning, and have a plan for adapting to it.

Indeed, and of course a classifier somewhere downstream can always
override the code point set by the application, if the traffic exits
the initial domain.

    Brian