Subject: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG?

From: ken carlberg <[email-masked]>
Date: Tue, 23 Oct 2012 09:15:26 -0400

Hi,

I've been asked publically and privately about my thoughts as to where this document should end up -- TSVWG or RMCAT.  When the question was first brought up I was indifferent because I could see a case for both.  However, when I thought about it for a while, I felt more comfortable advancing this through TSVWG.  

The reason for this line of thoughts is that only a portion of the ECN Reactions draft deals with congestion control algorithms.  And while RMCAT talks about the generic term of "mechanisms" in its charter, the heart of the charter and deliverables seems to focus on algorithms, which is really just one type of mechanism.  On the other hand, the Reactions draft looks into other "mechanisms" like FEC, signaling, and most importantly, the impact of a set of users not responding to ECN.  And its this last item where we bring in some simulation work and is probably the strongest reason (ie, the simulation results) as to why its beneficial to have this in an IETF document.  And its these other items that seem out of scope of RMCAT.

Assuming this draft is accepted as a working group item in TSVWG, I would also want to send the document to RMCAT for review when we get to a WG last call for comments stage, though I sure the core set of folks will be attending both sets of meetings and mailing lists.

If folks feel I've missed something, please don't be shy in letting us know :-)

-ken

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 24 Oct 2012 19:16:02 +0100

Ken,

Perhaps we could bounce this question back to you: what is the main 
single take-home message you want us to get from this draft? THat 
should decide which WG it's in.

I believe the primary message is "TFRC is good enough if you've got 
ECN, so we can get started without RMCAT if we have ECN." I don't 
think that's true (as I have been arguing on the list), but I think 
that's the message the draft is wanting people to hear most. If that 
were the case, then TSVWG would be reasonable.

I would have thought the impact of users not responding to ECN would 
be just as much in scope for RMCAT as TSVWG (and ConEx is where 
policing/non-compliance is most being addressed, which is the other 
side of this problem).

Regarding FEC, I think this is a bit of a corner-case in this draft, 
so I wouldn't decide which WG based on that.

Bob

At 14:15 23/10/2012, ken carlberg wrote:
>Hi,
>
>I've been asked publically and privately about my thoughts as to 
>where this document should end up -- TSVWG or RMCAT.  When the 
>question was first brought up I was indifferent because I could see 
>a case for both.  However, when I thought about it for a while, I 
>felt more comfortable advancing this through TSVWG.
>
>The reason for this line of thoughts is that only a portion of the 
>ECN Reactions draft deals with congestion control algorithms.  And 
>while RMCAT talks about the generic term of "mechanisms" in its 
>charter, the heart of the charter and deliverables seems to focus on 
>algorithms, which is really just one type of mechanism.  On the 
>other hand, the Reactions draft looks into other "mechanisms" like 
>FEC, signaling, and most importantly, the impact of a set of users 
>not responding to ECN.  And its this last item where we bring in 
>some simulation work and is probably the strongest reason (ie, the 
>simulation results) as to why its beneficial to have this in an IETF 
>document.  And its these other items that seem out of scope of RMCAT.
>
>Assuming this draft is accepted as a working group item in TSVWG, I 
>would also want to send the document to RMCAT for review when we get 
>to a WG last call for comments stage, though I sure the core set of 
>folks will be attending both sets of meetings and mailing lists.
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Michael Welzl <[email-masked]>
Date: Thu, 25 Oct 2012 13:06:08 +0200

Hi all,

I have read the document and only now got around to look at the  
thread. The view that I got from reading the document seems to match a  
lot of the criticism that this draft is receiving.

One first concern is: the draft seems to consist of one recommendation  
(using TFRC), and a ton of ideas (using DiffServ, using RSVP, using  
FEC, whatnot). I think that listing all the possible ideas of things  
one could possibly do in response to an ECN-mark is pretty pointless.  
Why not add NSIS? Why not change the packet size in response to ECN?  
Why not stop the flow if there is heavy congestion? And (rinse and)  
repeat? Why not change this in the codec, this in the codec, that in  
the codec? It's really an endless list!

