Subject: Re: [rmcat] MW's review of draft-ietf-rmcat-cc-requirements-00

From: Zaheduzzaman Sarker <[email-masked]>
Date: Mon, 2 Dec 2013 17:12:42 +0100

On 2013-11-25 11:28, Michael Welzl wrote:

>
> => I think this goes into too much detail and leaves too many
> questions open. Don't get me wrong, the things you say here are good
> "food for thought" for the group, but as we make progress towards a
> real requirements document most of the text in section 2 is probably
> useless. We need to specify something that we require, and agree on
> something here.
+1
>
> I tried to address this with my previous email to the list with
> subject "Fairness". Let's see what happens.
>
>
> 3. is about coupled congestion control. I think that the right way to
> specify this requirement is to point to the other document (whatever
> document that will be). Say that "the algorithm should be able to be
> interoperate with the mechanism that couples the congestion control
> of flows traversing the same bottleneck, specified in draft-YZ." and
> not more than that.
I am not really sure about the "not more than that" part. A solution can 
within itself have mechanisms to use information across multiple flow 
and handle the rate control efficiently. To me we should allow both use 
of cross traffic information internally and via some external mechanism.

BR

Zahed

-- 

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 Welzl <[email-masked]>
Date: Wed, 4 Dec 2013 13:10:59 +0100

> I am not really sure about the "not more than that" part. A solution can within itself have mechanisms to use information across multiple flow and handle the rate control efficiently. To me we should allow both use of cross traffic information internally and via some external mechanism.

It's a possiblity, but certainly nothing worth *requiring*. Else, why do we write the other document at all?

Cheers,
Michael

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Wed, 4 Dec 2013 14:47:13 +0100

On 2013-12-04 13:10, Michael Welzl wrote:
> It's a possiblity, but certainly nothing worth *requiring*.Else, why do we write the other document at all?

I believe the requiring part is the "merge of information across the 
flows" and how does the algorithm realizes that requirement is up to the 
respective designers. They can invent their own as a part of the 
solution or they can point to the some external mechanism.

or

do you think we should create a requirement to justify other documents?

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: Michael Welzl <[email-masked]>
Date: Wed, 4 Dec 2013 14:59:17 +0100

On 4. des. 2013, at 14:47, Zaheduzzaman Sarker <[email-masked]> wrote:

> I believe the requiring part is the "merge of information across the flows" and how does the algorithm realizes that requirement is up to the respective designers. They can invent their own as a part of the solution or they can point to the some external mechanism.

Agreed. But hopefully anything other than using the external mechanism won't buy you much, or else that other mechanism isn't very useful.

> do you think we should create a requirement to justify other documents?

Clearly not. My concern was to say "an algorithm must take care of cc-coupling" while we have another document describing a mechanism that does cc-coupling, because that implicitly assumes that the other document is worthless and everyone is required to build their own, better solution. But yes, you can have algorithm-specific ways of sharing things and could then do better than a more generic external mechanism perhaps.

Cheers,
Michael

---

From: Randell Jesup <[email-masked]>
Date: Sat, 21 Dec 2013 03:39:08 -0500

Note: comments based on work-in-progress including edits for Bill Ver 
Steeg's comments.

On 11/25/2013 5:28 AM, Michael Welzl wrote:
> Hi,
>
> I'm sending my comments on this draft now, as I think they're largely orthogonal to Bill's:
>
>
> Abstract: "needs by low-delay" seems broken. I'd end this (the second) sentence after "Web pages".  (strange to say "the TCP algorithms" and unnecessary anyway I think.

done

> 1. Intro: ' "as fast as possible" mode' is weird, somehow fix this wording please.

done

> 2. (fairness)
>
> => I think this goes into too much detail and leaves too many questions open. Don't get me wrong, the things you say here are good "food for thought" for the group, but as we make progress towards a real requirements document most of the text in section 2 is probably useless. We need to specify something that we require, and agree on something here.
>
> I tried to address this with my previous email to the list with subject "Fairness". Let's see what happens.

Removed sub-bullets.

> 3. is about coupled congestion control. I think that the right way to specify this requirement is to point to the other document (whatever document that will be). Say that "the algorithm should be able to be interoperate with the mechanism that couples the congestion control of flows traversing the same bottleneck, specified in draft-YZ." and not more than that.

Included reference, some rewording.

> 4. "leverage existing information about the incoming flows" is strange... I think this item is based on a "coupled congestion control" way of thinking, but I think we should really regard the congestion control algorithms as per-flow entities; this gives us a better separation of the problem space, and is more in line with the current proposals too. "packet sizes" seems out of place in the list of "leveraged information", btw, as it's a pre-determined factor that the algorithm simply knows about. The last sentence ("Extra information...") seems unnecessary to me.

Reworked some, moved last sentence into a sub-bullet, "incoming flows" 
-> "incoming flow".

> 8. (interaction with TCP)
> => here I suggested "not starve TCP and not be starved by TCP" in my separate email on "Fairness" to the list. I think that should do it, rather than this somewhat lengthy discussion.

I didn't touch this (yet).  We can discuss more; we may end up yanking 
it for being too like "discussion".

> 9. "stable and low-delay" seems grammatically broken here, and I'd rather avoid mentioning particular AQMs but just say that it should interoperate well with Active Queue Manamagement mechanisms.

Eliminated reference to specific AQMs.

>
> 10. too much detail here, I think - I would assume that the first paragraph, without sub-items a-d, is enough?

I'm on the fence - I don't want some of these issues/options to be 
ignored; for example a flow may have a nascent state where data isn't 
available yet but the algorithm can start gathering data or probing.

>
> 11. There will be a test suite RFC, right? In this case, just like with coupled congestion control, I'd just say that it should work well in accordance with the tests specified in document xy.

I'm not assuming that everything will be tested for or that only those 
things tested should be used in evaluating how well an algorithm meets 
the requirements.

> I hope this is helpful!

Very!

-- 
Randell Jesup -- rjesup a t mozilla d o t com