Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)

Soo-Hyun Choi <s.choi@computer.or.kr> Tue, 04 October 2011 00:17 UTC

Return-Path: <s.choi@computer.or.kr>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FADD21F8CF7 for <rtcweb@ietfa.amsl.com>; Mon, 3 Oct 2011 17:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.017
X-Spam-Level:
X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 lNEWipVGj7BH for <rtcweb@ietfa.amsl.com>; Mon, 3 Oct 2011 17:17:36 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 754E321F8C3C for <rtcweb@ietf.org>; Mon, 3 Oct 2011 17:17:05 -0700 (PDT)
Received: by bkaq10 with SMTP id q10so6573093bka.31 for <rtcweb@ietf.org>; Mon, 03 Oct 2011 17:20:08 -0700 (PDT)
Received: by 10.204.138.211 with SMTP id b19mr284637bku.257.1317687608224; Mon, 03 Oct 2011 17:20:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.41.202 with HTTP; Mon, 3 Oct 2011 17:19:48 -0700 (PDT)
In-Reply-To: <4E89AB33.3050703@jesup.org>
References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <CAEdus3LcjV9x+gLdZm5vwKhh-ge6xzfWSEB_NxcHe1Gz_5DZ8g@mail.gmail.com> <CAOhzyf=MqsgsGUi521oJ5N6+T+K1N01MjeHYPpX_VZK8uyQksw@mail.gmail.com> <CAKkvrEkx0mqnDWqNYse3r9WUMbYKNZhrBqQ0SPUAnTtKrA5bLg@mail.gmail.com> <CAOhzyf=_n3VhNi1GgxdKJpyzEMLORcKX2499+YZHQnGqYURxjg@mail.gmail.com> <CAKkvrEnXxoiJZJ3a3eg_Ybz0POCM+UTxU7nnWCf8Xt331jiXLA@mail.gmail.com> <4E787D56.8060106@alvestrand.no> <CAKkvrEnpMusPu8py2-98NffDY493z=tA_giW9X-p6c1LtgL+XA@mail.gmail.com> <4E788A9C.40105@alvestrand.no> <CAKkvrEk0_L6UfDsUHQea_5XXfYXGWQ-8dJm_mP+nTSeVeL90rQ@mail.gmail.com> <4E799F00.8030602@alvestrand.no> <4E79E698.2090905@jesup.org> <4E79EA16.7070909@freedesktop.org> <CAOhzyf=c5+X+ScgV5CXkJJVM_ev1Hog7QP9FBCeA67z-R=oOcg@mail.gmail.com> <DBB1DC060375D147AC43F310AD987DCC36AE894DEB@ESESSCMS0366.eemea.ericsson.se> <4E89AB33.3050703@jesup.org>
From: Soo-Hyun Choi <s.choi@computer.or.kr>
Date: Tue, 4 Oct 2011 09:19:48 +0900
Message-ID: <CAKkvrE=NUWvwRs+fDtCeg+QUnkevHL7ch7A7=LBvRGtp-VcACw@mail.gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>, Henrik Lundin <hlundin@google.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2011 00:17:37 -0000

On Mon, Oct 3, 2011 at 21:31, Randell Jesup <randell-ietf@jesup.org>; wrote:
>
> I suspect in practice you'll see (outgoing) a gap in received packets (delay
> spike, while the radio in the handset changes access points), followed by
> packets coming in at ever-increasing delays (because the packets already
> queued to send are larger than will fit over the interface).  Incoming
> packets will likewise have queued "somewhere" in the network - depending on
> the type of handover, you could have a burst of lost packets or a delay
> spike, again (if over-bandwidth in that direction) followed by a series of
> ever-increasing delays.
>
> In either case the signal (once transmission is re-established) should be
> very clear, and the types of algorithms used in Google's draft should
> quickly identify a strong "over-bandwidth" signal in the data.  Bufferbloat
> ironically may help in quickly identifying it, since you're less likely to
> have a lot of losses following by down-ticks in delay.  (Though some of the
> plans I have to modify the algorithm to extend across all the media streams
> would probably deal with that as well.)
>
> So, all-in-all I think the receivers at either end will likely identify the
> over-bandwidth condition within a small (4? 6? may depend on jitter) number
> of packets after an interface change.  Again, sharing the congestion control
> will help here (perhaps a lot) by putting all the datapoints into one
> bucket, so the signal will stabilize much faster.


I'd much appreciated if Google folks could present related data points
similar to the cases that you mentioned, if they have.


>
> Ok, so once the sides have recognized the sudden over-bandwidth situation,
> how do we get out of it?  In AVPF we're likely able to send an RTCP message
> anytime we want, so the receiver should be able to send an RTCP as soon as
> possible.  We've already said we plan to use RFC 5506 to reduce sizes of
> feed back messages, so that will keep the size smaller.   It will be stuck
> behind any already-queued packets (hello, bufferbloat!)  but there's little
> we can do about that.
>
> This RTCP feedback could of course be lost, and the CC algorithm should take
> that into account when it's trying to transmit a significant change in
> bandwidth (at least a significant reduction) by sending updated feedback
> messages frequently until stability has been achieved.


Sure - any kind of Ack-based CC mechanisms are significantly
influenced by the reliability of Ack flows.


>
> In some cases, if it's possible, it may be useful to know about a network
> switchover and perhaps reduce outgoing and ask for a reduction in incoming
> bandwidth to reduce the risk of a spike in delay over the switchover (at the
> cost of reduction in quality temporarily).
>
>> With ACK-clocked algorithms like TCP and TFWC the sender simply stops
>> sending packets when ACK's are not received anymore. Receiver based algos
>> are a bit more complicated as the risk is higher that the sender will
>> continue to send packets for some time even though the channel throughput
>> has dropped considerably, resulting in excessive congestion somewhere along
>> the path.
>> Is this a problem ?. I don't know, I guess time will tell.

Ack-clock based CC algos are simpler to implement in real apps as it
does not require a complicated non-linear computation in the algos.