So, why are the "ideas" only listed as such, and not as  
recommendations? Because you don't back them up with enough "meat" to  
make them recommendable. There's a ton of literature out there, on all  
these things - if you find something in it that lets you make a  
recommendation, go ahead, but as long as the things seem fishy to you,  
I would refrain from listing them because they end up being useless to  
the reader, too. (note, I have nothing against recommending things  
other than "let's just use TFRC", if this is convincingly written,  
based on citations to documents that make it clear that these things  
are indeed good ideas).

As for the simulation study, this looks pretty useless. It doesn't  
have enough details to be repeatable (e.g., the queue length is  
missing, and "RED parameters as recommended by Sally Floyd" isn't  
quite telling us all we need to know, either (e.g., gentle mode used  
or not?) ). As Bob has pointed out, it's also only one specific  
scenario, omitting other possible situations... if the point of  
documenting a simulation is just to illustrate a case with numbers to  
be able to explain them better, then that may be okay to have in a  
draft, but if the point is to justify a decision, as here, this would  
be better published in a paper, after peer review, and then cited, I  
think.

So, now I can get to what Bob wrote below - this message seems to be  
the most fitting one to answer:

If we could agree on removing ideas and sticking with just  
recommendations, then:

> policing/non-compliance is most being addressed, which is the other  

indeed, I would have thought that too.

> so I wouldn't decide which WG based on that.

FEC is just one of the ideas I talk about above, and, as such, should  
be removed IMO.

Cheers,
Michael

PS: a nit: section 3: you can't say that "TCP congestion control ...  
favours reliability over timeliness."  TCP does, but this is not its  
congestion control.

---

From: ken carlberg <[email-masked]>
Date: Thu, 25 Oct 2012 07:25:44 -0400

Bob,

a good bounceback question.

It wasn't our intention to say that "TFRC is good eough if you've got ECN".  The main point we wanted to make is that TFRC exists now, but there are some issues and that is being addressed in RMCAT in the form of requirements and potentially new CC algorithms.  So we'll need to fix our text to convey this properly.  Also, if our draft was that narrowly focused, then yes, we'd move the Reactions draft to RMCAT and probably fold that into one fo the deliverables in the RMCAT charter.

In writing RFC-6679 (ECN for RTP over UDP), the authors agreed that a default approach of using a CC algorithm is what is needed to reduce load when congestion is signaled.  Later on, I came across some carriers (as well as some vendors) who were of the mind set that they have a preference to swap codecs to one that produced less load instead of using a CC algorithm.  From my perspective, this is outside the scope and intent of RMCAT, and yet its a perfectly reasonable approach to consider.  And discussions with others brought up the ideas of on-demand invocation of FEC and RSVP as a means of further protecting certain flows.   From my perspective, this is outside the scope and intent of RMCAT, and yet its a perfectly reasonable approach to consider.  In addition, sets of users not responding to ECN would seem to be at the fringe of RMCAT's charter.

And so we use the title "Reactions to ECN" to purposely be broad in scope and not just focused on CC algorithms reactions to ECN.  That is why I think this document should stay with TSVWG.  Piers and I will also be participating in RMCAT, so we'll be sure to bring up items that can contribute to the discussion and advancement of RMCAT.

cheers,

-ken

On Oct 24, 2012, at 2:16 PM, Bob Briscoe wrote:

> Ken,
> 
> Perhaps we could bounce this question back to you: what is the main single take-home message you want us to get from this draft? THat should decide which WG it's in.
> 
> I believe the primary message is "TFRC is good enough if you've got ECN, so we can get started without RMCAT if we have ECN." I don't think that's true (as I have been arguing on the list), but I think that's the message the draft is wanting people to hear most. If that were the case, then TSVWG would be reasonable.
> 
> I would have thought the impact of users not responding to ECN would be just as much in scope for RMCAT as TSVWG (and ConEx is where policing/non-compliance is most being addressed, which is the other side of this problem).
> 
> Regarding FEC, I think this is a bit of a corner-case in this draft, so I wouldn't decide which WG based on that.
> 
> 
> Bob
>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 25 Oct 2012 13:50:54 +0100

