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

Colin Perkins <csp@csperkins.org> Wed, 13 March 2013 02:47 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5817821F8596 for <rmcat@ietfa.amsl.com>; Tue, 12 Mar 2013 19:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.999
X-Spam-Level:
X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TT5Ie65UmwN for <rmcat@ietfa.amsl.com>; Tue, 12 Mar 2013 19:47:11 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9328611E80F9 for <rmcat@ietf.org>; Tue, 12 Mar 2013 19:47:10 -0700 (PDT)
Received: from [130.129.70.145] (port=52667 helo=dhcp-4691.meeting.ietf.org) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1UFbid-0007Fv-Sr; Wed, 13 Mar 2013 02:47:09 +0000
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_33C6ED5A-B80A-4AD3-9A5F-8C3FED4C6ACF"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CAKmxLjVGQNVx4KZb+wi+pt5PvfeSr6_5g1Yk4-TdWUZeXtH_kw@mail.gmail.com>
Date: Tue, 12 Mar 2013 22:47:05 -0400
Message-Id: <23969000-A71B-4A37-93B9-F9D67206B346@csperkins.org>
References: <20130218232842.19535.91395.idtracker@ietfa.amsl.com> <8471CA16-DC31-4AFD-ABEF-558ABB79AE31@csperkins.org> <CAKmxLjVGQNVx4KZb+wi+pt5PvfeSr6_5g1Yk4-TdWUZeXtH_kw@mail.gmail.com>
To: Fu Jiantao <fuji246@gmail.com>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: rmcat@ietf.org
Subject: Re: [rmcat] I-D Action: draft-perkins-rmcat-rtp-cc-feedback-00.txt
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmcat>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2013 02:47:12 -0000

On 4 Mar 2013, at 23:41, Fu Jiantao wrote:
> 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.

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




> Thanks
> 
> Jeromy
> 
> 
> 2013/2/26 Colin Perkins <csp@csperkins.org>
> 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: internet-drafts@ietf.org
> > Subject: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-00.txt
> > Date: 18 February 2013 23:28:42 GMT
> > To: i-d-announce@ietf.org
> > Reply-To: internet-drafts@ietf.org
> >
> >
> > 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/
> 
> 
> 
> 



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