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

Fu Jiantao <fuji246@gmail.com> Tue, 05 March 2013 04:41 UTC

Return-Path: <fuji246@gmail.com>
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 1985321F86E6 for <rmcat@ietfa.amsl.com>; Mon, 4 Mar 2013 20:41:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1]
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 j-4dffGrhxXl for <rmcat@ietfa.amsl.com>; Mon, 4 Mar 2013 20:41:58 -0800 (PST)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id BDDAE21F86E3 for <rmcat@ietf.org>; Mon, 4 Mar 2013 20:41:57 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id m4so4532219lbo.28 for <rmcat@ietf.org>; Mon, 04 Mar 2013 20:41:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lbxBL33V8BtWDNuh5kdgN57A1+to6nEb9DRKhhHRvCI=; b=sXS2i7vUTnwDY2lAyXODTrKHuWIWSRhbdf980M1OZI3lvpTChwmIKATW5Z519HyPfz g3BjUHCVsgQO3+V4JJnYBWHGq0hSlcLQ/idmgEZpPRwXaF0UXKgauzVCi8uCY5NKiIcw hEWagiKZxJaE1PJgT41rP6OA5xG0Fem9l6ivZwMyHYbMThz1/1hiQp19dq1ww9cNrTEu drB+L1btWhRXTC8+YZLBAcyujibRNkBL0c5wi1rk8bWcMhTw8pfnjsXafbT0GEGcZ+Kf zuUugCAYYxyKiAwM+dJCT+0p10JMvW+t4KCixwR86HAJ7Bpe1cnSo/N5MtrJsZpHM0cr CFzA==
MIME-Version: 1.0
X-Received: by 10.112.88.10 with SMTP id bc10mr5365950lbb.70.1362458516663; Mon, 04 Mar 2013 20:41:56 -0800 (PST)
Received: by 10.114.25.231 with HTTP; Mon, 4 Mar 2013 20:41:56 -0800 (PST)
In-Reply-To: <8471CA16-DC31-4AFD-ABEF-558ABB79AE31@csperkins.org>
References: <20130218232842.19535.91395.idtracker@ietfa.amsl.com> <8471CA16-DC31-4AFD-ABEF-558ABB79AE31@csperkins.org>
Date: Tue, 05 Mar 2013 12:41:56 +0800
Message-ID: <CAKmxLjVGQNVx4KZb+wi+pt5PvfeSr6_5g1Yk4-TdWUZeXtH_kw@mail.gmail.com>
From: Fu Jiantao <fuji246@gmail.com>
To: Colin Perkins <csp@csperkins.org>
Content-Type: multipart/alternative; boundary="f46d04016975e839cf04d7261766"
Cc: rmcat@ietf.org
Subject: Re: [rmcat] Fwd: 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: Tue, 05 Mar 2013 04:41:59 -0000

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 <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/
>
>
>
>