Ken,

Now I understand where you're coming from (which wasn't clear BTW) I 
can start to bite on your question...

Changing codecs is driven by a cc algo, it's just an algo with a 
discrete output, not a continuous output. One can think of it like an 
internal continuous rate-vs-congestion response that drives step rate 
changes - once it has remained below or above a codec-change 
threshold for sufficiently long. Sometimes they are actually written 
like that. Other times they are driven by hi/lo watermarks in the 
playout buffer.

But these are cc algorithms all the same. So if you think cc algos 
should go in RMCAT, then this should, because that is the main meat 
of this draft.

Indeed, I imagine most of the RMCAT output will be targetted at 
codecs with discrete steps in spatial & temporal resolution.

THe emergency comms section (5.3) is merely a different degree of cc 
response, so it ought to be under "CC ALgos" (section 3), not "Other 
responses" (section 5).

On the other kitchen sink of responses (triggering RSVP, Diffserv, 
Redundancy, FEC etc), I'm with Michael W. If you're just listing what 
implementers might do, then it has little value. If you're 
recommending what implementers shouldn't do or what they should, it 
would be worth keeping these. But none of these other responses you 
list seem to be that prevalent, important or practical.

If a codec isn't using RSVP, but the going gets tough part-way 
through, calling to RSVP for help would be a bit like a ship-wreck 
victim praying for a miracle to save them :) If RSVP is available on 
a particular network (<1% chance), and specific apps have been 
written to use it but they start-out not using it (<1% * <1%), I 
don't see it will help commentating on that remote possibility in this draft.

Similarly, nowadays, nearly always where Diffserv is used, the 
network decides to apply the markings at the edge, not the host. So 
if there were a case where the network took account of host-initiated 
Diffserv markings (<1% chance), and specific apps have been written 
to use it but they start-out not using it (<1% * <1%), I don't see it 
will help commentating on that remote possibility in this draft.

And I've already said the ECN + (Redundancy or FEC) items are pretty 
much corner-cases too.

Bob

