IMCC - Interactive Media Congestion Control On Tue, Aug 7, 2012 at 9:15 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
It's an old IETF meme that if you want lots of people to comment, one should start discussing the name of something (protocol, WG, it doesn't matter).
I've got a page on the site for this subject:
http://rtp-congestion.alvestrand.com/bof-planning-page/naming
I've added IRCC to the suggestion list.
On 08/07/2012 09:10 PM, Mo Zanaty (mzanaty) wrote:
I'm glad John mentioned the proposed WG name. - I think IRCC (Interactive RTP Congestion Control) may be better than RMCAT. - Congestion control seems to have become the more common general term, with congestion avoidance often associated with a particular phase/state of overall TCP congestion control. We're not working on TCP, but readers of our charter and drafts will likely be well-versed in TCP CC/CA. - "Media" and "Techniques" seem superfluous. What RTP payloads are we trying to exclude by explicitly saying "Media"? - Interactive is missing, since we are explicitly excluding non-interactive RTP (e.g. highly buffered streaming applications).
So I would prefer the WG name to be IRCC (Interactive RTP Congestion Control), and the charter to talk in terms of congestion control. We will obviously have a control loop, and its time constant may be short or long, depending on the final solution(s), but it's still a control loop at any timescale.
Mo
-----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of John Leslie Sent: Tuesday, August 07, 2012 8:35 AM To: Harald Alvestrand Cc: rtp-congestion@alvestrand.no Subject: Re: [R-C] Charter -> congestion avoidance vs. congestion control?
Harald Alvestrand <harald@alvestrand.no> wrote:
When I first learned networking ~30 years ago, "congestion avoidance" was the term used when you managed things so that congestion at the media level could never happen (token ring, ATM), while "congestion control" was the whole area of what you did either to avoid congestion or to deal with it once it happened.
30-years? A newcomer!!
IMHO, both terms are kind of accidental -- congestion can only be prevented if you know the entire path a packet will follow. "Congestion control" is the term applied to the AIMD algorithm for TCP: IMHO to indicate a control loop. But we could just as well have talked of it as "congestion avoidance" since what it actually did is avoid sending data into a path believed to be congested.
"Congestion control" has always struck me as an optimistic name -- but then, _all_ names are optimistic! IMHO, what we will do for congestion-management in RMCAT will look even less like a tight control loop.
So I'd prefer "congestion control", since congestion is a fact of life; we're dealing with it, not avoiding it at all cost - but I'm a bit old-fashioned.
Congestion which drives up delay will _need_ to be avoided in RMCAT. "Congestion avoidance" to me has never meant "at all cost", but YMMV. Myself, I'm more sensitive to any suggestion that RMCAT can "control" overall congestion. We're going to find ourselves at the mercy of and competing TCP streams (which will always try to fill the pipe); and if we have any way to "control" them, it's not obvious to me.
But perhaps the final argument is our name:
RTP Media Congestion Avoidance Techniques (RMCAT)
-- John Leslie <john@jlc.net> _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Saverio Mascolo, Full Professor Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo@poliba.it http://c3lab.poliba.it ================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden.