[R-C] proposing a WG on RTP congestion control

Varun Singh vsingh.ietf at gmail.com
Mon Jan 9 15:26:11 CET 2012


Hi Wesley,

The charter looks comprehensive. Apologies for top posting.

need clarification/comment:
- The congestion control for uni-directional media may be different
from bi-directional or conversational media because of relaxed
constraints: timing, buffering and available repair mechanisms,
rate-switching etc. Should the charter clarify if it is looking at
only streaming or only conversational or both scenarios for congestion
control?

Extending on the above: does the charter need say something about the
applicability of algorithm to point-to-point scenarios or keep it open
and discuss this in the requirements document?

Cheers,
Varun

On Tue, Jan 3, 2012 at 18:03, Wesley Eddy <wes at mti-systems.com> wrote:
>
> On 1/3/2012 8:44 AM, Harald Alvestrand wrote:
> > On 01/02/2012 07:56 PM, Wesley Eddy wrote:
> >> Hello all, following up on our discussion in Taipei, I have proposed
> >> a working group in the TSV area to work on RTP congestion control.
> >> This is scheduled to be discussed by the IESG on 1/5 in "internal
> >> review".
> >>
> >> The draft charter is at:
> >> http://www.ietf.org/iesg/evaluation/rmcat-charter.txt
> >>
> >> I would welcome participants in this list to comment on this,
> >> particularly if/when it moves to "external review", as I would
> >> expect the folks currently on this list to be some of the main
> >> participants in the proposed WG.  I had previously had this
> >> reviewed by the TSV Directorate, and got fairly good responses
> >> and strong interest expressed from many of the directorate in
> >> participating as well.
> >>
> >> Happy New Year!
> >>
> > Happy new year!
> >
> > I like the charter as written, as it seems to cover the ground we've
> > gone over in discussion fairly well and in some detail.
> >
> > As a matter of planning, I'm a bit leery of the schedule; the first
> > milestone of the WG is in November 2012, and the last milestone is in
> > December 2012, corresponding to the second of the five bullets under
> > "The working group is chartered to...".
> >
> > My two worries are:
> >
> > - If we don't do even speculative planning for the further steps up to
> > "publish standards track RFCs", we're not setting expectations in the
> > community. This could be bad.
> > - Waiting 11 months from now before we start adopting documents for
> > possible Experimental publication seems like an awfully long time. If
> > the RTCWEB WG wants (likely experimental) documents to refer to in its
> > output, that means that those documents have to be RTCWEB work product
> > or independent submissions, meaning that we first have to publish them
> > outside this WG, then pull them back in; that seems to be a bit of a
> > circuitous route.
> >
> > Do you have a more detailed image of how the work should progress, that
> > gives some sense of what the steps that need to be taken are between now
> > and November 2012?
>
>
> The milestone dates had very little thought put into them on my part.
> We should adapt them to whatever folks think is more reasonable, based
> on discussion.
>
> There are possibly other milestones that could be added for things like
> common evaluation and test methodology, requirements, etc. that would
> possibly be happening early on in parallel with algorithms starting to
> be proposed and reviewed.  I think the need for these should be
> discussed.
>
> I would expect chairs to help define the workflow for accepting
> proposals as WG items and moving them forward.  It can be difficult,
> for instance, if a proposal is accepted before much data has been
> reviewed, the group may later want to un-accept it.  Although dropping
> documents has been done before, it may not be pleasant.  I, personally,
> would think it makes more sense to keep documents as individual
> submission proposals to the working group until there is strong
> consensus that a proposal is indeed something that the group is happy
> to publish.
>
>
> --
> Wes Eddy
> MTI Systems
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion




--
http://www.netlab.tkk.fi/~varun/


More information about the Rtp-congestion mailing list