At 12:25 25/10/2012, ken carlberg wrote:
>It wasn't our intention to say that "TFRC is good eough if you've 
>got ECN".  The main point we wanted to make is that TFRC exists now, 
>but there are some issues and that is being addressed in RMCAT in 
>the form of requirements and potentially new CC algorithms.  So 
>we'll need to fix our text to convey this properly.  Also, if our 
>draft was that narrowly focused, then yes, we'd move the Reactions 
>draft to RMCAT and probably fold that into one fo the deliverables 
>in the RMCAT charter.
>
>In writing RFC-6679 (ECN for RTP over UDP), the authors agreed that 
>a default approach of using a CC algorithm is what is needed to 
>reduce load when congestion is signaled.  Later on, I came across 
>some carriers (as well as some vendors) who were of the mind set 
>that they have a preference to swap codecs to one that produced less 
>load instead of using a CC algorithm.  From my perspective, this is 
>outside the scope and intent of RMCAT, and yet its a perfectly 
>reasonable approach to consider.  And discussions with others 
>brought up the ideas of on-demand invocation of FEC and RSVP as a 
>means of further protecting certain flows.   From my perspective, 
>this is outside the scope and intent of RMCAT, and yet its a 
>perfectly reasonable approach to consider.  In addition, sets of 
>users not responding to ECN would seem to be at the fringe of RMCAT's charter.
>
>And so we use the title "Reactions to ECN" to purposely be broad in 
>scope and not just focused on CC algorithms reactions to ECN.  That 
>is why I think this document should stay with TSVWG.  Piers and I 
>will also be participating in RMCAT, so we'll be sure to bring up 
>items that can contribute to the discussion and advancement of RMCAT.
>
>cheers,
>
>-ken
>
>
> > Perhaps we could bounce this question back to you: what is the 
> main single take-home message you want us to get from this draft? 
> THat should decide which WG it's in.
> >
> > I believe the primary message is "TFRC is good enough if you've 
> got ECN, so we can get started without RMCAT if we have ECN." I 
> don't think that's true (as I have been arguing on the list), but I 
> think that's the message the draft is wanting people to hear most. 
> If that were the case, then TSVWG would be reasonable.
> >
> > I would have thought the impact of users not responding to ECN 
> would be just as much in scope for RMCAT as TSVWG (and ConEx is 
> where policing/non-compliance is most being addressed, which is the 
> other side of this problem).
> >
> > Regarding FEC, I think this is a bit of a corner-case in this 
> draft, so I wouldn't decide which WG based on that.
> >
> >
> > Bob
> >
> >> The reason for this line of thoughts is that only a portion of 
> the ECN Reactions draft deals with congestion control 
> algorithms.  And while RMCAT talks about the generic term of 
> "mechanisms" in its charter, the heart of the charter and 
> deliverables seems to focus on algorithms, which is really just one 
> type of mechanism.  On the other hand, the Reactions draft looks 
> into other "mechanisms" like FEC, signaling, and most importantly, 
> the impact of a set of users not responding to ECN.  And its this 
> last item where we bring in some simulation work and is probably 
> the strongest reason (ie, the simulation results) as to why its 
> beneficial to have this in an IETF document.  And its these other 
> items that seem out of scope of RMCAT.
> >>
> >> Assuming this draft is accepted as a working group item in 
> TSVWG, I would also want to send the document to RMCAT for review 
> when we get to a WG last call for comments stage, though I sure the 
> core set of folks will be attending both sets of meetings and mailing lists.
> >>

---

From: ken carlberg <[email-masked]>
Date: Fri, 26 Oct 2012 12:01:13 -0400

I'm sorry, but i think you need to take a little more time in reading the related threads as well as the draft.

> I have read the document and only now got around to look at the thread. The view that I got from reading the document seems to match a lot of the criticism that this draft is receiving.
> 
> One first concern is: the draft seems to consist of one recommendation (using TFRC),

As I told Bob previously, the draft is *not* meant to be a recommendation.  It is meant to discuss the various reactions that can be used with ECN signaling -- and I'll add that we wanted to add some insight as well.  And with respect to TFRC, we are *not* recommending its use as the default CC algorithm as stipulated in rfc-6679.  If you look carefully at the *end* of this paragraph...

   However it should be noted that TFRC is only recommended for real-time
   media use with ECN response. TFRC is not recommended for non-ECN paths
   due to its loss based operation which leads to full queues with
   maximised latencies. It is assumed that ECN markings will usually occur
   with lower queue occupancy and thus lower latency. However it is
   understood that ECN marks may not provide for sufficiently low
   latencies in some situations so other congestion control solutions
   would be preferable.

...we state that "other congestion control solutions would be preferable".  The paragraph is meant to be read and taken as a whole. What we can do, based on Bob's initial feedback, is to add/alter the first part of the paragraph to reinforce the understanding that TFRC is one example of a CC algorithm.

> and a ton of ideas (using DiffServ, using RSVP, using FEC, whatnot). I think that listing all the possible ideas of things one could possibly do in response to an ECN-mark is pretty pointless. Why not add NSIS? Why not change the packet size in response to ECN? Why not stop the flow if there is heavy congestion? And (rinse and) repeat? Why not change this in the codec, this in the codec, that in the codec? It's really an endless list!

