Hi all, There were two minimal changes to the charter, which is at: https://sites.google.com/a/alvestrand.com/rtp-congestion/bof-planning-page/w... It now explicitly says that the following are out of scope: * Active queue management; modifications to TCP of any kind; and * Multicast congestion control (common control of multiple unicast flows is in scope). Other than that, the charter hasn't changed since the last version that was sent around in May. Cheers, Michael
Hi, one more comment regarding the charter. I was wondering if there is a difference between congestion avoidance and congestion control. I would say congestion avoidance is the more general term, while congestion control implies some kind of control loop. In case of real-time media traffic, as we have specific traffic characteristics, we might end up with something that e.g. only switches between certain pre-defined rate depending on feedback that we maybe get (only) once per RTT. This is quite different form current (TCP) congestion control where you calculate the sending rate based on continuous feedback (assuming you have more or less all the time data to send). Would we consider both as congestion control or only the latter case which is TCP-like congestion control? I would propose to only talk about congestion avoidance in the charter to make sure that we not only aim for TCP-like congestion control but also a solution as described above would be in the charter. Mirja On Thursday 02 August 2012 19:12:30 Michael Welzl wrote:
Hi all,
There were two minimal changes to the charter, which is at: https://sites.google.com/a/alvestrand.com/rtp-congestion/bof-planning-page/ wg-charter---input-to-vancouver
It now explicitly says that the following are out of scope: * Active queue management; modifications to TCP of any kind; and * Multicast congestion control (common control of multiple unicast flows is in scope).
Other than that, the charter hasn't changed since the last version that was sent around in May.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- ------------------------------------------------------------------- Dipl.-Ing. Mirja Kühlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de -------------------------------------------------------------------
Hi, That request seems easy to accommodate, and if it avoids misunderstandings then that's good. Thanks for your input! Cheers, Michael PS: I hope I'll have a charter update + the meeting minutes available soon; stay tuned... On 6. aug. 2012, at 14:47, Mirja Kuehlewind wrote:
Hi,
one more comment regarding the charter. I was wondering if there is a difference between congestion avoidance and congestion control. I would say congestion avoidance is the more general term, while congestion control implies some kind of control loop.
In case of real-time media traffic, as we have specific traffic characteristics, we might end up with something that e.g. only switches between certain pre-defined rate depending on feedback that we maybe get (only) once per RTT. This is quite different form current (TCP) congestion control where you calculate the sending rate based on continuous feedback (assuming you have more or less all the time data to send). Would we consider both as congestion control or only the latter case which is TCP-like congestion control?
I would propose to only talk about congestion avoidance in the charter to make sure that we not only aim for TCP-like congestion control but also a solution as described above would be in the charter.
Mirja
On Thursday 02 August 2012 19:12:30 Michael Welzl wrote:
Hi all,
There were two minimal changes to the charter, which is at: https://sites.google.com/a/alvestrand.com/rtp-congestion/bof-planning-page/ wg-charter---input-to-vancouver
It now explicitly says that the following are out of scope: * Active queue management; modifications to TCP of any kind; and * Multicast congestion control (common control of multiple unicast flows is in scope).
Other than that, the charter hasn't changed since the last version that was sent around in May.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- ------------------------------------------------------------------- Dipl.-Ing. Mirja Kühlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart
tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de -------------------------------------------------------------------
i would say congestion is particular part of congestion control. It refers to "gentle" part of the probing, that is done on purpose to avoid congestion (increase the winwow of 1 packet per rtt) Saverii On 8/6/12, Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de> wrote:
Hi,
one more comment regarding the charter. I was wondering if there is a difference between congestion avoidance and congestion control. I would say
congestion avoidance is the more general term, while congestion control implies some kind of control loop.
In case of real-time media traffic, as we have specific traffic characteristics, we might end up with something that e.g. only switches between certain pre-defined rate depending on feedback that we maybe get (only) once per RTT. This is quite different form current (TCP) congestion control where you calculate the sending rate based on continuous feedback (assuming you have more or less all the time data to send). Would we consider both as congestion control or only the latter case which is TCP-like congestion control?
I would propose to only talk about congestion avoidance in the charter to make sure that we not only aim for TCP-like congestion control but also a solution as described above would be in the charter.
Mirja
On Thursday 02 August 2012 19:12:30 Michael Welzl wrote:
Hi all,
There were two minimal changes to the charter, which is at: https://sites.google.com/a/alvestrand.com/rtp-congestion/bof-planning-page/ wg-charter---input-to-vancouver
It now explicitly says that the following are out of scope: * Active queue management; modifications to TCP of any kind; and * Multicast congestion control (common control of multiple unicast flows is in scope).
Other than that, the charter hasn't changed since the last version that was sent around in May.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- ------------------------------------------------------------------- Dipl.-Ing. Mirja Kühlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart
tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de ------------------------------------------------------------------- _______________________________________________ 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.
On 08/06/2012 02:47 PM, Mirja Kuehlewind wrote:
Hi,
one more comment regarding the charter. I was wondering if there is a difference between congestion avoidance and congestion control. I would say congestion avoidance is the more general term, while congestion control implies some kind of control loop. 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.
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. Harald
In case of real-time media traffic, as we have specific traffic characteristics, we might end up with something that e.g. only switches between certain pre-defined rate depending on feedback that we maybe get (only) once per RTT. This is quite different form current (TCP) congestion control where you calculate the sending rate based on continuous feedback (assuming you have more or less all the time data to send). Would we consider both as congestion control or only the latter case which is TCP-like congestion control?
I would propose to only talk about congestion avoidance in the charter to make sure that we not only aim for TCP-like congestion control but also a solution as described above would be in the charter.
Mirja
On Thursday 02 August 2012 19:12:30 Michael Welzl wrote:
Hi all,
There were two minimal changes to the charter, which is at: https://sites.google.com/a/alvestrand.com/rtp-congestion/bof-planning-page/ wg-charter---input-to-vancouver
It now explicitly says that the following are out of scope: * Active queue management; modifications to TCP of any kind; and * Multicast congestion control (common control of multiple unicast flows is in scope).
Other than that, the charter hasn't changed since the last version that was sent around in May.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
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>
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
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
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.
Like! On 8. aug. 2012, at 13:30, Saverio Mascolo wrote:
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
================================= 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. _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
I prefer an explicit reference to RTP (IRCC) not Media (IMCC) in the WG name, since we are explicitly targeting RTP, and plan to extend RTP/RTCP if necessary per the charter. ... The working group will: * Develop a clear understanding of the congestion control requirements for RTP flows, and document deficiencies of existing mechanisms such as TFRC with regards to these requirements. * Define interactions between applications and RTP flows to enable signalling requirements such as per-packet priorities. * Determine if there is an appropriate means to define standard RTP/RTCP extensions for carrying congestion control feedback, similar to how DCCP defines CCIDs, and if so, document such extensions as standards-track RFCs. ... But I understand if that name may irk some folks... :) Mo -----Original Message----- From: Saverio Mascolo [mailto:saverio.mascolo@gmail.com] Sent: Wednesday, August 08, 2012 7:31 AM To: Harald Alvestrand Cc: Mo Zanaty (mzanaty); John Leslie; rtp-congestion@alvestrand.no Subject: Re: [R-C] WG name (Re: Charter -> congestion avoidance vs. congestion control?) 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.
I just liked the sound of Interactive Media; I agree to have "interactive" in the name is good (that's maybe a problem with the RMCAT name). But I should probably add that *I* don't care much about the name. On 8. aug. 2012, at 16:49, Mo Zanaty (mzanaty) wrote:
I prefer an explicit reference to RTP (IRCC) not Media (IMCC) in the WG name, since we are explicitly targeting RTP, and plan to extend RTP/RTCP if necessary per the charter.
... The working group will: * Develop a clear understanding of the congestion control requirements for RTP flows, and document deficiencies of existing mechanisms such as TFRC with regards to these requirements. * Define interactions between applications and RTP flows to enable signalling requirements such as per-packet priorities. * Determine if there is an appropriate means to define standard RTP/RTCP extensions for carrying congestion control feedback, similar to how DCCP defines CCIDs, and if so, document such extensions as standards-track RFCs. ...
But I understand if that name may irk some folks... :)
Mo
-----Original Message----- From: Saverio Mascolo [mailto:saverio.mascolo@gmail.com] Sent: Wednesday, August 08, 2012 7:31 AM To: Harald Alvestrand Cc: Mo Zanaty (mzanaty); John Leslie; rtp-congestion@alvestrand.no Subject: Re: [R-C] WG name (Re: Charter -> congestion avoidance vs. congestion control?)
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
================================= 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. _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
It was pointed out that "fair share when competing with itself" may be a difficult goal, and that "fair share when competing with other protocols" is not likely to be possible. (It certainly is not possible if "other protocol" is unconstrained). I suggest splitting this item into multiples. - fair share when competing with itself - reasonable share when competing with other RT protocols - Idealy (but may not be feasible) a reasonable share when competing with TCP and other protocols. Also, I'm going to keep saying this: - Techniques to detect, instrument or diagnose failing to meet RT schedules due to failures of components out side of the charter scope, possibly in collaboration with IPPM. because this is the key to causing others to change the parts that are out of scope. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Thu, Aug 2, 2012 at 10:12 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi all,
There were two minimal changes to the charter, which is at: https://sites.google.com/a/alvestrand.com/rtp-congestion/bof-planning-page/w...
It now explicitly says that the following are out of scope: * Active queue management; modifications to TCP of any kind; and * Multicast congestion control (common control of multiple unicast flows is in scope).
Other than that, the charter hasn't changed since the last version that was sent around in May.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
I wish to strongly agree with Matt's point about diagnosis: Matt Mathis <mattmathis@google.com> wrote:
- Techniques to detect, instrument or diagnose failing to meet RT schedules due to failures of components out side of the charter scope, possibly in collaboration with IPPM.
(though I think it needs wordsmithing, which I'll tackle in another post.) But first I must tackle some overall points. I've gone over the proposed charter _very_ carefully since Thursday. Overall, I find it is a lot better than I initially thought. However, I will suggest changes which I think make misunderstandings like mine less likely. First, I support Mirja and Michael that it's generally better to say "congestion avoidance" than "congestion control". Specifically under "Description of Working Group": - s/congestion control mechanisms/congestion avoidance mechanisms/ under "The working group will": - s/congestion control requirements/congestion avoidance requirements/ - s/congestion control feedback/congestion feedback/ - s/congestion control algorithms/congestion avoidance algorithms/ NB RFC 2914 (congestion control principles): no change under "The following topics are out of scope": No changes under "Deliverables": - s/congestion control algorithms/congestion avoidance algorithms/ - s/congestion control algorithms/congestion avoidance algorithms/ - s/congestion control algorithm/congestion avoidance algorithm/ - s/congestion control algorithms/congestion avoidance algorithms/ - s/congestion control algorithm/congestion avoidance algorithm/ under Milestones: (needs more wordsmithing; I'll leave to another post.) I think we agreed that under "topics out of scope": - s/Active queue management/Requiring Active Queue Management/ (the point being we can't avoid discussing AQM, but we need to live with whatever AQM there is or isn't). Matt again:
It was pointed out that "fair share when competing with itself" may be a difficult goal, and that "fair share when competing with other protocols" is not likely to be possible. (It certainly is not possible if "other protocol" is unconstrained). I suggest splitting this item into multiples. - fair share when competing with itself - reasonable share when competing with other RT protocols - Idealy (but may not be feasible) a reasonable share when competing with TCP and other protocols.
(Presumably Matt meant the second bullet under "set of requirements" gets split into three bullets, making five bullets altogether.) I strongly recommend avoiding the word "fair"; thus I suggest the five bullets read: - Low delay for cases where there is no competing traffic - Reasonable share when competing with RMCAT traffic - Reasonable share when competing with other RT protocols - Reasonable share when competing with TCP-like protocols - Effective use of signals such as ECN and packet loss (I think we must _define_ a "reasonable share" when competing with TCP: but it won't look much like our traditional TCP-friendly definitions.) In case the above isn't sufficient to start some flame-wars, I also strongly suggest adding language better defining the problem, to cover: - RMCAT strongly wants low delay and low jitter - RMCAT can tolerate loss better than high delay - RMCAT prefers consistent bandwidth to inconsistent high bandwidth - we posit that RMCAT can reasonably adjust slower than TCP I'm not at all particular about where that goes, though I feel earlier is better... If we settle on language quickly, I see no reason this couldn't come before the IESG Thursday, August 16, and be approved for External Review. -- John Leslie <john@jlc.net>
On 8/6/2012 10:48 PM, John Leslie wrote:
I wish to strongly agree with Matt's point about diagnosis:
Matt Mathis <mattmathis@google.com> wrote:
- Techniques to detect, instrument or diagnose failing to meet RT schedules due to failures of components out side of the charter scope, possibly in collaboration with IPPM.
(though I think it needs wordsmithing, which I'll tackle in another post.)
But first I must tackle some overall points.
I've gone over the proposed charter _very_ carefully since Thursday. Overall, I find it is a lot better than I initially thought.
That's very good to hear.
However, I will suggest changes which I think make misunderstandings like mine less likely.
First, I support Mirja and Michael that it's generally better to say "congestion avoidance" than "congestion control". Specifically
Sure, this is reasonable.
I think we agreed that under "topics out of scope": - s/Active queue management/Requiring Active Queue Management/ (the point being we can't avoid discussing AQM, but we need to live with whatever AQM there is or isn't).
Agreed totally (I made a similar comment at the mic).
Matt again:
It was pointed out that "fair share when competing with itself" may be a difficult goal, and that "fair share when competing with other protocols" is not likely to be possible. (It certainly is not possible if "other protocol" is unconstrained). I suggest splitting this item into multiples. - fair share when competing with itself - reasonable share when competing with other RT protocols - Idealy (but may not be feasible) a reasonable share when competing with TCP and other protocols.
(Presumably Matt meant the second bullet under "set of requirements" gets split into three bullets, making five bullets altogether.)
I strongly recommend avoiding the word "fair"; thus I suggest the five bullets read: - Low delay for cases where there is no competing traffic - Reasonable share when competing with RMCAT traffic - Reasonable share when competing with other RT protocols - Reasonable share when competing with TCP-like protocols - Effective use of signals such as ECN and packet loss (I think we must _define_ a "reasonable share" when competing with TCP: but it won't look much like our traditional TCP-friendly definitions.)
Sounds good to me. "Fair" is a horribly defined (and loaded) term.
In case the above isn't sufficient to start some flame-wars, I also strongly suggest adding language better defining the problem, to cover: - RMCAT strongly wants low delay and low jitter - RMCAT can tolerate loss better than high delay - RMCAT prefers consistent bandwidth to inconsistent high bandwidth - we posit that RMCAT can reasonably adjust slower than TCP
I'm ok with that. All quite reasonable and may reduce confusion in cases, though it's edging towards solution space.
I'm not at all particular about where that goes, though I feel earlier is better...
If we settle on language quickly, I see no reason this couldn't come before the IESG Thursday, August 16, and be approved for External Review.
Great! -- Randell Jesup randell-ietf@jesup.org
Hi, Thanks for all your inputs! I agree with all of them, from Matt and John, except: (snip, snip...)
In case the above isn't sufficient to start some flame-wars, I also strongly suggest adding language better defining the problem, to cover: - RMCAT strongly wants low delay and low jitter - RMCAT can tolerate loss better than high delay - RMCAT prefers consistent bandwidth to inconsistent high bandwidth - we posit that RMCAT can reasonably adjust slower than TCP
because, indeed, as Randell says, this edges towards a solution space. Low delay has always been there, I added "and low jitter" now - but the other things are assumptions that I think we shouldn't make (in particular the third item). They may or may not be correct, depending on the codec in use, and so this gets too narrow IMO if we write it in the charter. Cheers, Michael
I agree on this input as well, and I particularly like the "reasonable share" parts. On Tue, Aug 7, 2012 at 9:54 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,
Thanks for all your inputs! I agree with all of them, from Matt and John, except:
(snip, snip...)
In case the above isn't sufficient to start some flame-wars, I also strongly suggest adding language better defining the problem, to cover: - RMCAT strongly wants low delay and low jitter - RMCAT can tolerate loss better than high delay - RMCAT prefers consistent bandwidth to inconsistent high bandwidth - we posit that RMCAT can reasonably adjust slower than TCP
because, indeed, as Randell says, this edges towards a solution space. Low delay has always been there, I added "and low jitter" now - but the other things are assumptions that I think we shouldn't make (in particular the third item). They may or may not be correct, depending on the codec in use, and so this gets too narrow IMO if we write it in the charter.
In addition this is not only focused on video or audio streams, but also data streams which may prefer inconsistent high bandwidth than a lower consistent bandwidth.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Stefan Holmer <stefan@webrtc.org> wrote:
On Tue, Aug 7, 2012 at 9:54 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
Thanks for all your inputs! I agree with all of them, from Matt and John, except: ... [John Leslie wrote:]
In case the above isn't sufficient to start some flame-wars, I also strongly suggest adding language better defining the problem, to cover: - RMCAT strongly wants low delay and low jitter - RMCAT can tolerate loss better than high delay - RMCAT prefers consistent bandwidth to inconsistent high bandwidth - we posit that RMCAT can reasonably adjust slower than TCP
because, indeed, as Randell says, this edges towards a solution space. Low delay has always been there, I added "and low jitter" now - but the other things are assumptions that I think we shouldn't make (in particular the third item). They may or may not be correct, depending on the codec in use, and so this gets too narrow IMO if we write it in the charter.
I'm not particular about the wording, but I think the charter needs at least a hint that the congestion-avoidance aims are different than TCP.
In addition this is not only focused on video or audio streams, but also data streams which may prefer inconsistent high bandwidth than a lower consistent bandwidth.
Indeed, there may be data streams included which would prefer TCP congestion-management rules; but these _are_ under our control, and almost by definition are incidental to the overall RMCAT congestion issues. We can give them incidental (arguably spare) bandwidth while still keeping our delay low. (I'm quite happy to let Michael wordsmith how big the hint should be: I just don't want to abandon mention of the differing aims.) -- John Leslie <john@jlc.net>
Although I like the seeming simplicity of "congestion avoidance", that precise pair of words is used to refer to the +1 per RTT behavior of TCP during the AIMD sawtooth. How about just "avoid congestion", which has a similar sense but is less specific and unlikely to cause any confusion. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Tue, Aug 7, 2012 at 6:10 AM, John Leslie <john@jlc.net> wrote:
Stefan Holmer <stefan@webrtc.org> wrote:
On Tue, Aug 7, 2012 at 9:54 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
Thanks for all your inputs! I agree with all of them, from Matt and John, except: ... [John Leslie wrote:]
In case the above isn't sufficient to start some flame-wars, I also strongly suggest adding language better defining the problem, to cover: - RMCAT strongly wants low delay and low jitter - RMCAT can tolerate loss better than high delay - RMCAT prefers consistent bandwidth to inconsistent high bandwidth - we posit that RMCAT can reasonably adjust slower than TCP
because, indeed, as Randell says, this edges towards a solution space. Low delay has always been there, I added "and low jitter" now - but the other things are assumptions that I think we shouldn't make (in particular the third item). They may or may not be correct, depending on the codec in use, and so this gets too narrow IMO if we write it in the charter.
I'm not particular about the wording, but I think the charter needs at least a hint that the congestion-avoidance aims are different than TCP.
In addition this is not only focused on video or audio streams, but also data streams which may prefer inconsistent high bandwidth than a lower consistent bandwidth.
Indeed, there may be data streams included which would prefer TCP congestion-management rules; but these _are_ under our control, and almost by definition are incidental to the overall RMCAT congestion issues. We can give them incidental (arguably spare) bandwidth while still keeping our delay low.
(I'm quite happy to let Michael wordsmith how big the hint should be: I just don't want to abandon mention of the differing aims.)
-- John Leslie <john@jlc.net> _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Hi all, About congestion control vs. congestion avoidance: my personal opinion was that it's really the same, and using "congestion control" is just fine. I agreed with the suggestion to go for "congestion avoidance" because I didn't care, but Matt's argument convinces me. Indeed, congestion avoidance, as introduced in the seminal paper about that, refers to a phase of TCP, and is hence a bit misleading. It's possible that this charter could be interpreted to mean that we're really only interested in replacing this specific phase of TCP, but keep the rest (slow start etc.) for interactive real-time apps. Congestion control clearly refers to the whole thing, and so I went back to that wording now. (just using "avoid congestion" is a more significant change to the text). About John's last suggestion: " I'm not particular about the wording, but I think the charter needs at least a hint that the congestion-avoidance aims are different than TCP." I have now incorporated that, just before the list of requirements; I hope you like the way I phrased it. I think it's high time for me to share my current version, sorry for not having done that up to now - I was expecting to do internal updates first and then start the wordsmithing, but you guys seem to be fully at it already :-) I'm attaching a pdf of a version I produced with Word, where I added comments about who said what. Not everything is from the mailing list, some things come directly from the BOF. Yes, having the minutes would be helpful too, I know... I hope we'll have them soon. I'm also copy+pasting the whole thing at the bottom of this email in plain text for your convenience - sorry if the formatting turns out strange. Cheers, Michael ************************************ copy+pasted version: Internal comments • The milestones need to be updated (more relaxed - though a suggestion was to finish soon with something that is replaceable...), but let’s perhaps first agree on the rest. RTP Media Congestion Avoidance Techniques (rmcat) Status: Proposed Working Group Last Updated: 2012-08-08 Chair(s): TBD Transport Area Director(s): Wesley Eddy <wes@mti-systems.com> Transport Area Advisor: Wesley Eddy <wes@mti-systems.com> Mailing Lists: TBD (until establishment, we use rtp-congestion@alvestrand.no) Description of Working Group In today's current internet, part of the traffic is delivery of interactive real time media, often in the form of sets of media flows using RTP over UDP. There is no generally accepted congestion control mechanism for this kind of data flow. With the deployment of applications using the RTCWEB protocol suite, the number of such flows is likely to increase, especially non-fixed-rate flows such as video or adaptive audio. There is therefore some urgency in specifying one or more congestion control mechanisms that can find general acceptance. Congestion control algorithms for interactive real time media may need to be quite different from the congestion control of TCP: for examples, some applications can be more tolerant to loss than delay and jitter. The set of requirements for such an algorithm includes, but is not limited to: • Low delay and low jitter for the case where there is no competing traffic using other algorithms • Reasonable share of bandwidth when competing with RMCAT traffic, other real-time media protocols, and ideally also TCP and other protocols • when there is competing traffic using other algorithms • Effective use of signals like packet loss and ECN markings to adapt to congestion The working group will: • Develop a clear understanding of the congestion control requirements for RTP flows, and document deficiencies of existing mechanisms such as TFRC with regards to these requirements. • Define interactions between applications and RTP flows to enable signalling requirements such as per-packet priorities. • Determine if there is an appropriate means to define standard RTP/RTCP extensions for carrying congestion control feedback, similar to how DCCP defines CCIDs, and if so, document such extensions as standards-track RFCs. • Develop techniques to detect, instrument or diagnose failing to meet RT schedules due to failures of components outside of the charter scope, possibly in collaboration with IPPM. • Define evaluation criteria for proposed mechanisms, and publish these as an Informational RFCs. • Find or develop candidate congestion control algorithms, verify that these can be tested on the Internet without significant risk, and publish one or more of these as Experimental RFCs. • Publish evaluation criteria and the result of experimentation with these Experimental algorithms on the Internet • Once an algorithm has been found or developed that meets the evaluation criteria, and has a satisfactory amount of documented experience on the Internet, publish this algorithm as a Standards Track RFC. There may be more than one such algorithm. • Develop a mechanism for jointly controlling multiple flows that may each experience different treatment by the network. The work will be guided by the advice laid out in RFC 5405 (UDP usage guidelines) and RFC 2914 (congestion control principles). The following topics are out of scope: • Circuit-breaker algorithms for stopping media flows when network conditions render them useless; this work is done in AVTCORE; • Media flows for non-interactive purposes like stored video playback; those are not as delay sensitive as interactive traffic; • Defining active queue management; modifications to TCP of any kind; and • Multicast congestion control (common control of multiple unicast flows is in scope). • Topologies other than point-to-point connections. Implications on multi-hop connections will be considered at a later stage. The working group is expected to work closely with the RAI area, including the underlying technologies being worked on in the AVTCORE and AVTEXT WGs, and the applications/protocol suites being developed in the CLUE and RTCWEB working groups. It will also liaise closely with other Transport area groups working on congestion control, and with the Internet Congestion Control Research Group of the IRTF. Deliverables • Requirements for congestion control algorithms for interactive real time media - Informational RFC • Evaluation criteria for congestion control algorithms for interactive real time media - Informational RFC • Define interactions between applications and RTP flows for signaling requirements such as per-packet priorities - Standards-track RFC • RTCP extensions for use with congestion control algorithms - Standards-track RFC • Candidate congestion control algorithm for interactive real time media - Experimental RFCs (likely more than one) • Experimentation and evaluation results for candidate congestion control algorithms - Informational RFC • A recommended congestion control algorithm for interactive real time media - Standards-track RFC • A mechanism for joint control of multiple flows that may each experience different treatment by the network - Standards-track RFC Milestones • NN NNNA: (chartering + 1 month) Publish first drafts of requirements and evaluation criteria • NN NNNB: Adopt first congestion control candidate as WG draft • NN NNNC: (A + 4 months) Submit evaluation criteria to IESG as Informational • NN NNND: (C + 1 month) Submit first congestion control candidate to IESG for Experimental publication • NN NNNE: (D + 3 months) First draft of evaluation results • NN NNNF: (=E) First draft of standars-track congestion control • NN NNNG: (F + 6 months) Submit congestion control to IESG for Proposed Standard (time from chartering to end of charter is 15 months)
participants (9)
-
Harald Alvestrand -
John Leslie -
Matt Mathis -
Michael Welzl -
Mirja Kuehlewind -
Mo Zanaty (mzanaty) -
Randell Jesup -
Saverio Mascolo -
Stefan Holmer