Subject: Re: [rmcat] Fwd: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-00.txt

From: Fu Jiantao <[email-masked]>
Date: Tue, 5 Mar 2013 12:41:56 +0800

Hi Colin,

   I've got the following comments:

  1."there is little point in providing feedback more often than the codec
can adapt", i think there is no need to send those overlimits data onto the
network if we've got feedback that the network is congested, so i think it
make sense if there is traffic shaper on the sender side, those overlimit
packets can buffered and dropped at the sender side, rather than sending
them to the network which affects other traffics.

  2. How about ack in a given interval, this can be treat as variant of
per-frame ack(several frames per ack). This is another kind which has less
load than per-frame ack.

  3. There can be adaptive feedback which feedback when there is need to do
so, for example, when the given interval is not enough for the adaption(the
queuing delay goes large very fast), the feedback can be accelerated in
this case.

  4. The feedback strategy has some relationship with
sender-based/receiver-based, is this in the scope of this draft?

Thanks

Jeromy

2013/2/26 Colin Perkins <[email-masked]>

> I submitted the following draft that talks about the types of congestion
> control feedback that can be sent using RTCP as is currently specified, and
> their suitability for implementing congestion control for unicast
> multimedia applications. In particular, it talks about the rate of
> congestion feedback that can be supported.
>
> Comments are welcome. I'm also happy to present this in Orlando, if the
> chairs think it useful.
>
> Colin
>
>
>
>
> Begin forwarded message:
> > From: [email-masked]
> > Subject: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-00.txt
> > Date: 18 February 2013 23:28:42 GMT
> > To: [email-masked]
> > Reply-To: [email-masked]
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >
> >       Title           : On the Use of RTP Control Protocol (RTCP)
> Feedback for Unicast Multimedia Congestion Control
> >       Author(s)       : Colin Perkins
> >       Filename        : draft-perkins-rmcat-rtp-cc-feedback-00.txt
> >       Pages           : 8
> >       Date            : 2013-02-18
> >
> > Abstract:
> > This memo discusses the types of congestion control feedback that it
> > is possible to send using the RTP Control Protocol (RTCP), and their
> > suitability of use in implementing congestion control for unicast
> > multimedia applications.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-perkins-rmcat-rtp-cc-feedback
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-perkins-rmcat-rtp-cc-feedback-00
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Mar 2013 22:47:05 -0400

On 4 Mar 2013, at 23:41, Fu Jiantao wrote:
>   1."there is little point in providing feedback more often than the codec can adapt", i think there is no need to send those overlimits data onto the network if we've got feedback that the network is congested, so i think it make sense if there is traffic shaper on the sender side, those overlimit packets can buffered and dropped at the sender side, rather than sending them to the network which affects other traffics.

This draft isn't proposing a congestion control algorithm, it's exploring the space of possible feedback using RTCP as defined. It might make sense to send feedback as you suggest. 

>   2. How about ack in a given interval, this can be treat as variant of per-frame ack(several frames per ack). This is another kind which has less load than per-frame ack.

Sure.

>   3. There can be adaptive feedback which feedback when there is need to do so, for example, when the given interval is not enough for the adaption(the queuing delay goes large very fast), the feedback can be accelerated in this case.

I agree that this is an option.

>   4. The feedback strategy has some relationship with sender-based/receiver-based, is this in the scope of this draft?

I'm not intending to progress this draft, but it's certainly an issue to consider when designing a congestion control algorithm.

Colin

> I submitted the following draft that talks about the types of congestion control feedback that can be sent using RTCP as is currently specified, and their suitability for implementing congestion control for unicast multimedia applications. In particular, it talks about the rate of congestion feedback that can be supported.
> 
> Comments are welcome. I'm also happy to present this in Orlando, if the chairs think it useful.
> 
> Colin
> 
> 
> 
> 
> Begin forwarded message:
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >
> >       Title           : On the Use of RTP Control Protocol (RTCP) Feedback for Unicast Multimedia Congestion Control

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