how many implementations by vendors have you seen of NSIS?  Which vendors dynamically change packet size due to loss?  Perhaps I'm long on the tooth, but I've seen *deployed* implementations (outside of the research/academic lab) of diff-serv, RSVP, FEC, and CODECS producing different load rates, along with a number of protocols associated with these designs.  NSIS is an experimental protocol, which I didn't feel comfortable including in the list, but if you feel differently, I'll be happy to read any text you'd like to propose.

> So, why are the "ideas" only listed as such, and not as recommendations? Because you don't back them up with enough "meat" to make them recommendable. There's a ton of literature out there, on all these things - if you find something in it that lets you make a recommendation, go ahead, but as long as the things seem fishy to you, I would refrain from listing them because they end up being useless to the reader, too. (note, I have nothing against recommending things other than "let's just use TFRC", if this is convincingly written, based on citations to documents that make it clear that these things are indeed good ideas).

see above.  And if your sole interest is to see a set of recomendations, I would suggest writing your own document and I'll be happy to review it with the same courtesy that you have shown.  But complaining about something that the document is not meant to be is a bit pointless.

> As for the simulation study, this looks pretty useless. It doesn't have enough details to be repeatable (e.g., the queue length is missing, and "RED parameters as recommended by Sally Floyd" isn't quite telling us all we need to know, either (e.g., gentle mode used or not?) ). As Bob has pointed out, it's also only one specific scenario, omitting other possible situations... if the point of documenting a simulation is just to illustrate a case with numbers to be able to explain them better, then that may be okay to have in a draft, but if the point is to justify a decision, as here, this would be better published in a paper, after peer review, and then cited, I think.

we shall add more information about the simulation, and see about expanding its scope.  As for the scenario, yes, it is speciic because its reflective of what we've come across in the real world instead of simply an academic paper exercise.

<snip snip>

kindest regards,

-ken

---

From: ken carlberg <[email-masked]>
Date: Fri, 26 Oct 2012 12:42:46 -0400

Bob,

> Ken,
> 
> Now I understand where you're coming from (which wasn't clear BTW) I can start to bite on your question...
> 
> Changing codecs is driven by a cc algo,

yes and no.  In RMCAT, and what its trying to accomplish, I would wholeheartedly agree.  How this is done can still be an open question, but we are in agreement that this approach is reasonable.  Another approach to take is to simply key off the presence of congestion (loss, or CE feedback) and swap codecs to one that produces an average lower tx rate without reliance on a particular CC algo.  Now, before you express your heartburn at that idea, I'm not advocateing (or recommending :-) this idea.  I'm just pointing out what others are considering.  There is an ITU document being written on this approach, and I'm waiting for it to sttle down a bit before I include it as a reference.

And i know in a previous response to Piers that you're not keen on citing work from outside the IETF.  But I think we want to do this so that "our" community is aware of what's being proposed, or can be considered, so that we can provide our own response (like this is a bad idea for these specific reasons, blah, blah, blah).

> it's just an algo with a discrete output, not a continuous output. One can think of it like an internal continuous rate-vs-congestion response that drives step rate changes - once it has remained below or above a codec-change threshold for sufficiently long. Sometimes they are actually written like that. Other times they are driven by hi/lo watermarks in the playout buffer.
> 
> But these are cc algorithms all the same. So if you think cc algos should go in RMCAT, then this should, because that is the main meat of this draft.

again, the purpose of the reactions draft is to point out one's options and not be solely constrained with CC algorithms.  I do agree what what you say above, and this should find its way in another more focused document in RMCAT.

> Indeed, I imagine most of the RMCAT output will be targetted at codecs with discrete steps in spatial & temporal resolution.
> 
> THe emergency comms section (5.3) is merely a different degree of cc response, so it ought to be under "CC ALgos" (section 3), not "Other responses" (section 5).

well, we could split the "other responses" into a subsection that describes a less aggressive CC algo into section 3, and a rationale behind it. I need to give this more thought. 

