Subject: [tsvwg] RFC 6077 "Open Research Issues in Internet Congestion Control"

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 24 Mar 2015 22:27:42 +0000

This is probably well-known: Section 3.1 discusses the ICCRG understanding of research challenges for network supported congestion control.

Michael (as co-author)

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 24 Mar 2015 18:12:48 -0500

Hi, Michael,

On Tue, Mar 24, 2015 at 5:27 PM, Scharf, Michael (Michael) <
[email-masked]> wrote:

> This is probably well-known: Section 3.1 discusses the ICCRG understanding
> of research challenges for network supported congestion control.

It wasn't well known to me :-)

It was published while I was dorking around on the IAB, and not paying much
attention to transport issues because I was paying attention to other stuff.

Thank you for the pointer.

Spencer

---

From: Michael Welzl <[email-masked]>
Date: Wed, 25 Mar 2015 00:00:22 -0500

FWIW, the document also (in summarizing a long discussion that happened when ICCRG started) defines what "congestion" and "congestion control" are, in paragraph 2 of the introduction. Useful to have, I think. These definitions reflect the consensus of ICCRG.

Cheers,
Michael

> On 24. mar. 2015, at 18.12, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Michael,
> 
> On Tue, Mar 24, 2015 at 5:27 PM, Scharf, Michael (Michael) <[email-masked]> wrote:
> It was published while I was dorking around on the IAB, and not paying much attention to transport issues because I was paying attention to other stuff.
>

---

From: John Leslie <[email-masked]>
Date: Wed, 25 Mar 2015 08:11:31 -0400

Michael Welzl <[email-masked]> wrote:
> 
> FWIW, the document also (in summarizing a long discussion that happened
> when ICCRG started) defines what "congestion" and "congestion control"
> are, in paragraph 2 of the introduction.
]
] Congestion can be defined as a state or condition that occurs when
] network resources are overloaded, resulting in impairments for
] network users as objectively measured by the probability of loss
] and/or delay.  The overload results in the reduction of utility in
] networks that support both spatial and temporal multiplexing, but no
] reservation [Keshav07].

   This is a bit on the vague side...

   "State or condition" covers a lot of ground.

   "Overloaded" is in the eye of the beholder, unless it means buffer
overflow (which I assume it doesn't in a 2011 document).

   "Objectively measured" means no two persons have to agree.

   "Loss and/or delay" leaves me scratching my head what ECN CE means.

   This "definition" was fine for the purpose of RFC 6077, which was
trying to give an overview of issues related to congestion control.

] Congestion control is a (typically distributed) algorithm to share
] network resources among competing traffic sources.

   I suppose that was a good starting point in 2011...

   Alas, "congestion control" is decidedly not one single algorithm.
It is a melange of signals and reactions to those signals, with no
unified structure.

   Too many folks talk of "congestion control" as if congestion signals
all mean the same thing and all endpoints "should" be doing TCP RENO.

   But in fact, we know that TCP CUBIC is quite common; and ECN CE
_doesn't_ signal the same thing as packet drop. I believe the time has
come to let go of the "everything is TCP RENO" paradigm.

   In any case, RFC 6077 is very much worth reading -- it's just that
I don't find it helpful to extract its definitions for talking about
today's challenges.

--
John Leslie <[email-masked]>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 25 Mar 2015 08:11:51 -0500

> On 25. mar. 2015, at 07.11, John Leslie <[email-masked]> wrote:
> 

I wrote the above paragraph in this email with you in mind   :-)   as I noticed that you repeatedly bring this point up.

So, note that, whatever you may think of this definition:
- it was discussed to death when ICCRG began
- as I also wrote above, the definition in RFC 6077 represents the consensus of ICCRG - the outcome of all this discussion.

You may like it or not, but perhaps we just shouldn't debate how congestion and congestion control should be defined until the end of time.

Cheers,
Michael

---

From: John Leslie <[email-masked]>
Date: Wed, 25 Mar 2015 11:11:07 -0400

Michael Welzl <[email-masked]> wrote:
> I wrote the above paragraph in this email with you in mind   :-) 
> as I noticed that you repeatedly bring this point up.

   Guilty as charged...

> - as I also wrote above, the definition in RFC 6077 represents the  
>   consensus of ICCRG - the outcome of all this discussion.

   Yes.

   But this is not <iccrg> in 2011.

   I chose not to argue this on the <iccrg> list -- although I quite
honestly believe our 2011 view of "congestion" is getting long-in-the-
tooth.
 
> You may like it or not, but perhaps we just shouldn't debate how
> congestion and congestion control should be defined until the end of
> time.

   I'm perfectly willing to avoid defining "congestion" completely --
if we'd agree to stop using the word to mean different things.

   (Seriously, our problem might be simply that we have too many folks
playing Humpty-Dumpty, while the rest of us have tired of arguing what
the word means.)

   (BTW, it is _not_ a given that an IRTF definition is binding on IETF
working-groups.)

   I responded to your post -- not because I think we need a good
definition in TSVWG right now -- but because I thought it might be
helpful for folks to think about some of the weaknesses of that
definition.

   If you wish to argue that no such weaknesses exist, that could be
a helpful way forward. Otherwise, I see no need to argue the definition
in TSVWG at this time.