Subject: [rmcat] Do we need a generic feedback message, should we work on this now?

From: Michael Welzl <[email-masked]>
Date: Fri, 6 Nov 2015 10:54:30 +0100

Hi,

I just watched the RMCAT recording at
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF94_RMCAT_II&chapter=chapter_1
and I can't help but be amazed at the discussion of the generic feedback message.

I strongly support doing this work NOW because delaying has the risk of never getting it done: code will be shipped, and then has to be retro-fitted with a generic feedback message... and then we may end up with an incentive problem too (why support this standard, when MY system works?).

Given all the work that the RTCWEB WG has put into agreeing on common codecs I honestly think it's ridiculous to even imagine that we in RMCAT may end up having senders and receivers that are not be able to talk to each other because we don't have a common feedback message and no agreement on what should be on the sender or receiver side.

At the risk of being a smart-ass, I can't help but repeat that I did say these things at the very first RMCAT meeting, in November 2012:
http://www.ietf.org/proceedings/85/slides/slides-85-rmcat-0.pdf   (slides 2-7)

I do believe we should have agreed on sender vs. receiver - based control and on a common feedback message before even doing anything else.
Okay, this is all voluntary work and there's no point complaining or just demanding certain work to be done, I understand that .... but: now that we have a proposal for a common feedback message, I absolutely think we should move ahead with this, try to come to a decision about sender vs. receiver-based control, and align the existing congestion controls with it ASAP.

Cheers,
Michael

---

From: Colin Perkins <[email-masked]>
Date: Fri, 6 Nov 2015 21:55:24 +0900

Michael,

If we’re to define a common feedback packet format, then it should a) convey the information needed by the various congestion control algorithm candidates; and b) match the RTP architecture, since it is providing RTP congestion control. I don’t believe the current proposal fits with the RTP framework, and it’s not clear that it conveys the right information, since there hasn’t been a requirements analysis of the feedback needed by the different algorithms. 

I don’t object to a common feedback packet format, although I’m perhaps less convinced of its benefits, but I do object to pushing forward with a proposal, such as that discussed in the meeting, that’s inconsistent with the way RTP feedback works.

Colin

> On 6 Nov 2015, at 18:54, Michael Welzl <[email-masked]> wrote:
> 
> Hi,
> 

-- 
Colin Perkins
https://csperkins.org/

---

From: Michael Welzl <[email-masked]>
Date: Fri, 6 Nov 2015 14:02:00 +0100

Ok - I don't object to fixing it, I just wanted to stress the importance of getting these things straight (which I'm convinced of) ... this not only concerns the feedback message format but also the "CC logic at the sender or receiver or both?" decision.

Cheers,
Michael

> On 06 Nov 2015, at 13:55, Colin Perkins <[email-masked]> wrote:
> 
> Michael,
>

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Sun, 15 Nov 2015 11:55:41 +0100

Hi Colin, All

The idea was indeed to do exactly what you propose Colin.
I.e., to collect requirements and then design a feedback message
within the RTP framework.

This was exactly what the chair slides said (or aimed to say ..).
Please see the last slide of
http://www.ietf.org/proceedings/94/slides/slides-94-rmcat-0.pdf.

There was no reference to any current proposal in the discussion in RMCAT wg
session on Friday.

BR, Karen

> -----Original Message-----
> From: rmcat [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: 6. november 2015 13:55
> To: Michael Welzl <[email-masked]>
> Cc: rmcat WG <[email-masked]>
> Subject: Re: [rmcat] Do we need a generic feedback message, should we
> work on this now?
>
> Michael,
>
> If we’re to define a common feedback packet format, then it should a)
> convey the information needed by the various congestion control algorithm
> candidates; and b) match the RTP architecture, since it is providing RTP
> congestion control. I don’t believe the current proposal fits with the RTP
> framework, and it’s not clear that it conveys the right information, since
> there hasn’t been a requirements analysis of the feedback needed by the
> different algorithms.
>
> I don’t object to a common feedback packet format, although I’m perhaps
> less convinced of its benefits, but I do object to pushing forward with a
> proposal, such as that discussed in the meeting, that’s inconsistent with
> the
> way RTP feedback works.
>
> Colin
>
>
> http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF94_RMCA
> T
> > _II&chapter=chapter_1 and I can't help but be amazed at the discussion
> > of the generic feedback message.
> >
> > I strongly support doing this work NOW because delaying has the risk of
> never getting it done: code will be shipped, and then has to be
> retro-fitted
> with a generic feedback message... and then we may end up with an
> incentive problem too (why support this standard, when MY system works?).
> >
> > Given all the work that the RTCWEB WG has put into agreeing on common
> codecs I honestly think it's ridiculous to even imagine that we in RMCAT
> may
> end up having senders and receivers that are not be able to talk to each
> other because we don't have a common feedback message and no
> agreement on what should be on the sender or receiver side.
> >
> > At the risk of being a smart-ass, I can't help but repeat that I did say
> > these
> things at the very first RMCAT meeting, in November 2012:
> > http://www.ietf.org/proceedings/85/slides/slides-85-rmcat-0.pdf
> > (slides
> 2-7)
> >
> > I do believe we should have agreed on sender vs. receiver - based
> > control
> and on a common feedback message before even doing anything else.
> > Okay, this is all voluntary work and there's no point complaining or
> > just
> demanding certain work to be done, I understand that .... but: now that we
> have a proposal for a common feedback message, I absolutely think we
> should move ahead with this, try to come to a decision about sender vs.
> receiver-based control, and align the existing congestion controls with it
> ASAP.
> >
> > Cheers,
> > Michael
> >
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>