> On the other kitchen sink of responses (triggering RSVP, Diffserv, Redundancy, FEC etc), I'm with Michael W. If you're just listing what implementers might do, then it has little value. If you're recommending what implementers shouldn't do or what they should, it would be worth keeping these. But none of these other responses you list seem to be that prevalent, important or practical.

I think what is missing in those sections is more discussion about the pro's and con's of the various approaches.  For example, (a) the need for, and difficulty in achieving, transitive trust between nodes under different administrative control for diff-serv code points, or on the other hand (b) the added value of adding markings to packets that could influence downstream traffic engineering on an as-needed basis.  I prefer to stay away from recomendations because that can be entirely scenario and user-group specific.  

> If a codec isn't using RSVP, but the going gets tough part-way through, calling to RSVP for help would be a bit like a ship-wreck victim praying for a miracle to save them :) If RSVP is available on a particular network (<1% chance), and specific apps have been written to use it but they start-out not using it (<1% * <1%), I don't see it will help commentating on that remote possibility in this draft.
> 
> Similarly, nowadays, nearly always where Diffserv is used, the network decides to apply the markings at the edge, not the host. So if there were a case where the network took account of host-initiated Diffserv markings (<1% chance), and specific apps have been written to use it but they start-out not using it (<1% * <1%), I don't see it will help commentating on that remote possibility in this draft.
> 
> And I've already said the ECN + (Redundancy or FEC) items are pretty much corner-cases too.

agreed, these are corner cases.  But I'm inclined to come across these corner cases in real life, and i think we make a mistake in ignoring them.  They do exist, but just not in the scale that many others come across.

cheers,

-ken

---

From: Michael Welzl <[email-masked]>
Date: Sat, 27 Oct 2012 10:54:52 +0200

Hi,

On Oct 26, 2012, at 6:01 PM, ken carlberg wrote:

> I'm sorry, but i think you need to take a little more time in  
> reading the related threads as well as the draft.

I have given the draft a close read. It should be self-contained.

>> thread. The view that I got from reading the document seems to  
>> match a lot of the criticism that this draft is receiving.
>>
> As I told Bob previously, the draft is *not* meant to be a  
> recommendation.  It is meant to discuss the various reactions that  
> can be used with ECN signaling -- and I'll add that we wanted to add  
> some insight as well.  And with respect to TFRC, we are *not*  
> recommending its use as the default CC algorithm as stipulated in  
> rfc-6679.  If you look carefully at the *end* of this paragraph...

"Not meant to be a recommendation": Here's the first sentence of your  
abstract:
"This document presents recommendations for response to Congestion  
Experience (CE) notifications by real time applications that have  
negotiated end-to-end support of Explicit Congestion Notification  
(ECN)."

So it's obvious that, upon reading it, I believe the draft is meant to  
be a recommendation, no?

> ...we state that "other congestion control solutions would be  
> preferable".  The paragraph is meant to be read and taken as a  
> whole. What we can do, based on Bob's initial feedback, is to add/ 
> alter the first part of the paragraph to reinforce the understanding  
> that TFRC is one example of a CC algorithm.

I got that. I agree, however, with Bob's point that you can't really  
expect ECN marking to lead to less delay (sure, AQMs might not follow  
RFC 3168, but that's rather speculative I guess? If it's not, a  
reference would be good).

>> and a ton of ideas (using DiffServ, using RSVP, using FEC,  
>> whatnot). I think that listing all the possible ideas of things one  
>> could possibly do in response to an ECN-mark is pretty pointless.  
>> Why not add NSIS? Why not change the packet size in response to  
>> ECN? Why not stop the flow if there is heavy congestion? And (rinse  
>> and) repeat? Why not change this in the codec, this in the codec,  
>> that in the codec? It's really an endless list!
>
> how many implementations by vendors have you seen of NSIS?  Which  
> vendors dynamically change packet size due to loss?  Perhaps I'm  
> long on the tooth, but I've seen *deployed* implementations (outside  
> of the research/academic lab) of diff-serv, RSVP, FEC, and CODECS  
> producing different load rates, along with a number of protocols  
> associated with these designs.  NSIS is an experimental protocol,  
> which I didn't feel comfortable including in the list, but if you  
> feel differently, I'll be happy to read any text you'd like to  
> propose.

