<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">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).<br>
      <br>
      I've got a page on the site for this subject:<br>
      <br>
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <a
        href="http://rtp-congestion.alvestrand.com/bof-planning-page/naming">http://rtp-congestion.alvestrand.com/bof-planning-page/naming</a><br>
      <br>
      I've added IRCC to the suggestion list.<br>
      <br>
      On 08/07/2012 09:10 PM, Mo Zanaty (mzanaty) wrote:<br>
    </div>
    <blockquote
cite="mid:3879D71E758A7E4AA99A35DD8D41D3D90F569BE6@xmb-rcd-x14.cisco.com"
      type="cite">
      <pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:rtp-congestion-bounces@alvestrand.no">rtp-congestion-bounces@alvestrand.no</a> [<a class="moz-txt-link-freetext" href="mailto:rtp-congestion-bounces@alvestrand.no">mailto:rtp-congestion-bounces@alvestrand.no</a>] On Behalf Of John Leslie
Sent: Tuesday, August 07, 2012 8:35 AM
To: Harald Alvestrand
Cc: <a class="moz-txt-link-abbreviated" href="mailto:rtp-congestion@alvestrand.no">rtp-congestion@alvestrand.no</a>
Subject: Re: [R-C] Charter -> congestion avoidance vs. congestion control?

Harald Alvestrand <a class="moz-txt-link-rfc2396E" href="mailto:harald@alvestrand.no"><harald@alvestrand.no></a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">
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.
</pre>
      </blockquote>
      <pre wrap="">
   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.

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
   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 <a class="moz-txt-link-rfc2396E" href="mailto:john@jlc.net"><john@jlc.net></a>
_______________________________________________
Rtp-congestion mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rtp-congestion@alvestrand.no">Rtp-congestion@alvestrand.no</a>
<a class="moz-txt-link-freetext" href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion">http://www.alvestrand.no/mailman/listinfo/rtp-congestion</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>