My point was just that DiffServ, RSVP, .... looks like a list of  
random ideas to me. If your basis for presenting them as possible  
reactions to ECN is that they are deployed, then what you're  
presenting is a survey of deployed work, which may have its own merits  
- but then this should be listed as such, with appropriate references  
wherever possible.

>> recommendations? Because you don't back them up with enough "meat"  
>> to make them recommendable. There's a ton of literature out there,  
>> on all these things - if you find something in it that lets you  
>> make a recommendation, go ahead, but as long as the things seem  
>> fishy to you, I would refrain from listing them because they end up  
>> being useless to the reader, too. (note, I have nothing against  
>> recommending things other than "let's just use TFRC", if this is  
>> convincingly written, based on citations to documents that make it  
>> clear that these things are indeed good ideas).
>
> see above.  And if your sole interest is to see a set of  
> recomendations, I would suggest writing your own document and I'll  
> be happy to review it with the same courtesy that you have shown.   
> But complaining about something that the document is not meant to be  
> is a bit pointless.

I agree with you that it's pointless to complain about something that  
the document is not meant to be.

This is really the key issue here, I don't understand the purpose of  
this draft. I mean, yes, you have clearly stated that this is a follow- 
on effort of RFC6679, but why should anyone read it, and what should  
that person learn from it?
It seems to me now that your draft is recommending one behavior and  
surveying some other implemented alternatives with a critical  
discussion of their value. Is that what it is? Then just state that.  
Personally, I'm not sure if the survey of implemented stuff is very  
useful unless it is an experience report, i.e. "this has been found to  
work well, as documented here..." and "this has been found to work  
poorly, as documented there...".

Cheers,
Michael

---

From: <[email-masked]>
Date: Mon, 29 Oct 2012 09:19:49 +0100

Ken,

my expertise is with QoS. I side with Michael and Bob that your document is not very helpful if it is a list with possible maybe-measures how to deal with congestion for real time applications. As mentioned earlier, PCN offers mechanisms with a scope on real tim,e services at least. So just stating "remark to another DSCP" doesn't seem to bother to provide an argument as we've looked into PCN and don't think it's useful. A review of the state of the art to me seems to be the least a what a reader may expect. Take PCN as an example, there's more to review today if it comes to QoS.

Regards,

Rüdiger

[snip]

[Bob]
> On the other kitchen sink of responses (triggering RSVP, Diffserv, Redundancy, FEC etc), I'm with Michael W. If you're just listing what implementers might do, then it has little value. If you're r…

[Ken]

[snip]

---

From: <[email-masked]>
Date: Mon, 29 Oct 2012 09:25:50 +0100

Ken,

You've asked: Which vendors dynamically change packet size due to loss?

http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.161.226&rep=rep1&type=pdf

http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.161.5738&rep=rep1&type=pdf

If the links don't work, type in "Skype" and "Congestion" in citeseer or look for authors Dario Bonfiglio, Marco Mellia, Michela Meo, Nicolò Ritacca, Dario Rossi or Luca De Cicco, Saverio Mascolo, Vittorio Palmisano.

Regards, Rüdiger

> and a ton of ideas (using DiffServ, using RSVP, using FEC, whatnot). I think that listing all the possible ideas of things one could possibly do in response to an ECN-mark is pretty pointless. Why…

Ken:

---

From: ken carlberg <[email-masked]>
Date: Mon, 29 Oct 2012 05:49:12 -0400

> "Not meant to be a recommendation": Here's the first sentence of your abstract:
> "This document presents recommendations for response to Congestion Experience (CE) notifications by real time applications that have negotiated end-to-end support of Explicit Congestion Notification (ECN)."
> 
> So it's obvious that, upon reading it, I believe the draft is meant to be a recommendation, no?

A good catch, which is appreciated, but no.  In previous versions of the draft, we had made a recommendation of using TFRC as *the* default CC algo discussed in rfc-6679.  The rationale was that there was some measure of implementation of TFRC and that we had an RFC to point to.  Feedback during meetings about this recommendation appeared to be in the form of tepid agreement and disagreement.  But our concerns about TFRC and the work ramping up for RMCAT made it seem that it was best to remove the recomendation and point to RMCAT.

As you will have noticed further into the reactions draft, we state a couple of times where in bringing up a type of reaction, we also bring up some issues to consider, but we refrain from giving specific recomendations.  Andas I stated to Bob, we can add more text (experience, best common practice, insights -- like what Ruediger brought up earlier in this discussion) on some of the various reactions we bring up.

So again, thanks for the catch and we scrub the abstract more cleanly next time.

> I got that. I agree, however, with Bob's point that you can't really expect ECN marking to lead to less delay (sure, AQMs might not follow RFC 3168, but that's rather speculative I guess? If it's not, a reference would be good).

I couldn't give a definitive answer to your question.  I think the answer comes from how the CC algo's in RMCAT are designed and the results we see in their simulation/implementation.

I think I've responded to the rest of your comments in a previous response to Bob's email.

cheers,

-ken

> My point was just that DiffServ, RSVP, .... looks like a list of random ideas to me. If your basis for presenting them as possible reactions to ECN is that they are deployed, then what you're presenting is a survey of deployed work, which may have its own merits - but then this should be listed as such, with appropriate references wherever possible.
> 
> 
> I agree with you that it's pointless to complain about something that the document is not meant to be.
> 
> This is really the key issue here, I don't understand the purpose of this draft. I mean, yes, you have clearly stated that this is a follow-on effort of RFC6679, but why should anyone read it, and what should that person learn from it?
> It seems to me now that your draft is recommending one behavior and surveying some other implemented alternatives with a critical discussion of their value. Is that what it is? Then just state that. Personally, I'm not sure if the survey of implemented stuff is very useful unless it is an experience report, i.e. "this has been found to work well, as documented here..." and "this has been found to work poorly, as documented there...".
> 
> 
> Cheers,
> Michael
>

---

From: ken carlberg <[email-masked]>
Date: Mon, 29 Oct 2012 05:57:43 -0400

Ruediger,

yes, a fair point. we'll add some more insight into the impact and possibly pro's/con's of various type of reactions.

And just to reinterate a point that I tried to make earlier in this discussion.  The fact that industry (vendors and providers) *are* doing work on reactions other than, and not related to, using CC algo in response to ECN signaling is a kind of reality check that we need to be aware of and provide insight where we can.

cheers,

-ken

---

From: ken carlberg <[email-masked]>
Date: Mon, 29 Oct 2012 05:58:52 -0400

Excellent.  Cool stuff.

-ken

---

From: Piers O'Hanlon <[email-masked]>
Date: Tue, 30 Oct 2012 12:40:50 +0000

Hi,

Thanks for your comments on the draft. Since Ken has addressed most of your issues I thought I'd add a reference in response to your question on RED and media flows below.

On 27 Oct 2012, at 09:54, Michael Welzl wrote:
[snip]

> I got that. I agree, however, with Bob's point that you can't really expect ECN marking to lead to less delay (sure, AQMs might not follow RFC 3168, but that's rather speculative I guess? If it's n…
There has been some work done in this area - see for example:
J.M. Pitts, X. Wang, Q. Yang, and J.A. Schormans, Excess-rate queuing theory for M/M/1/RED with application to VoIP QoS, IET Electronics Letters, 28 September 2006, Vol. 42, No. 20, pp.1188-1189
http://academic.research.microsoft.com/Publication/26843304/excess-rate-queuing-theory-for-m-m-1-red-with-application-to-voip-qos