From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Oct 2 09:09:23 2012 Return-Path: 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 77A1421F8593 for ; Tue, 2 Oct 2012 09:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GPVAhINxoiD for ; Tue, 2 Oct 2012 09:09:22 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9411D21F8589 for ; Tue, 2 Oct 2012 09:09:22 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id C3E1C633B1; Tue, 2 Oct 2012 18:09:20 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id B724259A8A; Tue, 2 Oct 2012 18:09:20 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: rmcat WG Date: Tue, 2 Oct 2012 18:09:19 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> Cc: "Eggert, Lars" Subject: [rmcat] First meeting 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:09:23 -0000 Dear working group! We are about to plan our first meeting in Atlanta. We will have a 2 hour time slot. Time and date are not announced yet but will be this week. Our first milestones include the following items: * Draft of requirements * Draft of evaluation criteria * Draft of RTCP extensions and interaction with applications/RTP flow (if needed) Please let us know if you are working on a draft that will address one of these items and if you are planing to present this work at the next meeting. Especially everyone who is working on a proposal for a congestion control algorithm, we would like to encourage to evaluate your own proposal (against other proposals) and contribute to the evaluation criteria draft. We would like to see sufficient discussion on each proposed algorithm on the mailing list before discussing the proposal at a meeting or even adopting a proposal as working group item. That also means that drafts describing a proposal in detail should be submitted early enough in advance of a meeting. See you in Atlanta! Mirja From michawe@ifi.uio.no Wed Oct 3 04:14:50 2012 Return-Path: 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 9239521F8593 for ; Wed, 3 Oct 2012 04:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw0ScRD0FntX for ; Wed, 3 Oct 2012 04:14:50 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 91F4421F86C6 for ; Wed, 3 Oct 2012 04:14:49 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TJMuc-0001IY-7f; Wed, 03 Oct 2012 13:14:46 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TJMub-0000VJ-KE; Wed, 03 Oct 2012 13:14:46 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C019F444-BD94-4256-9F4A-0CC1E9CDF955" From: Michael Welzl In-Reply-To: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> Date: Wed, 3 Oct 2012 13:14:41 +0200 Message-Id: <0AEBCDC2-91A2-4E49-AF15-3A84C25187E0@ifi.uio.no> References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> To: =?iso-8859-1?Q?Mirja_K=FChlewind?= X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 5 sum msgs/h 1 total rcpts 24238 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.2, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.228, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2CBF5225CFEA7A86E965BA41D5A8741C9CB8756B X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -61 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 9788 max/h 20 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "Eggert, Lars" Subject: Re: [rmcat] First meeting 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 11:14:50 -0000 --Apple-Mail=_C019F444-BD94-4256-9F4A-0CC1E9CDF955 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi! A comment / clarification below... On 2. okt. 2012, at 18:09, Mirja K=FChlewind wrote: > Dear working group! >=20 > We are about to plan our first meeting in Atlanta. We will have a 2 = hour time=20 > slot. Time and date are not announced yet but will be this week. >=20 > Our first milestones include the following items: >=20 > * Draft of requirements >=20 > * Draft of evaluation criteria >=20 > * Draft of RTCP extensions and interaction with applications/RTP flow = (if=20 > needed) About the "interaction with applications" bit: there was, I think, = general agreement pre-BOF / at the BOF that we need to some more = information than now to be exchanged between applications (i.e. the = codec, I think) and the transport (i.e. RTP/UDP). Some interesting = thoughts on that are in the cc workshop's paper 19, for example: = http://www.iab.org/activities/workshops/cc-workshop/papers/ One particular point that there seemed to be agreement on is that = packets will have different value to an application, and these = priorities should be specified to the transport to enable better = mechanisms at that level. So this is, essentially about the API between applications and = transport. Unsurprisingly, the word "API" caused some trouble, which I = resolved by rewording it into "interactions". Indeed we don't want to = specify an API, but still, what type of information is exchanged at = that, well, interface. I guess getting this right requires quite a bit = of discussion... I'm interested in this and volunteer to participate in document writing. = I'm probably not enough of an RTP expert to be the main author, though. > Please let us know if you are working on a draft that will address one = of=20 > these items and if you are planing to present this work at the next = meeting. >=20 > Especially everyone who is working on a proposal for a congestion = control=20 > algorithm, we would like to encourage to evaluate your own proposal = (against=20 > other proposals) and contribute to the evaluation criteria draft. We = would=20 > like to see sufficient discussion on each proposed algorithm on the = mailing=20 > list before discussing the proposal at a meeting or even adopting a = proposal=20 > as working group item. That also means that drafts describing a = proposal in=20 > detail should be submitted early enough in advance of a meeting.=20 >=20 > See you in Atlanta! > Mirja > _______________________________________________ > rmcat mailing list > rmcat@ietf.org > https://www.ietf.org/mailman/listinfo/rmcat Cheers, Michael --Apple-Mail=_C019F444-BD94-4256-9F4A-0CC1E9CDF955 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Dear = working group!

We are about to plan our first meeting in Atlanta. = We will have a 2 hour time
slot. Time and date are not announced yet = but will be this week.

Our first milestones include the following = items:

* Draft of requirements

* Draft of evaluation = criteria

* Draft of RTCP extensions and interaction with = applications/RTP flow (if =
needed)

About the = "interaction with applications" bit: there was, I think, general = agreement pre-BOF / at the BOF that we need to some more information = than now to be exchanged between applications (i.e. the codec, I think) = and the transport (i.e. RTP/UDP). Some interesting thoughts on that are = in the cc workshop's paper 19, for example: http:= //www.iab.org/activities/workshops/cc-workshop/papers/

<= /div>
One particular point that there seemed to be agreement on is = that packets will have different value to an application, and these = priorities should be specified to the transport to enable better = mechanisms at that level.

So this is, essentially = about the API between applications and transport. Unsurprisingly, the = word "API" caused some trouble, which I resolved by rewording it into = "interactions". Indeed we don't want to specify an API, but still, what = type of information is exchanged at that, well, interface. I guess = getting this right requires quite a bit of = discussion...

I'm interested in this and = volunteer to participate in document writing. I'm probably not enough of = an RTP expert to be the main author, = though.


Please= let us know if you are working on a draft that will address one of =
these items and if you are planing to present this work at the next = meeting.

Especially everyone who is working on a proposal for a = congestion control
algorithm, we would like to encourage to evaluate = your own proposal (against
other proposals) and contribute to the = evaluation criteria draft. We would
like to see sufficient = discussion on each proposed algorithm on the mailing
list before = discussing the proposal at a meeting or even adopting a proposal
as = working group item. That also means that drafts describing a proposal in =
detail should be submitted early enough in advance of a meeting. =

See you in = Atlanta!
Mirja
_______________________________________________
rm= cat mailing list
rmcat@ietf.org
https://www.ietf.org/= mailman/listinfo/rmcat

Cheers,<= /div>
Michael

= --Apple-Mail=_C019F444-BD94-4256-9F4A-0CC1E9CDF955-- From john@jlc.net Wed Oct 3 08:00:39 2012 Return-Path: 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 D4F2721F8554 for ; Wed, 3 Oct 2012 08:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.277 X-Spam-Level: X-Spam-Status: No, score=-106.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw6gLGGKngrJ for ; Wed, 3 Oct 2012 08:00:39 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B85B721F84C2 for ; Wed, 3 Oct 2012 08:00:38 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A14D433C22; Wed, 3 Oct 2012 11:00:37 -0400 (EDT) Date: Wed, 3 Oct 2012 11:00:37 -0400 From: John Leslie To: rmcat WG Message-ID: <20121003150037.GA97796@verdi> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50608290.5020601@jesup.org> User-Agent: Mutt/1.4.1i Subject: [rmcat] Piggybacking 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:00:40 -0000 Randell Jesup wrote: > On 9/24/2012 10:46 AM, Harald Alvestrand wrote: >> >> In the TCP case, the feedback mechanism is the ack, which is needed >> for reasons beyond congestion control. In the RTP case, there isn't >> such a single, simple mechanism needed for other reasons. > > Agreed, though Michael indicated that we can piggyback congestion info > on reverse traffic. > > This may be possible and I've thought about it. Part of the problem is > that if you want to signal data back quickly, you have to wait up to > 20ms and in some cases longer to piggyback (and on > low-upstream-bandwidth links, the uplink transit time if you're > piggybacking on a 1500-byte video packet might be 20+ms). This is missing the point, IMHO. We are dealing in IP packets -- "unreliable" packets: meaning that we aren't entitled to expect any particular packet to be delivered at all. The signal we wish to send is tiny -- probably on the order of one byte. If we allocate one byte per packet for feedback, it's almost lost in the noise. But if we expect that byte and it doesn't arrive, that's a clear congestion signal. (Granted its loss signals congestion in the path _to_ us...) Trying to optimize 20 msec of reaction time for real-time traffic isn't the right paradigm. We want real-time traffic to adapt more slowly than web-surfing traffic, but stay low for longer (to avoid self-congestion). Thus, we can be pretty sure that the absence of an expected feedback justifies a delay in any ramp-up of outgoing bit-rate currently planned. Beyond that, it gets more complicated. Nonetheless, we can easily signal in our next scheduled outgoing packet that we missed an expected feedback; and that signal (or the failure to receive our next outgoing packeti) can trigger a retransmission -- catching up typically faster than TCP can do. I'd like to suggest that we plan RMCAT around bidirectional (though possibly very small in one direction) media packets. There aren't many cases where the traffic is _so_ unidirectional that an "I'm still interested in this stream" isn't appropriate. (I don't mean to imply that the packet-rate needs to be the same in both directions, least of all the bit-rate.) > If you do piggyback, it has to be optional on a instance-by-instance > basis This is precisely what I _don't_ want to see. Perhaps the size of the feedback might vary (though I doubt that's needed); but I want the _absence_ of feedback to be a primary signal. > (perhaps even estimating when the next chance will be, and the priority > of the data - but that speaks against a dumb receiver). (I don't think it makes sense to even think about a "dumb receiver.) > TCP can "get away" with high packet count feedback because flows are > typically largely unidirectional or alternating flows, or on > well-connected devices, not edge nodes. The PacketCable/etc issue with > shared upstreams and slot allocation is an example of reacting to this - > there even with the typically largely downstream flows, the upstream > acks become a limiting factor. Yes! This issue is very real in cable-upstream, and also significant in many wireless setups. But the right approach is to measure "upstream" congestion and adapt our packet rate to it. Really-tiny upstream packet aren't much "cheaper" than medium-sized upstream packets. Granted, it's easy to confuse upstream-congestion with downstream- congestion; but it's not _that_ hard to separate them. >> Stickler: Amount of feedback has little correlation with packet drop. >> If feedback is lost due to congestion, more feedback will lead to more >> packet drops. What is true is that when feedback occurs more rarely, >> losing one feedback packet will lead to a greater gap between feedback >> packets. This is true, but some possible inferences are not true... > I'd say less feedback means the odds that a drop will hit a feedback > packet are *lower* (as routers typically either tail-drop or > random-drop, but in either case in a static evaluation a > lower-bandwidth/packet flow (i.e. the feedback packets) will get hit > less often), but as Harald says the impact is higher. And in a dynamic > evaluation this may shift some. In particular, inferring that we must do slavish AIMD is not true. >>> - receiver-side-congestion-control-based feedback reduction as in >>> RRTCC means to reduce the feedback whenever feedback isn't urgent for >>> the sender. I'd argue that, in fact, we should reduce feedback only >>> when the channel carrying it (the backwards channel) is congested, >>> and that is a generic function, not bound to the sender-side >>> congestion control behavior. I agree that reducing feedback when the feedback path is not congested really doesn't help. (When we _do_ need to reduce feedback, I suggest we need to lower the packet-rate, letting the chips fall where they may; and be slow to increase it again.) > Personally, I assume both channels are always congested, or will be soon > (if we're doing our job right and aren't on a huge link), The assumption isn't particularly bad; but I envision many cases where it isn't true. > so bandwidth reduction for feedback always allows more bandwidth for > useful data. While technically true, it's a bad tradeoff to discard information about congestion -- this leads to growing your bit-rate too fast, and more packet-loss than necessary. >... > And my position is that any *good* two-way communication will run > near-but-not-quite-over the bandwidth limit as much of the time as > possible, so ACKs always have the potential to cause problems (and > always will force you a little further down the quality curve). I don't agree with this conclusion. With "ideal" feedback, we can be sure we don't initiate any congestion problems, while "minimal" feedback means some of our guesses will be wrong. And I don't think we have a good understanding of "the quality curve" yet. Some real-time stacks will run very close to the maximum data-rate, and hopefully will have good redundancy algorithms to reconstruct lost packets. Others will choose to stay below the maximum. We shouldn't prejudge that tradeoff, but limit ourselves to timely delivery of the best congestion information, and algorithms for rate-adjustment. -- John Leslie From michawe@ifi.uio.no Thu Oct 4 03:44:20 2012 Return-Path: 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 B890721F86A7 for ; Thu, 4 Oct 2012 03:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz0aG8P7fkEM for ; Thu, 4 Oct 2012 03:44:15 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id E73D421F85F9 for ; Thu, 4 Oct 2012 03:44:14 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TJiua-0008KH-8s for rmcat@ietf.org; Thu, 04 Oct 2012 12:44:12 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TJiuZ-000437-K0 for rmcat@ietf.org; Thu, 04 Oct 2012 12:44:12 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Michael Welzl In-Reply-To: <20121003150037.GA97796@verdi> Date: Thu, 4 Oct 2012 12:44:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CA3669B-31D4-4709-84F3-3CF25CE72EFB@ifi.uio.no> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <20121003150037.GA97796@verdi> To: rmcat WG X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 24275 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.2, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, RP_MATCHES_RCVD=-1.17, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 30CF9D7E9AC067AAEDB34986F4978772D5BDCF2D X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -61 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 9808 max/h 20 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [rmcat] Piggybacking 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 10:44:20 -0000 Hi, On 3. okt. 2012, at 17:00, John Leslie wrote: > Randell Jesup wrote: >> On 9/24/2012 10:46 AM, Harald Alvestrand wrote: >>>=20 >>> In the TCP case, the feedback mechanism is the ack, which is needed=20= >>> for reasons beyond congestion control. In the RTP case, there isn't=20= >>> such a single, simple mechanism needed for other reasons. >>=20 >> Agreed, though Michael indicated that we can piggyback congestion = info=20 >> on reverse traffic. >>=20 >> This may be possible and I've thought about it. Part of the problem = is=20 >> that if you want to signal data back quickly, you have to wait up to=20= >> 20ms and in some cases longer to piggyback (and on=20 >> low-upstream-bandwidth links, the uplink transit time if you're=20 >> piggybacking on a 1500-byte video packet might be 20+ms). >=20 > This is missing the point, IMHO. >=20 > We are dealing in IP packets -- "unreliable" packets: meaning that > we aren't entitled to expect any particular packet to be delivered > at all. >=20 > The signal we wish to send is tiny -- probably on the order of one > byte. If we allocate one byte per packet for feedback, it's almost > lost in the noise. >=20 > But if we expect that byte and it doesn't arrive, that's a clear > congestion signal. >=20 > (Granted its loss signals congestion in the path _to_ us...) >=20 > Trying to optimize 20 msec of reaction time for real-time traffic > isn't the right paradigm. We want real-time traffic to adapt more > slowly than web-surfing traffic, but stay low for longer (to avoid > self-congestion). >=20 > Thus, we can be pretty sure that the absence of an expected feedback > justifies a delay in any ramp-up of outgoing bit-rate currently = planned. Indeed, I'm not sure a quick signal is always needed. Either way, as = John says, a packet may be lost and the signal is tiny. We could agree = to always piggyback - if the signal really can't wait, we can send it = immediately but include it piggybacked onto the next datapacket too, for = redundancy, making the whole thing more stable in case a feedback packet = gets lost. > Beyond that, it gets more complicated. Nonetheless, we can easily > signal in our next scheduled outgoing packet that we missed an > expected feedback; and that signal (or the failure to receive our > next outgoing packeti) can trigger a retransmission -- catching up > typically faster than TCP can do. I don't get that, and it sounds complicated and inefficient - you're = adding round-trips here? > I'd like to suggest that we plan RMCAT around bidirectional > (though possibly very small in one direction) media packets. There > aren't many cases where the traffic is _so_ unidirectional that > an "I'm still interested in this stream" isn't appropriate. > (I don't mean to imply that the packet-rate needs to be the same > in both directions, least of all the bit-rate.) >=20 >> If you do piggyback, it has to be optional on a instance-by-instance >> basis=20 >=20 > This is precisely what I _don't_ want to see. Perhaps the size of > the feedback might vary (though I doubt that's needed); but I want the > _absence_ of feedback to be a primary signal. >=20 >> (perhaps even estimating when the next chance will be, and the = priority=20 >> of the data - but that speaks against a dumb receiver). >=20 > (I don't think it makes sense to even think about a "dumb receiver.) Call it a *generic* receiver. That's what was meant in this discussion. The problem is really that it's a (major, I think) benefit for = deployment to have one side generic, and a generic sender is a more = complicated setting than a generic receiver... in my opinion, none of = the two choices are really ideal. To have things combined in the right = place, I'll address this in a separate email in which I extend my = previous analysis of the sender/receiver situation. >> TCP can "get away" with high packet count feedback because flows are=20= >> typically largely unidirectional or alternating flows, or on=20 >> well-connected devices, not edge nodes. The PacketCable/etc issue = with=20 >> shared upstreams and slot allocation is an example of reacting to = this -=20 >> there even with the typically largely downstream flows, the upstream=20= >> acks become a limiting factor. >=20 > Yes! >=20 > This issue is very real in cable-upstream, and also significant in > many wireless setups. >=20 > But the right approach is to measure "upstream" congestion and adapt > our packet rate to it. Really-tiny upstream packet aren't much = "cheaper" > than medium-sized upstream packets. That was my argument too; it does add some complexity though. See my = next email on sender vs receiver... As for John's comments below, I agree with many of them. > Granted, it's easy to confuse upstream-congestion with downstream- > congestion; but it's not _that_ hard to separate them. >=20 >>> Stickler: Amount of feedback has little correlation with packet = drop.=20 >>> If feedback is lost due to congestion, more feedback will lead to = more=20 >>> packet drops. What is true is that when feedback occurs more rarely,=20= >>> losing one feedback packet will lead to a greater gap between = feedback=20 >>> packets. >=20 > This is true, but some possible inferences are not true... >=20 >> I'd say less feedback means the odds that a drop will hit a feedback=20= >> packet are *lower* (as routers typically either tail-drop or=20 >> random-drop, but in either case in a static evaluation a=20 >> lower-bandwidth/packet flow (i.e. the feedback packets) will get hit=20= >> less often), but as Harald says the impact is higher. And in a = dynamic=20 >> evaluation this may shift some. >=20 > In particular, inferring that we must do slavish AIMD is not true. >=20 >>>> - receiver-side-congestion-control-based feedback reduction as in=20= >>>> RRTCC means to reduce the feedback whenever feedback isn't urgent = for=20 >>>> the sender. I'd argue that, in fact, we should reduce feedback only=20= >>>> when the channel carrying it (the backwards channel) is congested,=20= >>>> and that is a generic function, not bound to the sender-side=20 >>>> congestion control behavior. >=20 > I agree that reducing feedback when the feedback path is not > congested really doesn't help. >=20 > (When we _do_ need to reduce feedback, I suggest we need to lower > the packet-rate, letting the chips fall where they may; and be slow > to increase it again.) >=20 >> Personally, I assume both channels are always congested, or will be = soon=20 >> (if we're doing our job right and aren't on a huge link), >=20 > The assumption isn't particularly bad; but I envision many cases > where it isn't true. >=20 >> so bandwidth reduction for feedback always allows more bandwidth for >> useful data. >=20 > While technically true, it's a bad tradeoff to discard information > about congestion -- this leads to growing your bit-rate too fast, and > more packet-loss than necessary. >=20 >> ...=20 >> And my position is that any *good* two-way communication will run=20 >> near-but-not-quite-over the bandwidth limit as much of the time as=20 >> possible, so ACKs always have the potential to cause problems (and=20 >> always will force you a little further down the quality curve). >=20 > I don't agree with this conclusion. >=20 > With "ideal" feedback, we can be sure we don't initiate any > congestion problems, while "minimal" feedback means some of our > guesses will be wrong. >=20 > And I don't think we have a good understanding of "the quality > curve" yet. >=20 > Some real-time stacks will run very close to the maximum data-rate, > and hopefully will have good redundancy algorithms to reconstruct > lost packets. Others will choose to stay below the maximum. We = shouldn't > prejudge that tradeoff, but limit ourselves to timely delivery of the > best congestion information, and algorithms for rate-adjustment. >=20 > -- > John Leslie > _______________________________________________ > rmcat mailing list > rmcat@ietf.org > https://www.ietf.org/mailman/listinfo/rmcat From michawe@ifi.uio.no Thu Oct 4 03:58:06 2012 Return-Path: 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 A860E21F85F4 for ; Thu, 4 Oct 2012 03:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1CnS7EdmdSY for ; Thu, 4 Oct 2012 03:58:06 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id CE06121F85C6 for ; Thu, 4 Oct 2012 03:58:05 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TJj80-0002RT-Dt for rmcat@ietf.org; Thu, 04 Oct 2012 12:58:04 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TJj7z-0008Ty-WC for rmcat@ietf.org; Thu, 04 Oct 2012 12:58:04 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Michael Welzl In-Reply-To: <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> Date: Thu, 4 Oct 2012 12:58:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> To: rmcat WG X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 6 sum msgs/h 3 total rcpts 24276 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.2, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, RP_MATCHES_RCVD=-1.17, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B5C3D8E575870F03371711D203AC6759F2A85F25 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -61 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9809 max/h 20 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 10:58:06 -0000 I herewith extend my own analysis of the sender- vs. receiver-based = congestion control question, with one (in my opinion) significant plus = in each camp: > Ok, I think you got me convinced. The way I see it, there's a choice = between: > 1) sending a lot of feedback, and only reducing it when there is = backwards congestion, by doing congestion control on the backwards = channel like ACK-CC > 2) simply always sending as little feedback as possible, based on the = (forward) congestion control mechanism's requirements >=20 > If we think of e.g. a videoconference, indeed congestion from all the = feedback on the uplink is quite realistic. 1) can then become rather = complicated... you may get congestion on your uplink, and it might be = necessary to reduce the rate of your data stream, or it might suffice to = reduce it on some of the feedback streams, but which? And then we have = to apply priorities between feedback packets and your payload... >=20 > 2) seems simpler, but it has the problem of making the mechanism more = fragile, and perhaps unnecessarily so (in a situation where it might be = fine to send much more feedback). I say "unnecessarily" because I'm not = convinced about "both channels are always congested, or will be soon" = because codecs may not be greedy, and streams such as VoIP may simply = not generate enough traffic for that. 2), i.e. receiver-side congestion control, also has the ADVANTAGE that = it doesn't misinterpret the loss of feedback as an indication of forward = congestion. A receiver-side controller has a clear notion of all packets = that have arrived in an interval and knows exactly what was dropped on = the way from the sender to the receiver and what wasn't. 2), i.e. receiver-side congestion control, also has the DISADVANTAGE = that tight interaction with the sending application gets harder - e.g., = to consider per-packet priorities in the congestion control mechanism. = With a receiver-side scheme, this requires richer feedback (in the = style: "for high-priority packets: this rate; for low-priority and = high-priority packets combined: that rate"). Then, the receiver would = have to know how many priorities are there on the sender side to give = the right amount of feedback... this will make things unnecessarily = complicated or, as I rather suspect, not happen, and then greatly limit = us. Cheers, Michael From randell-ietf@jesup.org Thu Oct 4 07:08:34 2012 Return-Path: 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 41B8121F86A2 for ; Thu, 4 Oct 2012 07:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blGY6QseDUIq for ; Thu, 4 Oct 2012 07:08:33 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1E48021F8674 for ; Thu, 4 Oct 2012 07:08:32 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60]:1814 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TJm6K-0008Ds-2e for rmcat@ietf.org; Thu, 04 Oct 2012 09:08:32 -0500 Message-ID: <506D9801.1010104@jesup.org> Date: Thu, 04 Oct 2012 10:06:57 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rmcat@ietf.org References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <20121003150037.GA97796@verdi> <2CA3669B-31D4-4709-84F3-3CF25CE72EFB@ifi.uio.no> In-Reply-To: <2CA3669B-31D4-4709-84F3-3CF25CE72EFB@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rmcat] Piggybacking 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 14:08:34 -0000 On 10/4/2012 6:44 AM, Michael Welzl wrote: > Hi, > > > On 3. okt. 2012, at 17:00, John Leslie wrote: > >> Randell Jesup wrote: >>> On 9/24/2012 10:46 AM, Harald Alvestrand wrote: >>>> In the TCP case, the feedback mechanism is the ack, which is needed >>>> for reasons beyond congestion control. In the RTP case, there isn't >>>> such a single, simple mechanism needed for other reasons. >>> Agreed, though Michael indicated that we can piggyback congestion info >>> on reverse traffic. >>> >>> This may be possible and I've thought about it. Part of the problem is >>> that if you want to signal data back quickly, you have to wait up to >>> 20ms and in some cases longer to piggyback (and on >>> low-upstream-bandwidth links, the uplink transit time if you're >>> piggybacking on a 1500-byte video packet might be 20+ms). >> This is missing the point, IMHO. >> >> We are dealing in IP packets -- "unreliable" packets: meaning that >> we aren't entitled to expect any particular packet to be delivered >> at all. >> >> The signal we wish to send is tiny -- probably on the order of one >> byte. If we allocate one byte per packet for feedback, it's almost >> lost in the noise. >> >> But if we expect that byte and it doesn't arrive, that's a clear >> congestion signal. >> >> (Granted its loss signals congestion in the path _to_ us...) >> >> Trying to optimize 20 msec of reaction time for real-time traffic >> isn't the right paradigm. We want real-time traffic to adapt more >> slowly than web-surfing traffic, but stay low for longer (to avoid >> self-congestion). >> >> Thus, we can be pretty sure that the absence of an expected feedback >> justifies a delay in any ramp-up of outgoing bit-rate currently planned. > Indeed, I'm not sure a quick signal is always needed. Either way, as John says, a packet may be lost and the signal is tiny. We could agree to always piggyback - if the signal really can't wait, we can send it immediately but include it piggybacked onto the next datapacket too, for redundancy, making the whole thing more stable in case a feedback packet gets lost. That's closer to what I was thinking - use independent packets *sometimes*, but mostly use piggybacked (which reduced the overall impact of feedback). I'd use independent packets when there's an expected (or measured) long delay waiting to piggyback (for example if muted or using VAD), and when we have new (unexpected) information to send. There is an issue with 'how' piggybacking is done on RTP. In RTCP, it's fairly easy (though more than one byte!) In RTP, you either are changing the payload formats or you're using a header extension. (Or we're designing RTP v3.... That would be 'interesting'.) WebRTC 'bundle' helps us here (more packets to piggyback on), and in general if we have multiple flows sharing congestion-measurement/reporting domains. (Also more data (faster smoothing of noise), etc). In my previous implementation one common case was that on packet loss (video), the system would send an immediate RTCP NACK/rtcpfb pli/etc to ask for a refresh, and congestion info would hitchhike along with any RTCP packet we sent. >> Beyond that, it gets more complicated. Nonetheless, we can easily >> signal in our next scheduled outgoing packet that we missed an >> expected feedback; and that signal (or the failure to receive our >> next outgoing packeti) can trigger a retransmission -- catching up >> typically faster than TCP can do. > I don't get that, and it sounds complicated and inefficient - you're adding round-trips here? Basically PLI for congestion control. However, you need a jitter/delay buffer to handle transit jitter and reordering, so it's not so simple. Or you decide fairly frequent false positives are ok, which might be possible. >> I'd like to suggest that we plan RMCAT around bidirectional >> (though possibly very small in one direction) media packets. There I think it has to handle *well* both one-directional and bidirectional flows. But opportunistic piggybacking would do that (if you solve the 'how' question above for RTP). You definitely can piggyback with other RTCP traffic. >> aren't many cases where the traffic is _so_ unidirectional that >> an "I'm still interested in this stream" isn't appropriate. >> (I don't mean to imply that the packet-rate needs to be the same >> in both directions, least of all the bit-rate.) Right, though that also means we're not talking about ack-per-packet in unidirectional. While I'm not suggesting this, when there was no other RTCP traffic to piggyback on (and no loss) I ran ~1 second congestion reports. >> >>> If you do piggyback, it has to be optional on a instance-by-instance >>> basis >> This is precisely what I _don't_ want to see. Perhaps the size of >> the feedback might vary (though I doubt that's needed); but I want the >> _absence_ of feedback to be a primary signal. That's not at odds with what I was saying - I meant packet-by-packet/signal-by-signal you decide to piggyback or not - and if you're waiting to piggyback you can react to a timer expiry and send it standalone. So you *could* design it to have "feedback every Nms" (with adjustable N), and have the receiver send feedback every <=N, using piggyback or not as available. >>> TCP can "get away" with high packet count feedback because flows are >>> typically largely unidirectional or alternating flows, or on >>> well-connected devices, not edge nodes. The PacketCable/etc issue with >>> shared upstreams and slot allocation is an example of reacting to this - >>> there even with the typically largely downstream flows, the upstream >>> acks become a limiting factor. >> Yes! >> >> This issue is very real in cable-upstream, and also significant in >> many wireless setups. >> >> But the right approach is to measure "upstream" congestion and adapt >> our packet rate to it. Really-tiny upstream packet aren't much "cheaper" >> than medium-sized upstream packets. > That was my argument too; it does add some complexity though. See my next email on sender vs receiver... Agreed. Many/most routers buffer by packet not by packet-size. Each WiFi packet is much heavierweight than the payload size would indicate, etc. Which is why I like reducing ACK *packet* flows. > > As for John's comments below, I agree with many of them. > > >> Granted, it's easy to confuse upstream-congestion with downstream- >> congestion; but it's not _that_ hard to separate them. >> >>>> Stickler: Amount of feedback has little correlation with packet drop. >>>> If feedback is lost due to congestion, more feedback will lead to more >>>> packet drops. What is true is that when feedback occurs more rarely, >>>> losing one feedback packet will lead to a greater gap between feedback >>>> packets. >> This is true, but some possible inferences are not true... >> >>> I'd say less feedback means the odds that a drop will hit a feedback >>> packet are *lower* (as routers typically either tail-drop or >>> random-drop, but in either case in a static evaluation a >>> lower-bandwidth/packet flow (i.e. the feedback packets) will get hit >>> less often), but as Harald says the impact is higher. And in a dynamic >>> evaluation this may shift some. >> In particular, inferring that we must do slavish AIMD is not true. >> >>>>> - receiver-side-congestion-control-based feedback reduction as in >>>>> RRTCC means to reduce the feedback whenever feedback isn't urgent for >>>>> the sender. I'd argue that, in fact, we should reduce feedback only >>>>> when the channel carrying it (the backwards channel) is congested, >>>>> and that is a generic function, not bound to the sender-side >>>>> congestion control behavior. >> I agree that reducing feedback when the feedback path is not >> congested really doesn't help. >> >> (When we _do_ need to reduce feedback, I suggest we need to lower >> the packet-rate, letting the chips fall where they may; and be slow >> to increase it again.) >> >>> Personally, I assume both channels are always congested, or will be soon >>> (if we're doing our job right and aren't on a huge link), >> The assumption isn't particularly bad; but I envision many cases >> where it isn't true. >> >>> so bandwidth reduction for feedback always allows more bandwidth for >>> useful data. >> While technically true, it's a bad tradeoff to discard information >> about congestion -- this leads to growing your bit-rate too fast, and >> more packet-loss than necessary. >> >>> ... >>> And my position is that any *good* two-way communication will run >>> near-but-not-quite-over the bandwidth limit as much of the time as >>> possible, so ACKs always have the potential to cause problems (and >>> always will force you a little further down the quality curve). >> I don't agree with this conclusion. >> >> With "ideal" feedback, we can be sure we don't initiate any >> congestion problems, while "minimal" feedback means some of our >> guesses will be wrong. >> >> And I don't think we have a good understanding of "the quality >> curve" yet. >> >> Some real-time stacks will run very close to the maximum data-rate, >> and hopefully will have good redundancy algorithms to reconstruct >> lost packets. Others will choose to stay below the maximum. We shouldn't >> prejudge that tradeoff, but limit ourselves to timely delivery of the >> best congestion information, and algorithms for rate-adjustment. >> >> -- >> John Leslie >> _______________________________________________ >> rmcat mailing list >> rmcat@ietf.org >> https://www.ietf.org/mailman/listinfo/rmcat -- Randell Jesup randell-ietf@jesup.org From john@jlc.net Thu Oct 4 07:46:40 2012 Return-Path: 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 AFB8F21F8587 for ; Thu, 4 Oct 2012 07:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.3 X-Spam-Level: X-Spam-Status: No, score=-106.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H15sDH5uIQky for ; Thu, 4 Oct 2012 07:46:40 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id EFAC921F86B3 for ; Thu, 4 Oct 2012 07:46:39 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7780833C24; Thu, 4 Oct 2012 10:46:39 -0400 (EDT) Date: Thu, 4 Oct 2012 10:46:39 -0400 From: John Leslie To: Michael Welzl Message-ID: <20121004144639.GC97796@verdi> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> User-Agent: Mutt/1.4.1i Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 14:46:40 -0000 Michael Welzl wrote: > > I herewith extend my own analysis of the sender- vs. receiver-based > congestion control question, with one (in my opinion) significant plus > in each camp: > >>... The way I see it, there's a choice between: >> 1) sending a lot of feedback, and only reducing it when there is >> backwards congestion, by doing congestion control on the backwards >> channel like ACK-CC >> 2) simply always sending as little feedback as possible, based on the >> (forward) congestion control mechanism's requirements > > 2), i.e. receiver-side congestion control, also has the ADVANTAGE that > it doesn't misinterpret the loss of feedback as an indication of > forward congestion. We should try pretty hard to avoid the need to interpret the lack of feedback as indicating what happened on the forward path. > A receiver-side controller has a clear notion of all packets that > have arrived in an interval and knows exactly what was dropped on > the way from the sender to the receiver and what wasn't. (Assuming, of course, it knows the schedule of what the sender sent.) > 2), i.e. receiver-side congestion control, also has the DISADVANTAGE > that tight interaction with the sending application gets harder - > e.g., to consider per-packet priorities in the congestion control > mechanism. I don't see any necessary coupling between priorities of what the sender would like to send and what the receiver would like to receive. > With a receiver-side scheme, this requires richer feedback (in > the style: "for high-priority packets: this rate; for low-priority > and high-priority packets combined: that rate"). Then, the receiver > would have to know how many priorities are there on the sender > side to give the right amount of feedback... this will make > things unnecessarily complicated or, as I rather suspect, not > happen, and then greatly limit us. Congestion is somewhat orthogonal to priorities: we're interested in avoiding congestion far more than we're worried about which packets have the highest priority. The receiver may or may not wish to express an opinion of which streams should have highest priority. If it does, this preference should be stable over any particular period of congestion. The sender may well believe that certain events should have high priority regardless of the receiver's priorities. It will no doubt find a way to send these with higher priority regardless of what we may specify. We should concentrate our efforts on getting both endpoints a measure of congestion along the path they're using to send, and one or more algorithms to back off the _overall_ sending rate. The network doesn't care one whit for our application-layer priorities. -- John Leslie From michawe@ifi.uio.no Thu Oct 4 15:09:43 2012 Return-Path: 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 DDC0421F8621 for ; Thu, 4 Oct 2012 15:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7i+JhnnG9Ul for ; Thu, 4 Oct 2012 15:09:43 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id E20D021F8648 for ; Thu, 4 Oct 2012 15:09:42 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TJtby-0001Oz-25; Fri, 05 Oct 2012 00:09:42 +0200 Received: from 108.134.189.109.customer.cdi.no ([109.189.134.108] helo=[192.168.0.197]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TJtbx-0007Lc-DQ; Fri, 05 Oct 2012 00:09:42 +0200 Message-Id: From: Michael Welzl To: John Leslie In-Reply-To: <20121004144639.GC97796@verdi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 5 Oct 2012 00:09:18 +0200 References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 8 sum msgs/h 3 total rcpts 24303 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8CC1D76A71B585C1822CFEB83372A1339137BA7A X-UiO-SPAM-Test: remote_host: 109.189.134.108 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1493 max/h 15 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:09:44 -0000 On Oct 4, 2012, at 4:46 PM, John Leslie wrote: > Michael Welzl wrote: >> >> I herewith extend my own analysis of the sender- vs. receiver-based >> congestion control question, with one (in my opinion) significant >> plus >> in each camp: >> >>> ... The way I see it, there's a choice between: >>> 1) sending a lot of feedback, and only reducing it when there is >>> backwards congestion, by doing congestion control on the backwards >>> channel like ACK-CC >>> 2) simply always sending as little feedback as possible, based on >>> the >>> (forward) congestion control mechanism's requirements >> >> 2), i.e. receiver-side congestion control, also has the ADVANTAGE >> that >> it doesn't misinterpret the loss of feedback as an indication of >> forward congestion. > > We should try pretty hard to avoid the need to interpret the lack > of feedback as indicating what happened on the forward path. > >> A receiver-side controller has a clear notion of all packets that >> have arrived in an interval and knows exactly what was dropped on >> the way from the sender to the receiver and what wasn't. > > (Assuming, of course, it knows the schedule of what the sender > sent.) > >> 2), i.e. receiver-side congestion control, also has the DISADVANTAGE >> that tight interaction with the sending application gets harder - >> e.g., to consider per-packet priorities in the congestion control >> mechanism. > > I don't see any necessary coupling between priorities of what the > sender would like to send and what the receiver would like to receive. Not "what the receiver would like to receive", but between the sender's priorities and congestion control. >> With a receiver-side scheme, this requires richer feedback (in >> the style: "for high-priority packets: this rate; for low-priority >> and high-priority packets combined: that rate"). Then, the >> receiver >> would have to know how many priorities are there on the sender >> side to give the right amount of feedback... this will make >> things unnecessarily complicated or, as I rather suspect, not >> happen, and then greatly limit us. > > Congestion is somewhat orthogonal to priorities: we're interested > in avoiding congestion far more than we're worried about which packets > have the highest priority. > > The receiver may or may not wish to express an opinion of which > streams should have highest priority. If it does, this preference > should be stable over any particular period of congestion. > > The sender may well believe that certain events should have high > priority regardless of the receiver's priorities. It will no doubt > find a way to send these with higher priority regardless of what we > may specify. > > We should concentrate our efforts on getting both endpoints a > measure of congestion along the path they're using to send, and > one or more algorithms to back off the _overall_ sending rate. The > network doesn't care one whit for our application-layer priorities. First, to clarify, I'm talking about per-packet priorities within a stream. Second, my point is that congestion control could be done better if packet priorities would be known, and could then be taken into account. Right now, we are essentially facing greedy or non-greedy traffic, and we have the LEDBAT notion of a generally lower priority. In fact a mechanism could opt for a more LEDBAT'ish behavior when its buffer is full of low-priority packets and be more aggressive when it has high- priority packets. To the best of my knowledge, these things don't really exist yet, but I believe that this is largely because this knowledge is not typically available to a congestion control mechanism. Note that conforming to such priorities is not just some obscure idea, as there are hard facts for a significant qualitative impact, e.g. in the case of video. But if a mechanism does such things, and it's on the receiver side, whereas the send buffer is on the sender side, things get problematic. Either we fix this, or we move the mechanism to the sender, or we ignore the chance we have, here, to do things better. I guess these are our choices. Cheers, Michael From john@jlc.net Thu Oct 4 15:31:16 2012 Return-Path: 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 776D51F0381 for ; Thu, 4 Oct 2012 15:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.011 X-Spam-Level: X-Spam-Status: No, score=-106.011 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CWy3NdhLPXx for ; Thu, 4 Oct 2012 15:31:15 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A1B9321F8505 for ; Thu, 4 Oct 2012 15:31:15 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 19BAF33C21; Thu, 4 Oct 2012 18:31:15 -0400 (EDT) Date: Thu, 4 Oct 2012 18:31:15 -0400 From: John Leslie To: Michael Welzl Message-ID: <20121004223115.GE97796@verdi> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:31:16 -0000 Michael Welzl wrote: > On Oct 4, 2012, at 4:46 PM, John Leslie wrote: >... >> I don't see any necessary coupling between priorities of what the >> sender would like to send and what the receiver would like to receive. > > Not "what the receiver would like to receive", but between the > sender's priorities and congestion control. Two different things... >... > First, to clarify, I'm talking about per-packet priorities within a > stream. Second, my point is that congestion control could be done > better if packet priorities would be known, and could then be taken > into account. I guess I'm missing why packet priorities would ever _not_ be the domain of the sender -- even if advised by receiver preferences. > Right now, we are essentially facing greedy or non-greedy traffic, Do you mean we're "contending against" those? If so, I agree. > and we have the LEDBAT notion of a generally lower priority. In fact a > mechanism could opt for a more LEDBAT'ish behavior when its buffer is > full of low-priority packets and be more aggressive when it has high- > priority packets. If you're saying that sending rate may deserve to increase faster when there are higher priority packets to send, I could agree but it seems unlikely such a situation will happen. If OTOH, the sender has _only_ higher priority packets, a more aggressive sending rate _may_ be justified. Either way, it seems unlikely to be a good idea to increase sending rate too aggressively for low-priority packets... > To the best of my knowledge, these things don't really exist yet, but > I believe that this is largely because this knowledge is not typically > available to a congestion control mechanism. Note that conforming to > such priorities is not just some obscure idea, as there are hard facts > for a significant qualitative impact, e.g. in the case of video. This sounds worth discussing. (I'm seriously hopeful that the "video codec" BoF will lead to a family of video codecs with smoother bit-rate than is typical today.) > But if a mechanism does such things, and it's on the receiver side, > whereas the send buffer is on the sender side, things get problematic. > Either we fix this, or we move the mechanism to the sender, or we > ignore the chance we have, here, to do things better. I guess these > are our choices. To tell truth, I think it's premature to specify what will be receiver-side vs. sender-side. Especially, I think we need intelligence at both ends in order to communicate useful congestion information in the two directions. Once we have designed that we will be better able to specify the control loops. (Assuming ConEx ever finishes, we are likely to see some kind of congestion-based pricing both for senders and receivers -- and the control loops ideally would serve the price-based needs of both senders and receivers.) -- John Leslie From michawe@ifi.uio.no Fri Oct 5 02:46:29 2012 Return-Path: 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 DE96E21F8608 for ; Fri, 5 Oct 2012 02:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdEB5d67m3z6 for ; Fri, 5 Oct 2012 02:46:29 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id A2C5D21F85ED for ; Fri, 5 Oct 2012 02:46:28 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TK4UE-0000rb-Qn; Fri, 05 Oct 2012 11:46:26 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TK4UE-00078a-7f; Fri, 05 Oct 2012 11:46:26 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <20121004223115.GE97796@verdi> Date: Fri, 5 Oct 2012 11:46:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> <20121004223115.GE97796@verdi> To: John Leslie X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 9 sum msgs/h 4 total rcpts 24319 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.2, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, RP_MATCHES_RCVD=-1.17, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EBE74CED7BE88991E182C2DC44B95D31244ED6B7 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -61 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9823 max/h 20 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 09:46:30 -0000 On 5. okt. 2012, at 00:31, John Leslie wrote: > Michael Welzl wrote: >> On Oct 4, 2012, at 4:46 PM, John Leslie wrote: >> ...=20 >>> I don't see any necessary coupling between priorities of what the >>> sender would like to send and what the receiver would like to = receive. >>=20 >> Not "what the receiver would like to receive", but between the =20 >> sender's priorities and congestion control. >=20 > Two different things... >=20 >> ...=20 >> First, to clarify, I'm talking about per-packet priorities within a =20= >> stream. Second, my point is that congestion control could be done =20 >> better if packet priorities would be known, and could then be taken =20= >> into account. >=20 > I guess I'm missing why packet priorities would ever _not_ be the > domain of the sender -- even if advised by receiver preferences. It's just not what I meant. I meant priorities influencing the = congestion control behavior (I should say the "sender's" behavior, but = this discussion is about having the congestion control logic on the = sender or receiver side... so...). >> Right now, we are essentially facing greedy or non-greedy traffic, >=20 > Do you mean we're "contending against" those? If so, I agree. I would agree with that too, but I meant: congestion control mechanism = design is considering only these two classes of traffic. Sorry for my = imprecise wording here! >> and we have the LEDBAT notion of a generally lower priority. In fact = a =20 >> mechanism could opt for a more LEDBAT'ish behavior when its buffer is = =20 >> full of low-priority packets and be more aggressive when it has high-=20= >> priority packets. >=20 > If you're saying that sending rate may deserve to increase faster > when there are higher priority packets to send, I could agree but it > seems unlikely such a situation will happen. If OTOH, the sender has Yes that's what I'm saying. I don't understand why that would be = unlikely? > _only_ higher priority packets, a more aggressive sending rate _may_ > be justified. Either way, it seems unlikely to be a good idea to > increase sending rate too aggressively for low-priority packets... Yes, exactly. We can be less aggressive when we have low-priority = packets to send. >> To the best of my knowledge, these things don't really exist yet, but = =20 >> I believe that this is largely because this knowledge is not = typically =20 >> available to a congestion control mechanism. Note that conforming to =20= >> such priorities is not just some obscure idea, as there are hard = facts =20 >> for a significant qualitative impact, e.g. in the case of video. >=20 > This sounds worth discussing. (I'm seriously hopeful that the > "video codec" BoF will lead to a family of video codecs with smoother > bit-rate than is typical today.) >=20 >> But if a mechanism does such things, and it's on the receiver side, =20= >> whereas the send buffer is on the sender side, things get = problematic. =20 >> Either we fix this, or we move the mechanism to the sender, or we =20 >> ignore the chance we have, here, to do things better. I guess these =20= >> are our choices. >=20 > To tell truth, I think it's premature to specify what will be > receiver-side vs. sender-side. >=20 > Especially, I think we need intelligence at both ends in order to > communicate useful congestion information in the two directions. > Once we have designed that we will be better able to specify the > control loops. I hear you, but have a hard time imagining this without envisioning = whether the control decision is made on the sender or receiver side, as = this influences what needs to be signalled. So I think it's a key architectural decision that we'd better get right = from the outset. This is because having one side generic ("dumb") is = probably very important for deployment. Look at TCP, with its many = congestion control flavors in Linux' or FreeBSD's pluggable congestion = control. If I run a TCP based (e.g. web) server, I can just pick a = mechanism with a simple command. No need to hope for clients to support = it; no need to signal to the client what mechanism I use. No need to = even standardize it, as we had to learn the hard way... In case of rmcat in rtcweb, this would mean that browser vendor X could = simply start playing with a new congestion control mechanism (offer it = to its users or enable it by default), and that would work with all = other rtcweb/rmcat browsers, without ever having support for this = mechanism from browser vendor Y or Z. If we want that to be possible, we = need to decide which side should be the generic one at some point, and = then agree on the exact functionality of this generic side. > (Assuming ConEx ever finishes, we are likely to see some kind of > congestion-based pricing both for senders and receivers -- and the > control loops ideally would serve the price-based needs of both > senders and receivers.) I would prefer to leave this consideration aside, because 1) rmcat works = on a much tighter schedule than ConEx, as it will probably be deployed = in the rtcweb context fast, while I don't know how long we'd have to = wait for reasonably wide-spread ConEx deployment... 2) I don't think = that this matters much for our decision - in the worst case, we would = find that ConEx related information needs to be signalled from one end = to the other, and then we could consider extending to whatever = signalling scheme we define. Cheers, Michael From csp@csperkins.org Fri Oct 5 02:53:37 2012 Return-Path: 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 6B86E21F8480 for ; Fri, 5 Oct 2012 02:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWzaLPv6Z+5b for ; Fri, 5 Oct 2012 02:53:36 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id BD63321F8476 for ; Fri, 5 Oct 2012 02:53:36 -0700 (PDT) Received: from [130.209.247.112] (helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1TK4b9-00071y-AH; Fri, 05 Oct 2012 10:53:35 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <506D9801.1010104@jesup.org> Date: Fri, 5 Oct 2012 10:53:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <20121003150037.GA97796@verdi> <2CA3669B-31D4-4709-84F3-3CF25CE72EFB@ifi.uio.no> <506D9801.1010104@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -9 X-Mythic-Debug: Threshold = On = Cc: rmcat@ietf.org Subject: Re: [rmcat] Piggybacking 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 09:53:37 -0000 On 4 Oct 2012, at 15:06, Randell Jesup wrote: > On 10/4/2012 6:44 AM, Michael Welzl wrote: >> On 3. okt. 2012, at 17:00, John Leslie wrote: ... > There is an issue with 'how' piggybacking is done on RTP. In RTCP, = it's fairly easy (though more than one byte!) In RTP, you either are = changing the payload formats or you're using a header extension. (Or = we're designing RTP v3.... That would be 'interesting'.) Or defining a new RTP Profile (see section 5.3 of RFC 3550). --=20 Colin Perkins http://csperkins.org/ From lars@netapp.com Fri Oct 5 06:50:54 2012 Return-Path: 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 9286521F8714 for ; Fri, 5 Oct 2012 06:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.395 X-Spam-Level: X-Spam-Status: No, score=-10.395 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3E8IicRhVIk for ; Fri, 5 Oct 2012 06:50:53 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 81B0F21F86B6 for ; Fri, 5 Oct 2012 06:50:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,541,1344236400"; d="p7s'?scan'208";a="697683980" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 05 Oct 2012 06:50:44 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q95DohV0010291; Fri, 5 Oct 2012 06:50:44 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.46]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0309.002; Fri, 5 Oct 2012 06:50:43 -0700 From: "Eggert, Lars" To: =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: [rmcat] First meeting Thread-Index: AQHNoLhVv7ijESgSPk+u1jhA8XRZY5erNLGA Date: Fri, 5 Oct 2012 13:50:42 +0000 Message-ID: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_232247FA-8C92-4F11-8559-F3EA9BD9A968"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: rmcat WG Subject: Re: [rmcat] First meeting 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:50:54 -0000 --Apple-Mail=_232247FA-8C92-4F11-8559-F3EA9BD9A968 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On Oct 2, 2012, at 18:09, Mirja K=FChlewind = wrote: > We are about to plan our first meeting in Atlanta. We will have a 2 = hour time=20 > slot. Time and date are not announced yet but will be this week. our TENTATIVE slot is THURSDAY, November 8, 2012, 1300-1500 Afternoon = Session I. This may still change. The ID cutoff for new -00 drafts (which most of ours will be) is Oct 15. = Please make sure your draft-yourname-rmcat-* is submitted by then. Begin discussing drafts on the list as soon as they become available. = Mirja and me will gauge the need for facetime in Atlanta based on = whether list discussion indicated interest in a draft or topic. Lars= --Apple-Mail=_232247FA-8C92-4F11-8559-F3EA9BD9A968 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAwNTEzNTAzNVowIwYJKoZIhvcNAQkEMRYEFKWY eYuCusWgk3T/2Qlbk/M8XQ/JMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAFO9zYlo ic10JQHFQ7+Vr099YFe9UulK7wDhSM8Ztsc0bbHbYqyv940Jw+eS60m9FXHXWrl6F6/T+VC8jVhV 6MlOSi3HTzxLafSIVwW5u8bVqYHqLMfwSda8xUJDMuTa/qK/9jpzshOh3YKwI18aVIH6FpqTBj1u DtWmkjwRN0eFDQwPkODqify0+xvFOoc2B23YY2VhwsfKHBb/5c/852uCIiP5NazzBFEmV7iIpY7A YDmZyoOmh0pRYNIv4XzO7rR0M3x+oDuTjT0mq7vih3+CXmcL26YEL4YL+6+PU+y9qJyd8OCHns/k HnidKeD0lEi5N3UJuxM05BUjppd2RlcAAAAAAAA= --Apple-Mail=_232247FA-8C92-4F11-8559-F3EA9BD9A968-- From john@jlc.net Fri Oct 5 07:58:40 2012 Return-Path: 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 F3BF321F8471 for ; Fri, 5 Oct 2012 07:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.011 X-Spam-Level: X-Spam-Status: No, score=-106.011 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEQfMJ00JGYe for ; Fri, 5 Oct 2012 07:58:39 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E611921F846E for ; Fri, 5 Oct 2012 07:58:38 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 618A933C22; Fri, 5 Oct 2012 10:58:38 -0400 (EDT) Date: Fri, 5 Oct 2012 10:58:38 -0400 From: John Leslie To: Michael Welzl Message-ID: <20121005145838.GF97796@verdi> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> <20121004223115.GE97796@verdi> <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> User-Agent: Mutt/1.4.1i Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:58:40 -0000 Michael Welzl wrote: > On 5. okt. 2012, at 00:31, John Leslie wrote: >> Michael Welzl wrote: >> >>> First, to clarify, I'm talking about per-packet priorities within a >>> stream. Second, my point is that congestion control could be done >>> better if packet priorities would be known, and could then be taken >>> into account. >> >> I guess I'm missing why packet priorities would ever _not_ be the >> domain of the sender -- even if advised by receiver preferences. > > It's just not what I meant. I meant priorities influencing the > congestion control behavior (I should say the "sender's" behavior, > but this discussion is about having the congestion control logic > on the sender or receiver side... so...). "Priorities influencing" is actually quite separable from packet scheduling. I think we're hopelessly talking past each other here. It might help if you outlined some "likely" mixes of priorities for packets. >>> Right now, we are essentially facing greedy or non-greedy traffic, >> >> Do you mean we're "contending against" those? If so, I agree. > > I would agree with that too, but I meant: congestion control > mechanism design is considering only these two classes of traffic. Alas, I don't understand that statement either (and it sounds as if I would disagree if I did understand it). >>> In fact a mechanism could opt for a more LEDBAT'ish behavior when >>> its buffer is full of low-priority packets and be more aggressive >>> when it has high-priority packets. >> >> If you're saying that sending rate may deserve to increase faster >> when there are higher priority packets to send, I could agree but >> it seems unlikely such a situation will happen. > > Yes that's what I'm saying. I don't understand why that would be > unlikely? I expressed myself poorly, but I think we're suffering from the lack of a shared vision of "priority" again... >> If OTOH, the sender has _only_ higher priority packets, a more >> aggressive sending rate _may_ be justified. Either way, it seems >> unlikely to be a good idea to increase sending rate too aggressively >> for low-priority packets... > > Yes, exactly. We can be less aggressive when we have low-priority > packets to send. In essence, I was trying to say that an increased aggressiveness for sending high-priority packets shouldn't spill over into the rate for low-priority packets. (I still think we're talking past each other, though.) >> To tell truth, I think it's premature to specify what will be >> receiver-side vs. sender-side. >> >> Especially, I think we need intelligence at both ends in order to >> communicate useful congestion information in the two directions. >> Once we have designed that we will be better able to specify the >> control loops. > > I hear you, but have a hard time imagining this without envisioning > whether the control decision is made on the sender or receiver side, > as this influences what needs to be signalled. I think it's way to early to talk bits on the wire. > So I think it's a key architectural decision that we'd better get > right from the outset. This is because having one side generic ("dumb") > is probably very important for deployment. To the extent that _is_ important for deployment (IMHO) we'd need to design for both sending _and_ receiving to be "dumb" on one side of a two-way session. I don't think of optimizing for "one side dumb" as important for deployment, though I would certainly agree that fallback when one side turns out to be "dumb" is critical. > Look at TCP, with its many congestion control flavors in Linux' or > FreeBSD's pluggable congestion control. If I run a TCP based (e.g. web) > server, I can just pick a mechanism with a simple command. No need to > hope for clients to support it; no need to signal to the client what > mechanism I use. No need to even standardize it, as we had to learn > the hard way... Those are all sender-based-control. Are you arguing we should give up considering receiver-based-control? > In case of rmcat in rtcweb, this would mean that browser vendor X > could simply start playing with a new congestion control mechanism > (offer it to its users or enable it by default), and that would work > with all other rtcweb/rmcat browsers, without ever having support for > this mechanism from browser vendor Y or Z. That indeed is a worthy goal. But do understand that X, Y, and Z all will be both sender and receiver. > If we want that to be possible, we need to decide which side should > be the generic one at some point, and then agree on the exact > functionality of this generic side. I don't agree that's necessary or sufficient. OTOH, I _do_ believe we need to establish a feedback mechanism with a clear definition of what the feedback means (in both directions, of course). >> (Assuming ConEx ever finishes, we are likely to see some kind of >> congestion-based pricing both for senders and receivers -- and the >> control loops ideally would serve the price-based needs of both >> senders and receivers.) I expressed myself poorly again. We will (IMHO) see congestion- based pricing for both senders and receivers anyway -- it's happening already, though the measure of "congestion" is very poor. I meant to indicate that, even if absent from the first version, our control loops should allow receivers to request "lower congestion" and senders to moderate their sending rate to avoid "congestion" charges. > I would prefer to leave this consideration aside, because > 1) rmcat works on a much tighter schedule than ConEx, as it will > probably be deployed in the rtcweb context fast, while I don't > know how long we'd have to wait for reasonably wide-spread ConEx > deployment... Agreed: we may not see widespread ConEx deployment in our lifetime. > 2) I don't think that this matters much for our decision - in the > worst case, we would find that ConEx related information needs > to be signalled from one end to the other, and then we could > consider extending to whatever signalling scheme we define. Although there may (someday) be value to selective ConEx marking by the sender, it's way premature to talk about such bits on the wire. -- John Leslie From michawe@ifi.uio.no Sun Oct 7 06:18:08 2012 Return-Path: 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 65B2721F865B for ; Sun, 7 Oct 2012 06:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.159 X-Spam-Level: X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r+34mk4CBAC for ; Sun, 7 Oct 2012 06:18:07 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id C288521F863F for ; Sun, 7 Oct 2012 06:18:06 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TKqk8-00023t-TE; Sun, 07 Oct 2012 15:18:04 +0200 Received: from 108.134.189.109.customer.cdi.no ([109.189.134.108] helo=[192.168.0.197]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TKqk7-000077-RO; Sun, 07 Oct 2012 15:18:04 +0200 Message-Id: <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> From: Michael Welzl To: John Leslie In-Reply-To: <20121005145838.GF97796@verdi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 7 Oct 2012 15:17:40 +0200 References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> <20121004223115.GE97796@verdi> <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> <20121005145838.GF97796@verdi> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 3 sum msgs/h 2 total rcpts 24359 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8B427449E729BE6C9DB536E4029F8210E8AD21C2 X-UiO-SPAM-Test: remote_host: 109.189.134.108 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1503 max/h 15 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 13:18:08 -0000 Hi, Very sorry for any disadvantages that might have come from having expressed myself unclear. I'll try to clean things up in this email now: On Oct 5, 2012, at 4:58 PM, John Leslie wrote: > Michael Welzl wrote: >> On 5. okt. 2012, at 00:31, John Leslie wrote: >>> Michael Welzl wrote: >>> >>>> First, to clarify, I'm talking about per-packet priorities within a >>>> stream. Second, my point is that congestion control could be done >>>> better if packet priorities would be known, and could then be taken >>>> into account. >>> >>> I guess I'm missing why packet priorities would ever _not_ be the >>> domain of the sender -- even if advised by receiver preferences. >> >> It's just not what I meant. I meant priorities influencing the >> congestion control behavior (I should say the "sender's" behavior, >> but this discussion is about having the congestion control logic >> on the sender or receiver side... so...). > > "Priorities influencing" is actually quite separable from packet > scheduling. > > I think we're hopelessly talking past each other here. It might > help if you outlined some "likely" mixes of priorities for packets. Maybe you're considering one type of priority and me another. Indeed, in rmcat we're facing two kinds of priorities. One, priorities between streams. I think we *must* be able to support these priorities because they are required by rtcweb (A23 in draft-ietf-rtcweb-use- cases-and-requirements). In case of rtcweb, these priorities are under control of the user or at least the web site programmer via the javascript API, and should therefore probably be expected to be reasonably long-lived. Second (and this is what I meant in this current discussion), individual packets in a multimedia stream differ in importance. One easy way to say this is that a video consists of e.g. I-frames, P- frames and B-frames, where the priority is I > P > B. In reality, things are more complex: a frame typically spans multiple packets, but there are blocks in frames of different type (e.g. a P-frame may contain I- P- and B-blocks), and then there is also a dependency chain: some blocks may have many other blocks depend upon them, making them more important, and others may have less, making them less important. Honoring these priorities is important for the receiver's subjective quality - here's one out of many, many existing publications documenting this in one way or another: Michael Schier, Michael Welzl: "Optimizing Selective ARQ for H.264 Live Streaming: A Novel Method for Predicting Loss-Impact in Realtime", IEEE Transactions on Multimedia 14(2), April 2012. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6095636 Suffice to say, we can have different priorities per packet as a function of the multimedia encoding, and these priorities could quickly change (this is a way to represent the dependence - if the sending application is in control of its data until the last moment, and if it is informed about the loss of packet X, it could quickly assign a very low priority to packets that depend on X. Supporting these priorities in rmcat doesn't seem to be a MUST in accordance with the charter and rtcweb requirements. I am arguing that it would be great if we could support them. What I mean with supporting them via congestion control is: going back to the overly simplistic example of I- P- and B-"packets", one may decide to be less aggressive when the buffer is full of "B-packets" and more aggressive when it is full of "I-packets". One out of many possibilities... my point is, such functionality should be enabled by handing over the right information to the congestion controller, and this requires the controller to be close to the send buffer, or the information to be signalled to the other side. Both can be okay, but we should be clear about this. >>>> Right now, we are essentially facing greedy or non-greedy traffic, >>> >>> Do you mean we're "contending against" those? If so, I agree. >> >> I would agree with that too, but I meant: congestion control >> mechanism design is considering only these two classes of traffic. > > Alas, I don't understand that statement either (and it sounds as if > I would disagree if I did understand it). Let's leave it at that, this bit doesn't really matter for the discussion anyway. >>>> In fact a mechanism could opt for a more LEDBAT'ish behavior when >>>> its buffer is full of low-priority packets and be more aggressive >>>> when it has high-priority packets. >>> >>> If you're saying that sending rate may deserve to increase faster >>> when there are higher priority packets to send, I could agree but >>> it seems unlikely such a situation will happen. >> >> Yes that's what I'm saying. I don't understand why that would be >> unlikely? > > I expressed myself poorly, but I think we're suffering from the > lack of a shared vision of "priority" again... Perhaps; I hope my explanation above helps. >>> If OTOH, the sender has _only_ higher priority packets, a more >>> aggressive sending rate _may_ be justified. Either way, it seems >>> unlikely to be a good idea to increase sending rate too aggressively >>> for low-priority packets... >> >> Yes, exactly. We can be less aggressive when we have low-priority >> packets to send. > > In essence, I was trying to say that an increased aggressiveness > for sending high-priority packets shouldn't spill over into the rate > for low-priority packets. (I still think we're talking past each > other, though.) > >>> To tell truth, I think it's premature to specify what will be >>> receiver-side vs. sender-side. >>> >>> Especially, I think we need intelligence at both ends in order to >>> communicate useful congestion information in the two directions. >>> Once we have designed that we will be better able to specify the >>> control loops. >> >> I hear you, but have a hard time imagining this without envisioning >> whether the control decision is made on the sender or receiver side, >> as this influences what needs to be signalled. > > I think it's way to early to talk bits on the wire. > >> So I think it's a key architectural decision that we'd better get >> right from the outset. This is because having one side generic >> ("dumb") >> is probably very important for deployment. > > To the extent that _is_ important for deployment (IMHO) we'd need > to design for both sending _and_ receiving to be "dumb" on one side > of a two-way session. > > I don't think of optimizing for "one side dumb" as important for > deployment, though I would certainly agree that fallback when one side > turns out to be "dumb" is critical. See immediately below, I think this is clearer: >> Look at TCP, with its many congestion control flavors in Linux' or >> FreeBSD's pluggable congestion control. If I run a TCP based (e.g. >> web) >> server, I can just pick a mechanism with a simple command. No need to >> hope for clients to support it; no need to signal to the client what >> mechanism I use. No need to even standardize it, as we had to learn >> the hard way... > > Those are all sender-based-control. Are you arguing we should give > up considering receiver-based-control? I'm arguing that we should have either this, or strictly only-receiver- based control. Then we could get the same functionality: you could just change the receiver to use a new mechanism X, without waiting for the sender to support the new mechanism X or even signalling to the sender what mechanism to use. Sender- or receiver- based, but not both. Note that this doesn't exclude two-way behavior at all. To get back to the example of TCP and sender-based control, it's absolutely possible to have two way communication on a connection there, where one side uses say CUBIC congestion control and the other Compound TCP. Each side doesn't require any specific behavior from the other, because it simply expects the other side to show the simple generic receiver behavior. This is what I'd like to see in rmcat. (again, the situation is the same for the case of receiver-based control with a generic, generally agreed upon sender behavior - but spreading each congestion controller over both sides ruins this ability) >> In case of rmcat in rtcweb, this would mean that browser vendor X >> could simply start playing with a new congestion control mechanism >> (offer it to its users or enable it by default), and that would work >> with all other rtcweb/rmcat browsers, without ever having support for >> this mechanism from browser vendor Y or Z. > > That indeed is a worthy goal. But do understand that X, Y, and Z > all will be both sender and receiver. See just above, I hope this was clear enough. >> If we want that to be possible, we need to decide which side should >> be the generic one at some point, and then agree on the exact >> functionality of this generic side. > > I don't agree that's necessary or sufficient. OTOH, I _do_ believe > we need to establish a feedback mechanism with a clear definition > of what the feedback means (in both directions, of course). I do believe it's necessary (sufficient, no - indeed we'd need a clearly defined feedback mechanism). For example, with strict receiver- based control, only having a clearly defined feedback mechanism will not make flexible use of controls as with TCP possible. Or, in other words: having e.g. RRTCC's sender behavior but multiply defined receiver behaviors would make this flexibility possible, but having multiple sender- AND receiver-behaviors will not. >>> (Assuming ConEx ever finishes, we are likely to see some kind of >>> congestion-based pricing both for senders and receivers -- and the >>> control loops ideally would serve the price-based needs of both >>> senders and receivers.) > > I expressed myself poorly again. We will (IMHO) see congestion- > based pricing for both senders and receivers anyway -- it's happening > already, though the measure of "congestion" is very poor. > > I meant to indicate that, even if absent from the first version, > our control loops should allow receivers to request "lower congestion" > and senders to moderate their sending rate to avoid "congestion" > charges. Agreed, but I don't see a problem in doing this with either sender- or receiver-based control. >> I would prefer to leave this consideration aside, because >> 1) rmcat works on a much tighter schedule than ConEx, as it will >> probably be deployed in the rtcweb context fast, while I don't >> know how long we'd have to wait for reasonably wide-spread ConEx >> deployment... > > Agreed: we may not see widespread ConEx deployment in our lifetime. > >> 2) I don't think that this matters much for our decision - in the >> worst case, we would find that ConEx related information needs >> to be signalled from one end to the other, and then we could >> consider extending to whatever signalling scheme we define. > > Although there may (someday) be value to selective ConEx marking > by the sender, it's way premature to talk about such bits on the wire. > > -- > John Leslie Cheers, Michael From ingemar.s.johansson@ericsson.com Mon Oct 8 00:26:41 2012 Return-Path: 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 6BBDC21F8770 for ; Mon, 8 Oct 2012 00:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-I3JSE1pC4a for ; Mon, 8 Oct 2012 00:26:40 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C7BC721F8754 for ; Mon, 8 Oct 2012 00:26:39 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-33-5072802ecc4f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 89.64.25676.E2082705; Mon, 8 Oct 2012 09:26:38 +0200 (CEST) Received: from ESESSHC003.ericsson.se (153.88.183.27) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 8 Oct 2012 09:26:37 +0200 Received: from ESESSMB205.ericsson.se ([169.254.5.129]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 09:26:37 +0200 From: Ingemar Johansson S To: Michael Welzl , rmcat WG Thread-Topic: [rmcat] Piggybacking Thread-Index: AQHNoj8WX/Qxdi9ThEmPBoOiVuGqVZevBe7g Date: Mon, 8 Oct 2012 07:26:37 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA0244E0@ESESSMB205.ericsson.se> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <20121003150037.GA97796@verdi> <2CA3669B-31D4-4709-84F3-3CF25CE72EFB@ifi.uio.no> In-Reply-To: <2CA3669B-31D4-4709-84F3-3CF25CE72EFB@ifi.uio.no> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+Jvra5eQ1GAwbITQhbLX55gtPhxdier xeqbH9gcmD2m3b/P5rFkyU8mj9WrHzIHMEdx2aSk5mSWpRbp2yVwZZx5+5C5YJ5rxce2FywN jPfNuxg5OSQETCQOHn3BAmGLSVy4t56ti5GLQ0jgFKPEhalzWUESQgI7GCUWrhCESCxmlOjq vsQOkmATsJFYeeg7I4gtIuAo0fXiBxOIzSygLfHu2g6wqcICihJrDk9lgahRkvjy9j87hG0k ser0OzYQm0VARaJlSgtYDa+At8TxP/+grrjEKDFjxT6wKzgF7CRmvzwBtoBRQFbi/vd7LBDL xCVuPZnPBPGCgMSSPeeZIWxRiZeP/7FC2IoSH1/tY4So15FYsPsTG8yhyxa+ZoZYLChxcuYT FoiPdSXW77jKPoFRYhaSFbOQtM9C0j4LSfsCRpZVjMK5iZk56eVGeqlFmcnFxfl5esWpmxiB MXhwy2/VHYx3zokcYpTmYFES57XeusdfSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Pbz80Z ZZuYk9pVTGR4xL94ZzYyhVn8Z5lje7ZVMmxa2KULaSorWT9elztauMtc5FLJNyn7Ld0KmyJT JCd4Jbxcc/f/X+fAV+J39rYeSOVouL4w6uPzHWcmpfDMl6rJ43Gzu37qvvAHjWu+qUkMdaWq +rlvDqdLb/NMvR20PmfhJMVdN8/O+KfEUpyRaKjFXFScCABdt0kQjwIAAA== Cc: "csp@csperkins.org" Subject: Re: [rmcat] Piggybacking 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 07:26:41 -0000 Hi This brings up old memories (OK, not that old) I proposed something very 3GPP AMR specific ~6 years ago.=20 http://tools.ietf.org/html/draft-johansson-avt-rtp-shim-01=20 The message in the AVT WG was then to define a new RTP profile or use RTCP,= we ended up with reduced size RTCP (RFC5506) /Ingemar -----Original Message----- From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 Sent: den 4 oktober 2012 12:44 To: rmcat WG Subject: Re: [rmcat] Piggybacking Hi, On 3. okt. 2012, at 17:00, John Leslie wrote: > Randell Jesup wrote: >> On 9/24/2012 10:46 AM, Harald Alvestrand wrote: >>>=20 >>> In the TCP case, the feedback mechanism is the ack, which is needed=20 >>> for reasons beyond congestion control. In the RTP case, there isn't=20 >>> such a single, simple mechanism needed for other reasons. >>=20 >> Agreed, though Michael indicated that we can piggyback congestion=20 >> info on reverse traffic. >>=20 >> This may be possible and I've thought about it. Part of the problem=20 >> is that if you want to signal data back quickly, you have to wait up=20 >> to 20ms and in some cases longer to piggyback (and on=20 >> low-upstream-bandwidth links, the uplink transit time if you're=20 >> piggybacking on a 1500-byte video packet might be 20+ms). >=20 > This is missing the point, IMHO. >=20 > We are dealing in IP packets -- "unreliable" packets: meaning that=20 > we aren't entitled to expect any particular packet to be delivered at=20 > all. >=20 > The signal we wish to send is tiny -- probably on the order of one=20 > byte. If we allocate one byte per packet for feedback, it's almost=20 > lost in the noise. >=20 > But if we expect that byte and it doesn't arrive, that's a clear=20 > congestion signal. >=20 > (Granted its loss signals congestion in the path _to_ us...) >=20 > Trying to optimize 20 msec of reaction time for real-time traffic=20 > isn't the right paradigm. We want real-time traffic to adapt more=20 > slowly than web-surfing traffic, but stay low for longer (to avoid=20 > self-congestion). >=20 > Thus, we can be pretty sure that the absence of an expected feedback=20 > justifies a delay in any ramp-up of outgoing bit-rate currently planned. Indeed, I'm not sure a quick signal is always needed. Either way, as John s= ays, a packet may be lost and the signal is tiny. We could agree to always = piggyback - if the signal really can't wait, we can send it immediately but= include it piggybacked onto the next datapacket too, for redundancy, makin= g the whole thing more stable in case a feedback packet gets lost. > Beyond that, it gets more complicated. Nonetheless, we can easily=20 > signal in our next scheduled outgoing packet that we missed an=20 > expected feedback; and that signal (or the failure to receive our next=20 > outgoing packeti) can trigger a retransmission -- catching up=20 > typically faster than TCP can do. I don't get that, and it sounds complicated and inefficient - you're adding= round-trips here? > I'd like to suggest that we plan RMCAT around bidirectional (though=20 > possibly very small in one direction) media packets. There > aren't many cases where the traffic is _so_ unidirectional that an=20 > "I'm still interested in this stream" isn't appropriate. > (I don't mean to imply that the packet-rate needs to be the same in=20 > both directions, least of all the bit-rate.) >=20 >> If you do piggyback, it has to be optional on a instance-by-instance=20 >> basis >=20 > This is precisely what I _don't_ want to see. Perhaps the size of=20 > the feedback might vary (though I doubt that's needed); but I want the=20 > _absence_ of feedback to be a primary signal. >=20 >> (perhaps even estimating when the next chance will be, and the=20 >> priority of the data - but that speaks against a dumb receiver). >=20 > (I don't think it makes sense to even think about a "dumb receiver.) Call it a *generic* receiver. That's what was meant in this discussion. The problem is really that it's a (major, I think) benefit for deployment t= o have one side generic, and a generic sender is a more complicated setting= than a generic receiver... in my opinion, none of the two choices are real= ly ideal. To have things combined in the right place, I'll address this in = a separate email in which I extend my previous analysis of the sender/recei= ver situation. >> TCP can "get away" with high packet count feedback because flows are=20 >> typically largely unidirectional or alternating flows, or on=20 >> well-connected devices, not edge nodes. The PacketCable/etc issue=20 >> with shared upstreams and slot allocation is an example of reacting=20 >> to this - there even with the typically largely downstream flows, the=20 >> upstream acks become a limiting factor. >=20 > Yes! >=20 > This issue is very real in cable-upstream, and also significant in=20 > many wireless setups. >=20 > But the right approach is to measure "upstream" congestion and adapt=20 > our packet rate to it. Really-tiny upstream packet aren't much "cheaper" > than medium-sized upstream packets. That was my argument too; it does add some complexity though. See my next e= mail on sender vs receiver... As for John's comments below, I agree with many of them. > Granted, it's easy to confuse upstream-congestion with downstream-=20 > congestion; but it's not _that_ hard to separate them. >=20 >>> Stickler: Amount of feedback has little correlation with packet drop.=20 >>> If feedback is lost due to congestion, more feedback will lead to=20 >>> more packet drops. What is true is that when feedback occurs more=20 >>> rarely, losing one feedback packet will lead to a greater gap=20 >>> between feedback packets. >=20 > This is true, but some possible inferences are not true... >=20 >> I'd say less feedback means the odds that a drop will hit a feedback=20 >> packet are *lower* (as routers typically either tail-drop or=20 >> random-drop, but in either case in a static evaluation a=20 >> lower-bandwidth/packet flow (i.e. the feedback packets) will get hit=20 >> less often), but as Harald says the impact is higher. And in a=20 >> dynamic evaluation this may shift some. >=20 > In particular, inferring that we must do slavish AIMD is not true. >=20 >>>> - receiver-side-congestion-control-based feedback reduction as in=20 >>>> RRTCC means to reduce the feedback whenever feedback isn't urgent=20 >>>> for the sender. I'd argue that, in fact, we should reduce feedback=20 >>>> only when the channel carrying it (the backwards channel) is=20 >>>> congested, and that is a generic function, not bound to the=20 >>>> sender-side congestion control behavior. >=20 > I agree that reducing feedback when the feedback path is not=20 > congested really doesn't help. >=20 > (When we _do_ need to reduce feedback, I suggest we need to lower=20 > the packet-rate, letting the chips fall where they may; and be slow to=20 > increase it again.) >=20 >> Personally, I assume both channels are always congested, or will be=20 >> soon (if we're doing our job right and aren't on a huge link), >=20 > The assumption isn't particularly bad; but I envision many cases=20 > where it isn't true. >=20 >> so bandwidth reduction for feedback always allows more bandwidth for=20 >> useful data. >=20 > While technically true, it's a bad tradeoff to discard information=20 > about congestion -- this leads to growing your bit-rate too fast, and=20 > more packet-loss than necessary. >=20 >> ...=20 >> And my position is that any *good* two-way communication will run=20 >> near-but-not-quite-over the bandwidth limit as much of the time as=20 >> possible, so ACKs always have the potential to cause problems (and=20 >> always will force you a little further down the quality curve). >=20 > I don't agree with this conclusion. >=20 > With "ideal" feedback, we can be sure we don't initiate any=20 > congestion problems, while "minimal" feedback means some of our=20 > guesses will be wrong. >=20 > And I don't think we have a good understanding of "the quality=20 > curve" yet. >=20 > Some real-time stacks will run very close to the maximum data-rate,=20 > and hopefully will have good redundancy algorithms to reconstruct lost=20 > packets. Others will choose to stay below the maximum. We shouldn't=20 > prejudge that tradeoff, but limit ourselves to timely delivery of the=20 > best congestion information, and algorithms for rate-adjustment. >=20 > -- > John Leslie > _______________________________________________ > rmcat mailing list > rmcat@ietf.org > https://www.ietf.org/mailman/listinfo/rmcat From michawe@ifi.uio.no Mon Oct 8 00:47:46 2012 Return-Path: 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 22B8121F8780 for ; Mon, 8 Oct 2012 00:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.779 X-Spam-Level: X-Spam-Status: No, score=-101.779 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqoVDsPUerGK for ; Mon, 8 Oct 2012 00:47:44 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 3B58A21F8769 for ; Mon, 8 Oct 2012 00:47:44 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TL83y-0000tP-Pr for rmcat@ietf.org; Mon, 08 Oct 2012 09:47:42 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TL83y-0006ED-DX for rmcat@ietf.org; Mon, 08 Oct 2012 09:47:42 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Michael Welzl In-Reply-To: <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> Date: Mon, 8 Oct 2012 09:47:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <26390412-C08B-47A9-B94E-4AB0B4D131A9@ifi.uio.no> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> <20121004223115.GE97796@verdi> <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> <20121005145838.GF97796@verdi> <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> To: rmcat WG X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 7 sum msgs/h 4 total rcpts 24380 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.2, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, RP_MATCHES_RCVD=-1.17, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 793E919A4C428111CE035448004CDF04A09C05C1 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -61 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 9841 max/h 20 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 07:47:46 -0000 This gave me an extra thought: > Second (and this is what I meant in this current discussion), = individual packets in a multimedia stream differ in importance. One easy = way to say this is that a video consists of e.g. I-frames, P-frames and = B-frames, where the priority is I > P > B. In reality, things are more = complex: a frame typically spans multiple packets, but there are blocks = in frames of different type (e.g. a P-frame may contain I- P- and = B-blocks), and then there is also a dependency chain: some blocks may = have many other blocks depend upon them, making them more important, and = others may have less, making them less important. Honoring these = priorities is important for the receiver's subjective quality - here's = one out of many, many existing publications documenting this in one way = or another: > Michael Schier, Michael Welzl: "Optimizing Selective ARQ for H.264 = Live Streaming: A Novel Method for Predicting Loss-Impact in Realtime", = IEEE Transactions on Multimedia 14(2), April 2012. > http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D6095636 I don't know how many systems do these sort of thing in practice, but I = know that there are lots and lots of papers on such content-aware = mechanisms. What they tend to do is either ARQ or FEC, and yes, these = things can operate in real-time (also the mechanism in our paper above = was designed for that), i.e. they work for interactive media. For this stuff to work, what is needed at the sender is precise = knowledge about which packets have been lost, as quickly as possible. = This means that, if we go for a = receiver-side-congestion-control-sending-as-little-feedback-as-possible = scheme, we should have "special" feedback whenever loss happens: provide = fine-grain information about exactly which packets were lost, and = probably increase the feedback frequency. Given that this is about loss on the sender=3D>receiver path which may = not be affected by increased traffic on the receiver=3D>sender path, I = don't see a big problem in doing this. It just complicates the = minimum-feedback-due-to-receiver-side-cc. case somewhat, I suppose. Cheers, Michael From holmer@google.com Mon Oct 8 04:43:12 2012 Return-Path: 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 0629621F8682 for ; Mon, 8 Oct 2012 04:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N62eSjzUOpnR for ; Mon, 8 Oct 2012 04:43:10 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8CAA21F867E for ; Mon, 8 Oct 2012 04:43:09 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so10369529iec.31 for ; Mon, 08 Oct 2012 04:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=+Wo7noJjr8+eavSpgLR70Btt0jqe5f2F8ozuJouNnzY=; b=MjpBaAaTGI4KwyK9LGc7PQ+Hjjo1X4OVj5uX2fVzsLJeD4+4APpSq6RAO0FV+B+pQq VvqW23F/j5Q4Q09TVSSjKBzsPYLqfJ8PL+zWW//wHcQ91prGWlX7IfOAqxpcnVlency4 dOIIzzd0cGuHNDqYU/RcU8/ZBalw4NRdIA0p7jmKKB2tu0TkLeHLnQKyY0xEzDCOtAI3 t8/OBbwgm4yCKGXu8qRkuoPmAnN9uytYRiEIyIXNh3bPf067AIwiU3MYyq4swB19Bdl1 sxDWqDWFyz6K3FV+D8ul8gGtiUbwTuOiI4kiIbh1NG2ZXuEx/5M2xP+BOXY5L/gz5vf7 QkaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=+Wo7noJjr8+eavSpgLR70Btt0jqe5f2F8ozuJouNnzY=; b=BqHSaAR+mZcL4JWDltVWcYOzJ03bOzpDueWveq7T05ghKjXSIYBH2yfPrgEVKfcyMW 1hwaZwhMdDKBGQJ6/30QRXR9cAdNUB5QWE3RYFAEU4jvNnwlLR2aRjZTnEpoTzgUWhp5 6FtjyiNhIcPYGgNj3S0aK4/fzeE4IMotMibXZ8kc0z/f7friFFJmwfn7SUVkGzIyitsd 1gGMSSasLSzkfftNLmvwpd90A3AyC+ASyURqJQQd53plk8l6/7CJc8tQB4tR3gL64CIO UeEJdDrkH5U3kxaR7df7PWPIhaae5AKbudkJtGgSLPF52Vkd53347c22d8L1ASk9SwOI QVMg== MIME-Version: 1.0 Received: by 10.50.40.163 with SMTP id y3mr7913849igk.32.1349696589412; Mon, 08 Oct 2012 04:43:09 -0700 (PDT) Sender: holmer@google.com Received: by 10.50.45.133 with HTTP; Mon, 8 Oct 2012 04:43:09 -0700 (PDT) In-Reply-To: <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> <20121004223115.GE97796@verdi> <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> <20121005145838.GF97796@verdi> <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> Date: Mon, 8 Oct 2012 13:43:09 +0200 X-Google-Sender-Auth: 7zik3_Ye4u6qgAIJ_77OnAwZg38 Message-ID: From: Stefan Holmer To: Michael Welzl Content-Type: multipart/alternative; boundary=14dae9340dc9c43a7804cb8ab9bf X-System-Of-Record: true X-Gm-Message-State: ALoCoQnii0IypY87+g5nchsm106IDJSVyoeXhvAR1pBcVzqhmS7yTSlNehW3sCw5IY803QJ2itsuhV+sSl7swHUOFZdh/AABPWVMN/xBVIU6/zc8NKal40+dm6p1RIt4nOodmRJgfENKUGE0akhOuKC02fSeIfLvRR6ypax1ukv1H0lVBflufvHkv4sp0gPrBemoHbQlESrW Cc: rmcat WG , John Leslie Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 11:43:12 -0000 --14dae9340dc9c43a7804cb8ab9bf Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 7, 2012 at 3:17 PM, Michael Welzl wrote: > Hi, > > Very sorry for any disadvantages that might have come from having > expressed myself unclear. I'll try to clean things up in this email now: > > > > On Oct 5, 2012, at 4:58 PM, John Leslie wrote: > > Michael Welzl wrote: >> >>> On 5. okt. 2012, at 00:31, John Leslie wrote: >>> >>>> Michael Welzl wrote: >>>> >>>> First, to clarify, I'm talking about per-packet priorities within a >>>>> stream. Second, my point is that congestion control could be done >>>>> better if packet priorities would be known, and could then be taken >>>>> into account. >>>>> >>>> >>>> I guess I'm missing why packet priorities would ever _not_ be the >>>> domain of the sender -- even if advised by receiver preferences. >>>> >>> >>> It's just not what I meant. I meant priorities influencing the >>> congestion control behavior (I should say the "sender's" behavior, >>> but this discussion is about having the congestion control logic >>> on the sender or receiver side... so...). >>> >> >> "Priorities influencing" is actually quite separable from packet >> scheduling. >> >> I think we're hopelessly talking past each other here. It might >> help if you outlined some "likely" mixes of priorities for packets. >> > > Maybe you're considering one type of priority and me another. > > Indeed, in rmcat we're facing two kinds of priorities. One, priorities > between streams. I think we *must* be able to support these priorities > because they are required by rtcweb (A23 in draft-ietf-rtcweb-use-cases-**and-requirements). > In case of rtcweb, these priorities are under control of the user or at > least the web site programmer via the javascript API, and should therefore > probably be expected to be reasonably long-lived. > > Second (and this is what I meant in this current discussion), individual > packets in a multimedia stream differ in importance. One easy way to say > this is that a video consists of e.g. I-frames, P-frames and B-frames, > where the priority is I > P > B. In reality, things are more complex: a > frame typically spans multiple packets, but there are blocks in frames of > different type (e.g. a P-frame may contain I- P- and B-blocks), and then > there is also a dependency chain: some blocks may have many other blocks > depend upon them, making them more important, and others may have less, > making them less important. Honoring these priorities is important for the > receiver's subjective quality - here's one out of many, many existing > publications documenting this in one way or another: > Michael Schier, Michael Welzl: "Optimizing Selective ARQ for H.264 Live > Streaming: A Novel Method for Predicting Loss-Impact in Realtime", IEEE > Transactions on Multimedia 14(2), April 2012. > http://ieeexplore.ieee.org/**xpls/abs_all.jsp?arnumber=**6095636 > > Suffice to say, we can have different priorities per packet as a function > of the multimedia encoding, and these priorities could quickly change (this > is a way to represent the dependence - if the sending application is in > control of its data until the last moment, and if it is informed about the > loss of packet X, it could quickly assign a very low priority to packets > that depend on X. > > Supporting these priorities in rmcat doesn't seem to be a MUST in > accordance with the charter and rtcweb requirements. I am arguing that it > would be great if we could support them. > > What I mean with supporting them via congestion control is: going back to > the overly simplistic example of I- P- and B-"packets", one may decide to > be less aggressive when the buffer is full of "B-packets" and more > aggressive when it is full of "I-packets". One out of many possibilities... > my point is, such functionality should be enabled by handing over the right > information to the congestion controller, and this requires the controller > to be close to the send buffer, or the information to be signalled to the > other side. Both can be okay, but we should be clear about this. You want to allow the sender to, for a short time, override the bandwidth estimate by sending at a higher rate because it has important packets to send? Isn't this possible even though the estimator is at the receiver? I'm also not sure that is something you want to do. Sending important packets at a higher rate increases the risk of losing those important packets, which is the opposite of what you want, right? > > > > Right now, we are essentially facing greedy or non-greedy traffic, >>>>> >>>> >>>> Do you mean we're "contending against" those? If so, I agree. >>>> >>> >>> I would agree with that too, but I meant: congestion control >>> mechanism design is considering only these two classes of traffic. >>> >> >> Alas, I don't understand that statement either (and it sounds as if >> I would disagree if I did understand it). >> > > Let's leave it at that, this bit doesn't really matter for the discussion > anyway. > > > > In fact a mechanism could opt for a more LEDBAT'ish behavior when >>>>> its buffer is full of low-priority packets and be more aggressive >>>>> when it has high-priority packets. >>>>> >>>> >>>> If you're saying that sending rate may deserve to increase faster >>>> when there are higher priority packets to send, I could agree but >>>> it seems unlikely such a situation will happen. >>>> >>> >>> Yes that's what I'm saying. I don't understand why that would be >>> unlikely? >>> >> >> I expressed myself poorly, but I think we're suffering from the >> lack of a shared vision of "priority" again... >> > > Perhaps; I hope my explanation above helps. > > > > If OTOH, the sender has _only_ higher priority packets, a more >>>> aggressive sending rate _may_ be justified. Either way, it seems >>>> unlikely to be a good idea to increase sending rate too aggressively >>>> for low-priority packets... >>>> >>> >>> Yes, exactly. We can be less aggressive when we have low-priority >>> packets to send. >>> >> >> In essence, I was trying to say that an increased aggressiveness >> for sending high-priority packets shouldn't spill over into the rate >> for low-priority packets. (I still think we're talking past each >> other, though.) >> >> To tell truth, I think it's premature to specify what will be >>>> receiver-side vs. sender-side. >>>> >>>> Especially, I think we need intelligence at both ends in order to >>>> communicate useful congestion information in the two directions. >>>> Once we have designed that we will be better able to specify the >>>> control loops. >>>> >>> >>> I hear you, but have a hard time imagining this without envisioning >>> whether the control decision is made on the sender or receiver side, >>> as this influences what needs to be signalled. >>> >> >> I think it's way to early to talk bits on the wire. >> >> So I think it's a key architectural decision that we'd better get >>> right from the outset. This is because having one side generic ("dumb") >>> is probably very important for deployment. >>> >> >> To the extent that _is_ important for deployment (IMHO) we'd need >> to design for both sending _and_ receiving to be "dumb" on one side >> of a two-way session. >> >> I don't think of optimizing for "one side dumb" as important for >> deployment, though I would certainly agree that fallback when one side >> turns out to be "dumb" is critical. >> > > See immediately below, I think this is clearer: > > > > Look at TCP, with its many congestion control flavors in Linux' or >>> FreeBSD's pluggable congestion control. If I run a TCP based (e.g. web) >>> server, I can just pick a mechanism with a simple command. No need to >>> hope for clients to support it; no need to signal to the client what >>> mechanism I use. No need to even standardize it, as we had to learn >>> the hard way... >>> >> >> Those are all sender-based-control. Are you arguing we should give >> up considering receiver-based-control? >> > > I'm arguing that we should have either this, or strictly > only-receiver-based control. Then we could get the same functionality: you > could just change the receiver to use a new mechanism X, without waiting > for the sender to support the new mechanism X or even signalling to the > sender what mechanism to use. Sender- or receiver- based, but not both. > > Note that this doesn't exclude two-way behavior at all. To get back to the > example of TCP and sender-based control, it's absolutely possible to have > two way communication on a connection there, where one side uses say CUBIC > congestion control and the other Compound TCP. Each side doesn't require > any specific behavior from the other, because it simply expects the other > side to show the simple generic receiver behavior. This is what I'd like to > see in rmcat. > > (again, the situation is the same for the case of receiver-based control > with a generic, generally agreed upon sender behavior - but spreading each > congestion controller over both sides ruins this ability) > > > > In case of rmcat in rtcweb, this would mean that browser vendor X >>> could simply start playing with a new congestion control mechanism >>> (offer it to its users or enable it by default), and that would work >>> with all other rtcweb/rmcat browsers, without ever having support for >>> this mechanism from browser vendor Y or Z. >>> >> >> That indeed is a worthy goal. But do understand that X, Y, and Z >> all will be both sender and receiver. >> > > See just above, I hope this was clear enough. > > > > If we want that to be possible, we need to decide which side should >>> be the generic one at some point, and then agree on the exact >>> functionality of this generic side. >>> >> >> I don't agree that's necessary or sufficient. OTOH, I _do_ believe >> we need to establish a feedback mechanism with a clear definition >> of what the feedback means (in both directions, of course). >> > > I do believe it's necessary (sufficient, no - indeed we'd need a clearly > defined feedback mechanism). For example, with strict receiver-based > control, only having a clearly defined feedback mechanism will not make > flexible use of controls as with TCP possible. Or, in other words: having > e.g. RRTCC's sender behavior but multiply defined receiver behaviors would > make this flexibility possible, but having multiple sender- AND > receiver-behaviors will not. > > > > (Assuming ConEx ever finishes, we are likely to see some kind of >>>> congestion-based pricing both for senders and receivers -- and the >>>> control loops ideally would serve the price-based needs of both >>>> senders and receivers.) >>>> >>> >> I expressed myself poorly again. We will (IMHO) see congestion- >> based pricing for both senders and receivers anyway -- it's happening >> already, though the measure of "congestion" is very poor. >> >> I meant to indicate that, even if absent from the first version, >> our control loops should allow receivers to request "lower congestion" >> and senders to moderate their sending rate to avoid "congestion" >> charges. >> > > Agreed, but I don't see a problem in doing this with either sender- or > receiver-based control. > > > > I would prefer to leave this consideration aside, because >>> 1) rmcat works on a much tighter schedule than ConEx, as it will >>> probably be deployed in the rtcweb context fast, while I don't >>> know how long we'd have to wait for reasonably wide-spread ConEx >>> deployment... >>> >> >> Agreed: we may not see widespread ConEx deployment in our lifetime. >> >> 2) I don't think that this matters much for our decision - in the >>> worst case, we would find that ConEx related information needs >>> to be signalled from one end to the other, and then we could >>> consider extending to whatever signalling scheme we define. >>> >> >> Although there may (someday) be value to selective ConEx marking >> by the sender, it's way premature to talk about such bits on the wire. >> >> -- >> John Leslie >> > > > Cheers, > Michael > > --14dae9340dc9c43a7804cb8ab9bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sun, O= ct 7, 2012 at 3:17 PM, Michael Welzl <michawe@ifi.uio.no= > wrote:
Hi,

Very sorry for any disadvantages that might have come from having expressed= myself unclear. I'll try to clean things up in this email now:



On Oct 5, 2012, at 4:58 PM, John Leslie wrote:

Michael Welzl <michawe@ifi.uio.no> wrote:
On 5. okt. 2012, at 00:31, John Leslie wrote:
Michael Welzl <michawe@ifi.uio.no> wrote:

First, to clarify, I'm talking about per-packet priorities within a
stream. Second, my point is that congestion control could be done
better if packet priorities would be known, and could then be taken
into account.

I guess I'm missing why packet priorities would ever _not_ be the
domain of the sender -- even if advised by receiver preferences.

It's just not what I meant. I meant priorities influencing the
congestion control behavior (I should say the "sender's" beha= vior,
but this discussion is about having the congestion control logic
on the sender or receiver side... so...).

=A0 "Priorities influencing" is actually quite separable from pac= ket
scheduling.

=A0 I think we're hopelessly talking past each other here. It might
help if you outlined some "likely" mixes of priorities for packet= s.

Maybe you're considering one type of priority and me another.

Indeed, in rmcat we're facing two kinds of priorities. One, priorities = between streams. I think we *must* be able to support these priorities beca= use they are required by rtcweb (A23 in draft-ietf-rtcweb-use-cases-= and-requirements). In case of rtcweb, these priorities are under control of= the user or at least the web site programmer via the javascript API, and s= hould therefore probably be expected to be reasonably long-lived.

Second (and this is what I meant in this current discussion), individual pa= ckets in a multimedia stream differ in importance. One easy way to say this= is that a video consists of e.g. I-frames, P-frames and B-frames, where th= e priority is I > P > B. In reality, things are more complex: a frame= typically spans multiple packets, but there are blocks in frames of differ= ent type (e.g. a P-frame may contain I- P- and B-blocks), and then there is= also a dependency chain: some blocks may have many other blocks depend upo= n them, making them more important, and others may have less, making them l= ess important. Honoring these priorities is important for the receiver'= s subjective quality - here's one out of many, many existing publicatio= ns documenting this in one way or another:
Michael Schier, Michael Welzl: "Optimizing Selective ARQ for H.264 Liv= e Streaming: A Novel Method for Predicting Loss-Impact in Realtime", I= EEE Transactions on Multimedia 14(2), April 2012.
http://ieeexplore.ieee.org/xpls/a= bs_all.jsp?arnumber=3D6095636

Suffice to say, we can have different priorities per packet as a function o= f the multimedia encoding, and these priorities could quickly change (this = is a way to represent the dependence - if the sending application is in con= trol of its data until the last moment, and if it is informed about the los= s of packet X, it could quickly assign a very low priority to packets that = depend on X.

Supporting these priorities in rmcat doesn't seem to be a MUST in accor= dance with the charter and rtcweb requirements. I am arguing that it would = be great if we could support them.

What I mean with supporting them via congestion control is: going back to t= he overly simplistic example of I- P- and B-"packets", one may de= cide to be less aggressive when the buffer is full of "B-packets"= and more aggressive when it is full of "I-packets". One out of m= any possibilities... my point is, such functionality should be enabled by h= anding over the right information to the congestion controller, and this re= quires the controller to be close to the send buffer, or the information to= be signalled to the other side. Both can be okay, but we should be clear a= bout this.

You want to allow the sender to, for a short time, over= ride the bandwidth estimate by sending at a higher rate because it has impo= rtant packets to send? Isn't this possible even though the estimator is= at the receiver? I'm also not sure that is something you want to do. S= ending important packets at a higher rate increases the risk of losing thos= e important packets, which is the opposite of what you want, right?
=A0



Right now, we are essentially facing greedy or non-greedy traffic,

Do you mean we're "contending against" those? If so, I agree.=

I would agree with that too, but I meant: congestion control
mechanism design is considering only these two classes of traffic.

=A0 Alas, I don't understand that statement either (and it sounds as if=
I would disagree if I did understand it).

Let's leave it at that, this bit doesn't really matter for the disc= ussion anyway.



In fact a mechanism could opt for a more LEDBAT'ish behavior when
its buffer is full of low-priority packets and be more aggressive
when it has high-priority packets.

If you're saying that sending rate may deserve to increase faster
when there are higher priority packets to send, I could agree but
it seems unlikely such a situation will happen.

Yes that's what I'm saying. I don't understand why that would b= e
unlikely?

=A0 I expressed myself poorly, but I think we're suffering from the
lack of a shared vision of "priority" again...

Perhaps; I hope my explanation above helps.



If OTOH, the sender has _only_ higher priority packets, a more
aggressive sending rate _may_ be justified. Either way, it seems
unlikely to be a good idea to increase sending rate too aggressively
for low-priority packets...

Yes, exactly. We can be less aggressive when we have low-priority
packets to send.

=A0 In essence, I was trying to say that an increased aggressiveness
for sending high-priority packets shouldn't spill over into the rate for low-priority packets. (I still think we're talking past each
other, though.)

To tell truth, I think it's premature to specify what will be
receiver-side vs. sender-side.

Especially, I think we need intelligence at both ends in order to
communicate useful congestion information in the two directions.
Once we have designed that we will be better able to specify the
control loops.

I hear you, but have a hard time imagining this without envisioning
whether the control decision is made on the sender or receiver side,
as this influences what needs to be signalled.

=A0 I think it's way to early to talk bits on the wire.

So I think it's a key architectural decision that we'd better get right from the outset. This is because having one side generic ("dumb&= quot;)
is probably very important for deployment.

=A0 To the extent that _is_ important for deployment (IMHO) we'd need to design for both sending _and_ receiving to be "dumb" on one si= de
of a two-way session.

=A0 I don't think of optimizing for "one side dumb" as import= ant for
deployment, though I would certainly agree that fallback when one side
turns out to be "dumb" is critical.

See immediately below, I think this is clearer:



Look at TCP, with its many congestion control flavors in Linux' or
FreeBSD's pluggable congestion control. If I run a TCP based (e.g. web)=
server, I can just pick a mechanism with a simple command. No need to
hope for clients to support it; no need to signal to the client what
mechanism I use. No need to even standardize it, as we had to learn
the hard way...

=A0 Those are all sender-based-control. Are you arguing we should give
up considering receiver-based-control?

I'm arguing that we should have either this, or strictly only-receiver-= based control. Then we could get the same functionality: you could just cha= nge the receiver to use a new mechanism X, without waiting for the sender t= o support the new mechanism X or even signalling to the sender what mechani= sm to use. Sender- or receiver- based, but not both.

Note that this doesn't exclude two-way behavior at all. To get back to = the example of TCP and sender-based control, it's absolutely possible t= o have two way communication on a connection there, where one side uses say= CUBIC congestion control and the other Compound TCP. Each side doesn't= require any specific behavior from the other, because it simply expects th= e other side to show the simple generic receiver behavior. This is what I&#= 39;d like to see in rmcat.

(again, the situation is the same for the case of receiver-based control wi= th a generic, generally agreed upon sender behavior - but spreading each co= ngestion controller over both sides ruins this ability)



In case of rmcat in rtcweb, this would mean that browser vendor X
could simply start playing with a new congestion control mechanism
(offer it to its users or enable it by default), and that would work
with all other rtcweb/rmcat browsers, without ever having support for
this mechanism from browser vendor Y or Z.

=A0 That indeed is a worthy goal. But do understand that X, Y, and Z
all will be both sender and receiver.

See just above, I hope this was clear enough.



If we want that to be possible, we need to decide which side should
be the generic one at some point, and then agree on the exact
functionality of this generic side.

=A0 I don't agree that's necessary or sufficient. OTOH, I _do_ beli= eve
we need to establish a feedback mechanism with a clear definition
of what the feedback means (in both directions, of course).

I do believe it's necessary (sufficient, no - indeed we'd need a cl= early defined feedback mechanism). For example, with strict receiver-based = control, only having a clearly defined feedback mechanism will not make fle= xible use of controls as with TCP possible. Or, in other words: having e.g.= RRTCC's sender behavior but multiply defined receiver behaviors would = make this flexibility possible, but having multiple sender- AND receiver-be= haviors will not.



(Assuming ConEx ever finishes, we are likely to see some kind of
congestion-based pricing both for senders and receivers -- and the
control loops ideally would serve the price-based needs of both
senders and receivers.)

=A0 I expressed myself poorly again. We will (IMHO) see congestion-
based pricing for both senders and receivers anyway -- it's happening already, though the measure of "congestion" is very poor.

=A0 I meant to indicate that, even if absent from the first version,
our control loops should allow receivers to request "lower congestion&= quot;
and senders to moderate their sending rate to avoid "congestion"<= br> charges.

Agreed, but I don't see a problem in doing this with either sender- or = receiver-based control.



I would prefer to leave this consideration aside, because
1) rmcat works on a much tighter schedule than ConEx, as it will
=A0 probably be deployed in the rtcweb context fast, while I don't
=A0 know how long we'd have to wait for reasonably wide-spread ConEx =A0 deployment...

=A0 Agreed: we may not see widespread ConEx deployment in our lifetime.

2) I don't think that this matters much for our decision - in the
=A0 worst case, we would find that ConEx related information needs
=A0 to be signalled from one end to the other, and then we could
=A0 consider extending to whatever signalling scheme we define.

=A0 Although there may (someday) be value to selective ConEx marking
by the sender, it's way premature to talk about such bits on the wire.<= br>
--
John Leslie <john@jlc.net>


Cheers,
Michael


--14dae9340dc9c43a7804cb8ab9bf-- From michawe@ifi.uio.no Mon Oct 8 04:54:09 2012 Return-Path: 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 28D1821F8552 for ; Mon, 8 Oct 2012 04:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2ijKf07Qfb7 for ; Mon, 8 Oct 2012 04:54:08 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 6773821F8551 for ; Mon, 8 Oct 2012 04:54:07 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TLBuP-0000E9-Ky; Mon, 08 Oct 2012 13:54:05 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TLBuO-0002bU-Pu; Mon, 08 Oct 2012 13:54:05 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0FF2E28D-0849-4079-84D1-6DC3D17B50CF" From: Michael Welzl In-Reply-To: Date: Mon, 8 Oct 2012 13:54:01 +0200 Message-Id: References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> <20121004223115.GE97796@verdi> <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> <20121005145838.GF97796@verdi> <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> To: Stefan Holmer X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 8 sum msgs/h 3 total rcpts 24400 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.997, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6F4419CFB3901CCF74C901ECC1D03010DC180EC7 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9851 max/h 20 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , John Leslie Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 11:54:09 -0000 --Apple-Mail=_0FF2E28D-0849-4079-84D1-6DC3D17B50CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 8. okt. 2012, at 13:43, Stefan Holmer wrote: >=20 >=20 >=20 > On Sun, Oct 7, 2012 at 3:17 PM, Michael Welzl = wrote: > Hi, >=20 > Very sorry for any disadvantages that might have come from having = expressed myself unclear. I'll try to clean things up in this email now: >=20 >=20 >=20 > On Oct 5, 2012, at 4:58 PM, John Leslie wrote: >=20 > Michael Welzl wrote: > On 5. okt. 2012, at 00:31, John Leslie wrote: > Michael Welzl wrote: >=20 > First, to clarify, I'm talking about per-packet priorities within a > stream. Second, my point is that congestion control could be done > better if packet priorities would be known, and could then be taken > into account. >=20 > I guess I'm missing why packet priorities would ever _not_ be the > domain of the sender -- even if advised by receiver preferences. >=20 > It's just not what I meant. I meant priorities influencing the > congestion control behavior (I should say the "sender's" behavior, > but this discussion is about having the congestion control logic > on the sender or receiver side... so...). >=20 > "Priorities influencing" is actually quite separable from packet > scheduling. >=20 > I think we're hopelessly talking past each other here. It might > help if you outlined some "likely" mixes of priorities for packets. >=20 > Maybe you're considering one type of priority and me another. >=20 > Indeed, in rmcat we're facing two kinds of priorities. One, priorities = between streams. I think we *must* be able to support these priorities = because they are required by rtcweb (A23 in = draft-ietf-rtcweb-use-cases-and-requirements). In case of rtcweb, these = priorities are under control of the user or at least the web site = programmer via the javascript API, and should therefore probably be = expected to be reasonably long-lived. >=20 > Second (and this is what I meant in this current discussion), = individual packets in a multimedia stream differ in importance. One easy = way to say this is that a video consists of e.g. I-frames, P-frames and = B-frames, where the priority is I > P > B. In reality, things are more = complex: a frame typically spans multiple packets, but there are blocks = in frames of different type (e.g. a P-frame may contain I- P- and = B-blocks), and then there is also a dependency chain: some blocks may = have many other blocks depend upon them, making them more important, and = others may have less, making them less important. Honoring these = priorities is important for the receiver's subjective quality - here's = one out of many, many existing publications documenting this in one way = or another: > Michael Schier, Michael Welzl: "Optimizing Selective ARQ for H.264 = Live Streaming: A Novel Method for Predicting Loss-Impact in Realtime", = IEEE Transactions on Multimedia 14(2), April 2012. > http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D6095636 >=20 > Suffice to say, we can have different priorities per packet as a = function of the multimedia encoding, and these priorities could quickly = change (this is a way to represent the dependence - if the sending = application is in control of its data until the last moment, and if it = is informed about the loss of packet X, it could quickly assign a very = low priority to packets that depend on X. >=20 > Supporting these priorities in rmcat doesn't seem to be a MUST in = accordance with the charter and rtcweb requirements. I am arguing that = it would be great if we could support them. >=20 > What I mean with supporting them via congestion control is: going back = to the overly simplistic example of I- P- and B-"packets", one may = decide to be less aggressive when the buffer is full of "B-packets" and = more aggressive when it is full of "I-packets". One out of many = possibilities... my point is, such functionality should be enabled by = handing over the right information to the congestion controller, and = this requires the controller to be close to the send buffer, or the = information to be signalled to the other side. Both can be okay, but we = should be clear about this. >=20 > You want to allow the sender to, for a short time, override the = bandwidth estimate by sending at a higher rate because it has important = packets to send? Isn't this > possible even though the estimator is at the receiver? I'm also not = sure that is something you want to do. Sending important packets at a = higher rate increases the risk of losing those important packets, which = is the opposite of what you want, right? That's a possibility; I was actually thinking of the exact opposite - to = be overly cautious when you only have low-priority packets to send. Tune = your filter to say "yes there's congestion, don't increase" when it = might actually be noise in the measured delay signal in these = conditions.=20 Yes this can also be done when the controller is at the receiver, but to = do such a thing you need to inform the controller about the current = state of the sender buffer (how many low-, medium- and high-priority = packets are waiting there) =3D> more signalling. I'm not saying this is = a big problem, but it's probably another weight in the "minus" part of = the scale. Either way, it's just something to keep in mind, I think. Cheers, Michael --Apple-Mail=_0FF2E28D-0849-4079-84D1-6DC3D17B50CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1



On Sun, Oct 7, = 2012 at 3:17 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

Very sorry for any disadvantages that might have come from having = expressed myself unclear. I'll try to clean things up in this email = now:



On Oct 5, 2012, at 4:58 PM, John Leslie wrote:

Michael Welzl <michawe@ifi.uio.no> wrote:
On 5. okt. 2012, at 00:31, John Leslie wrote:
Michael Welzl <michawe@ifi.uio.no> wrote:

First, to clarify, I'm talking about per-packet priorities within a
stream. Second, my point is that congestion control could be done
better if packet priorities would be known, and could then be taken
into account.

I guess I'm missing why packet priorities would ever _not_ be the
domain of the sender -- even if advised by receiver preferences.

It's just not what I meant. I meant priorities influencing the
congestion control behavior (I should say the "sender's" behavior,
but this discussion is about having the congestion control logic
on the sender or receiver side... so...).

  "Priorities influencing" is actually quite separable from = packet
scheduling.

  I think we're hopelessly talking past each other here. It = might
help if you outlined some "likely" mixes of priorities for packets.

Maybe you're considering one type of priority and me another.

Indeed, in rmcat we're facing two kinds of priorities. One, priorities = between streams. I think we *must* be able to support these priorities = because they are required by rtcweb (A23 in = draft-ietf-rtcweb-use-cases-and-requirements). In case of rtcweb, = these priorities are under control of the user or at least the web site = programmer via the javascript API, and should therefore probably be = expected to be reasonably long-lived.

Second (and this is what I meant in this current discussion), individual = packets in a multimedia stream differ in importance. One easy way to say = this is that a video consists of e.g. I-frames, P-frames and B-frames, = where the priority is I > P > B. In reality, things are more = complex: a frame typically spans multiple packets, but there are blocks = in frames of different type (e.g. a P-frame may contain I- P- and = B-blocks), and then there is also a dependency chain: some blocks may = have many other blocks depend upon them, making them more important, and = others may have less, making them less important. Honoring these = priorities is important for the receiver's subjective quality - here's = one out of many, many existing publications documenting this in one way = or another:
Michael Schier, Michael Welzl: "Optimizing Selective ARQ for H.264 Live = Streaming: A Novel Method for Predicting Loss-Impact in Realtime", IEEE = Transactions on Multimedia 14(2), April 2012.
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumb= er=3D6095636

Suffice to say, we can have different priorities per packet as a = function of the multimedia encoding, and these priorities could quickly = change (this is a way to represent the dependence - if the sending = application is in control of its data until the last moment, and if it = is informed about the loss of packet X, it could quickly assign a very = low priority to packets that depend on X.

Supporting these priorities in rmcat doesn't seem to be a MUST in = accordance with the charter and rtcweb requirements. I am arguing that = it would be great if we could support them.

What I mean with supporting them via congestion control is: going back = to the overly simplistic example of I- P- and B-"packets", one may = decide to be less aggressive when the buffer is full of "B-packets" and = more aggressive when it is full of "I-packets". One out of many = possibilities... my point is, such functionality should be enabled by = handing over the right information to the congestion controller, and = this requires the controller to be close to the send buffer, or the = information to be signalled to the other side. Both can be okay, but we = should be clear about this.

You want to allow the sender to, for a short time, = override the bandwidth estimate by sending at a higher rate because it = has important packets to send? Isn't = this
possible even = though the estimator is at the receiver? I'm also not sure that is = something you want to do. Sending important packets at a higher rate = increases the risk of losing those important packets, which is the = opposite of what you want, = right?

That's a = possibility; I was actually thinking of the exact opposite - to be = overly cautious when you only have low-priority packets to = send. Tune your filter to say "yes there's congestion, don't increase" = when it might actually be noise in the measured delay signal in these = conditions. 

Yes this can also be done = when the controller is at the receiver, but to do such a thing you need = to inform the controller about the current state of the sender buffer = (how many low-, medium- and high-priority packets are waiting there) = =3D> more signalling. I'm not saying this is a big problem, but it's = probably another weight in the "minus" part of the scale. Either way, = it's just something to keep in mind, I = think.

Cheers,
Michael

= --Apple-Mail=_0FF2E28D-0849-4079-84D1-6DC3D17B50CF-- From john@jlc.net Mon Oct 8 06:19:42 2012 Return-Path: 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 3107421F8532 for ; Mon, 8 Oct 2012 06:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.31 X-Spam-Level: X-Spam-Status: No, score=-106.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SapHrPQdJOha for ; Mon, 8 Oct 2012 06:19:41 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id CAE9821F84FF for ; Mon, 8 Oct 2012 06:19:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 535D433C26; Mon, 8 Oct 2012 09:19:40 -0400 (EDT) Date: Mon, 8 Oct 2012 09:19:40 -0400 From: John Leslie To: Michael Welzl Message-ID: <20121008131940.GD10559@verdi> References: <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> <20121004223115.GE97796@verdi> <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> <20121005145838.GF97796@verdi> <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> User-Agent: Mutt/1.4.1i Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 13:19:42 -0000 Michael Welzl wrote: > > Maybe you're considering one type of priority and me another. Indeed! > Indeed, in rmcat we're facing two kinds of priorities. One, priorities > between streams. I think we *must* be able to support these priorities > because they are required by rtcweb (A23 in > draft-ietf-rtcweb-use-cases-and-requirements). ] ] A23 The Web API MUST provide means for the ] application to specify the priority to ] apply for outgoing streams and data. Agreed. > In case of rtcweb, these priorities are under control of the user or > at least the web site programmer via the javascript API, and should > therefore probably be expected to be reasonably long-lived. Yes. > Second (and this is what I meant in this current discussion), > individual packets in a multimedia stream differ in importance. One > easy way to say this is that a video consists of e.g. I-frames, P- > frames and B-frames, where the priority is I > P > B. Hmmm... One should tread carefully here. Most video codecs are designed to expect in-order delivery; and priorities can mess that up. (Or are you actually talking about trying to jiggle probability-of- loss, rather than what goes first?) > In reality, things are more complex: a frame typically spans multiple > packets, but there are blocks in frames of different type (e.g. a > P-frame may contain I- P- and B-blocks), You're starting to lose me... :^( There are a heck of a lot of video codec standards. Are you referring to one in particular? I think of an I-frame as a picture complete in itself, and both P-frames and B-frames as trying to describe motion between frames of the original video signal -- the difference being that P-frames refer to previous I-frames while B-frames refer to following I-frames as well. (This in itself is enough to make my head ache!) I'm reduced to guesswork to try to attach a meaning to "P-block" and "B-block"... I'd rather not go too far into guesswork... > and then there is also a dependency chain: some blocks may have many > other blocks depend upon them, making them more important, and others > may have less, making them less important. Honoring these priorities > is important for the receiver's subjective quality That sounds like probability-of-loss... > - here's one out of many, many existing publications documenting this > in one way or another: > Michael Schier, Michael Welzl: "Optimizing Selective ARQ for H.264 > Live Streaming: A Novel Method for Predicting Loss-Impact in > Realtime", IEEE Transactions on Multimedia 14(2), April 2012. > http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6095636 Many of us won't have time to access and read this... > Suffice to say, we can have different priorities per packet as a > function of the multimedia encoding, and these priorities could > quickly change (this is a way to represent the dependence - if the > sending application is in control of its data until the last moment, > and if it is informed about the loss of packet X, it could quickly > assign a very low priority to packets that depend on X. I have been assuming the sender _will_ be in control of what goes into each packet sent (in other words, the sender will compose packets, not streams). But you're losing me at "assign a very low priority"... There are many things that could mean. The most obvious is QoS bits. I dislike that because it _asks_ to mess with order of delivery. I won't list any other meanings -- this email is complicated enough already... > Supporting these priorities in rmcat doesn't seem to be a MUST in > accordance with the charter and rtcweb requirements. I am arguing that > it would be great if we could support them. To the extent you mean in what order the sender packs the pieces into outgoing packets, I very much want to support that. If you mean some "priority" mechanism other than QoS bits attached to packets, I'm all ears to learn of it... > What I mean with supporting them via congestion control is: going back > to the overly simplistic example of I- P- and B-"packets", one may > decide to be less aggressive when the buffer is full of "B-packets" > and more aggressive when it is full of "I-packets". One out of many > possibilities... my point is, such functionality should be enabled by > handing over the right information to the congestion controller, and > this requires the controller to be close to the send buffer, or the > information to be signalled to the other side. Both can be okay, but > we should be clear about this. Philosophically, I'm more friendly to congestion-control-at-sender; but I still don't think we need to settle that yet. >> Are you arguing we should give up considering receiver-based-control? > > I'm arguing that we should have either this, or strictly only-receiver- > based control. Then we could get the same functionality: you could > just change the receiver to use a new mechanism X, without waiting for > the sender to support the new mechanism X or even signalling to the > sender what mechanism to use. Sender- or receiver- based, but not both. This is a bit convoluted... I agree we could accomplish what we need with either receiver-based or sender-based congestion control; thus I don't see the need to settle it yet. I disagree that we can't do it with a mix (though at first blush that would seem a very poor choice). >> I _do_ believe we need to establish a feedback mechanism with a clear >> definition of what the feedback means (in both directions, of course). > I do believe it's necessary (sufficient, no - indeed we'd need a > clearly defined feedback mechanism). :^) > For example, with strict receiver-based control, only having a > clearly defined feedback mechanism will not make flexible use of > controls as with TCP possible. Or, in other words: having e.g. > RRTCC's sender behavior but multiply defined receiver behaviors > would make this flexibility possible, but having multiple sender- > AND receiver-behaviors will not. I think you've lost most of our readers here. :^( Presumably you mean: http://tools.ietf.org/id/draft-alvestrand-rtcweb-congestion-02.txt I _could_ follow the math there, had I more time to spare... I'm guessing the critical part comes in section 3.4: ] ] 3.4. Rate control ] ] The rate control at the receiving side is designed to increase the ] receive-side estimate of the available bandwidth A_hat as long as the ] detected state is normal. Doing that assures that we, sooner or ] later, will reach the available bandwidth of the channel and detect ] an over-use. ]... any you're saying A_hat isn't sufficient to the purpose. (I don't even see why that's necessarily true, unless you mean that any intelligence whatsoever at sender-side is forbidden.) -- John Leslie From michawe@ifi.uio.no Mon Oct 8 12:25:24 2012 Return-Path: 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 D94B621F8817 for ; Mon, 8 Oct 2012 12:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 232Z8UV-L4Y0 for ; Mon, 8 Oct 2012 12:25:23 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 2534421F8811 for ; Mon, 8 Oct 2012 12:25:22 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TLIx7-0006rG-Nn; Mon, 08 Oct 2012 21:25:21 +0200 Received: from 108.134.189.109.customer.cdi.no ([109.189.134.108] helo=[192.168.0.197]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TLIx6-0007hy-PY; Mon, 08 Oct 2012 21:25:21 +0200 Message-Id: From: Michael Welzl To: John Leslie In-Reply-To: <20121008131940.GD10559@verdi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Oct 2012 21:24:55 +0200 References: <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> <20121004223115.GE97796@verdi> <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> <20121005145838.GF97796@verdi> <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> <20121008131940.GD10559@verdi> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 6 sum msgs/h 3 total rcpts 24449 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 43C820257E695ECE60CE47BA24BA3882F2FB2099 X-UiO-SPAM-Test: remote_host: 109.189.134.108 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1509 max/h 15 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 19:25:25 -0000 On Oct 8, 2012, at 3:19 PM, John Leslie wrote: > Michael Welzl wrote: >> >> Maybe you're considering one type of priority and me another. > > Indeed! > >> Indeed, in rmcat we're facing two kinds of priorities. One, >> priorities >> between streams. I think we *must* be able to support these >> priorities >> because they are required by rtcweb (A23 in >> draft-ietf-rtcweb-use-cases-and-requirements). > ] > ] A23 The Web API MUST provide means for the > ] application to specify the priority to > ] apply for outgoing streams and data. > > Agreed. > >> In case of rtcweb, these priorities are under control of the user or >> at least the web site programmer via the javascript API, and should >> therefore probably be expected to be reasonably long-lived. > > Yes. > >> Second (and this is what I meant in this current discussion), >> individual packets in a multimedia stream differ in importance. One >> easy way to say this is that a video consists of e.g. I-frames, P- >> frames and B-frames, where the priority is I > P > B. > > Hmmm... > > One should tread carefully here. Most video codecs are designed to > expect in-order delivery; and priorities can mess that up. > > (Or are you actually talking about trying to jiggle probability-of- > loss, rather than what goes first?) Well, there is only so much you can squeeze through a pipe. When what you'd like to send is more than the network allows, a decision has to be taken, and that should be done on priorities. In a way that's similar to a loss - it's a decision on the sender side, to not send certain packets in favor of others. >> In reality, things are more complex: a frame typically spans multiple >> packets, but there are blocks in frames of different type (e.g. a >> P-frame may contain I- P- and B-blocks), > > You're starting to lose me... :^( > > There are a heck of a lot of video codec standards. Are you > referring > to one in particular? AFAIK many codecs are based on MPEG in one way or another. This basis is what I'm referring to. > I think of an I-frame as a picture complete in itself, and both > P-frames and B-frames as trying to describe motion between frames of > the original video signal -- the difference being that P-frames refer > to previous I-frames while B-frames refer to following I-frames as > well. > (This in itself is enough to make my head ache!) > > I'm reduced to guesswork to try to attach a meaning to "P-block" and > "B-block"... I'd rather not go too far into guesswork... A block is just a part of a frame. Anyway, as I said in my previous email, for simplicity it's enough to think about I- vs. P- vs. B- frames, exactly as you describe them here. >> and then there is also a dependency chain: some blocks may have many >> other blocks depend upon them, making them more important, and others >> may have less, making them less important. Honoring these priorities >> is important for the receiver's subjective quality > > That sounds like probability-of-loss... ... in the sender. See above. >> - here's one out of many, many existing publications documenting this >> in one way or another: >> Michael Schier, Michael Welzl: "Optimizing Selective ARQ for H.264 >> Live Streaming: A Novel Method for Predicting Loss-Impact in >> Realtime", IEEE Transactions on Multimedia 14(2), April 2012. >> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6095636 > > Many of us won't have time to access and read this... Not needed to get my point. It's just one out of many examples, to clarify that honoring such priorities can make a pronounced quality difference. >> Suffice to say, we can have different priorities per packet as a >> function of the multimedia encoding, and these priorities could >> quickly change (this is a way to represent the dependence - if the >> sending application is in control of its data until the last moment, >> and if it is informed about the loss of packet X, it could quickly >> assign a very low priority to packets that depend on X. > > I have been assuming the sender _will_ be in control of what goes > into each packet sent (in other words, the sender will compose > packets, not streams). That's good. I hope the sender will be in control until the very last moment in actual implementations coming out of rmcat. This is not as simple and obvious as it may sound, I think. > But you're losing me at "assign a very low priority"... There are > many things that could mean. > The most obvious is QoS bits. I dislike that because it _asks_ to > mess with order of delivery. > > I won't list any other meanings -- this email is complicated enough > already... Let's stay with the I-, P-, B-frame model. That makes priority 1, 2, 3. I am then saying that priorities could be changed to be 3. My context is the send buffer, influencing the congestion control behavior but nothing else. Nothing on the wire. I'm not trying to make things THAT complicated! :-) >> Supporting these priorities in rmcat doesn't seem to be a MUST in >> accordance with the charter and rtcweb requirements. I am arguing >> that >> it would be great if we could support them. > > To the extent you mean in what order the sender packs the pieces > into outgoing packets, I very much want to support that. If you mean > some "priority" mechanism other than QoS bits attached to packets, I'm > all ears to learn of it... I mean: if the sender's buffer is full of 1-priority packets, be more aggressive. If the sender's buffer is full of 3-priority packets, be less aggressive. This can be implemented in more or less reasonable ways. One, to me, reasonable method is what I described in the email answering Stefan: only implement low priorities, by being overly cautious in increasing the rate when your buffer is full of low-priority packets. ("Overly cautious" has a bad sound to it, but in fact any delay-based mechanism must be based on some parameters which can never be ideal - always trade-offs there, and I'm merely suggesting to tune these trade-offs based on what is in the sender buffer). Here's another example: RRTCC: http://tools.ietf.org/id/draft-alvestrand-rtcweb-congestion-02.txt has the sender send at least as much as one standard TCP would, using the TCP equation. With the MulTCP equation: http://heim.ifi.uio.no/~michawe/research/projects/multfrc/index.html one could easily tune this to send at least as much as N standard TCP's, where N could for example be 1.5 or 0.8. N could depend on the number of priority-1, priority-2 or priority-3 packets waiting to be transmitted. >> What I mean with supporting them via congestion control is: going >> back >> to the overly simplistic example of I- P- and B-"packets", one may >> decide to be less aggressive when the buffer is full of "B-packets" >> and more aggressive when it is full of "I-packets". One out of many >> possibilities... my point is, such functionality should be enabled by >> handing over the right information to the congestion controller, and >> this requires the controller to be close to the send buffer, or the >> information to be signalled to the other side. Both can be okay, but >> we should be clear about this. > > Philosophically, I'm more friendly to congestion-control-at-sender; > but I still don't think we need to settle that yet. > >>> Are you arguing we should give up considering receiver-based- >>> control? >> >> I'm arguing that we should have either this, or strictly only- >> receiver- >> based control. Then we could get the same functionality: you could >> just change the receiver to use a new mechanism X, without waiting >> for >> the sender to support the new mechanism X or even signalling to the >> sender what mechanism to use. Sender- or receiver- based, but not >> both. > > This is a bit convoluted... I agree we could accomplish what we need > with either receiver-based or sender-based congestion control; thus I > don't see the need to settle it yet. > > I disagree that we can't do it with a mix (though at first blush > that would seem a very poor choice). I don't understand how a mix would be as easily deployable as a one- sided approach. >>> I _do_ believe we need to establish a feedback mechanism with a >>> clear >>> definition of what the feedback means (in both directions, of >>> course). > >> I do believe it's necessary (sufficient, no - indeed we'd need a >> clearly defined feedback mechanism). > > :^) > >> For example, with strict receiver-based control, only having a >> clearly defined feedback mechanism will not make flexible use of >> controls as with TCP possible. Or, in other words: having e.g. >> RRTCC's sender behavior but multiply defined receiver behaviors >> would make this flexibility possible, but having multiple sender- >> AND receiver-behaviors will not. > > I think you've lost most of our readers here. :^( > > Presumably you mean: > > http://tools.ietf.org/id/draft-alvestrand-rtcweb-congestion-02.txt > > I _could_ follow the math there, had I more time to spare... I'm > guessing the critical part comes in section 3.4: > ] > ] 3.4. Rate control > ] > ] The rate control at the receiving side is designed to increase the > ] receive-side estimate of the available bandwidth A_hat as long as > the > ] detected state is normal. Doing that assures that we, sooner or > ] later, will reach the available bandwidth of the channel and detect > ] an over-use. > ]... > > any you're saying A_hat isn't sufficient to the purpose. (I don't even Err... now you're losing me. I think your interpretation of what I'm saying is way more complicated than what I mean :-) Sorry if I'm not clear enough, I promise I'm doing my best here... > see why that's necessarily true, unless you mean that any intelligence > whatsoever at sender-side is forbidden.) I mean that any mechanism-specific intelligence at sender-side should be forbidden, if we settle for receiver-based congestion control. That's what I mean with "generic": not mechanism-specific. RMCAT will perhaps standardize 3 mechanisms. A, B and C. Say each is split into a sender and receiver behavior: A_send and A_recv, B_send and B_recv, C_send and C_recv. Say they are not compatible, i.e. A_send cannot talk to B_recv, and C_send cannot talk to A_recv and so on. Then, for any mechanism X to work, you need both X_send and X_recv to be in place. Say, we decide to do receiver-based congestion control. Then I argue that we should agree on G_send, which is a generic sender behavior. Then, A, B and C only consist of A_recv, B_recv and C_recv, and you always only need to deploy this receiving end to use the new mechanism. Symmetrically, the same is true for pure sender-based congestion control. It's a mix of the two that's hard to deploy. Cheers, Michael From paalh@ifi.uio.no Tue Oct 9 01:30:32 2012 Return-Path: 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 8B50921F8839; Tue, 9 Oct 2012 01:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoYfaV6KmdCx; Tue, 9 Oct 2012 01:30:32 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id A66A621F883E; Tue, 9 Oct 2012 01:30:31 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TLVCu-0003wj-Jk; Tue, 09 Oct 2012 10:30:28 +0200 Received: from [77.88.71.190] (helo=mbpal.simula.no) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user paalh (Exim 4.80) (envelope-from ) id 1TLVCu-0000ke-1d; Tue, 09 Oct 2012 10:30:28 +0200 From: =?iso-8859-1?Q?P=E5l_Halvorsen?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Oct 2012 10:30:26 +0200 Message-Id: <2D7DEBDF-11E1-4794-96E8-3FEAF500A5CD@ifi.uio.no> To: bloat@lists.bufferbloat.net, iccrg@cs.ucl.ac.uk, rmcat@ietf.org, rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 50 msgs/h 18 sum rcpts/h 51 sum msgs/h 19 total rcpts 24832 max rcpts/h 4849 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A72A9F7ADC04AC3EE44E54370BD8B8FA8699EEE0 X-UiO-SPAM-Test: remote_host: 77.88.71.190 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 18 total 24 max/h 18 blacklist 0 greylist 0 ratelimit 0 Subject: [rmcat] PhD position available in the area of in Time-Dependent Networking 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 08:30:33 -0000 AVAILABLE PHD POSITION At Simula Research Laboratory (Norway) there is an available PhD = position in the area of in Time-Dependent Networking. The PhD Student = will work in the area of networking support for time-dependent = applications, focusing on thin streams. Thin streams are generated by = applications that send data with high interarrival time and also often = small packet sizes. These traffic patterns are in stark contrast to = greedy streams where the application always has data to send and the = sending rate is limited by congestion control. Typical for thin streams = is that they are generated by interactive applications with a need for = low latency communication. The following topics are central for the work in this position: =95 Develop mechanisms to improve thin-stream latency when transmitted = via different buffer types with varying drop schemes. =95 Investigate the congestion control support of conditionally thin = streams (i.e. not everything must be sent at all times) via per-packet = priorities. =95 Work towards a formal definition of the concept of thin streams. =95 Work towards defining what TCP fairness must mean in thin-stream = scenarios. The position is connected to the "Traffic behaviour of interactive = time-dependent thin streams on the modern Internet" (TimeIn) research = project cooperating with partners like UNINETT, University of Oslo, = Karlstad University, University of Kaiserslautern, CAIDA San Diego, = Cisco and Funcom. It is planned to align the research with, and possibly contribute to, = ongoing standardization efforts in the RTP Media Congestion Avoidance = Techniques (RMCAT) working group in the IETF. For more information about the project, the requirements, Simula, = salary, etc.,=20 please see http://simula.no/jobs/PhDStudent-TimeIn or contact: Postdoc Andreas Petlund, e-mail: apetlund@simula.no or Professor P=E5l Halvorsen, e-mail: paalh@simula.no (where you include the following phrase in the subject field: =93TimeIn = PhD position=94) The application deadline is as soon as possible, but no later than 20 = October 2012. To apply for this position, click here:=20 = https://emea3.recruitmentplatform.com/appproc/index.cfm?event=3DcreateSess= ionAfterSessionClear&ID=3DQL5FK026203F3VBQBV779QWAD&jobboard=3D0&nPTID=3D2= 8&bSessionClear=3Dtrue= From lars@netapp.com Tue Oct 9 04:58:26 2012 Return-Path: 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 0137721F8499 for ; Tue, 9 Oct 2012 04:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.54 X-Spam-Level: X-Spam-Status: No, score=-10.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oa9NyB5wCk3T for ; Tue, 9 Oct 2012 04:58:25 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD6121F8233 for ; Tue, 9 Oct 2012 04:58:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,560,1344236400"; d="p7s'?scan'208";a="699115019" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 09 Oct 2012 04:58:25 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q99BwPA2004727 for ; Tue, 9 Oct 2012 04:58:25 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.46]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 04:58:24 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: send agenda requests (was Re: [rmcat] First meeting) Thread-Index: AQHNphVijbcJ5BGWykajSkaMQB5cww== Date: Tue, 9 Oct 2012 11:58:24 +0000 Message-ID: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_16D874B9-3625-465C-8288-6FE11FB4854B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:58:26 -0000 --Apple-Mail=_16D874B9-3625-465C-8288-6FE11FB4854B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On Oct 5, 2012, at 15:50, "Eggert, Lars" wrote: > The ID cutoff for new -00 drafts (which most of ours will be) is Oct = 15. Please make sure your draft-yourname-rmcat-* is submitted by then. and even if your draft is not submitted yet, please already send Mirja = and me requests for agenda time, so we can start the planning process. Thanks, Lars= --Apple-Mail=_16D874B9-3625-465C-8288-6FE11FB4854B Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAwOTExNTgyNFowIwYJKoZIhvcNAQkEMRYEFH9+ 00Mu+SkxJYa4+fMLU5SgPuO+MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAB3P0lhO kmkFCNvIfiu5z245TVm+6zCcA8INetKERrQGWwbOYkwkBMh+6J9f7MQ8DL+NVu28Y7uYu7wZgqfy Od8eaIkX4rmo/AK3mxQPDJI/IFLyZIM016ZiOAPSl0t9nj/5A6ekS06X+5qDL0RYRM42KqCrT67T M8dX3k4Hd81r7vcH8kxTAVexcrq5Z/nlMXw7of2kwmjmDArPg3TeAjfjGlvQdLAPsQ3y8YjiGfSB VgxB0oWEgy20KQWUagsOnbYswAaNp5CMcz9UQmpcnrrloIPI5T5M+5k2fus8kkpAt4z/FoA61xy+ /McTSLd21tF4ipzYf8JKIhkkoVfoUHEAAAAAAAA= --Apple-Mail=_16D874B9-3625-465C-8288-6FE11FB4854B-- From john@jlc.net Tue Oct 9 06:06:46 2012 Return-Path: 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 5212A21F880D for ; Tue, 9 Oct 2012 06:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.32 X-Spam-Level: X-Spam-Status: No, score=-106.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa0P92bXHuhz for ; Tue, 9 Oct 2012 06:06:45 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C4ABC21F870F for ; Tue, 9 Oct 2012 06:06:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1928D33C22; Tue, 9 Oct 2012 09:06:40 -0400 (EDT) Date: Tue, 9 Oct 2012 09:06:40 -0400 From: John Leslie To: Michael Welzl Message-ID: <20121009130640.GA54140@verdi> References: <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> <20121004223115.GE97796@verdi> <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> <20121005145838.GF97796@verdi> <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> <20121008131940.GD10559@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:06:46 -0000 Michael Welzl wrote: > On Oct 8, 2012, at 3:19 PM, John Leslie wrote: >> Michael Welzl wrote: > > Well, there is only so much you can squeeze through a pipe. When what > you'd like to send is more than the network allows, a decision has to > be taken, and that should be done on priorities. I'm not sure "priorities" is a good name for this -- it's allowed me to get confused with packet-forwarding priorities. >> There are a heck of a lot of video codec standards. Are you >> referring to one in particular? > > AFAIK many codecs are based on MPEG in one way or another. This basis > is what I'm referring to. That's probably a good family of codecs to think in terms of; but we might find ourselves working with something different. Not surprisingly, "Moving Pictures Experts Group" concentrated on motion, while we will have uses where motion is limited... >> I have been assuming the sender _will_ be in control of what goes >> into each packet sent (in other words, the sender will compose >> packets, not streams). > > That's good. I hope the sender will be in control until the very last > moment in actual implementations coming out of rmcat. This is not as > simple and obvious as it may sound, I think. It may indeed not be "simple" for web-browsers in general. Our charter calls for: " " - Find or develop candidate congestion control algorithms, verify that " these can be tested on the Internet without significant risk, and " publish one or more of these as Experimental RFCs. which I think gives us sufficient wiggle-room for demonstrating a congestion control algorithm that not all web-browsers can initially support. Nonetheless, I see sender control of what gets packed into packets as essential to our eventual success; and I think that browsers can evolve to escape the TCP-stream paradigm. >> But you're losing me at "assign a very low priority"... There are >> many things that could mean... > > Let's stay with the I-, P-, B-frame model. That makes priority 1, 2, > 3. I am then saying that priorities could be changed to be 3. My > context is the send buffer, influencing the congestion control > behavior but nothing else. Nothing on the wire. I'm not trying to make > things THAT complicated! :-) :^) In some sense, you seem to be talking of pre-determining x-frame loss, rather than waiting for the network to drop something. "Priority" IMHO isn't a good word for that; though it may turn out to be a very good paradigm. Fundamentally, under "congestion control" we want to back off sending bit-rate when congestion is detected, and ramp it back up when congestion appears to have cleared. Packing less into the packets we send is certainly an appropriate mechanism. "Priority" may be a good term for academic types to describe policies for which frames don't get sent, but I'm afraid that to operations types it brings too much baggage. Also, "priority" suggests we're talking about a scalar, when IMHO the problem space is multi- dimensional. >> To the extent you mean in what order the sender packs the pieces >> into outgoing packets, I very much want to support that. If you mean >> some "priority" mechanism other than QoS bits attached to packets, I'm >> all ears to learn of it... > > I mean: if the sender's buffer is full of 1-priority packets, be more > aggressive. If the sender's buffer is full of 3-priority packets, be > less aggressive. This deserves its own thread. (I agree it's a promising path.) > This can be implemented in more or less reasonable ways. One, to me, > reasonable method is what I described in the email answering Stefan: > only implement low priorities, by being overly cautious in increasing > the rate when your buffer is full of low-priority packets. (I have gone beyond this, to suggest maintaining two rates: a slower one for less important packets and a faster one for the most important packets; both to be reduced when congestion is detected. This may deserve discussion in some other thread...) > ("Overly cautious" has a bad sound to it, but in fact any delay-based > mechanism must be based on some parameters which can never be ideal - > always trade-offs there, and I'm merely suggesting to tune these > trade-offs based on what is in the sender buffer). This may not be the easiest thing to model... :^( The way I think about it is that we want to avoid a situation where _our_ packets are growing the bit-rate at the bottleneck too quickly. There are plenty of uses out there which deserve to be called greedy: where every second of delay in delivering a fixed-size web-page reduces the user experience. For these, multiple TCP streams are "the" way to go; but this leads to overshoot and congestion more severe than "should" be needed. Thus, by the "first, do no harm" principle, we should avoid driving a bottleneck into severe congestion. In trade, we should be able to back off a bit more slowly when congestion _is_ encountered. Our true aim is to deliver a _consistent_ user experience -- not an "optimized" delivery of a fixed-size message. > Here's another example: > RRTCC: http://tools.ietf.org/id/draft-alvestrand-rtcweb-congestion-02.txt > has the sender send at least as much as one standard TCP would, using > the TCP equation. With the MulTCP equation: > http://heim.ifi.uio.no/~michawe/research/projects/multfrc/index.html > one could easily tune this to send at least as much as N standard > TCP's, where N could for example be 1.5 or 0.8. N could depend on the > number of priority-1, priority-2 or priority-3 packets waiting to be > transmitted. At first blush, that seems a reasonable way to model the situation; but I suspect we can do better. N>1 TCP is a big part of the problem... >> This is a bit convoluted... I agree we could accomplish what we need >> with either receiver-based or sender-based congestion control; thus I >> don't see the need to settle it yet. >> >> I disagree that we can't do it with a mix (though at first blush >>that would seem a very poor choice). > > I don't understand how a mix would be as easily deployable as a one- > sided approach. I'm not talking about "ease of deployment". We need first to establish we have something worth deploying. >>... Presumably you mean: >> >> http://tools.ietf.org/id/draft-alvestrand-rtcweb-congestion-02.txt >> >> I _could_ follow the math there, had I more time to spare... I'm >> guessing the critical part comes in section 3.4: >>] >>] 3.4. Rate control >>] >>] The rate control at the receiving side is designed to increase the >>] receive-side estimate of the available bandwidth A_hat as long as the >>] detected state is normal. Doing that assures that we, sooner or >>] later, will reach the available bandwidth of the channel and detect >>] an over-use. >>]... >> >> and you're saying A_hat isn't sufficient to the purpose. (I don't >> even see why that's necessarily true, unless you mean that any >> intelligence whatsoever at sender-side is forbidden.) > > I mean that any mechanism-specific intelligence at sender-side should > be forbidden, if we settle for receiver-based congestion control. I don't agree that would be helpful. > That's what I mean with "generic": not mechanism-specific. > RMCAT will perhaps standardize 3 mechanisms. A, B and C. Say each is > split into a sender and receiver behavior: A_send and A_recv, B_send > and B_recv, C_send and C_recv. Say they are not compatible, i.e. > A_send cannot talk to B_recv, and C_send cannot talk to A_recv and so > on. Then, for any mechanism X to work, you need both X_send and X_recv > to be in place. Logically true; but not particularly interesting... We're chartered to explore Experimental protocols. There's every reason to believe when the time comes for Proposed Standard, we will have learned from the experiments. IMHO, at this stage it's more important to design good experiments than worry about deployment of something not yet designed. -- John Leslie From michawe@ifi.uio.no Tue Oct 9 06:38:49 2012 Return-Path: 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 E53A221F8743 for ; Tue, 9 Oct 2012 06:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-eeNXfVSF1C for ; Tue, 9 Oct 2012 06:38:48 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4DD21F8742 for ; Tue, 9 Oct 2012 06:38:47 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TLa1G-0006ar-Ty; Tue, 09 Oct 2012 15:38:46 +0200 Received: from [193.214.121.5] (helo=[192.168.10.134]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TLa1F-0001SU-Us; Tue, 09 Oct 2012 15:38:46 +0200 Message-Id: <26E70B67-DE69-426E-97D5-A325DBEB83D6@ifi.uio.no> From: Michael Welzl To: John Leslie In-Reply-To: <20121009130640.GA54140@verdi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 9 Oct 2012 15:38:44 +0200 References: <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> <20121004223115.GE97796@verdi> <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> <20121005145838.GF97796@verdi> <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> <20121008131940.GD10559@verdi> <20121009130640.GA54140@verdi> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 4 sum rcpts/h 14 sum msgs/h 7 total rcpts 24503 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 69673AC49D8A66C6567F1EB024A827D985204A6F X-UiO-SPAM-Test: remote_host: 193.214.121.5 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 996 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:38:50 -0000 On Oct 9, 2012, at 3:06 PM, John Leslie wrote: > Michael Welzl wrote: >> On Oct 8, 2012, at 3:19 PM, John Leslie wrote: >>> Michael Welzl wrote: >> >> Well, there is only so much you can squeeze through a pipe. When what >> you'd like to send is more than the network allows, a decision has to >> be taken, and that should be done on priorities. > > I'm not sure "priorities" is a good name for this -- it's allowed me > to get confused with packet-forwarding priorities. I understand; sorry. I herewith coin the term "Packet Importance" (PI) :-) >>> There are a heck of a lot of video codec standards. Are you >>> referring to one in particular? >> >> AFAIK many codecs are based on MPEG in one way or another. This basis >> is what I'm referring to. > > That's probably a good family of codecs to think in terms of; but > we might find ourselves working with something different. Not > surprisingly, "Moving Pictures Experts Group" concentrated on motion, > while we will have uses where motion is limited... Different importance of different parts of media is a natural occurrence if you want to compress, really. And compression is a natural occurrence if you want to squeeze, say, video through the network. We might not only consider video, yes, but for cases where you have similar-importance packets, well, you have no problem. It's just that WHEN different PIs (defined as per above) occur, it can be useful to let the congestion controller know about them. >>> I have been assuming the sender _will_ be in control of what goes >>> into each packet sent (in other words, the sender will compose >>> packets, not streams). >> >> That's good. I hope the sender will be in control until the very last >> moment in actual implementations coming out of rmcat. This is not as >> simple and obvious as it may sound, I think. > > It may indeed not be "simple" for web-browsers in general. Our > charter calls for: > " > " - Find or develop candidate congestion control algorithms, verify > that > " these can be tested on the Internet without significant risk, and > " publish one or more of these as Experimental RFCs. > > which I think gives us sufficient wiggle-room for demonstrating a > congestion control algorithm that not all web-browsers can initially > support. > > Nonetheless, I see sender control of what gets packed into packets > as essential to our eventual success; and I think that browsers can > evolve to escape the TCP-stream paradigm. I'm completely with you here. >>> But you're losing me at "assign a very low priority"... There are >>> many things that could mean... >> >> Let's stay with the I-, P-, B-frame model. That makes priority 1, 2, >> 3. I am then saying that priorities could be changed to be 3. My >> context is the send buffer, influencing the congestion control >> behavior but nothing else. Nothing on the wire. I'm not trying to >> make >> things THAT complicated! :-) > > :^) > > In some sense, you seem to be talking of pre-determining x-frame > loss, rather than waiting for the network to drop something. > "Priority" > IMHO isn't a good word for that; though it may turn out to be a very > good paradigm. PI hereinafter :-) and "pre-determining x-frame loss" is a rather complicated phrase for what really is: "reducing the send rate". Adaptive multimedia. > Fundamentally, under "congestion control" we want to back off > sending bit-rate when congestion is detected, and ramp it back up > when congestion appears to have cleared. Packing less into the packets > we send is certainly an appropriate mechanism. > > "Priority" may be a good term for academic types to describe > policies for which frames don't get sent, but I'm afraid that to > operations types it brings too much baggage. Also, "priority" suggests > we're talking about a scalar, when IMHO the problem space is multi- > dimensional. Nononononono please! A scalar please!!! I herewith very very quickly define that "Packet Importance" is a scalar with values 1, 2 and 3. Not multiple dimensions!!! >>> To the extent you mean in what order the sender packs the pieces >>> into outgoing packets, I very much want to support that. If you mean >>> some "priority" mechanism other than QoS bits attached to packets, >>> I'm >>> all ears to learn of it... >> >> I mean: if the sender's buffer is full of 1-priority packets, be more >> aggressive. If the sender's buffer is full of 3-priority packets, be >> less aggressive. > > This deserves its own thread. (I agree it's a promising path.) > >> This can be implemented in more or less reasonable ways. One, to me, >> reasonable method is what I described in the email answering Stefan: >> only implement low priorities, by being overly cautious in increasing >> the rate when your buffer is full of low-priority packets. > > (I have gone beyond this, to suggest maintaining two rates: a > slower one for less important packets and a faster one for the most > important packets; both to be reduced when congestion is detected. > This may deserve discussion in some other thread...) Ok about another thread. About your suggestion: another possibility... there are many. All I'm saying is that such stuff could be done, and would probably be beneficial, and for that to be possible the congestion controller must be informed about the PIs of packets in the buffer. Which, in case of sender-side control, is straightforward, and in case of receiver-side control, needs signalling. >> ("Overly cautious" has a bad sound to it, but in fact any delay-based >> mechanism must be based on some parameters which can never be ideal - >> always trade-offs there, and I'm merely suggesting to tune these >> trade-offs based on what is in the sender buffer). > > This may not be the easiest thing to model... :^( > > The way I think about it is that we want to avoid a situation where > _our_ packets are growing the bit-rate at the bottleneck too quickly. > There are plenty of uses out there which deserve to be called greedy: > where every second of delay in delivering a fixed-size web-page > reduces the user experience. For these, multiple TCP streams are "the" > way to go; but this leads to overshoot and congestion more severe > than "should" be needed. > > Thus, by the "first, do no harm" principle, we should avoid driving > a bottleneck into severe congestion. In trade, we should be able to > back off a bit more slowly when congestion _is_ encountered. Our true > aim is to deliver a _consistent_ user experience -- not an "optimized" > delivery of a fixed-size message. > >> Here's another example: >> RRTCC: http://tools.ietf.org/id/draft-alvestrand-rtcweb-congestion-02.txt >> has the sender send at least as much as one standard TCP would, using >> the TCP equation. With the MulTCP equation: >> http://heim.ifi.uio.no/~michawe/research/projects/multfrc/index.html >> one could easily tune this to send at least as much as N standard >> TCP's, where N could for example be 1.5 or 0.8. N could depend on the >> number of priority-1, priority-2 or priority-3 packets waiting to be >> transmitted. > > At first blush, that seems a reasonable way to model the situation; > but I suspect we can do better. N>1 TCP is a big part of the > problem... Our equation also allows for N<1 TCP :-) Like, 0.5 :-) >>> This is a bit convoluted... I agree we could accomplish what we need >>> with either receiver-based or sender-based congestion control; >>> thus I >>> don't see the need to settle it yet. >>> >>> I disagree that we can't do it with a mix (though at first blush >>> that would seem a very poor choice). >> >> I don't understand how a mix would be as easily deployable as a one- >> sided approach. > > I'm not talking about "ease of deployment". We need first to > establish we have something worth deploying. > >>> ... Presumably you mean: >>> >>> http://tools.ietf.org/id/draft-alvestrand-rtcweb-congestion-02.txt >>> >>> I _could_ follow the math there, had I more time to spare... I'm >>> guessing the critical part comes in section 3.4: >>> ] >>> ] 3.4. Rate control >>> ] >>> ] The rate control at the receiving side is designed to increase >>> the >>> ] receive-side estimate of the available bandwidth A_hat as long >>> as the >>> ] detected state is normal. Doing that assures that we, sooner or >>> ] later, will reach the available bandwidth of the channel and >>> detect >>> ] an over-use. >>> ]... >>> >>> and you're saying A_hat isn't sufficient to the purpose. (I don't >>> even see why that's necessarily true, unless you mean that any >>> intelligence whatsoever at sender-side is forbidden.) >> >> I mean that any mechanism-specific intelligence at sender-side should >> be forbidden, if we settle for receiver-based congestion control. > > I don't agree that would be helpful. > >> That's what I mean with "generic": not mechanism-specific. >> RMCAT will perhaps standardize 3 mechanisms. A, B and C. Say each is >> split into a sender and receiver behavior: A_send and A_recv, B_send >> and B_recv, C_send and C_recv. Say they are not compatible, i.e. >> A_send cannot talk to B_recv, and C_send cannot talk to A_recv and so >> on. Then, for any mechanism X to work, you need both X_send and >> X_recv >> to be in place. > > Logically true; but not particularly interesting... > > We're chartered to explore Experimental protocols. There's every > reason to believe when the time comes for Proposed Standard, we will > have learned from the experiments. IMHO, at this stage it's more > important to design good experiments than worry about deployment of > something not yet designed. I disagree on both accounts. 1) About the importance: the IETF has standardized a wealth of undeployed / undeployable stuff, e.g. DCCP. 2) About the design aspect: I don't see any notable benefit from having a per-mechanism sender *and* receiver behavior, but, as stated, a significant deployment problem with two-sided approaches. And I believe it's important to get these major architectural decisions right from the outset. But I don't believe we will come to an agreement here, and have yet converged to a point where we can probably just leave it at that, for now :) Cheers, Michael From randell-ietf@jesup.org Tue Oct 9 13:05:52 2012 Return-Path: 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 471021F0C5F for ; Tue, 9 Oct 2012 13:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRjh1isaLylo for ; Tue, 9 Oct 2012 13:05:51 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 71F381F0C69 for ; Tue, 9 Oct 2012 13:05:51 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60]:2357 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TLg3q-0001nW-QW for rmcat@ietf.org; Tue, 09 Oct 2012 15:05:50 -0500 Message-ID: <50748338.7050900@jesup.org> Date: Tue, 09 Oct 2012 16:04:08 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rmcat@ietf.org References: <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> <20121004223115.GE97796@verdi> <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> <20121005145838.GF97796@verdi> <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> <20121008131940.GD10559@verdi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 20:05:52 -0000 On 10/8/2012 3:24 PM, Michael Welzl wrote: > > On Oct 8, 2012, at 3:19 PM, John Leslie wrote: > >> Michael Welzl wrote: >>> >>> Maybe you're considering one type of priority and me another. >> >> Indeed! >> >>> Indeed, in rmcat we're facing two kinds of priorities. One, priorities >>> between streams. I think we *must* be able to support these priorities >>> because they are required by rtcweb (A23 in >>> draft-ietf-rtcweb-use-cases-and-requirements). >> ] >> ] A23 The Web API MUST provide means for the >> ] application to specify the priority to >> ] apply for outgoing streams and data. >> >> Agreed. >> >>> In case of rtcweb, these priorities are under control of the user or >>> at least the web site programmer via the javascript API, and should >>> therefore probably be expected to be reasonably long-lived. >> >> Yes. >> >>> Second (and this is what I meant in this current discussion), >>> individual packets in a multimedia stream differ in importance. One >>> easy way to say this is that a video consists of e.g. I-frames, P- >>> frames and B-frames, where the priority is I > P > B. >> >> Hmmm... >> >> One should tread carefully here. Most video codecs are designed to >> expect in-order delivery; and priorities can mess that up. >> >> (Or are you actually talking about trying to jiggle probability-of- >> loss, rather than what goes first?) > > Well, there is only so much you can squeeze through a pipe. When what > you'd like to send is more than the network allows, a decision has to > be taken, and that should be done on priorities. > In a way that's similar to a loss - it's a decision on the sender > side, to not send certain packets in favor of others. Except in most cases we're not sitting with a pile of frames/packets and deciding which ones get dropped (liek a router); we're encoding data to meet the current-moment bandwidth requirements. There is a separate component of feeding data out onto the wire, which would be applied to non-encode-controlled streams like a SCTP/DTLS DataChannel sharing the pipe. For encoder-based streams, we generally want to control via the encoder not by inducing possible internal delay in how we select packets for transmission. If the data doesn't fit in the current pipe estimate, we shouldn't be generating it in the first place. And intermediate nodes don't know our priorities to adjust probability of drop except maybe indirectly via markings, which may instead mess with order of delivery (not a good thing). >> I'm reduced to guesswork to try to attach a meaning to "P-block" and >> "B-block"... I'd rather not go too far into guesswork... > > > A block is just a part of a frame. Anyway, as I said in my previous > email, for simplicity it's enough to think about I- vs. P- vs. > B-frames, exactly as you describe them here. Most packets are at a much higher level than blocks, so barring considerable swizzling of internal order it's likely that all packets for a frame should have similar priority and likelyhood of drop. > >> That sounds like probability-of-loss... > > > ... in the sender. See above. We should never drop in the sender. :-) >> see why that's necessarily true, unless you mean that any intelligence >> whatsoever at sender-side is forbidden.) > > I mean that any mechanism-specific intelligence at sender-side should > be forbidden, if we settle for receiver-based congestion control. > That's what I mean with "generic": not mechanism-specific. > RMCAT will perhaps standardize 3 mechanisms. A, B and C. Say each is > split into a sender and receiver behavior: A_send and A_recv, B_send > and B_recv, C_send and C_recv. Say they are not compatible, i.e. > A_send cannot talk to B_recv, and C_send cannot talk to A_recv and so > on. Then, for any mechanism X to work, you need both X_send and X_recv > to be in place. > > Say, we decide to do receiver-based congestion control. Then I argue > that we should agree on G_send, which is a generic sender behavior. > Then, A, B and C only consist of A_recv, B_recv and C_recv, and you > always only need to deploy this receiving end to use the new mechanism. > > Symmetrically, the same is true for pure sender-based congestion > control. It's a mix of the two that's hard to deploy. Not that I'm arguing for it at this moment: but you could design things so that 'generic'/dumb mechanisms are available to support either sender or receiver-based control, with the decision on which done by negotiation or even in-band decision. It simply requires defining both, and defining a way to select the one that's non-default. This would allow innovation at either end in the future. As to whether this is useful... I haven't given it the thought it deserves yet. But it's quite doable. (And on a separate note, a 'generic'/dumb mechanism doesn't mean there can't be feedback from the other side affecting how it operates, or that it can't be a more complex state machine than "send one packet per packet received"). Just that it be relatively simple and well-defined. (A bit like the whole video-codec "we'll define the quite-complex decoder and let the encoder innovate") -- Randell Jesup randell-ietf@jesup.org From michawe@ifi.uio.no Wed Oct 10 09:10:42 2012 Return-Path: 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 8555521F86C8 for ; Wed, 10 Oct 2012 09:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEH5LiHVTCjf for ; Wed, 10 Oct 2012 09:10:33 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 4054821F86C3 for ; Wed, 10 Oct 2012 09:10:32 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TLyrf-0002aU-L7; Wed, 10 Oct 2012 18:10:31 +0200 Received: from vpn-client423.uio.no ([193.157.137.170] helo=[172.18.14.211]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TLyrd-0002rJ-1q; Wed, 10 Oct 2012 18:10:31 +0200 Message-Id: From: Michael Welzl To: Randell Jesup In-Reply-To: <50748338.7050900@jesup.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 10 Oct 2012 18:10:18 +0200 References: <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <20121004144639.GC97796@verdi> <20121004223115.GE97796@verdi> <9CADC40E-6432-4DFA-9512-8C780A6A0E4C@ifi.uio.no> <20121005145838.GF97796@verdi> <09A85867-0999-4723-B224-2D9812AE02FA@ifi.uio.no> <20121008131940.GD10559@verdi> <50748338.7050900@jesup.org> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 24535 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.997, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B633293B775CA5A8EF86300423AF3854388A9CC5 X-UiO-SPAM-Test: remote_host: 193.157.137.170 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 580 max/h 18 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat@ietf.org Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 16:10:42 -0000 On Oct 9, 2012, at 10:04 PM, Randell Jesup wrote: > On 10/8/2012 3:24 PM, Michael Welzl wrote: >> >> On Oct 8, 2012, at 3:19 PM, John Leslie wrote: >> >>> Michael Welzl wrote: >>>> >>>> Maybe you're considering one type of priority and me another. >>> >>> Indeed! >>> >>>> Indeed, in rmcat we're facing two kinds of priorities. One, >>>> priorities >>>> between streams. I think we *must* be able to support these >>>> priorities >>>> because they are required by rtcweb (A23 in >>>> draft-ietf-rtcweb-use-cases-and-requirements). >>> ] >>> ] A23 The Web API MUST provide means for the >>> ] application to specify the priority to >>> ] apply for outgoing streams and data. >>> >>> Agreed. >>> >>>> In case of rtcweb, these priorities are under control of the user >>>> or >>>> at least the web site programmer via the javascript API, and should >>>> therefore probably be expected to be reasonably long-lived. >>> >>> Yes. >>> >>>> Second (and this is what I meant in this current discussion), >>>> individual packets in a multimedia stream differ in importance. One >>>> easy way to say this is that a video consists of e.g. I-frames, P- >>>> frames and B-frames, where the priority is I > P > B. >>> >>> Hmmm... >>> >>> One should tread carefully here. Most video codecs are designed to >>> expect in-order delivery; and priorities can mess that up. >>> >>> (Or are you actually talking about trying to jiggle probability-of- >>> loss, rather than what goes first?) >> >> Well, there is only so much you can squeeze through a pipe. When >> what you'd like to send is more than the network allows, a decision >> has to be taken, and that should be done on priorities. >> In a way that's similar to a loss - it's a decision on the sender >> side, to not send certain packets in favor of others. > > Except in most cases we're not sitting with a pile of frames/packets > and deciding which ones get dropped (liek a router); we're encoding > data to meet the current-moment bandwidth requirements. There is a > separate component of feeding data out onto the wire, which would be > applied to non-encode-controlled streams like a SCTP/DTLS > DataChannel sharing the pipe. For encoder-based streams, we > generally want to control via the encoder not by inducing possible > internal delay in how we select packets for transmission. > > If the data doesn't fit in the current pipe estimate, we shouldn't > be generating it in the first place. And intermediate nodes don't > know our priorities to adjust probability of drop except maybe > indirectly via markings, which may instead mess with order of > delivery (not a good thing). I agree about marking, or at least I'd like to keep this a separate issue, so I ignore your last sentence above. About the rest of what you say: I guess that may be case-dependent? I would think that always generating exactly the right amount, as you describe, is an ideal case - but sometimes you may not be able to get exactly that amount, and then you will have to have a (of course, very small) send buffer, and then honoring the importance of packets in this buffer is useful. BUT I am waving my hands here. Note that the case I previusly dealt with, this Ph.D. thesis: http://heim.ifi.uio.no/~michawe/research/students/michael_schier-diss_final.pdf ... is about real-time communication all right, but for real-time one- way TV transmission with interactive controls, having timing constraints which are probably not as strict as e.g. in WebRTC. Maybe we're only interested in codecs that would give you just the right amount of data at the right moment. I don't know (after all, rmcat is not exclusively about WebRTC too). I thought that we could probably have such situations with a short send buffer, and then honoring the importance of packets in this buffer would be useful, that's all. >>> I'm reduced to guesswork to try to attach a meaning to "P-block" >>> and >>> "B-block"... I'd rather not go too far into guesswork... >> >> >> A block is just a part of a frame. Anyway, as I said in my previous >> email, for simplicity it's enough to think about I- vs. P- vs. B- >> frames, exactly as you describe them here. > > Most packets are at a much higher level than blocks, so barring > considerable swizzling of internal order it's likely that all > packets for a frame should have similar priority and likelyhood of > drop. That depends on various factors and is not always true. Going back to the Ph.D. thesis I linked to above, and papers that have come out of it, in this case we had a clearly distinguishable importance for packets within the same frame, depending on block and macroblock types, their dependencies and such. I guess this will greatly depend on video configuration and whatnot. >>> That sounds like probability-of-loss... >> >> >> ... in the sender. See above. > > We should never drop in the sender. :-) That might have to depend on the granularity of send rates the codec produces. But again, I'm waving my hands. >>> see why that's necessarily true, unless you mean that any >>> intelligence >>> whatsoever at sender-side is forbidden.) >> >> I mean that any mechanism-specific intelligence at sender-side >> should be forbidden, if we settle for receiver-based congestion >> control. That's what I mean with "generic": not mechanism-specific. >> RMCAT will perhaps standardize 3 mechanisms. A, B and C. Say each >> is split into a sender and receiver behavior: A_send and A_recv, >> B_send and B_recv, C_send and C_recv. Say they are not compatible, >> i.e. A_send cannot talk to B_recv, and C_send cannot talk to A_recv >> and so on. Then, for any mechanism X to work, you need both X_send >> and X_recv to be in place. >> >> Say, we decide to do receiver-based congestion control. Then I >> argue that we should agree on G_send, which is a generic sender >> behavior. Then, A, B and C only consist of A_recv, B_recv and >> C_recv, and you always only need to deploy this receiving end to >> use the new mechanism. >> >> Symmetrically, the same is true for pure sender-based congestion >> control. It's a mix of the two that's hard to deploy. > > Not that I'm arguing for it at this moment: but you could design > things so that 'generic'/dumb mechanisms are available to support > either sender or receiver-based control, with the decision on which > done by negotiation or even in-band decision. It simply requires > defining both, and defining a way to select the one that's non- > default. > > This would allow innovation at either end in the future. > > As to whether this is useful... I haven't given it the thought it > deserves yet. But it's quite doable. This is an interesting idea! Not sure if it's useful either. Perhaps? > (And on a separate note, a 'generic'/dumb mechanism doesn't mean > there can't be feedback from the other side affecting how it > operates, or that it can't be a more complex state machine than > "send one packet per packet received"). Just that it be relatively > simple and well-defined. (A bit like the whole video-codec "we'll > define the quite-complex decoder and let the encoder innovate") Yes, agree 100% Cheers, Michael From lars@netapp.com Thu Oct 11 00:43:37 2012 Return-Path: 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 2E8AD21F8539 for ; Thu, 11 Oct 2012 00:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooEpRy31lgfq for ; Thu, 11 Oct 2012 00:43:36 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id C946121F84DD for ; Thu, 11 Oct 2012 00:43:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,570,1344236400"; d="p7s'?scan'208";a="699764585" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 11 Oct 2012 00:43:30 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q9B7hUUd027469 for ; Thu, 11 Oct 2012 00:43:30 -0700 (PDT) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.102]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 00:43:29 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: interest in streaming the session? Thread-Index: AQHNp4QamYZWPxfVBECIaKSk8d2MmQ== Date: Thu, 11 Oct 2012 07:43:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/signed; boundary="Apple-Mail=_2E950B7D-BA09-4E7E-BB07-C0DA838C0D2D"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [rmcat] interest in streaming the session? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "rmcat-chairs@tools.ietf.org" List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 07:43:37 -0000 --Apple-Mail=_2E950B7D-BA09-4E7E-BB07-C0DA838C0D2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, is there an interest in having our Atlanta session streamed online? = Please reply off-list if so. Lars= --Apple-Mail=_2E950B7D-BA09-4E7E-BB07-C0DA838C0D2D Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAxMTA3NDMyOFowIwYJKoZIhvcNAQkEMRYEFOpA bHs7MpdxVVpms5inmqpRl8WcMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAHHCiCFr +VlaSN+eilLDb59RplFA51VbHFTiLtAtAY05962rMUXeT8S6ofLPhW85AWjNCmUfyMjfC8O5G8xN obPT/0QFFUteW9W9UvVgHuV/Q4BCB47bb2zdM31AW66rOJ4L0NxP9eW4ZyG3uqd6oNpiYOlivij5 xWNx53ZD58mQEr6B8AO0KNfD+QjoIpZadwfl2b0xZqv/rgiIAwjQaX97w8s/jYRVnakJNEg7XGA+ x2EWonG0c99icWT8LJwofu76UrJhZVxTHgJfvBhPldXZBumYSj8kYTvLpPBEJlrW3g2H24jJW8B1 6IjAQL4LgPZgrteIhw4oSEQ427nFqNUAAAAAAAA= --Apple-Mail=_2E950B7D-BA09-4E7E-BB07-C0DA838C0D2D-- From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Oct 11 04:56:13 2012 Return-Path: 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 DE31521F86F8 for ; Thu, 11 Oct 2012 04:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYrh3XjWMOw0 for ; Thu, 11 Oct 2012 04:56:13 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id BC01E21F8625 for ; Thu, 11 Oct 2012 04:56:12 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 1F599633B1; Thu, 11 Oct 2012 13:56:11 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 0EF9659A8A; Thu, 11 Oct 2012 13:56:11 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: rmcat@ietf.org Date: Thu, 11 Oct 2012 13:56:10 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <5060725F.4090709@alvestrand.no> <50748338.7050900@jesup.org> In-Reply-To: <50748338.7050900@jesup.org> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201210111356.10209.mkuehle@ikr.uni-stuttgart.de> Cc: Randell Jesup , Michael Welzl Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:56:14 -0000 Hi, skipped the part on (intra-flow packet) priorities because that a topic on its own. > > I mean that any mechanism-specific intelligence at sender-side should > > be forbidden, if we settle for receiver-based congestion control. > > That's what I mean with "generic": not mechanism-specific. > > RMCAT will perhaps standardize 3 mechanisms. A, B and C. Say each is > > split into a sender and receiver behavior: A_send and A_recv, B_send > > and B_recv, C_send and C_recv. Say they are not compatible, i.e. > > A_send cannot talk to B_recv, and C_send cannot talk to A_recv and so > > on. Then, for any mechanism X to work, you need both X_send and X_recv > > to be in place. > > > > Say, we decide to do receiver-based congestion control. Then I argue > > that we should agree on G_send, which is a generic sender behavior. > > Then, A, B and C only consist of A_recv, B_recv and C_recv, and you > > always only need to deploy this receiving end to use the new mechanism. > > > > Symmetrically, the same is true for pure sender-based congestion > > control. It's a mix of the two that's hard to deploy. > > Not that I'm arguing for it at this moment: but you could design things > so that 'generic'/dumb mechanisms are available to support either sender > or receiver-based control, with the decision on which done by > negotiation or even in-band decision. It simply requires defining both, > and defining a way to select the one that's non-default. > > This would allow innovation at either end in the future. > > As to whether this is useful... I haven't given it the thought it > deserves yet. But it's quite doable. > > (And on a separate note, a 'generic'/dumb mechanism doesn't mean there > can't be feedback from the other side affecting how it operates, or that > it can't be a more complex state machine than "send one packet per > packet received"). Just that it be relatively simple and well-defined. > (A bit like the whole video-codec "we'll define the quite-complex > decoder and let the encoder innovate") I want to note that the algorithm design is mostly independent of this question who sends feedback to whom. A certain algorithm should be implementable at sender or receiver side. But as soon as you have one specific algorithm you might be able to analyze which implementation causes how much feedback to send. I personally agree that it would be nice to have on one side a very simple and well defined state maschine (dumb side) such that only one side needs to be changed to deploy new algorithms. But actually having this simple state maschine for both sides and then negotiate at the beginning who will do the actual control would be an option. For my understand in TCP the reason why sometmes a receiver control would be more useful, is because the receiver might be close to be bottleneck and thus might be able to use additional information on the bottleneck (without additional signaling and signaling delay to the sender). In case of interactive audio/video up- and downstream traffic between to home costumers it might be not that clear where the bottleneck is... Mirja From michawe@ifi.uio.no Thu Oct 11 05:05:21 2012 Return-Path: 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 98F3221F86CA for ; Thu, 11 Oct 2012 05:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PW2BtvZ0IKN for ; Thu, 11 Oct 2012 05:05:21 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id AA79321F86C3 for ; Thu, 11 Oct 2012 05:05:20 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TMHVv-0000PA-L8 for rmcat@ietf.org; Thu, 11 Oct 2012 14:05:19 +0200 Received: from vpn-client238.uio.no ([193.157.136.239] helo=[172.18.14.54]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TMHVu-00016W-Jb for rmcat@ietf.org; Thu, 11 Oct 2012 14:05:19 +0200 Message-Id: From: Michael Welzl To: rmcat WG In-Reply-To: <201210111356.10209.mkuehle@ikr.uni-stuttgart.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Oct 2012 14:05:16 +0200 References: <5060725F.4090709@alvestrand.no> <50748338.7050900@jesup.org> <201210111356.10209.mkuehle@ikr.uni-stuttgart.de> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 1 sum msgs/h 1 total rcpts 24553 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.997, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0C4EF11A2FF172C8BB8A88A6772DE9CDFEEDA130 X-UiO-SPAM-Test: remote_host: 193.157.136.239 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 475 max/h 14 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 12:05:21 -0000 Hi, Just saying, I agree 100% with every word here. Cheers, Michael On Oct 11, 2012, at 1:56 PM, Mirja K=FChlewind wrote: > Hi, > > skipped the part on (intra-flow packet) priorities because that a =20 > topic on its > own. > >>> I mean that any mechanism-specific intelligence at sender-side =20 >>> should >>> be forbidden, if we settle for receiver-based congestion control. >>> That's what I mean with "generic": not mechanism-specific. >>> RMCAT will perhaps standardize 3 mechanisms. A, B and C. Say each is >>> split into a sender and receiver behavior: A_send and A_recv, B_send >>> and B_recv, C_send and C_recv. Say they are not compatible, i.e. >>> A_send cannot talk to B_recv, and C_send cannot talk to A_recv and =20= >>> so >>> on. Then, for any mechanism X to work, you need both X_send and =20 >>> X_recv >>> to be in place. >>> >>> Say, we decide to do receiver-based congestion control. Then I argue >>> that we should agree on G_send, which is a generic sender behavior. >>> Then, A, B and C only consist of A_recv, B_recv and C_recv, and you >>> always only need to deploy this receiving end to use the new =20 >>> mechanism. >>> >>> Symmetrically, the same is true for pure sender-based congestion >>> control. It's a mix of the two that's hard to deploy. >> >> Not that I'm arguing for it at this moment: but you could design =20 >> things >> so that 'generic'/dumb mechanisms are available to support either =20 >> sender >> or receiver-based control, with the decision on which done by >> negotiation or even in-band decision. It simply requires defining =20= >> both, >> and defining a way to select the one that's non-default. >> >> This would allow innovation at either end in the future. >> >> As to whether this is useful... I haven't given it the thought it >> deserves yet. But it's quite doable. >> >> (And on a separate note, a 'generic'/dumb mechanism doesn't mean =20 >> there >> can't be feedback from the other side affecting how it operates, or =20= >> that >> it can't be a more complex state machine than "send one packet per >> packet received"). Just that it be relatively simple and well-=20 >> defined. >> (A bit like the whole video-codec "we'll define the quite-complex >> decoder and let the encoder innovate") > > I want to note that the algorithm design is mostly independent of this > question who sends feedback to whom. A certain algorithm should be > implementable at sender or receiver side. But as soon as you have one > specific algorithm you might be able to analyze which implementation =20= > causes > how much feedback to send. > > I personally agree that it would be nice to have on one side a very =20= > simple and > well defined state maschine (dumb side) such that only one side =20 > needs to be > changed to deploy new algorithms. But actually having this simple =20 > state > maschine for both sides and then negotiate at the beginning who will =20= > do the > actual control would be an option. > > For my understand in TCP the reason why sometmes a receiver control =20= > would be > more useful, is because the receiver might be close to be bottleneck =20= > and thus > might be able to use additional information on the bottleneck (without > additional signaling and signaling delay to the sender). In case of > interactive audio/video up- and downstream traffic between to home =20 > costumers > it might be not that clear where the bottleneck is... > > Mirja From michawe@ifi.uio.no Thu Oct 11 05:19:19 2012 Return-Path: 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 4DDCA21F8616 for ; Thu, 11 Oct 2012 05:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q64qsYhMEJXR for ; Thu, 11 Oct 2012 05:19:18 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id D8CF121F85B4 for ; Thu, 11 Oct 2012 05:19:14 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TMHjO-0002id-72 for rmcat@ietf.org; Thu, 11 Oct 2012 14:19:14 +0200 Received: from vpn-client238.uio.no ([193.157.136.239] helo=[172.18.14.54]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TMHjM-0004yI-IL for rmcat@ietf.org; Thu, 11 Oct 2012 14:19:14 +0200 Message-Id: <985E7F58-2217-4256-A995-9ABBD2E29E72@ifi.uio.no> From: Michael Welzl To: rmcat WG In-Reply-To: <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Oct 2012 14:19:09 +0200 References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 2 sum msgs/h 2 total rcpts 24554 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.997, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 69CA5E850E6DD614C845E8E62F60A53674F00BCC X-UiO-SPAM-Test: remote_host: 193.157.136.239 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 476 max/h 14 blacklist 0 greylist 0 ratelimit 0 Subject: [rmcat] Reliable feedback 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 12:19:19 -0000 Hi all, Just a quick thought, below, quoting my own old email again (sorry): On Oct 4, 2012, at 12:58 PM, Michael Welzl wrote: > I herewith extend my own analysis of the sender- vs. receiver-based > congestion control question, with one (in my opinion) significant > plus in each camp: > >> Ok, I think you got me convinced. The way I see it, there's a >> choice between: >> 1) sending a lot of feedback, and only reducing it when there is >> backwards congestion, by doing congestion control on the backwards >> channel like ACK-CC >> 2) simply always sending as little feedback as possible, based on >> the (forward) congestion control mechanism's requirements >> >> If we think of e.g. a videoconference, indeed congestion from all >> the feedback on the uplink is quite realistic. 1) can then become >> rather complicated... you may get congestion on your uplink, and it >> might be necessary to reduce the rate of your data stream, or it >> might suffice to reduce it on some of the feedback streams, but >> which? And then we have to apply priorities between feedback >> packets and your payload... >> > >> 2) seems simpler, but it has the problem of making the mechanism >> more fragile, and perhaps unnecessarily so (in a situation where it >> might be fine to send much more feedback). I say "unnecessarily" >> because I'm not convinced about "both channels are always >> congested, or will be soon" because codecs may not be greedy, and >> streams such as VoIP may simply not generate enough traffic for that. This increased fragility is, to me, the biggest problem of 2) above (feedback minimization via receiver-based control). But: I think this could largely be compensated for if we make that feedback reliable (a la ACKs-of-ACKs). What I mean is: a sender could piggyback a short message in its data packets to the receiver, to acknowledge the reception of feedback. If a receiver only sends feedback very rarely, it could use a quite aggressive timeout to send the feedback again if it doesn't get an acknowledgement fast. Yes, this message would be piggybacked onto an unreliable data stream, but such problems have been fixed before (e.g. TCP's ECN-ECE-CWR sequence). What does everyone think? Good idea, bad idea? (yes, I know, such stuff would ideally be discussed in the context of the RTCP extensions draft, but I clearly don't know enough about RTP/ RTCP to lead this effort... happy to contribute though!) > 2), i.e. receiver-side congestion control, also has the ADVANTAGE > that it doesn't misinterpret the loss of feedback as an indication > of forward congestion. A receiver-side controller has a clear notion > of all packets that have arrived in an interval and knows exactly > what was dropped on the way from the sender to the receiver and what > wasn't. > > 2), i.e. receiver-side congestion control, also has the DISADVANTAGE > that tight interaction with the sending application gets harder - > e.g., to consider per-packet priorities in the congestion control > mechanism. With a receiver-side scheme, this requires richer > feedback (in the style: "for high-priority packets: this rate; for > low-priority and high-priority packets combined: that rate"). Then, > the receiver would have to know how many priorities are there on the > sender side to give the right amount of feedback... this will make > things unnecessarily complicated or, as I rather suspect, not > happen, and then greatly limit us. > > > > Cheers, > Michael > From lars@netapp.com Fri Oct 12 01:29:22 2012 Return-Path: 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 DD6EF21F853F for ; Fri, 12 Oct 2012 01:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOluZewCxAJP for ; Fri, 12 Oct 2012 01:29:22 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 52BD021F853C for ; Fri, 12 Oct 2012 01:29:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,576,1344236400"; d="p7s'?scan'208";a="700135771" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 12 Oct 2012 01:29:22 -0700 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q9C8TLkK021752; Fri, 12 Oct 2012 01:29:22 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.216]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 01:29:21 -0700 From: "Eggert, Lars" To: Xiaoqing Zhu Thread-Topic: [rmcat] send agenda requests (was Re: First meeting) Thread-Index: AQHNp9gjLnb/cyI3SEW608TCOjF7Mpe1zQOA Date: Fri, 12 Oct 2012 08:29:21 +0000 Message-ID: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/signed; boundary="Apple-Mail=_80DF2169-D63C-48E2-9A06-74A9250C0DF5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: rmcat WG , "Rong \(ropan\) \(ropan\)" , Xiaoqing Zhu Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 08:29:23 -0000 --Apple-Mail=_80DF2169-D63C-48E2-9A06-74A9250C0DF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On Oct 11, 2012, at 18:45, Xiaoqing Zhu = wrote: > My colleague and I are working on a congestion control scheme for > real-time conferencing applications at Cisco. A brief version of that > algorithm was presented at the IAB Workshop in Vancouver (paper #12, > "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due > to time constraints, however, we did not get a chance to mention the > delay-based variant of that scheme, which may be a better fit for > rmcat. >=20 > We would like to request for a slot to present in Atlanta. We will > also submit the ID draft before Oct 15, for further discussions on > this mailing list. I look forward to seeing the draft being discussed on the list! Also, I'm noting your request for a slot. Because the actual CC = mechanisms are not our most pressing milestones initially - the = requirements and eval criteria are - we may decide to focus our meeting = time on those other drafts, if demand for agenda time is high.=20 Lars= --Apple-Mail=_80DF2169-D63C-48E2-9A06-74A9250C0DF5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAxMjA4MjkyMVowIwYJKoZIhvcNAQkEMRYEFPkx K2CVi2PMCUFgye/jyCk8rk82MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAG2XmmBD YwzX8MNxTWs4HYE1ENLcwvtayzOz6Eu+G+5w5DUslVyqDUogi9PSDf5XR1VTJK1768qfwqw/NvDC u5rNWqf1IfYN+2hDDxEdyHwW4zs5H8AWCcHPbw9OcjxSLPjYZkM1Od0m8B5aQYReV6ThqO71//tf XTuCJb2XFnPwW2LNWZiiuJWoUfzH5PNZyVcpvRqIoUeRaP9oxtF3gcGnDtAkEzBWHwApL5qxxDAR 6DJvzsUwl42mNeoZrsgJTd/C8bFL4gIXCAzHx8ujy6RLoJJ/dPhhd0nbi1tzWIK4txqcUNzHmDvs ZoHzlBgbgqSNEyhd+mmk5Lro45FEroIAAAAAAAA= --Apple-Mail=_80DF2169-D63C-48E2-9A06-74A9250C0DF5-- From john@jlc.net Fri Oct 12 03:41:04 2012 Return-Path: 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 ACB8421F8567 for ; Fri, 12 Oct 2012 03:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.429 X-Spam-Level: X-Spam-Status: No, score=-106.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjeMmO2yF39b for ; Fri, 12 Oct 2012 03:41:04 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E9DEE21F855A for ; Fri, 12 Oct 2012 03:41:03 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id CC81B33C23; Fri, 12 Oct 2012 06:41:02 -0400 (EDT) Date: Fri, 12 Oct 2012 06:41:02 -0400 From: John Leslie To: Michael Welzl Message-ID: <20121012104102.GE22359@verdi> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> <9E9AE97E-2E9E-406B-8E55-2FAA966DF9D3@ifi.uio.no> <985E7F58-2217-4256-A995-9ABBD2E29E72@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <985E7F58-2217-4256-A995-9ABBD2E29E72@ifi.uio.no> User-Agent: Mutt/1.4.1i Cc: rmcat WG Subject: Re: [rmcat] Reliable feedback 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 10:41:04 -0000 Michael Welzl wrote: >... >>> The way I see it, there's a choice between: >>> 1) sending a lot of feedback, and only reducing it when there is >>> backwards congestion, by doing congestion control on the >>> backwards channel like ACK-CC >>> 2) simply always sending as little feedback as possible, based on >>> the (forward) congestion control mechanism's requirements I'm not commenting on this choice! > This increased fragility is, to me, the biggest problem of 2) above > (feedback minimization via receiver-based control). (I'm not commenting on that either.) > But: I think this could largely be compensated for if we make that > feedback reliable (a la ACKs-of-ACKs). We should be careful about using the term "reliable". > What I mean is: a sender could piggyback a short message in its data > packets to the receiver, to acknowledge the reception of feedback. > If a receiver only sends feedback very rarely, it could use a quite > aggressive timeout to send the feedback again if it doesn't get an > acknowledgement fast. This is, indeed, possible. But since we're inherently talking "media" here, there will inherently be a fairly-regular succession of packets from "sender" to "receiver". Keeping an event-counter and always sending a few low-order bits of that counter gives us a better approximation of what we want than any attempt at "reliable" by re-transmission. (I also claim that many of our use-cases will involve media in both directions, and that the remainder deserve periodic "I'm still listening" messages; so there is always a packet stream to attach these low-order bits to, although the packet rates may be quite different in the two directions.) > Yes, this message would be piggybacked onto an unreliable data stream, > but such problems have been fixed before (e.g. TCP's ECN-ECE-CWR > sequence). ECN-ECE-CWR is doing essentially the event-counter sending one low-order bit. I prefer to think of the general case, and recommend two or three low-order bits at least. (Bits just aren't as scarce today as they were ten years ago -- heck, RFC3168 was trying to squeeze into a 1981 straitjacket!) > What does everyone think? Good idea, bad idea? I prefer the always-send-counter approach to reliable-by-retransmit. I have no objection to _also_ sending an immediate event-report, but I'm not sure it's worth the trouble. We care about avoiding self-congestion; but that's mostly a matter of avoiding the TCP habit of ramping-up too quickly. Depending on an unreliable event report to tune the ramp-up is a suboptimal design. > (yes, I know, such stuff would ideally be discussed in the context of > the RTCP extensions draft, but I clearly don't know enough about RTP/ > RTCP to lead this effort... happy to contribute though!) Hint to chairs: I think Michael would be a good Document Editor for this... -- John Leslie From xiaoqzhu@cisco.com Fri Oct 12 11:42:50 2012 Return-Path: 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 92ADF21F8731 for ; Fri, 12 Oct 2012 11:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdTAsz-1YKY4 for ; Fri, 12 Oct 2012 11:42:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C1FAE21F8712 for ; Fri, 12 Oct 2012 11:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1363; q=dns/txt; s=iport; t=1350067369; x=1351276969; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nqd/QT4bx2byxFB4SZC6zbZl9pbEWHNkZnLmxivT7zU=; b=OO1p848fmYK6EdOef2JTsp8swlPZEOo4QW24AgwvU7VpadhEe4QlnAFD kQYrhk1o8p4A2AzPjmKxN4E1XFMJf1FqWfakAQWQgsgyT2mUwz2RwHC44 RVnCMMLeeF19w9IGTikdKq5t/pkRUZlrJFVWLDrXEwB3SepwWdNeu1kBr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEVkeFCtJXG9/2dsb2JhbABFgm68eIEIgiABAQEDARIBJzQLBQsCAQgYChQQMiUCBA4FCBqHXAYBmnSgBYtShV1gA6QygWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,577,1344211200"; d="scan'208";a="131073156" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 12 Oct 2012 18:42:36 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9CIgaqu021744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Oct 2012 18:42:36 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 13:42:35 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "Eggert, Lars" Thread-Topic: [rmcat] send agenda requests (was Re: First meeting) Thread-Index: AQHNp9grf2quh6JMt0CYpuBNP/SHCpe1q3yAgACrU4A= Date: Fri, 12 Oct 2012 18:42:34 +0000 Message-ID: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.215.233] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000 x-tm-as-result: No--33.074600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <1EAC0862E617F049BDDBF9EA79519EC2@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 12 Oct 2012 13:22:06 -0700 Cc: rmcat WG , Xiaoqing Zhu , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 18:42:50 -0000 Hi Lars,=20 Thanks a lot for your prompt response. Fully agree with the chosen priorit= ies for the topics=20 to be discussed in the meeting. I'll keep you posted once the draft is sub= mitted.=20 Best, Xiaoqing =20 On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: > Hi, >=20 > On Oct 11, 2012, at 18:45, Xiaoqing Zhu wrote= : >> My colleague and I are working on a congestion control scheme for >> real-time conferencing applications at Cisco. A brief version of that >> algorithm was presented at the IAB Workshop in Vancouver (paper #12, >> "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due >> to time constraints, however, we did not get a chance to mention the >> delay-based variant of that scheme, which may be a better fit for >> rmcat. >>=20 >> We would like to request for a slot to present in Atlanta. We will >> also submit the ID draft before Oct 15, for further discussions on >> this mailing list. >=20 > I look forward to seeing the draft being discussed on the list! >=20 > Also, I'm noting your request for a slot. Because the actual CC mechanism= s are not our most pressing milestones initially - the requirements and eva= l criteria are - we may decide to focus our meeting time on those other dra= fts, if demand for agenda time is high.=20 >=20 > Lars From vsingh.ietf@gmail.com Mon Oct 15 13:33:59 2012 Return-Path: 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 AD83721F89A4 for ; Mon, 15 Oct 2012 13:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGjwhDSESA1o for ; Mon, 15 Oct 2012 13:33:58 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B441721F8987 for ; Mon, 15 Oct 2012 13:33:58 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so5221070pbb.31 for ; Mon, 15 Oct 2012 13:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=6A62kf+5FVYY/CKxeIQStvB0pwQ4DjmTrJVg4jNub/8=; b=I4MOr0hIN3qXxmrwXCD4SLPlvNlZAYYpg39bsXgmMdtih+OKQFE8FW9CUDYDf6ShTf vrEIqGOKqIzTMYRB9vToe4eqtAwlT+7PHYbCpBz6L0cMjcSR58mYsXJPzcqJxg8l13J7 pib9ZCLkHPO+FtVR6FvGIpW/JZ/2NYU7uIR/UyVIz0CixZe7vE2250UgWH4O4H+nR0Fi fJquQc/mZA8VBQnV4/TPrTplNPk+o9LWNb1ZI4eble1NOuLbsM1by2svNVnQr1WAJD6y Gl5dCsf8RTfFdL32Td/J4MG28mowPKbMDZuUAE4oRTchR4ZTvvsHkXmRBuZzjpj6J+uf w/Bg== Received: by 10.68.229.201 with SMTP id ss9mr40486109pbc.80.1350333238390; Mon, 15 Oct 2012 13:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.29.105 with HTTP; Mon, 15 Oct 2012 13:33:37 -0700 (PDT) From: Varun Singh Date: Mon, 15 Oct 2012 23:33:37 +0300 Message-ID: To: rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [rmcat] Fwd: New Version Notification for draft-singh-rmcat-cc-eval-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 20:33:59 -0000 Greetings, We have submitted an initial draft outlining the criteria for evaluating congestion control algorithms. The metrics section is a bit light on details and will to expand on that in the next revision. We hope that the draft is a good starting point to get the discussion started about metrics and scenarios for simulation and testbed experiments. Cheers, Varun Begin forwarded message: A new version of I-D, draft-singh-rmcat-cc-eval-00.txt has been successfully submitted by Varun Singh and posted to the IETF repository. Filename: draft-singh-rmcat-cc-eval Revision: 00 Title: Evaluating Congestion Control for Interactive Real-time Media. Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-singh-rmcat-cc-eval-00.txt Status: http://datatracker.ietf.org/doc/draft-singh-rmcat-cc-eval Htmlized: http://tools.ietf.org/html/draft-singh-rmcat-cc-eval-00 Abstract: The Real-time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media. The IETF Secretariat From xiaoqzhu@cisco.com Mon Oct 15 14:44:14 2012 Return-Path: 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 499B821F89A7 for ; Mon, 15 Oct 2012 14:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-hOUiY7iOzr for ; Mon, 15 Oct 2012 14:44:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D6A7821F89B2 for ; Mon, 15 Oct 2012 14:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8060; q=dns/txt; s=iport; t=1350337440; x=1351547040; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Qz2uyRkc/JFKgST38yoKh93j6LrXJgktSpQhQxbIzFU=; b=hkr2ZofboEod9i5Jx8kvGdc8kto5/oTrJSHZre5kfncBGDRK3b57Z3O/ nvM5zAlBGIHEzSYeVUHj50otWv/89yt9BUOJA3YvaWJ6CXcei5hFfIOTq ZX0PN9FpZHknrAUho+k0nY40lv7LyqOhFVXXfipikp/ZILdFHYtDwhUm8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIIAEyDfFCtJXHA/2dsb2JhbABFgm6GA6VGiHQBhieCP4EIgiEBAQQSAVsLEAIBCBIQHQcyFAMOAgQOBQgBGYdiAQqcOaAri1mFXWADlwGNMIFrgS6BP4IX X-IronPort-AV: E=Sophos;i="4.80,590,1344211200"; d="scan'208,217";a="131860766" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 15 Oct 2012 21:43:59 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9FLhxCO012261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 21:43:59 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 16:43:59 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "Eggert, Lars" Thread-Topic: [rmcat] send agenda requests (was Re: First meeting) Thread-Index: AQHNp9grf2quh6JMt0CYpuBNP/SHCpe1q3yAgAWVAgA= Date: Mon, 15 Oct 2012 21:43:59 +0000 Message-ID: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.37.20] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--26.000300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E7175A8E3DC14048A7D3020E0338C1FA0B3EE9xmbalnx13ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 15 Oct 2012 16:24:28 -0700 Cc: rmcat WG , Xiaoqing Zhu , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 21:44:14 -0000 --_000_E7175A8E3DC14048A7D3020E0338C1FA0B3EE9xmbalnx13ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And below is the notification of our submission: Thanks, Xiaoqing -------------------------------------- A new version of I-D, draft-zhu-rmcat-nada-00.txt has been successfully submitted by Xiaoqing Zhu and posted to the IETF repository. Filename: draft-zhu-rmcat-nada Revision: 00 Title: NADA: A Unified Congestion Control Scheme for Real-Time Media Creation date: 2012-10-14 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-0= 0.txt Status: http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-00 Abstract: This document describes a scheme named network-assisted dynamic adaptation (NADA), a novel congestion control approach for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can reap the benefits of explicit congestion notification markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays instead. We present here the overall system architecture, recommended behaviors at the sender and the receiver, as well as expected network nodes operations. Results from extensive simulation studies of the proposed scheme are available upon request. The IETF Secretariat -------------------------------------- On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: Hi, On Oct 11, 2012, at 18:45, Xiaoqing Zhu > wrote: My colleague and I are working on a congestion control scheme for real-time conferencing applications at Cisco. A brief version of that algorithm was presented at the IAB Workshop in Vancouver (paper #12, "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due to time constraints, however, we did not get a chance to mention the delay-based variant of that scheme, which may be a better fit for rmcat. We would like to request for a slot to present in Atlanta. We will also submit the ID draft before Oct 15, for further discussions on this mailing list. I look forward to seeing the draft being discussed on the list! Also, I'm noting your request for a slot. Because the actual CC mechanisms = are not our most pressing milestones initially - the requirements and eval = criteria are - we may decide to focus our meeting time on those other draft= s, if demand for agenda time is high. Lars --_000_E7175A8E3DC14048A7D3020E0338C1FA0B3EE9xmbalnx13ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1EA607A75E121F48B11854DA9ADED3C3@cisco.com> Content-Transfer-Encoding: quoted-printable And below is the notification of our submission: 

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename:  draft-zhu-rmcat-nada
Revision:  00
Title: <= span class=3D"Apple-tab-span" style=3D"white-space: pre; "> NAD= A: A Unified Congestion Control Scheme for Real-Time Media
Creation date: =  2012-10-14
WG ID: <= span class=3D"Apple-tab-span" style=3D"white-space: pre; "> Ind= ividual Submission
Number of pages: 10
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt
Status:          http://datatracker.ietf= .org/doc/draft-zhu-rmcat-nada
Htmlized:        http://tools.ietf.org/html/draft-zh= u-rmcat-nada-00


Abstract:
  This document describes a scheme named network-assisted dynamic=
  adaptation (NADA), a novel congestion control approach for
  interactive real-time media applications, such as video confere= ncing.
  In the proposed scheme, the sender regulates its sending rate b= ased
  on either implicit or explicit congestion signaling, in a unifi= ed
  approach. The scheme can reap the benefits of explicit congesti= on
  notification markings from network nodes. It also maintains
  consistent sender behavior in the absence of such markings, by<= br>   reacting to queuing delays instead.

  We present here the overall system architecture, recommended   behaviors at the sender and the receiver, as well as expected n= etwork
  nodes operations. Results from extensive simulation studies of = the
  proposed scheme are available upon request.




The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <zhuxq@alumni.stanford.edu> wrote:
My colleague and I are working on a congestion co= ntrol scheme for
real-time conferencing applications at Cisco. A b= rief version of that
algorithm was presented at the IAB Workshop in Va= ncouver (paper #12,
"Network-Assisted Dynamic Adaptation (NADA):= A Design Summary"). Due
to time constraints, however, we did not get a ch= ance to mention the
delay-based variant of that scheme, which may be = a better fit for
rmcat.

We would like to request for a slot to present in= Atlanta. We will
also submit the ID draft before Oct 15, for furth= er discussions on
this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC mechanisms = are not our most pressing milestones initially - the requirements and eval = criteria are - we may decide to focus our meeting time on those other draft= s, if demand for agenda time is high.

Lars

--_000_E7175A8E3DC14048A7D3020E0338C1FA0B3EE9xmbalnx13ciscocom_-- From michawe@ifi.uio.no Tue Oct 16 01:11:42 2012 Return-Path: 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 AE6E621F886E for ; Tue, 16 Oct 2012 01:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1McU4xym+JYC for ; Tue, 16 Oct 2012 01:11:41 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCD121F8868 for ; Tue, 16 Oct 2012 01:11:41 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TO2FV-0007W4-0P; Tue, 16 Oct 2012 10:11:37 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TO2FU-0002fR-BK; Tue, 16 Oct 2012 10:11:36 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_47AD916F-E81B-4512-8265-7D9492391FB7" From: Michael Welzl In-Reply-To: Date: Tue, 16 Oct 2012 10:11:32 +0200 Message-Id: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> To: Xiaoqing Zhu (xiaoqzhu) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 24665 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.912, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 63D72662DF20B497725A8F708F500BBF985A1E95 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 9915 max/h 21 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 08:11:42 -0000 --Apple-Mail=_47AD916F-E81B-4512-8265-7D9492391FB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I took a quick look at this: I like the general idea of using as much as possible of existing network = support - but I'm critical about the actual control you propose. In section 5.3.2, you suggest to replace eqn. 1 from section 5.3 with = eqn. 2 when ECN feedback is available. This means to ignore a delay = signal from now on, and interpret ECN marks in the exact same way as you = interpreted delay before - this is too simplistic, I think. After all, = ECN marks require a queue to grow, and this group intends to minimize = delay... why would you stop using delay once you have ECN in addition? In practice, using your scheme would probably mean that, as soon as I = enable RED with ECN on the bottleneck between the two end systems, the = users' observed delay grows. Not exactly an incentive? Cheers, Michael On 15. okt. 2012, at 23:43, Xiaoqing Zhu (xiaoqzhu) wrote: > And below is the notification of our submission:=20 >=20 > Thanks, > Xiaoqing >=20 > -------------------------------------- > A new version of I-D, draft-zhu-rmcat-nada-00.txt > has been successfully submitted by Xiaoqing Zhu and posted to the > IETF repository. >=20 > Filename: draft-zhu-rmcat-nada > Revision: 00 > Title: NADA: A Unified Congestion Control Scheme for Real-Time Media > Creation date: 2012-10-14 > WG ID: Individual Submission > Number of pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt > Status: http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada > Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-00 >=20 >=20 > Abstract: > This document describes a scheme named network-assisted dynamic > adaptation (NADA), a novel congestion control approach for > interactive real-time media applications, such as video = conferencing. > In the proposed scheme, the sender regulates its sending rate based > on either implicit or explicit congestion signaling, in a unified > approach. The scheme can reap the benefits of explicit congestion > notification markings from network nodes. It also maintains > consistent sender behavior in the absence of such markings, by > reacting to queuing delays instead. >=20 > We present here the overall system architecture, recommended > behaviors at the sender and the receiver, as well as expected = network > nodes operations. Results from extensive simulation studies of the > proposed scheme are available upon request. >=20 >=20 >=20 >=20 > The IETF Secretariat > -------------------------------------- > On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: >=20 >> Hi, >>=20 >> On Oct 11, 2012, at 18:45, Xiaoqing Zhu = wrote: >>> My colleague and I are working on a congestion control scheme for >>> real-time conferencing applications at Cisco. A brief version of = that >>> algorithm was presented at the IAB Workshop in Vancouver (paper #12, >>> "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due >>> to time constraints, however, we did not get a chance to mention the >>> delay-based variant of that scheme, which may be a better fit for >>> rmcat. >>>=20 >>> We would like to request for a slot to present in Atlanta. We will >>> also submit the ID draft before Oct 15, for further discussions on >>> this mailing list. >>=20 >> I look forward to seeing the draft being discussed on the list! >>=20 >> Also, I'm noting your request for a slot. Because the actual CC = mechanisms are not our most pressing milestones initially - the = requirements and eval criteria are - we may decide to focus our meeting = time on those other drafts, if demand for agenda time is high.=20 >>=20 >> Lars >=20 --Apple-Mail=_47AD916F-E81B-4512-8265-7D9492391FB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
And below is the notification of our submission: 

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename: =  draft-zhu-rmcat-nada
Revision: =  00
Title: = = h= ttp://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt
Status:          http://datat= racker.ietf.org/doc/draft-zhu-rmcat-nada
Htmlized:        http://tools.i= etf.org/html/draft-zhu-rmcat-nada-00


Abstract:
  This document describes a scheme named network-assisted = dynamic
  adaptation (NADA), a novel congestion control approach = for
  interactive real-time media applications, such as video = conferencing.
  In the proposed scheme, the sender regulates its sending = rate based
  on either implicit or explicit congestion signaling, in a = unified
  approach. The scheme can reap the benefits of explicit = congestion
  notification markings from network nodes. It also = maintains
  consistent sender behavior in the absence of such markings, = by
  reacting to queuing delays instead.

  We present here the overall system architecture, = recommended
  behaviors at the sender and the receiver, as well as = expected network
  nodes operations. Results from extensive simulation studies = of the
  proposed scheme are available upon request.




The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <zhuxq@alumni.stanford.edu>= ; wrote:
My colleague and I are working on a congestion = control scheme for
real-time conferencing applications at Cisco. = A brief version of that
algorithm was presented at the IAB Workshop in = Vancouver (paper #12,
"Network-Assisted Dynamic Adaptation (NADA): A = Design Summary"). Due
to time constraints, however, we did not get a = chance to mention the
delay-based variant of that scheme, which may = be a better fit for
rmcat.

We would like to request for a slot to present = in Atlanta. We will
also submit the ID draft before Oct 15, for = further discussions on
this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC = mechanisms are not our most pressing milestones initially - the = requirements and eval criteria are - we may decide to focus our meeting = time on those other drafts, if demand for agenda time is high.

Lars


= --Apple-Mail=_47AD916F-E81B-4512-8265-7D9492391FB7-- From p.ohanlon@gmail.com Tue Oct 16 01:55:07 2012 Return-Path: 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 C13BC21F88AC for ; Tue, 16 Oct 2012 01:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axhzOc+hMLQV for ; Tue, 16 Oct 2012 01:55:06 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE2721F88AB for ; Tue, 16 Oct 2012 01:55:05 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so2651276wib.13 for ; Tue, 16 Oct 2012 01:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=o9qo48r/jB/nbZMBHEpBPNbcYHzvlfMtswfI1DwSTw0=; b=UQyHU+xVVyVA3HXEWYm47vAlLda6WDwjEM3naBg7YKO8pRlkdlxwCkPkP/Skrmwx0J NT0SeABKh5g54O4AXd1WUs93Dsa/nUeDk3d60OKoJvV/pNgWq22BIDXvYnQTS5Fx14sa djRrmsRTX6Gn/o45wI22kf5peFZmTTXbemwtg5Wyq1o+OYScX0BGbEj8j7CaS7hLv5M1 Kw6HbwDuTLI9dsZw9s7zI6+c9RatHQ/fvL1DTUpui5+0k+aNAbkOhInA2QL/W9foIfnD rra/05EOlneoKO9NjySkWZX6Rfn+qTdMDB3aRSkFmBy8Pf94BdMG4S1nqoJkecfFsjBX YyAg== Received: by 10.180.87.132 with SMTP id ay4mr30186293wib.5.1350377704874; Tue, 16 Oct 2012 01:55:04 -0700 (PDT) Received: from black.lan ([149.241.132.141]) by mx.google.com with ESMTPS id cl8sm18199067wib.10.2012.10.16.01.54.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Oct 2012 01:54:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_83DB50FE-0A30-47A5-8CE3-3F5233EB7349" From: Piers O'Hanlon In-Reply-To: Date: Tue, 16 Oct 2012 09:54:39 +0100 Message-Id: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> To: "Xiaoqing Zhu (xiaoqzhu)" X-Mailer: Apple Mail (2.1283) Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 08:55:07 -0000 --Apple-Mail=_83DB50FE-0A30-47A5-8CE3-3F5233EB7349 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I too had a quick look at the proposal. I was interested as to how kappa is calculated in equation (1) or = whether it is a fixed value? Also your slow start algorithm only seems to be time dependent - = literally it appears to start slowly from t_0 to some preset time (T) - = is there any mechanism to terminate slow start on loss/marked packets? = Does slow start ever occur mid stream? (e.g. after a silence period?) Out of interest it was mentioned that there were extensive simulation = studies - would it be possible to post a simulation of multiple NADA = flows competing. And also a competition of NADA with a TCP flow? Thanks, Piers. On 15 Oct 2012, at 22:43, Xiaoqing Zhu (xiaoqzhu) wrote: > And below is the notification of our submission:=20 >=20 > Thanks, > Xiaoqing >=20 > -------------------------------------- > A new version of I-D, draft-zhu-rmcat-nada-00.txt > has been successfully submitted by Xiaoqing Zhu and posted to the > IETF repository. >=20 > Filename: draft-zhu-rmcat-nada > Revision: 00 > Title: NADA: A Unified Congestion Control Scheme for Real-Time Media > Creation date: 2012-10-14 > WG ID: Individual Submission > Number of pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt > Status: http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada > Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-00 >=20 >=20 > Abstract: > This document describes a scheme named network-assisted dynamic > adaptation (NADA), a novel congestion control approach for > interactive real-time media applications, such as video = conferencing. > In the proposed scheme, the sender regulates its sending rate based > on either implicit or explicit congestion signaling, in a unified > approach. The scheme can reap the benefits of explicit congestion > notification markings from network nodes. It also maintains > consistent sender behavior in the absence of such markings, by > reacting to queuing delays instead. >=20 > We present here the overall system architecture, recommended > behaviors at the sender and the receiver, as well as expected = network > nodes operations. Results from extensive simulation studies of the > proposed scheme are available upon request. >=20 >=20 >=20 >=20 > The IETF Secretariat > -------------------------------------- > On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: >=20 >> Hi, >>=20 >> On Oct 11, 2012, at 18:45, Xiaoqing Zhu = wrote: >>> My colleague and I are working on a congestion control scheme for >>> real-time conferencing applications at Cisco. A brief version of = that >>> algorithm was presented at the IAB Workshop in Vancouver (paper #12, >>> "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due >>> to time constraints, however, we did not get a chance to mention the >>> delay-based variant of that scheme, which may be a better fit for >>> rmcat. >>>=20 >>> We would like to request for a slot to present in Atlanta. We will >>> also submit the ID draft before Oct 15, for further discussions on >>> this mailing list. >>=20 >> I look forward to seeing the draft being discussed on the list! >>=20 >> Also, I'm noting your request for a slot. Because the actual CC = mechanisms are not our most pressing milestones initially - the = requirements and eval criteria are - we may decide to focus our meeting = time on those other drafts, if demand for agenda time is high.=20 >>=20 >> Lars >=20 --Apple-Mail=_83DB50FE-0A30-47A5-8CE3-3F5233EB7349 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
And below is the notification of our submission: 

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename: =  draft-zhu-rmcat-nada
Revision: =  00
Title: = = h= ttp://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt
Status:          http://datat= racker.ietf.org/doc/draft-zhu-rmcat-nada
Htmlized:        http://tools.i= etf.org/html/draft-zhu-rmcat-nada-00


Abstract:
  This document describes a scheme named network-assisted = dynamic
  adaptation (NADA), a novel congestion control approach = for
  interactive real-time media applications, such as video = conferencing.
  In the proposed scheme, the sender regulates its sending = rate based
  on either implicit or explicit congestion signaling, in a = unified
  approach. The scheme can reap the benefits of explicit = congestion
  notification markings from network nodes. It also = maintains
  consistent sender behavior in the absence of such markings, = by
  reacting to queuing delays instead.

  We present here the overall system architecture, = recommended
  behaviors at the sender and the receiver, as well as = expected network
  nodes operations. Results from extensive simulation studies = of the
  proposed scheme are available upon request.




The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <zhuxq@alumni.stanford.edu>= ; wrote:
My colleague and I are working on a congestion = control scheme for
real-time conferencing applications at Cisco. = A brief version of that
algorithm was presented at the IAB Workshop in = Vancouver (paper #12,
"Network-Assisted Dynamic Adaptation (NADA): A = Design Summary"). Due
to time constraints, however, we did not get a = chance to mention the
delay-based variant of that scheme, which may = be a better fit for
rmcat.

We would like to request for a slot to present = in Atlanta. We will
also submit the ID draft before Oct 15, for = further discussions on
this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC = mechanisms are not our most pressing milestones initially - the = requirements and eval criteria are - we may decide to focus our meeting = time on those other drafts, if demand for agenda time is high.

Lars


= --Apple-Mail=_83DB50FE-0A30-47A5-8CE3-3F5233EB7349-- From ldecicco@gmail.com Tue Oct 16 02:01:23 2012 Return-Path: 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 38F1D21F88C5 for ; Tue, 16 Oct 2012 02:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiNeybKAos76 for ; Tue, 16 Oct 2012 02:01:22 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE5221F88B8 for ; Tue, 16 Oct 2012 02:01:22 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so6934770vbb.31 for ; Tue, 16 Oct 2012 02:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vlIZiJCyXjJiOVUXm1QoqLdrUh3hRXt/e/mjngBkv3g=; b=jG72DGbgv70w+LnD3o30AAqo3CqnGfNQTfq2YvZq7Fdv0nLBLbK+6N35kIIz6bybK1 fDBYo7iaCzub+xmpEdoLBUDZ9Wtfib6DHfVoXZz1TwuyKJkbsGNauTmYkJ8Fm9HO4hwb eOVwQJ2WR3Npn6ajyDDu2wMjXrK3aDh98gJOz2cXr7T5M/AbyoPfevZlrMVwmJu1HxJX litGfw5Ud2rGYIVWe14u3N6N1NSIYdU3lqPf2O1KCx9+XikkOMQsGuxylQ1xLbCXz7lL QE837SaZmLO0m/cUJ3Dyav+itk8A2mOCOj8jOzHTRjtTkt0D+z4PgH2/0vPu7BOZ/vxJ NCEA== MIME-Version: 1.0 Received: by 10.220.154.17 with SMTP id m17mr8300545vcw.31.1350378081531; Tue, 16 Oct 2012 02:01:21 -0700 (PDT) Received: by 10.58.246.201 with HTTP; Tue, 16 Oct 2012 02:01:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Oct 2012 11:01:21 +0200 Message-ID: From: Luca De Cicco To: Varun Singh Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat WG Subject: Re: [rmcat] Fwd: New Version Notification for draft-singh-rmcat-cc-eval-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 09:01:23 -0000 Dear Varun, I've read the draft and I have a couple of comments. 1) regarding the definition of stability which is given in the draft: Stability: is the period of time when the endpoint's encoding rate is relatively stable, i.e., the bandwidth utilization is constant. I would use "steady-state" instead of "stability" since the latter has a formal definition which has a precise meaning. Moreover, it has to be noticed that "steady-state" can be reached if and only if the available bandwidth is constant. 2) for what concerns the video quality indices, it is well known that PSNR is not well related to the QoE. (See for instance http://www.pscr.gov/about_pscr/press/video/video_quality_experts_interview_sigmm-122009.pdf) Are we sure we want to cite PSNR? Cheers, -- Luca De Cicco, PhD, Eng. Politecnico di Bari Dipartimento di Elettrotecnica ed Elettronica Via Re David, 200 - Bari - ITALY Office: +39 080 596 3851 On Mon, Oct 15, 2012 at 10:33 PM, Varun Singh wrote: > > Greetings, > > We have submitted an initial draft outlining the criteria for evaluating > congestion control algorithms. The metrics section is a bit light > on details and will to expand on that in the next revision. > > We hope that the draft is a good starting point to get the discussion > started about metrics and scenarios for simulation and testbed experiments. > > Cheers, > Varun > > Begin forwarded message: > > > A new version of I-D, draft-singh-rmcat-cc-eval-00.txt > has been successfully submitted by Varun Singh and posted to the > IETF repository. > > Filename: draft-singh-rmcat-cc-eval > Revision: 00 > Title: Evaluating Congestion Control for Interactive Real-time Media. > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-singh-rmcat-cc-eval-00.txt > Status: http://datatracker.ietf.org/doc/draft-singh-rmcat-cc-eval > Htmlized: http://tools.ietf.org/html/draft-singh-rmcat-cc-eval-00 > > > Abstract: > The Real-time Transport Protocol (RTP) is used to transmit media in > telephony and video conferencing applications. This document > describes the guidelines to evaluate new congestion control > algorithms for interactive point-to-point real-time media. > > > > > The IETF Secretariat From vsingh.ietf@gmail.com Tue Oct 16 03:57:34 2012 Return-Path: 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 64F8921F8966 for ; Tue, 16 Oct 2012 03:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2U6e61yxDp9M for ; Tue, 16 Oct 2012 03:57:33 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5DA21F8965 for ; Tue, 16 Oct 2012 03:57:33 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so3069930dan.31 for ; Tue, 16 Oct 2012 03:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NHcOvmrnCiGwhhdUgdlsFm52tNEGGJI2wP8kl36eC2k=; b=dV6mixxmAVx7Z0hBL60dy34mGEyrqxKpLPNg8Fyf7wLSm/3IQvZrzgMl8p2BNNUEHo lHIy6oFtg5I8omrSNHbWGg8flcUvUOTZBSbum21jTwKDkcdVr4kebE+nrDgcuXj1Y409 zH1g6a6xdEZxag8Ue1xJLmMIchAtuUjyCR5436yslogFzmXJJ+0uHlKAaazPJ3P4TJTU XPPhkFKnrekFOAUILm7IybSHyBqxFJgP9bcWoaJ37k2CHu7zdLMoBx9c9O597/PokiMy BJ7PPfvLYAEdh27vVKC3k672hyugGxHpISNF0uEri0VkLXxaS38fonyBWVf8YOK5FQPI 3M+w== Received: by 10.66.82.101 with SMTP id h5mr40899884pay.15.1350385053102; Tue, 16 Oct 2012 03:57:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.29.105 with HTTP; Tue, 16 Oct 2012 03:57:12 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Tue, 16 Oct 2012 13:57:12 +0300 Message-ID: To: Luca De Cicco Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat WG Subject: Re: [rmcat] Fwd: New Version Notification for draft-singh-rmcat-cc-eval-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 10:57:34 -0000 Hi Luca, Thanks for your comments, responses inline. On Tue, Oct 16, 2012 at 12:01 PM, Luca De Cicco wrote: [snip] > 1) regarding the definition of stability which is given in the draft: > > Stability: is the period of time when the endpoint's encoding > rate is relatively stable, i.e., the bandwidth utilization is > constant. > > I would use "steady-state" instead of "stability" since the latter has a > formal definition which has a precise meaning. Moreover, it has to be True, will change stability to steady-state. > noticed that "steady-state" can be reached if and only if the > available bandwidth is constant. I defined steady-state as a period when bandwidth utilization is constant (not close to 1). Apart from the situation when the congestion control is operating close to the bottleneck capacity, it can also have constant utilization if it is under-utilizing the link or detects cross-traffic and attempts to be fair. The metrics section has intentionally been left a bit open for discussion because I want to tune the definitions to match the exact requirements of the congestion control. > > 2) for what concerns the video quality indices, it is well known > that PSNR is not well related to the QoE. (See for instance > http://www.pscr.gov/about_pscr/press/video/video_quality_experts_interview_sigmm-122009.pdf) > Are we sure we want to cite PSNR? > I believe we need some objective metric for video either PSNR or something else. I am happy to include or update the document based on that discussion. (Note: I have not read the above document but will go through it.) However, when choosing these quality metrics we should be aware of their defined operating range (some models are limited to specific range of video resolutions or bit rates, etc.). Cheers, Varun > Cheers, > -- > Luca De Cicco, PhD, Eng. > Politecnico di Bari > Dipartimento di Elettrotecnica ed Elettronica > Via Re David, 200 - Bari - ITALY > Office: +39 080 596 3851 > > > On Mon, Oct 15, 2012 at 10:33 PM, Varun Singh wrote: >> >> Greetings, >> >> We have submitted an initial draft outlining the criteria for evaluating >> congestion control algorithms. The metrics section is a bit light >> on details and will to expand on that in the next revision. >> >> We hope that the draft is a good starting point to get the discussion >> started about metrics and scenarios for simulation and testbed experiments. >> >> Cheers, >> Varun >> >> Begin forwarded message: >> >> >> A new version of I-D, draft-singh-rmcat-cc-eval-00.txt >> has been successfully submitted by Varun Singh and posted to the >> IETF repository. >> >> Filename: draft-singh-rmcat-cc-eval >> Revision: 00 >> Title: Evaluating Congestion Control for Interactive Real-time Media. >> Creation date: 2012-10-15 >> WG ID: Individual Submission >> Number of pages: 9 >> URL: >> http://www.ietf.org/internet-drafts/draft-singh-rmcat-cc-eval-00.txt >> Status: http://datatracker.ietf.org/doc/draft-singh-rmcat-cc-eval >> Htmlized: http://tools.ietf.org/html/draft-singh-rmcat-cc-eval-00 >> >> >> Abstract: >> The Real-time Transport Protocol (RTP) is used to transmit media in >> telephony and video conferencing applications. This document >> describes the guidelines to evaluate new congestion control >> algorithms for interactive point-to-point real-time media. >> >> >> >> >> The IETF Secretariat -- http://www.netlab.tkk.fi/~varun/ From holmer@google.com Tue Oct 16 04:29:26 2012 Return-Path: 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 4816F21F87F3 for ; Tue, 16 Oct 2012 04:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUjA+3hc7k9F for ; Tue, 16 Oct 2012 04:29:24 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0F6321F859A for ; Tue, 16 Oct 2012 04:29:15 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so11046118iec.31 for ; Tue, 16 Oct 2012 04:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=lUZQ5/2jvw+AI0Z4bUB9izCZdOFvIUToJB1jYFXTC28=; b=NebRHUTFR4YDEARPr0BYJLtkJixjEIKFwpY+nydmM8svmWpd12odKOl0EkGUygM8R8 8/ljzhNa+wizMPNRzlQmpuqjGmygr8MctJjLHcnD4ldzXlDCyaty7uvI7C/HyY8COVnr bWVlYVBcn+LyMAy3qxpSeaMTx1jWcjI9j6H1rWdj0ZHJHXbu1zGrOasEoDMfgmu6S7wL ZQGIZLV3CZ2aPD7NVKNvURrzMQYfByxW08vHTox+VZOcNGRe5GuzLS0S5P+md9m/EgSU D+xVtm5X9tRPPdUUDEMR+LP1yfHoYYU3ova9BNP3kOW5rsGExIxMArlQIlTH1yTSrrNz FRGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=lUZQ5/2jvw+AI0Z4bUB9izCZdOFvIUToJB1jYFXTC28=; b=ZAbdYUapuieMaKmgOFmn1fAS0UTjslHNUHrgcOG8Yh+jmgaIiv9AIDwcm6qdvRiFpv V00WIcWAXZiPBosslaB6L3tKJOfzFYK+FH/T2lksPfotp9raWC3UEZhY6vY4JLpT+wRD KU+ZYAMfdvYgIR9jo9y7NXaVEJ/M9SyzcmJiuHdm7yMEq1Ib20Xud5lmCU1bCLVXVctu i07wv7Q0RN52Off6b9Om0BsaUxVuzRqd7hsA3JgPvDo8Ep2pwu9lyRbvxilaGvtzngzU iDOk+9/mqBbnGhEVWSzUVUEyWzgOknv7g7UtJB6yZqHWeZnbAyPtJo0weyFINR3Zzqvb I8JQ== MIME-Version: 1.0 Received: by 10.42.52.5 with SMTP id h5mr11394571icg.50.1350386954966; Tue, 16 Oct 2012 04:29:14 -0700 (PDT) Sender: holmer@google.com Received: by 10.50.184.134 with HTTP; Tue, 16 Oct 2012 04:29:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Oct 2012 13:29:14 +0200 X-Google-Sender-Auth: 5aqJDH_rAh9scpq8e8lNaUy4klc Message-ID: From: Stefan Holmer To: Varun Singh Content-Type: multipart/alternative; boundary=485b397dd1c9c2973104cc2b7622 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkTmsIyTMDOBykAMRFOqlvPcruebvbXW7QuydXajj+8BqnQSGXAykgITPvU3z5zK9p3VaaOGsY3RQYYtIShVGAHeqOU+zBW1bo5J1CU9X3TnHfX1NCz3ctq0Z1WqI2qgZOCM31nljln/t1VLcJDcjNTHbRBXhnP49KIpC4YQUypjV+EDM2Y6lMwYXR0FLzcjFfY5s2S Cc: rmcat WG , Luca De Cicco Subject: Re: [rmcat] Fwd: New Version Notification for draft-singh-rmcat-cc-eval-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 11:29:26 -0000 --485b397dd1c9c2973104cc2b7622 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 16, 2012 at 12:57 PM, Varun Singh wrote: > Hi Luca, > > Thanks for your comments, responses inline. > > On Tue, Oct 16, 2012 at 12:01 PM, Luca De Cicco > wrote: > [snip] > > 1) regarding the definition of stability which is given in the draft: > > > > Stability: is the period of time when the endpoint's encoding > > rate is relatively stable, i.e., the bandwidth utilization is > > constant. > > > > I would use "steady-state" instead of "stability" since the latter has a > > formal definition which has a precise meaning. Moreover, it has to be > > True, will change stability to steady-state. > > > noticed that "steady-state" can be reached if and only if the > > available bandwidth is constant. > > > I defined steady-state as a period when bandwidth utilization is > constant (not close to 1). > Apart from the situation when the congestion control is operating > close to the bottleneck capacity, it can also have constant utilization > if it is under-utilizing the link or detects cross-traffic and > attempts to be fair. > > The metrics section has intentionally been left a bit open for discussion > because I want to tune the definitions to match the exact requirements > of the congestion control. > > > > > > 2) for what concerns the video quality indices, it is well known > > that PSNR is not well related to the QoE. (See for instance > > > http://www.pscr.gov/about_pscr/press/video/video_quality_experts_interview_sigmm-122009.pdf > ) > > Are we sure we want to cite PSNR? > > > > I believe we need some objective metric for video either > PSNR or something else. I am happy to include or > update the document based on that discussion. > (Note: I have not read the above document but > will go through it.) > > However, when choosing these quality metrics we should be aware > of their defined operating range (some models are limited to specific > range of video resolutions or bit rates, etc.). > > I agree that PSNR isn't likely to be a good choice, I would assume that we at least need a metric which takes both the video quality and the delay into account? The experienced video quality depends on several aspects other than the congestion control, such as encoder settings, transmitted spatial and temporal resolution, video jitter buffer algorithm at the receiver, etc. Therefore I'm not sure it's a good idea to evaluate our congestion control algorithms based on video quality. If possible I would rather see us concentrate on simpler metrics as those you described earlier in your draft, which are more related to how the algorithm actually adapts to changes in bandwidth. > Cheers, > Varun > > > > Cheers, > > -- > > Luca De Cicco, PhD, Eng. > > Politecnico di Bari > > Dipartimento di Elettrotecnica ed Elettronica > > Via Re David, 200 - Bari - ITALY > > Office: +39 080 596 3851 > > > > > > On Mon, Oct 15, 2012 at 10:33 PM, Varun Singh > wrote: > >> > >> Greetings, > >> > >> We have submitted an initial draft outlining the criteria for evaluating > >> congestion control algorithms. The metrics section is a bit light > >> on details and will to expand on that in the next revision. > >> > >> We hope that the draft is a good starting point to get the discussion > >> started about metrics and scenarios for simulation and testbed > experiments. > >> > >> Cheers, > >> Varun > >> > >> Begin forwarded message: > >> > >> > >> A new version of I-D, draft-singh-rmcat-cc-eval-00.txt > >> has been successfully submitted by Varun Singh and posted to the > >> IETF repository. > >> > >> Filename: draft-singh-rmcat-cc-eval > >> Revision: 00 > >> Title: Evaluating Congestion Control for Interactive > Real-time Media. > >> Creation date: 2012-10-15 > >> WG ID: Individual Submission > >> Number of pages: 9 > >> URL: > >> http://www.ietf.org/internet-drafts/draft-singh-rmcat-cc-eval-00.txt > >> Status: > http://datatracker.ietf.org/doc/draft-singh-rmcat-cc-eval > >> Htmlized: > http://tools.ietf.org/html/draft-singh-rmcat-cc-eval-00 > >> > >> > >> Abstract: > >> The Real-time Transport Protocol (RTP) is used to transmit media in > >> telephony and video conferencing applications. This document > >> describes the guidelines to evaluate new congestion control > >> algorithms for interactive point-to-point real-time media. > >> > >> > >> > >> > >> The IETF Secretariat > > > > -- > http://www.netlab.tkk.fi/~varun/ > --485b397dd1c9c2973104cc2b7622 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, O= ct 16, 2012 at 12:57 PM, Varun Singh <vsingh.ietf@gma= il.com> wrote:
Hi Luca,

Thanks for your comments, responses inline.

On Tue, Oct 16, 2012 at 12:01 PM, Luca De Cicco <ldecicco@gmail.com> wrote:
[snip]
> 1) regarding the definition of stability which is gi= ven in the draft:
>
> Stability: is the period of time when the endpoint's encoding
> =A0 =A0 =A0 =A0 =A0rate is relatively stable, i.e., the bandwidth util= ization is
> =A0 =A0 =A0 =A0 =A0constant.
>
> I would use "steady-state" instead of "stability" = since the latter has a
> formal definition which has a precise meaning. Moreover, it has to be<= br>
True, will change stability to steady-state.

> noticed that "steady-state" can be reached if and only if th= e
> available bandwidth is constant.


I defined steady-state as a period when bandwidth utilization is
constant (not close to 1).
Apart from the situation when the congestion control is operating
close to the bottleneck capacity, it can also have constant utilization
if it is under-utilizing the link or detects cross-traffic and
attempts to be fair.

The metrics section has intentionally been left a bit open for discussion because I want to tune the definitions to match the exact requirements
of the congestion control.


>
> 2) for what concerns the video quality indices, it is well known
> that PSNR is not well related to the QoE. (See for instance
> http:/= /www.pscr.gov/about_pscr/press/video/video_quality_experts_interview_sigmm-= 122009.pdf)
> Are we sure we want to cite PSNR?
>

I believe we need some objective metric for video either
PSNR or something else. I am happy to include or
update the document based on that discussion.
(Note: I have not read the above document but
will go through it.)

However, when choosing these quality metrics we should be aware
of their defined operating range (some models are limited to specific
range of video resolutions or bit rates, etc.).


I agree that PSNR isn't likely to = be a good choice, I would assume that we at least need a metric which takes= both the video quality and the delay into account? The experienced video q= uality depends on several aspects other than the congestion control, such a= s encoder settings, transmitted spatial and temporal resolution, video jitt= er buffer algorithm at the receiver, etc. Therefore I'm not sure it'= ;s a good idea to evaluate our congestion control algorithms based on video= quality. If possible I would rather see us concentrate on simpler metrics = as those you described earlier in your draft, which are more related to how= the algorithm actually adapts to changes in bandwidth.
=A0
Cheers,
Varun


> Cheers,
> --
> Luca De Cicco, PhD, Eng.
> Politecnico di Bari
> Dipartimento di Elettrotecnica ed Elettronica
> Via Re David, 200 - Bari - ITALY
> Office: +39 080 596 3851
>
>
> On Mon, Oct 15, 2012 at 10:33 PM, Varun Singh <vsingh.ietf@gmail.com> wrote:<= br> >>
>> Greetings,
>>
>> We have submitted an initial draft outlining the criteria for eval= uating
>> congestion control algorithms. The metrics section is a bit light<= br> >> on details and will to expand on that in the next revision.
>>
>> We hope that the draft is a good starting point to get the discuss= ion
>> started about metrics and scenarios for simulation and testbed exp= eriments.
>>
>> Cheers,
>> Varun
>>
>> Begin forwarded message:
>>
>>
>> A new version of I-D, draft-singh-rmcat-cc-eval-00.txt
>> has been successfully submitted by Varun Singh and posted to the >> IETF repository.
>>
>> Filename: =A0 =A0 =A0 =A0draft-singh-rmcat-cc-eval
>> Revision: =A0 =A0 =A0 =A000
>> Title: =A0 =A0 =A0 =A0 =A0 Evaluating Congestion Control for Inter= active Real-time Media.
>> Creation date: =A0 2012-10-15
>> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
>> Number of pages: 9
>> URL:
>> http://www.ietf.org/inter= net-drafts/draft-singh-rmcat-cc-eval-00.txt
>> Status: =A0 =A0 =A0 =A0 =A0http://da= tatracker.ietf.org/doc/draft-singh-rmcat-cc-eval
>> Htmlized: =A0 =A0 =A0 =A0http://tools.= ietf.org/html/draft-singh-rmcat-cc-eval-00
>>
>>
>> Abstract:
>> =A0 The Real-time Transport Protocol (RTP) is used to transmit med= ia in
>> =A0 telephony and video conferencing applications. =A0This documen= t
>> =A0 describes the guidelines to evaluate new congestion control >> =A0 algorithms for interactive point-to-point real-time media.
>>
>>
>>
>>
>> The IETF Secretariat



--
http://www.netlab.tkk.fi/~varun/

--485b397dd1c9c2973104cc2b7622-- From vsingh.ietf@gmail.com Tue Oct 16 05:35:04 2012 Return-Path: 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 49EC821F8887 for ; Tue, 16 Oct 2012 05:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ktp4vmX0+pq for ; Tue, 16 Oct 2012 05:35:01 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25D8B21F8883 for ; Tue, 16 Oct 2012 05:35:01 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so5875261pbb.31 for ; Tue, 16 Oct 2012 05:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=NG9qW+Lana8hHCuEMEJ7H9s8DJ7iXaclMGZu+liudtM=; b=p5dQY7ZEiA0syaILys41c0blNSmR9A2rdFGBT8Emif8AUdaBC8e60486MWnwRr9Vcb 8+Yf/RoQc8AKQldeQm/9v6QBAheVEVV/ctU2lKTvc8qyIj8FCSaOeEySuroiOaGfeWeG bYCKANzuKBiOG+L7v+KMdv5qLD7eQF+yifisnCNwB2A9/4mYiM9Y+gIDCdHas9SbQh30 aqfg22wfT1Ac2FlkqCg5KaESYB3iDtkifnAS2xbqMxXn5LQ0WqK415Xtf+LZ2EcV1z4B sHlNsMWR7QgdMEgyxOraBW3OG6pSYaOtSRCe2RwOa67Kd24qhhzGW893/JLR/H2H3D+2 /XeA== Received: by 10.68.229.201 with SMTP id ss9mr46379106pbc.80.1350390900896; Tue, 16 Oct 2012 05:35:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.29.105 with HTTP; Tue, 16 Oct 2012 05:34:40 -0700 (PDT) From: Varun Singh Date: Tue, 16 Oct 2012 15:34:40 +0300 Message-ID: To: Stefan Holmer Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat WG , Luca De Cicco Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 12:35:04 -0000 Hi Stefan, changing the email subject and snipping away the rest of the message. Comments inline. >> > >> > 2) for what concerns the video quality indices, it is well known >> > that PSNR is not well related to the QoE. (See for instance >> > >> > http://www.pscr.gov/about_pscr/press/video/video_quality_experts_interview_sigmm-122009.pdf) >> > Are we sure we want to cite PSNR? >> > >> >> I believe we need some objective metric for video either >> PSNR or something else. I am happy to include or >> update the document based on that discussion. >> (Note: I have not read the above document but >> will go through it.) >> >> However, when choosing these quality metrics we should be aware >> of their defined operating range (some models are limited to specific >> range of video resolutions or bit rates, etc.). >> > > I agree that PSNR isn't likely to be a good choice, I would assume that we > at least need a metric which takes both the video quality and the delay into > account? The experienced video quality depends on several aspects other than Apart from delay there is also balancing throughput and loss. In the scenario of a single RTP flow we could come up with a simple metric but with competing traffic it may be more difficult. By introducing a video quality metric in those scenarios, I was intending to quantify the balance of throughput, loss and delay. > the congestion control, such as encoder settings, transmitted spatial and > temporal resolution, video jitter buffer algorithm at the receiver, etc. Since we are talking about interactive real-time media, we could *agree* on running a baseline setup with preset parameters and reference video sequences. :) > Therefore I'm not sure it's a good idea to evaluate our congestion control > algorithms based on video quality. If possible I would rather see us > concentrate on simpler metrics as those you described earlier in your draft, > which are more related to how the algorithm actually adapts to changes in > bandwidth. In my opinion, if we can come up with a good QoE metric then it would be nice to have in addition to the throughput, loss and delay metrics. OTOH if we come up with a quality metric that is based on the relationship of the three then we may have a single metric to compare each algorithm. I am not sure which of these two methods would be better, but I am happy to hear more arguments for and against QoE, also other QoE methods before we decide on a quality metric. Regards, Varun From michawe@ifi.uio.no Tue Oct 16 06:01:36 2012 Return-Path: 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 C5BDD21F8883 for ; Tue, 16 Oct 2012 06:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsbgpKYcAzO4 for ; Tue, 16 Oct 2012 06:01:34 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 64F1F21F8894 for ; Tue, 16 Oct 2012 06:01:34 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TO6m4-0002pv-00; Tue, 16 Oct 2012 15:01:32 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TO6m3-0002GD-JE; Tue, 16 Oct 2012 15:01:31 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: Date: Tue, 16 Oct 2012 15:01:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Varun Singh X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 6 sum msgs/h 3 total rcpts 24679 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.912, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8E396BC9D80051D9086C3DF83F5F14BEEBDE5178 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 9925 max/h 21 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Luca De Cicco , Stefan Holmer Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 13:01:36 -0000 Sorry if this is stupid, perhaps I'm missing something - but: even if we could agree on a baseline test setup, standard movies etc.: = isn't the very idea of a QoE metric inevitably bound to the codec, which = then binds evaluating congestion control mechanisms to a debate that = this really shouldn't be a part of? Cheers, Michael On 16. okt. 2012, at 14:34, Varun Singh wrote: > Hi Stefan, >=20 > changing the email subject and snipping away the rest of the message. >=20 > Comments inline. >=20 >>>>=20 >>>> 2) for what concerns the video quality indices, it is well known >>>> that PSNR is not well related to the QoE. (See for instance >>>>=20 >>>> = http://www.pscr.gov/about_pscr/press/video/video_quality_experts_interview= _sigmm-122009.pdf) >>>> Are we sure we want to cite PSNR? >>>>=20 >>>=20 >>> I believe we need some objective metric for video either >>> PSNR or something else. I am happy to include or >>> update the document based on that discussion. >>> (Note: I have not read the above document but >>> will go through it.) >>>=20 >>> However, when choosing these quality metrics we should be aware >>> of their defined operating range (some models are limited to = specific >>> range of video resolutions or bit rates, etc.). >>>=20 >>=20 >> I agree that PSNR isn't likely to be a good choice, I would assume = that we >> at least need a metric which takes both the video quality and the = delay into >> account? The experienced video quality depends on several aspects = other than >=20 > Apart from delay there is also balancing throughput and loss. > In the scenario of a single RTP flow we could come up with a > simple metric but with competing traffic it may be more difficult. > By introducing a video quality metric in those scenarios, > I was intending to quantify the balance of throughput, loss and delay. >=20 >=20 >> the congestion control, such as encoder settings, transmitted spatial = and >> temporal resolution, video jitter buffer algorithm at the receiver, = etc. >=20 > Since we are talking about interactive real-time media, we could = *agree* on > running a baseline setup with preset parameters and reference video > sequences. :) >=20 >> Therefore I'm not sure it's a good idea to evaluate our congestion = control >> algorithms based on video quality. If possible I would rather see us >> concentrate on simpler metrics as those you described earlier in your = draft, >> which are more related to how the algorithm actually adapts to = changes in >> bandwidth. >=20 > In my opinion, if we can come up with a good QoE metric then it > would be nice to have in addition to the throughput, loss and delay = metrics. > OTOH if we come up with a quality metric that is based on the = relationship > of the three then we may have a single metric to compare each = algorithm. > I am not sure which of these two methods would be better, but I am = happy > to hear more arguments for and against QoE, also other QoE methods > before we decide on a quality metric. >=20 >=20 > Regards, > Varun From xiaoqzhu@cisco.com Tue Oct 16 21:58:46 2012 Return-Path: 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 4F21921F853D for ; Tue, 16 Oct 2012 21:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otvlu6smL4GO for ; Tue, 16 Oct 2012 21:58:45 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1C00F21F84F9 for ; Tue, 16 Oct 2012 21:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13222; q=dns/txt; s=iport; t=1350449919; x=1351659519; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xi0x8BkgD40LRd4T4YIeFeeML+pnCbx/ez7TC0mRk8s=; b=jMqP4K6/EITb8aMWvW2yQB4zR7Qx2IiaUbgNv+XSf+jxHx/+BLA5Xcki +oEuv1O52hwhmhaYYsvsPmYqn2RpyR5JJTT+/M+xsTjTy+JmXzQ/XMpDM hsqSB31cme306cIRucKItBESpnJjwJ6A9qdzSIhK/d2e32BeIYCnjB4qq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAHANk5flCtJV2a/2dsb2JhbABFgm2GA6VviHABhiKCNIEIgiEBAQQSAVsLEAIBCA4EEB0HMhQDDgIEDgUIARmHYgEKmxqgIItPhWBgA5cAjTKBa4EugT+CFw X-IronPort-AV: E=Sophos;i="4.80,597,1344211200"; d="scan'208,217";a="132403317" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 17 Oct 2012 04:58:38 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9H4wcRK010708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 04:58:38 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 23:58:37 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: Michael Welzl Thread-Topic: [rmcat] send agenda requests (was Re: First meeting) Thread-Index: AQHNp9grf2quh6JMt0CYpuBNP/SHCpe1q3yAgAWVAgCAAK9XAIABXGsA Date: Wed, 17 Oct 2012 04:58:36 +0000 Message-ID: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004 x-tm-as-result: No--34.414700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E7175A8E3DC14048A7D3020E0338C1FA0B4C5Exmbalnx13ciscocom_" MIME-Version: 1.0 Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 04:58:46 -0000 --_000_E7175A8E3DC14048A7D3020E0338C1FA0B4C5Exmbalnx13ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael, Thanks for your comments. Please find my replies inline below. Best, Xiaoqing On Oct 16, 2012, at 1:11 AM, Michael Welzl wrote: Hi, I took a quick look at this: I like the general idea of using as much as possible of existing network su= pport - but I'm critical about the actual control you propose. In section 5.3.2, you suggest to replace eqn. 1 from section 5.3 with eqn. = 2 when ECN feedback is available. This means to ignore a delay signal from = now on, and interpret ECN marks in the exact same way as you interpreted de= lay before - this is too simplistic, I think. After all, ECN marks require = a queue to grow, and this group intends to minimize delay... why would you = stop using delay once you have ECN in addition? In our design, we considered the two cases, with or without ECN markings, s= eparately. Therefore, the dynamic scenario when ECN becomes available in t= he middle of a video conferencing session has not yet been fully studied. = Just wondering, are cases where ECN marking are turned on and off dynamical= ly common in reality? In practice, using your scheme would probably mean that, as soon as I enabl= e RED with ECN on the bottleneck between the two end systems, the users' ob= served delay grows. Not exactly an incentive? What you mentioned (uers observing higher delay in ECN-enabled systems) wil= l not happen. But rather, our simulation results have indicated that ECN with RED-based m= arking yields fairly similar results as the default delay-based scheme. The= y certainly do not incur higher delay, since the endpoint will automaticall= y back off in face of higher ECN markings, which are indications of higher = delay. The two systems (delay-based and ECN-based) can be tuned to stabiliz= e that the same queuing delay at the bottleneck. Cheers, Michael On 15. okt. 2012, at 23:43, Xiaoqing Zhu (xiaoqzhu) wrote: And below is the notification of our submission: Thanks, Xiaoqing -------------------------------------- A new version of I-D, draft-zhu-rmcat-nada-00.txt has been successfully submitted by Xiaoqing Zhu and posted to the IETF repository. Filename: draft-zhu-rmcat-nada Revision: 00 Title: NADA: A Unified Congestion Control Scheme for Real-Time Media Creation date: 2012-10-14 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-0= 0.txt Status: http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-00 Abstract: This document describes a scheme named network-assisted dynamic adaptation (NADA), a novel congestion control approach for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can reap the benefits of explicit congestion notification markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays instead. We present here the overall system architecture, recommended behaviors at the sender and the receiver, as well as expected network nodes operations. Results from extensive simulation studies of the proposed scheme are available upon request. The IETF Secretariat -------------------------------------- On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: Hi, On Oct 11, 2012, at 18:45, Xiaoqing Zhu > wrote: My colleague and I are working on a congestion control scheme for real-time conferencing applications at Cisco. A brief version of that algorithm was presented at the IAB Workshop in Vancouver (paper #12, "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due to time constraints, however, we did not get a chance to mention the delay-based variant of that scheme, which may be a better fit for rmcat. We would like to request for a slot to present in Atlanta. We will also submit the ID draft before Oct 15, for further discussions on this mailing list. I look forward to seeing the draft being discussed on the list! Also, I'm noting your request for a slot. Because the actual CC mechanisms = are not our most pressing milestones initially - the requirements and eval = criteria are - we may decide to focus our meeting time on those other draft= s, if demand for agenda time is high. Lars --_000_E7175A8E3DC14048A7D3020E0338C1FA0B4C5Exmbalnx13ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <63321D566D83864B836FA4EAD766D5F4@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Michael, 

Thanks for your comments.  Please find my replies inline below.&n= bsp;

Best,
Xiaoqing

 
On Oct 16, 2012, at 1:11 AM, Michael Welzl wrote:

Hi,

I took a quick look at this:

I like the general idea of using as much as possible of existing netwo= rk support - but I'm critical about the actual control you propose.

In section 5.3.2, you suggest to replace eqn. 1 from section 5.3 with = eqn. 2 when ECN feedback is available. This means to ignore a delay signal = from now on, and interpret ECN marks in the exact same way as you interpret= ed delay before - this is too simplistic, I think. After all, ECN marks require a queue to grow, and this group inte= nds to minimize delay... why would you stop using delay once you have ECN i= n addition?


In our design, we considered the two cases, with or without ECN markin= gs, separately.  Therefore, the dynamic scenario when ECN becomes avai= lable in the middle of a video conferencing session has not yet been fully = studied.  Just wondering, are cases where ECN marking are turned on and off dynamically common in reality?  



In practice, using your scheme would probably mean that, as soon as I = enable RED with ECN on the bottleneck between the two end systems, the user= s' observed delay grows. Not exactly an incentive?

What you mentioned (uers observing higher delay in ECN-enabled systems= ) will not happen. 

But rather, our simulation results have indicated that ECN with RED-ba= sed marking yields fairly similar results as the default delay-based scheme= . They certainly do not incur higher delay, since the endpoint will automat= ically back off in face of higher ECN markings, which are indications of higher delay. The two systems (dela= y-based and ECN-based) can be tuned to stabilize that the same queuing dela= y at the bottleneck. 

Cheers,
Michael


On 15. okt. 2012, at 23:43, Xiaoqing Zhu (xiaoqzhu) wrote:

And below is the notification of our submission: 

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename:  draft-zhu-rmcat-nada
Revision:  00
Title: <= span class=3D"Apple-tab-span" style=3D"white-space: pre; "> NAD= A: A Unified Congestion Control Scheme for Real-Time Media
Creation date: =  2012-10-14
WG ID: <= span class=3D"Apple-tab-span" style=3D"white-space: pre; "> Ind= ividual Submission
Number of pages: 10
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt
Status:          http://datatracker.ietf= .org/doc/draft-zhu-rmcat-nada
Htmlized:        http://tools.ietf.org/html/draft-zh= u-rmcat-nada-00


Abstract:
  This document describes a scheme named network-assisted dynamic=
  adaptation (NADA), a novel congestion control approach for
  interactive real-time media applications, such as video confere= ncing.
  In the proposed scheme, the sender regulates its sending rate b= ased
  on either implicit or explicit congestion signaling, in a unifi= ed
  approach. The scheme can reap the benefits of explicit congesti= on
  notification markings from network nodes. It also maintains
  consistent sender behavior in the absence of such markings, by<= br>   reacting to queuing delays instead.

  We present here the overall system architecture, recommended   behaviors at the sender and the receiver, as well as expected n= etwork
  nodes operations. Results from extensive simulation studies of = the
  proposed scheme are available upon request.




The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <zhuxq@alumni.stanford.edu> wrote:
My colleague and I are working on a congestion co= ntrol scheme for
real-time conferencing applications at Cisco. A b= rief version of that
algorithm was presented at the IAB Workshop in Va= ncouver (paper #12,
"Network-Assisted Dynamic Adaptation (NADA):= A Design Summary"). Due
to time constraints, however, we did not get a ch= ance to mention the
delay-based variant of that scheme, which may be = a better fit for
rmcat.

We would like to request for a slot to present in= Atlanta. We will
also submit the ID draft before Oct 15, for furth= er discussions on
this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC mechanisms = are not our most pressing milestones initially - the requirements and eval = criteria are - we may decide to focus our meeting time on those other draft= s, if demand for agenda time is high.

Lars



--_000_E7175A8E3DC14048A7D3020E0338C1FA0B4C5Exmbalnx13ciscocom_-- From xiaoqzhu@cisco.com Tue Oct 16 22:05:00 2012 Return-Path: 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 3097721F873E for ; Tue, 16 Oct 2012 22:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7mE90G3Lk5z for ; Tue, 16 Oct 2012 22:04:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B757F21F877B for ; Tue, 16 Oct 2012 22:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13310; q=dns/txt; s=iport; t=1350450298; x=1351659898; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L4ssDKI+SeIDdjl7xaoFv80vq+kyGz8qlxtMppK9INs=; b=Ni0VnFlFH9IZRGAcKeorO9cAZpzbucCoY1GYMuKTb4pnsBXUpXSklp+s LEiuzy3GWGZCBhWqOjeiQwdaWt3D/uRRYjFYWWNcMXskruMRzSiCDGDl1 u0mTj38J8+Hx+fgkiHRdfDawj2/NoC9cw891AOUdHKHaF7CdRVC68VEca k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAHAEI7flCtJV2Z/2dsb2JhbABFgm2GA6VviHABhiKCNIEIgiEBAQQSAVsLEAIBCBIQHQcyFAMOAgQOBQgBGYdiAQqbGKAai0+FYGADlwCNMoFrgS6BP4IX X-IronPort-AV: E=Sophos;i="4.80,597,1344211200"; d="scan'208,217";a="132185521" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 17 Oct 2012 05:04:57 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9H54vja009092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 05:04:57 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 00:04:57 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "Piers O'Hanlon" Thread-Topic: [rmcat] send agenda requests (was Re: First meeting) Thread-Index: AQHNp9grf2quh6JMt0CYpuBNP/SHCpe1q3yAgAWVAgCAALtjgIABUiQA Date: Wed, 17 Oct 2012 05:04:56 +0000 Message-ID: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--30.811300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E7175A8E3DC14048A7D3020E0338C1FA0B4CC9xmbalnx13ciscocom_" MIME-Version: 1.0 Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 05:05:00 -0000 --_000_E7175A8E3DC14048A7D3020E0338C1FA0B4CC9xmbalnx13ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, On Oct 16, 2012, at 1:54 AM, Piers O'Hanlon wrote: Hi, I too had a quick look at the proposal. I was interested as to how kappa is calculated in equation (1) or whether i= t is a fixed value? The scaling values, kappa for (1) and eta for (2) are fixed values at the v= ideo conferencing endpoint during any session. The system typically works = with a range of values for kappa and eta, leading to the same steady-state = behavior, but with different dynamics during transients. Also your slow start algorithm only seems to be time dependent - literally = it appears to start slowly from t_0 to some preset time (T) - is there any = mechanism to terminate slow start on loss/marked packets? Does slow start e= ver occur mid stream? (e.g. after a silence period?) Good point. Right now slow start only works at the beginning of the stream= . The rationale being that when a stream has not yet gathered enough conges= tion information (implicit or explicit) from the network, it rather stay on= the cautious side. Note that the sending rate is chosen to be the minimum= of slow-start rate R_ss and congestion-based rate R_o, so if excessive con= gestion has been observed initially, the sender will still back off. We haven't yet looked into the case whether slow start is needed mid-stream= . Open for comments/suggestions in this aspect. Out of interest it was mentioned that there were extensive simulation studi= es - would it be possible to post a simulation of multiple NADA flows compe= ting. And also a competition of NADA with a TCP flow? Thanks for the suggestions. I'll try to compile a set of representative re= sults on multiple self-competing NADA streams to share over this mailing li= st. Some modifications are need to make NADA compete fairly with loss-base= d TCP, we are still working on that. Thanks, Piers. On 15 Oct 2012, at 22:43, Xiaoqing Zhu (xiaoqzhu) wrote: And below is the notification of our submission: Thanks, Xiaoqing -------------------------------------- A new version of I-D, draft-zhu-rmcat-nada-00.txt has been successfully submitted by Xiaoqing Zhu and posted to the IETF repository. Filename: draft-zhu-rmcat-nada Revision: 00 Title: NADA: A Unified Congestion Control Scheme for Real-Time Media Creation date: 2012-10-14 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-0= 0.txt Status: http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-00 Abstract: This document describes a scheme named network-assisted dynamic adaptation (NADA), a novel congestion control approach for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can reap the benefits of explicit congestion notification markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays instead. We present here the overall system architecture, recommended behaviors at the sender and the receiver, as well as expected network nodes operations. Results from extensive simulation studies of the proposed scheme are available upon request. The IETF Secretariat -------------------------------------- On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: Hi, On Oct 11, 2012, at 18:45, Xiaoqing Zhu > wrote: My colleague and I are working on a congestion control scheme for real-time conferencing applications at Cisco. A brief version of that algorithm was presented at the IAB Workshop in Vancouver (paper #12, "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due to time constraints, however, we did not get a chance to mention the delay-based variant of that scheme, which may be a better fit for rmcat. We would like to request for a slot to present in Atlanta. We will also submit the ID draft before Oct 15, for further discussions on this mailing list. I look forward to seeing the draft being discussed on the list! Also, I'm noting your request for a slot. Because the actual CC mechanisms = are not our most pressing milestones initially - the requirements and eval = criteria are - we may decide to focus our meeting time on those other draft= s, if demand for agenda time is high. Lars --_000_E7175A8E3DC14048A7D3020E0338C1FA0B4CC9xmbalnx13ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, 

On Oct 16, 2012, at 1:54 AM, Piers O'Hanlon wrote:

Hi,

I too had a quick look at the proposal.

I was interested as to how kappa is calculated in equation (1) or whet= her it is a fixed value?

The scaling values, kappa for (1) and eta for (2) are fixed values at the v= ideo conferencing endpoint during any session.  The system typically w= orks with a range of values for kappa and eta, leading to the same steady-s= tate behavior, but with different dynamics during transients. 


Also your slow start algorithm only seems to be time dependent - liter= ally it appears to start slowly from t_0 to some preset time (T) - is there= any mechanism to terminate slow start on loss/marked packets? Does slow st= art ever occur mid stream? (e.g. after a silence period?)

Good point.  Right now slow start only works at the beginning of = the stream. The rationale being that when a stream has not yet gathered eno= ugh congestion information (implicit or explicit) from the network, it rath= er stay on the cautious side.  Note that the sending rate is chosen to be the minimum of slow-start rate R_ss and c= ongestion-based rate R_o, so if excessive congestion has been observed init= ially, the sender will still back off. 

We haven't yet looked into the case whether slow start is needed mid-s= tream.  Open for comments/suggestions in this aspect.  


Out of interest it was mentioned that there were extensive simulation = studies - would it be possible to post a simulation of multiple NADA flows = competing. And also a competition of NADA with a TCP flow?

Thanks for the suggestions.  I'll try to compile a set of representati= ve results on multiple self-competing NADA streams to share over this maili= ng list.  Some modifications are need to make NADA compete fairly with= loss-based TCP, we are still working on that. 

Thanks,

Piers.

On 15 Oct 2012, at 22:43, Xiaoqing Zhu (xiaoqzhu) wrote:

And below is the notification of our submission: 

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename:  draft-zhu-rmcat-nada
Revision:  00
Title: <= span class=3D"Apple-tab-span" style=3D"white-space: pre; "> NAD= A: A Unified Congestion Control Scheme for Real-Time Media
Creation date: =  2012-10-14
WG ID: <= span class=3D"Apple-tab-span" style=3D"white-space: pre; "> Ind= ividual Submission
Number of pages: 10
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt
Status:          http://datatracker.ietf= .org/doc/draft-zhu-rmcat-nada
Htmlized:        http://tools.ietf.org/html/draft-zh= u-rmcat-nada-00


Abstract:
  This document describes a scheme named network-assisted dynamic=
  adaptation (NADA), a novel congestion control approach for
  interactive real-time media applications, such as video confere= ncing.
  In the proposed scheme, the sender regulates its sending rate b= ased
  on either implicit or explicit congestion signaling, in a unifi= ed
  approach. The scheme can reap the benefits of explicit congesti= on
  notification markings from network nodes. It also maintains
  consistent sender behavior in the absence of such markings, by<= br>   reacting to queuing delays instead.

  We present here the overall system architecture, recommended   behaviors at the sender and the receiver, as well as expected n= etwork
  nodes operations. Results from extensive simulation studies of = the
  proposed scheme are available upon request.




The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <zhuxq@alumni.stanford.edu> wrote:
My colleague and I are working on a congestion co= ntrol scheme for
real-time conferencing applications at Cisco. A b= rief version of that
algorithm was presented at the IAB Workshop in Va= ncouver (paper #12,
"Network-Assisted Dynamic Adaptation (NADA):= A Design Summary"). Due
to time constraints, however, we did not get a ch= ance to mention the
delay-based variant of that scheme, which may be = a better fit for
rmcat.

We would like to request for a slot to present in= Atlanta. We will
also submit the ID draft before Oct 15, for furth= er discussions on
this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC mechanisms = are not our most pressing milestones initially - the requirements and eval = criteria are - we may decide to focus our meeting time on those other draft= s, if demand for agenda time is high.

Lars



--_000_E7175A8E3DC14048A7D3020E0338C1FA0B4CC9xmbalnx13ciscocom_-- From michawe@ifi.uio.no Wed Oct 17 00:32:10 2012 Return-Path: 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 712AD21F875B for ; Wed, 17 Oct 2012 00:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYJeLChv8+Yq for ; Wed, 17 Oct 2012 00:32:09 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 79D9621F8758 for ; Wed, 17 Oct 2012 00:32:09 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TOO6n-0002wt-FC; Wed, 17 Oct 2012 09:32:05 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TOO6m-0002LG-Te; Wed, 17 Oct 2012 09:32:05 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: Date: Wed, 17 Oct 2012 09:31:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7829361A-29CE-429B-A40B-BB63B76C56C9@ifi.uio.no> References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> To: Xiaoqing Zhu (xiaoqzhu) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 8 sum msgs/h 3 total rcpts 24697 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.912, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: ECAB26EF367CA5AF4CFC408F7BA3DD66BBC23CC5 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 9933 max/h 21 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 07:32:10 -0000 On 17. okt. 2012, at 06:58, Xiaoqing Zhu (xiaoqzhu) wrote: > Hi Michael,=20 >=20 > Thanks for your comments. Please find my replies inline below.=20 >=20 > Best, > Xiaoqing >=20 > =20 > On Oct 16, 2012, at 1:11 AM, Michael Welzl wrote: >=20 >> Hi, >>=20 >> I took a quick look at this: >>=20 >> I like the general idea of using as much as possible of existing = network support - but I'm critical about the actual control you propose. >>=20 >> In section 5.3.2, you suggest to replace eqn. 1 from section 5.3 with = eqn. 2 when ECN feedback is available. This means to ignore a delay = signal from now on, and interpret ECN marks in the exact same way as you = interpreted delay before - this is too simplistic, I think. After all, = ECN marks require a queue to grow, and this group intends to minimize = delay... why would you stop using delay once you have ECN in addition? >=20 >=20 > In our design, we considered the two cases, with or without ECN = markings, separately. Therefore, the dynamic scenario when ECN becomes = available in the middle of a video conferencing session has not yet been = fully studied. Just wondering, are cases where ECN marking are turned = on and off dynamically common in reality? =20 First, anything can happen when you have a routing change. Second, I'm really sorry, but this wasn't what I meant. I shouldn't have = written "when" but "if". I wasn't referring to a case where we go from = no-ECN-support to ECN-support. So this is about the ECN-always-supported = case. >> In practice, using your scheme would probably mean that, as soon as I = enable RED with ECN on the bottleneck between the two end systems, the = users' observed delay grows. Not exactly an incentive? >>=20 > What you mentioned (uers observing higher delay in ECN-enabled = systems) will not happen.=20 >=20 > But rather, our simulation results have indicated that ECN with = RED-based marking yields fairly similar results as the default = delay-based scheme. They certainly do not incur higher delay, since the = endpoint will automatically back off in face of higher ECN markings, = which are indications of higher delay. The two systems (delay-based and = ECN-based) can be tuned to stabilize that the same queuing delay at the = bottleneck.=20 Whether you see significant delay before you see a large enough amount = of ECN markings depends on the queue length and RED parameters, none of = which are under the end system's control. ECN is also a probabilistic = signal, so sometimes you may get delay growth but just be lucky (or = unlucky) enough to not get an ECN mark. So, I'd have to see results that involve various RED settings and queue = lengths before I believe that. Cheers, Michael From p.ohanlon@gmail.com Wed Oct 17 04:25:36 2012 Return-Path: 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 AF22C21F87D6 for ; Wed, 17 Oct 2012 04:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhBbcXJFV9Aa for ; Wed, 17 Oct 2012 04:25:35 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id D2B9D21F87A2 for ; Wed, 17 Oct 2012 04:25:34 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so435951wib.13 for ; Wed, 17 Oct 2012 04:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dXs9eXQ5IagY/itfMLhaasToRy+GXET5oeeY3c7ouJ8=; b=p24n2BZeE9UKWmIZ01wrpZBx6TzHXiUXJ9yH2oepb6gn3izUorlRwAWUsg+pZX1cHt DKMeS6Yc0pT6J1ZtkMKdgihJ/KcU/L3nZcFKGyyRZunXmQ/XVtTxYQWf0+LJ4is4c53W 6tT8Zuf2fe/7SXehOUdXRGToReGlL4Ovg/UHRYIR9Z0N4dDxV4/z5MYIbk8EjLjH+JpY HWp/7c44d+8ee+a9Amj+zWs1uW2cPhpaAeDL3DUMOUwRaczF0VnDUCgZN5Ft3gtUbNMK vTw4us9I2sz6X4NVIrwh+OBR3gt1t1/5mTfR1zuJjxPL7viSEueZVPaZV9EShfyR/V78 OZyg== Received: by 10.216.206.152 with SMTP id l24mr10477549weo.66.1350473134016; Wed, 17 Oct 2012 04:25:34 -0700 (PDT) Received: from ?IPv6:2001:470:1f09:d24:85ff:11d4:e5f8:ef72? ([2001:470:1f09:d24:85ff:11d4:e5f8:ef72]) by mx.google.com with ESMTPS id k20sm23920150wiv.11.2012.10.17.04.25.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Oct 2012 04:25:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Piers O'Hanlon In-Reply-To: Date: Wed, 17 Oct 2012 12:25:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2B1A13B9-6783-4AFE-A411-57899D8D1CB5@gmail.com> References: To: Varun Singh X-Mailer: Apple Mail (2.1283) Cc: rmcat WG Subject: Re: [rmcat] New Version Notification for draft-singh-rmcat-cc-eval-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 11:25:36 -0000 Hi Varun, The draft looks like a good start. I think it would good to add evaluation of idle and data-limited = behaviours - as these are important as regards media transport - they = were the reasons the original TFRC (RFC3448) was updated to RFC5348. = See: http://dx.doi.org/10.1016%2fj.comcom.2011.05.003 "TCP-Friendly Rate Control (TFRC) for bursty media flows", Arjuna = Sathiaseelan, Gorry Fairhurst, Comcom 2011 Furthermore it would also be useful to evaluate the algorithms with = respect to their operation in terms of competing against a small number = of flows vs a large number - see:=20 On the Effectiveness of Delay-Based Congestion Avoidance, Ravi S. = Prasad, Manish Jain Georgia, Constantinos Dovrolis, PFLDnet 2004 Cheers, Piers On 15 Oct 2012, at 21:33, Varun Singh wrote: > Greetings, >=20 > We have submitted an initial draft outlining the criteria for = evaluating > congestion control algorithms. The metrics section is a bit light > on details and will to expand on that in the next revision. >=20 > We hope that the draft is a good starting point to get the discussion > started about metrics and scenarios for simulation and testbed = experiments. >=20 > Cheers, > Varun >=20 > Begin forwarded message: >=20 >=20 > A new version of I-D, draft-singh-rmcat-cc-eval-00.txt > has been successfully submitted by Varun Singh and posted to the > IETF repository. >=20 > Filename: draft-singh-rmcat-cc-eval > Revision: 00 > Title: Evaluating Congestion Control for Interactive = Real-time Media. > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-singh-rmcat-cc-eval-00.txt > Status: = http://datatracker.ietf.org/doc/draft-singh-rmcat-cc-eval > Htmlized: = http://tools.ietf.org/html/draft-singh-rmcat-cc-eval-00 >=20 >=20 > Abstract: > The Real-time Transport Protocol (RTP) is used to transmit media in > telephony and video conferencing applications. This document > describes the guidelines to evaluate new congestion control > algorithms for interactive point-to-point real-time media. >=20 >=20 >=20 >=20 > The IETF Secretariat From tterriberry@mozilla.com Wed Oct 17 17:31:29 2012 Return-Path: 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 C5FE721F854A for ; Wed, 17 Oct 2012 17:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[AWL=1.103, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWO65G8VI7qd for ; Wed, 17 Oct 2012 17:31:27 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 986F621F8546 for ; Wed, 17 Oct 2012 17:31:27 -0700 (PDT) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 4D802F2052 for ; Wed, 17 Oct 2012 17:31:27 -0700 (PDT) Message-ID: <507F4DDF.6090405@mozilla.com> Date: Wed, 17 Oct 2012 17:31:27 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1 MIME-Version: 1.0 To: rmcat WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 00:31:29 -0000 Varun Singh wrote: > Apart from delay there is also balancing throughput and loss. > In the scenario of a single RTP flow we could come up with a > simple metric but with competing traffic it may be more difficult. > By introducing a video quality metric in those scenarios, > I was intending to quantify the balance of throughput, loss and delay. If you want to measure video quality in the presence of changing bitrates, loss, and delay, you have a difficult problem on your hands. Not the least of which is that PSNR (or similar metrics) require a reference to compare against, which starts to get meaningless once you change resolution or framerate in the encoder (with dropping frames being a very crude form of changing framerate), all of which are things the encoder can do to adapt to changes in available bandwidth. I discussed some of this in more detail in my submission to the workshop: From tterriberry@mozilla.com Wed Oct 17 17:38:43 2012 Return-Path: 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 BFDAE21F852D for ; Wed, 17 Oct 2012 17:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApkYz5GT4t71 for ; Wed, 17 Oct 2012 17:38:43 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 52F7A21F851A for ; Wed, 17 Oct 2012 17:38:43 -0700 (PDT) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 5F234F2408 for ; Wed, 17 Oct 2012 17:38:41 -0700 (PDT) Message-ID: <507F4F91.6040409@mozilla.com> Date: Wed, 17 Oct 2012 17:38:41 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1 MIME-Version: 1.0 To: rmcat WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 00:38:43 -0000 Michael Welzl wrote: > Sorry if this is stupid, perhaps I'm missing something - but: > > even if we could agree on a baseline test setup, standard movies etc.: isn't the very idea of a QoE metric inevitably bound to the codec, which then binds evaluating congestion control mechanisms to a debate that this really shouldn't be a part of? Yes. I think there are two separable problems here: 1) Estimating the channel capacity 2) Allocating that capacity among multiple flows constrained by the same bottleneck (or multiple, multiplexed streams on the same flow, if you like). The only interaction between problem 1 and the codec(s) is how quickly they can adapt to the changing estimates that are produced. I'm not sure that requires looking at the quality of the resulting content at all, however. For problem 2, actual video/audio quality becomes much more interesting, but I think is something this is a problem that has to be solved by the application itself, not the congestion control layer. Only the application knows things like "I'm using G.711: the only way I can adapt its rate is to drop the packets, so all reductions must come from my video stream," or "I'm transmitting two video streams, but one of them is much easier to encode than the other, so when the rate drops, I should steal more bits from that one." From wes@mti-systems.com Wed Oct 17 20:14:35 2012 Return-Path: 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 DF98011E808A for ; Wed, 17 Oct 2012 20:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6+OWgbSDXKe for ; Wed, 17 Oct 2012 20:14:35 -0700 (PDT) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id 4F29A1F0417 for ; Wed, 17 Oct 2012 20:14:35 -0700 (PDT) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id q9I3EXDA003630 for ; Wed, 17 Oct 2012 23:14:33 -0400 Received: (qmail 18534 invoked by uid 0); 18 Oct 2012 03:14:33 -0000 Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.143.209) by 0 with ESMTPA; 18 Oct 2012 03:14:33 -0000 Message-ID: <507F740D.6050409@mti-systems.com> Date: Wed, 17 Oct 2012 23:14:21 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Timothy B. Terriberry" References: <507F4F91.6040409@mozilla.com> In-Reply-To: <507F4F91.6040409@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rmcat WG Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 03:14:36 -0000 On 10/17/2012 8:38 PM, Timothy B. Terriberry wrote: > Michael Welzl wrote: >> Sorry if this is stupid, perhaps I'm missing something - but: >> >> even if we could agree on a baseline test setup, standard movies etc.: >> isn't the very idea of a QoE metric inevitably bound to the codec, >> which then binds evaluating congestion control mechanisms to a debate >> that this really shouldn't be a part of? > > Yes. I think there are two separable problems here: > > 1) Estimating the channel capacity > 2) Allocating that capacity among multiple flows constrained by the same > bottleneck (or multiple, multiplexed streams on the same flow, if you > like). > > The only interaction between problem 1 and the codec(s) is how quickly > they can adapt to the changing estimates that are produced. I'm not sure > that requires looking at the quality of the resulting content at all, > however. > > For problem 2, actual video/audio quality becomes much more interesting, > but I think is something this is a problem that has to be solved by the > application itself, not the congestion control layer. Only the > application knows things like "I'm using G.711: the only way I can adapt > its rate is to drop the packets, so all reductions must come from my > video stream," or "I'm transmitting two video streams, but one of them > is much easier to encode than the other, so when the rate drops, I > should steal more bits from that one." > > I totally agree with this. The elasticity of the codecs matters, and the congestion controller will benefit from an understanding of the envelopes they can operate within, but it's the job of the codecs to ensure quality within their envelopes of elasticity, and not at all the congestion controller's job. The CC may say "you now have N kbps to work within" to each codec, and this will be based on what it estimates is safe for the network given the current ensemble of codecs and their stated operating envelopes, *not* on any explicit attempt by the CC to maximize user experience. -- Wes Eddy MTI Systems From xiaoqzhu@cisco.com Wed Oct 17 20:49:47 2012 Return-Path: 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 B7E4921F8545 for ; Wed, 17 Oct 2012 20:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOIGG5Q9Tu7h for ; Wed, 17 Oct 2012 20:49:46 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C510E21F853A for ; Wed, 17 Oct 2012 20:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3533; q=dns/txt; s=iport; t=1350532187; x=1351741787; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UNNGBjhYEOUg29HjmvQwBQC3fnnPgBDsoG0RtCm2/20=; b=i/zCvGw3deKDUlkj40/EZyx38xSBiNzSQzOfV+fF/gwgPXFc3Im8iXeM xOAn8vXgG1FnW0TZJEzWVOaTjuxIfpHcKNP1NnudgxIe4xrrR01fBoMEi Aq+rFwCb7x3WMY/BL7gjWewPSOwHixkL0HHMo4RccryDEr+K8gRevnGCg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcGAB57f1CtJXG8/2dsb2JhbABFgm25JYQvgQiCIAEBAQMBEgEnPxACAQgOCgoUEDIlAgQODRqHXAYBnAygIItYhWJgA6Q0gWuCb4IX X-IronPort-AV: E=Sophos;i="4.80,604,1344211200"; d="scan'208";a="132854563" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 18 Oct 2012 03:49:40 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9I3nd05029661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 03:49:39 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 22:49:39 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: Michael Welzl Thread-Topic: [rmcat] send agenda requests (was Re: First meeting) Thread-Index: AQHNp9grf2quh6JMt0CYpuBNP/SHCpe1q3yAgAWVAgCAAK9XAIABXGsAgAAq3YCAAVQ0gA== Date: Thu, 18 Oct 2012 03:49:38 +0000 Message-ID: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> <7829361A-29CE-429B-A40B-BB63B76C56C9@ifi.uio.no> In-Reply-To: <7829361A-29CE-429B-A40B-BB63B76C56C9@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.123.4] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--43.450000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <45D2F8B2A4956E4093DC6363C70EF62F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 03:49:47 -0000 Your points are well taken, Michael. =20 Agree that ultimately, it would be nice to have the scheme consider a merge= of delay and ECN signals, instead of switching naively between the two. We= considered that as a stretch goal though, according to the priorities disc= ussed in the last BOF. We are still in the process of improving the algorit= hm in that aspect.=20 I will put in some results from ECN-based marking in the compiled file to s= hare. But admitted, we have not yet explored the impact of all variations o= f ECN configurations. I will need to run more tests for that.=20 -Xiaoqing On Oct 17, 2012, at 12:31 AM, Michael Welzl wrote: >=20 > On 17. okt. 2012, at 06:58, Xiaoqing Zhu (xiaoqzhu) wrote: >=20 >> Hi Michael,=20 >>=20 >> Thanks for your comments. Please find my replies inline below.=20 >>=20 >> Best, >> Xiaoqing >>=20 >>=20 >> On Oct 16, 2012, at 1:11 AM, Michael Welzl wrote: >>=20 >>> Hi, >>>=20 >>> I took a quick look at this: >>>=20 >>> I like the general idea of using as much as possible of existing networ= k support - but I'm critical about the actual control you propose. >>>=20 >>> In section 5.3.2, you suggest to replace eqn. 1 from section 5.3 with e= qn. 2 when ECN feedback is available. This means to ignore a delay signal f= rom now on, and interpret ECN marks in the exact same way as you interprete= d delay before - this is too simplistic, I think. After all, ECN marks requ= ire a queue to grow, and this group intends to minimize delay... why would = you stop using delay once you have ECN in addition? >>=20 >>=20 >> In our design, we considered the two cases, with or without ECN markings= , separately. Therefore, the dynamic scenario when ECN becomes available i= n the middle of a video conferencing session has not yet been fully studied= . Just wondering, are cases where ECN marking are turned on and off dynami= cally common in reality? =20 >=20 > First, anything can happen when you have a routing change. > Second, I'm really sorry, but this wasn't what I meant. I shouldn't have = written "when" but "if". I wasn't referring to a case where we go from no-E= CN-support to ECN-support. So this is about the ECN-always-supported case. >=20 >=20 >>> In practice, using your scheme would probably mean that, as soon as I e= nable RED with ECN on the bottleneck between the two end systems, the users= ' observed delay grows. Not exactly an incentive? >>>=20 >> What you mentioned (uers observing higher delay in ECN-enabled systems) = will not happen.=20 >>=20 >> But rather, our simulation results have indicated that ECN with RED-base= d marking yields fairly similar results as the default delay-based scheme. = They certainly do not incur higher delay, since the endpoint will automatic= ally back off in face of higher ECN markings, which are indications of high= er delay. The two systems (delay-based and ECN-based) can be tuned to stabi= lize that the same queuing delay at the bottleneck.=20 >=20 > Whether you see significant delay before you see a large enough amount of= ECN markings depends on the queue length and RED parameters, none of which= are under the end system's control. ECN is also a probabilistic signal, so= sometimes you may get delay growth but just be lucky (or unlucky) enough t= o not get an ECN mark. >=20 > So, I'd have to see results that involve various RED settings and queue l= engths before I believe that. >=20 > Cheers, > Michael >=20 From michawe@ifi.uio.no Thu Oct 18 00:45:33 2012 Return-Path: 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 3CD9821F860E for ; Thu, 18 Oct 2012 00:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+4kx+U+0yYj for ; Thu, 18 Oct 2012 00:45:32 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFB621F85F7 for ; Thu, 18 Oct 2012 00:45:32 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TOknI-0008Ks-Dc; Thu, 18 Oct 2012 09:45:28 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TOknH-00045U-VH; Thu, 18 Oct 2012 09:45:28 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: <507F740D.6050409@mti-systems.com> Date: Thu, 18 Oct 2012 09:45:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3354E46F-7215-443A-A36C-959EFFAF54ED@ifi.uio.no> References: <507F4F91.6040409@mozilla.com> <507F740D.6050409@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 5 sum msgs/h 3 total rcpts 24735 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.912, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 31174C79C26570A215741406A2574B7E879364D7 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 9974 max/h 21 blacklist 0 greylist 0 ratelimit 0 Cc: "Timothy B. Terriberry" , rmcat WG Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 07:45:33 -0000 On 18. okt. 2012, at 05:14, Wesley Eddy wrote: > On 10/17/2012 8:38 PM, Timothy B. Terriberry wrote: >> Michael Welzl wrote: >>> Sorry if this is stupid, perhaps I'm missing something - but: >>>=20 >>> even if we could agree on a baseline test setup, standard movies = etc.: >>> isn't the very idea of a QoE metric inevitably bound to the codec, >>> which then binds evaluating congestion control mechanisms to a = debate >>> that this really shouldn't be a part of? >>=20 >> Yes. I think there are two separable problems here: >>=20 >> 1) Estimating the channel capacity >> 2) Allocating that capacity among multiple flows constrained by the = same >> bottleneck (or multiple, multiplexed streams on the same flow, if you >> like). >>=20 >> The only interaction between problem 1 and the codec(s) is how = quickly >> they can adapt to the changing estimates that are produced. I'm not = sure >> that requires looking at the quality of the resulting content at all, >> however. >>=20 >> For problem 2, actual video/audio quality becomes much more = interesting, >> but I think is something this is a problem that has to be solved by = the >> application itself, not the congestion control layer. Only the >> application knows things like "I'm using G.711: the only way I can = adapt >> its rate is to drop the packets, so all reductions must come from my >> video stream," or "I'm transmitting two video streams, but one of = them >> is much easier to encode than the other, so when the rate drops, I >> should steal more bits from that one." >>=20 >>=20 >=20 >=20 > I totally agree with this. The elasticity of the codecs matters, and > the congestion controller will benefit from an understanding of the > envelopes they can operate within, but it's the job of the codecs to > ensure quality within their envelopes of elasticity, and not at all = the > congestion controller's job. Exactly, I also totally agree. Do we then have a consensus to kick out = the QoE metric? :-) I think that would be a good thing. > The CC may say "you now have N kbps to work within" to each codec, and > this will be based on what it estimates is safe for the network given > the current ensemble of codecs and their stated operating envelopes, > *not* on any explicit attempt by the CC to maximize user experience. Agreed. Note, what you describe here is an "interaction between = applications and RTP flows", which is a quote from the charter, a part = of a milestone due in December... is anyone working on a draft for this? This is where "packet importance" to be handed over to the congestion = control should also fit... (that was discussed as a part of the sender- = vs. receiver-based thread) IF we decide to have that. Cheers, Michael From harald@alvestrand.no Thu Oct 18 06:26:00 2012 Return-Path: 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 20F1F21F8599 for ; Thu, 18 Oct 2012 06:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.408 X-Spam-Level: X-Spam-Status: No, score=-110.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GBdvoGiH26v for ; Thu, 18 Oct 2012 06:25:59 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D941D21F854F for ; Thu, 18 Oct 2012 06:25:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EEE7139E0F3 for ; Thu, 18 Oct 2012 15:25:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiWL2N9p53vS for ; Thu, 18 Oct 2012 15:25:57 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EE7FB39E04C for ; Thu, 18 Oct 2012 15:25:56 +0200 (CEST) Message-ID: <50800364.1070908@alvestrand.no> Date: Thu, 18 Oct 2012 15:25:56 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rmcat@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rmcat] Multihop congestion control - two words of caution 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:26:00 -0000 I got into a discussion in Vancouver with someone about multihop congestion control, why it was hard, and why it should be ruled out of scope - and promised to say something about it later. But at this point, I no longer remember who it was with, so I'm posting it here instead. One interesting thing about congestion control is a tendency to oscillation. If there is a feedback signal, that's always based on past history; the decisions based on that signal will affect traffic in the future. So there's always a delay between the events we take action on and the action we take. If, for instance, the delay is 1 second (the argument's the same for 1 millisecond, but a second is easier to think about), the feedback signal is "congestion", and the decision is "reduce traffic" .. the signal an instant after the decision is made is based on the *previous* second's worth of traffic, and will still say "congestion"; if we take action on that, we'll reduce traffic even more - perhaps too much. Once we detect "no congestion", the same thing happens in reverse. If the delays and the size of action is just right, we can get into oscillation: jumping between inefficient use of bandwidth (sending too little) and serious congestion (sending too much). The mitigation against this kind of behaviour is that one designs the strength of the action to be commensurate with the delay so as to avoid damping; in TCP, this is obtained by scaling reaction time by the RTT; we don't react faster than 1 unit of reaction per RTT. Now consider what happens if we have two hops after each other, possibly with different delays, each running their own congestion control algorithm - and a linkage that tries to feed congestion control information from the second hop back to the congestion control algorithm running on the first hop. The overall system will have a delay - but that delay won't be visible to the congestion control algorithm on the first hop, so the reaction time and size can't be scaled appropriately. The result is that the overall system is very likely to exhibit oscillatory behaviour - simply because the time constants we need to observe for a proper design are invisible to the observer. We can imagine ways of working around this limitation - but for the purposes of RMCAT, I think we should just stick with two principles: - We don't design for the two-hop case. - We advise designers of two-hop systems (like relay nodes) that if they want to feed capacity information from a second hop back to the first hop, they should reflect those changes SLOWLY. Experts, did this sound reasonable? Harald From harald@alvestrand.no Thu Oct 18 06:32:09 2012 Return-Path: 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 CFF6E21F8797 for ; Thu, 18 Oct 2012 06:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.416 X-Spam-Level: X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48IBR4eB2pLR for ; Thu, 18 Oct 2012 06:32:08 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A68FB21F873C for ; Thu, 18 Oct 2012 06:32:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55B0939E04C for ; Thu, 18 Oct 2012 15:32:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOv3q2tYU0WH for ; Thu, 18 Oct 2012 15:32:05 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1FBDB39E0F3 for ; Thu, 18 Oct 2012 15:32:05 +0200 (CEST) Message-ID: <508004D4.5060305@alvestrand.no> Date: Thu, 18 Oct 2012 15:32:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rmcat@ietf.org References: <507F4DDF.6090405@mozilla.com> In-Reply-To: <507F4DDF.6090405@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:32:09 -0000 On 10/18/2012 02:31 AM, Timothy B. Terriberry wrote: > Varun Singh wrote: >> Apart from delay there is also balancing throughput and loss. >> In the scenario of a single RTP flow we could come up with a >> simple metric but with competing traffic it may be more difficult. >> By introducing a video quality metric in those scenarios, >> I was intending to quantify the balance of throughput, loss and delay. > > If you want to measure video quality in the presence of changing > bitrates, loss, and delay, you have a difficult problem on your hands. > Not the least of which is that PSNR (or similar metrics) require a > reference to compare against, which starts to get meaningless once you > change resolution or framerate in the encoder (with dropping frames > being a very crude form of changing framerate), all of which are > things the encoder can do to adapt to changes in available bandwidth. > I discussed some of this in more detail in my submission to the > workshop: > Wouldn't a simple (simplistic?) way of measuring quality in the presence of packet drops be to always use a test rig where one end looped back the encoded video signal to the other end? Thus, the one that injects the signal could compare the pre-encoding video source to the post-decoding video sink, which I suppose is what PSNR measurements need. This is inappropriate for measurements on a live service, but might be appropriate for generating benchmarks. From radhika.r.roy.civ@mail.mil Thu Oct 18 07:36:48 2012 Return-Path: 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 C869E21F8812 for ; Thu, 18 Oct 2012 07:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycKgpDtWBq10 for ; Thu, 18 Oct 2012 07:36:48 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id DF9E221F8815 for ; Thu, 18 Oct 2012 07:36:47 -0700 (PDT) Received: from UCOLHP3A.easf.csd.disa.mil (131.64.100.148) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 18 Oct 2012 14:38:37 +0000 Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.175]) by UCOLHP3A.easf.csd.disa.mil ([131.64.100.148]) with mapi id 14.02.0309.003; Thu, 18 Oct 2012 14:38:37 +0000 From: "Roy, Radhika R CIV (US)" To: Harald Alvestrand , "rmcat@ietf.org" Thread-Topic: [rmcat] Multihop congestion control - two words of caution Thread-Index: AQHNrTRsaVMYuf3ibky8v3/CzQXQIJe/HSqA Date: Thu, 18 Oct 2012 14:38:36 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF485F1CC2@ucolhp9h.easf.csd.disa.mil> References: <50800364.1070908@alvestrand.no> In-Reply-To: <50800364.1070908@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0020_01CDAD1C.6FE68400" MIME-Version: 1.0 Subject: Re: [rmcat] Multihop congestion control - two words of caution 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 14:36:48 -0000 ------=_NextPart_000_0020_01CDAD1C.6FE68400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Herald: In general, your observation is OK. There are a couple of things are as follows: 1. We have to look into aggregate statistical model of traffic congestions. 2. Contributions to congestions are different for different types of traffic. 3. Behavior of each kind of traffic is also different. 4. Performance requirements of each kind of traffic are also different. 4. High bandwidth-intensive video vs. low bandwidth audio vs. low-high bandwidth with very busty data with different performance requirements over the same IP network will need to have very different requirements for taking actions when congestions are detected. The point that I am making is this: IETF is being the technical organization needs to try to solve, if not complete solutions for congestions, but at least to look into in addressing the problems especially when video is becoming (or has become) the most dominant traffic. As we gain more and more insights of this complex problem, we will be developing the technical standards accordingly as time goes by. BR/Radhika -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: Thursday, October 18, 2012 9:26 AM To: rmcat@ietf.org Subject: [rmcat] Multihop congestion control - two words of caution I got into a discussion in Vancouver with someone about multihop congestion control, why it was hard, and why it should be ruled out of scope - and promised to say something about it later. But at this point, I no longer remember who it was with, so I'm posting it here instead. One interesting thing about congestion control is a tendency to oscillation. If there is a feedback signal, that's always based on past history; the decisions based on that signal will affect traffic in the future. So there's always a delay between the events we take action on and the action we take. If, for instance, the delay is 1 second (the argument's the same for 1 millisecond, but a second is easier to think about), the feedback signal is "congestion", and the decision is "reduce traffic" .. the signal an instant after the decision is made is based on the *previous* second's worth of traffic, and will still say "congestion"; if we take action on that, we'll reduce traffic even more - perhaps too much. Once we detect "no congestion", the same thing happens in reverse. If the delays and the size of action is just right, we can get into oscillation: jumping between inefficient use of bandwidth (sending too little) and serious congestion (sending too much). The mitigation against this kind of behaviour is that one designs the strength of the action to be commensurate with the delay so as to avoid damping; in TCP, this is obtained by scaling reaction time by the RTT; we don't react faster than 1 unit of reaction per RTT. Now consider what happens if we have two hops after each other, possibly with different delays, each running their own congestion control algorithm - and a linkage that tries to feed congestion control information from the second hop back to the congestion control algorithm running on the first hop. The overall system will have a delay - but that delay won't be visible to the congestion control algorithm on the first hop, so the reaction time and size can't be scaled appropriately. The result is that the overall system is very likely to exhibit oscillatory behaviour - simply because the time constants we need to observe for a proper design are invisible to the observer. We can imagine ways of working around this limitation - but for the purposes of RMCAT, I think we should just stick with two principles: - We don't design for the two-hop case. - We advise designers of two-hop systems (like relay nodes) that if they want to feed capacity information from a second hop back to the first hop, they should reflect those changes SLOWLY. Experts, did this sound reasonable? Harald ------=_NextPart_000_0020_01CDAD1C.6FE68400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjEwMTgxNDM2MzFaMCMGCSqGSIb3DQEJBDEWBBTaVY2ioFmVZtSTywn/IbBi CgsstTBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAFierlAWawVFaObVLy5ICJEj9nFP25Oqa4EFPlgV9zaKN8Czj0XCK8NKg2NFvFc2D/kU 1Up9EpJDfbmzuVpb+cC/Ft4o70e0oJlKu88BMh1y4Yf5owYUOwtVoVHlaWwjgOGlXvrgM4jk2sOR 3Bt3/hwaBG19MojWW0i0f0w7je1v97LTecUCiguEf1U6cw63jNnsGsX2vY/UDKokL+kRwt9lg5w4 TmHKhwJkX2iFDvlRECc2sdfAObZB2tuNkbWhfhbbjNbvU+XTr78tzzKW1VKs6MbPdOdnXJfpWSCK KIW3C1Ob3gauXIp/oaKLWftvsX4k79Pkl4w8r1aai79IDNMAAAAAAAA= ------=_NextPart_000_0020_01CDAD1C.6FE68400-- From ford@isoc.org Thu Oct 18 07:56:09 2012 Return-Path: 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 67F5521F870E for ; Thu, 18 Oct 2012 07:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7fVlmvbrdgI for ; Thu, 18 Oct 2012 07:56:09 -0700 (PDT) Received: from smtp110.dfw.emailsrvr.com (smtp110.dfw.emailsrvr.com [67.192.241.110]) by ietfa.amsl.com (Postfix) with ESMTP id 0212021F86FC for ; Thu, 18 Oct 2012 07:56:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 7E64A24042A; Thu, 18 Oct 2012 10:56:08 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp21.relay.dfw1a.emailsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id E88FA24027D; Thu, 18 Oct 2012 10:56:07 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Matthew Ford In-Reply-To: <50800364.1070908@alvestrand.no> Date: Thu, 18 Oct 2012 15:56:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50800364.1070908@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1498) Cc: rmcat@ietf.org Subject: Re: [rmcat] Multihop congestion control - two words of caution 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 14:56:09 -0000 On 18 Oct 2012, at 14:25, Harald Alvestrand = wrote: > - We don't design for the two-hop case. For me at least, visualisation helps: = http://www.youtube.com/watch?v=3DQXf95_EKS6E From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Oct 18 08:58:47 2012 Return-Path: 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 EBC9921F84CD for ; Thu, 18 Oct 2012 08:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9v52wR6DSpa for ; Thu, 18 Oct 2012 08:58:47 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D53921F8659 for ; Thu, 18 Oct 2012 08:58:47 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id AFA73633B1; Thu, 18 Oct 2012 17:58:45 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 717AE59A8A; Thu, 18 Oct 2012 17:58:45 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: rmcat@ietf.org Date: Thu, 18 Oct 2012 17:58:44 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <50800364.1070908@alvestrand.no> In-Reply-To: <50800364.1070908@alvestrand.no> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201210181758.44757.mirja.kuehlewind@ikr.uni-stuttgart.de> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: Harald Alvestrand Subject: Re: [rmcat] Multihop congestion control - two words of caution 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 15:58:48 -0000 Hi Harald, i believe do not understand your scenario: > Now consider what happens if we have two hops after each other, possibly > with different delays, each running their own congestion control > algorithm - and a linkage that tries to feed congestion control > information from the second hop back to the congestion control algorithm > running on the first hop. Are we talking of end-to-end congestion control here? Then if we have=20 congestion feedback from different nodes on one path, this feedback signal= =20 will have the same delay. And usually there is only one bottleneck at one=20 point of time as there is always on link with the smallest available=20 bandwidth. Is this the scenario your are talking about or something else? Mirja > > The overall system will have a delay - but that delay won't be visible > to the congestion control algorithm on the first hop, so the reaction > time and size can't be scaled appropriately. > > The result is that the overall system is very likely to exhibit > oscillatory behaviour - simply because the time constants we need to > observe for a proper design are invisible to the observer. > > We can imagine ways of working around this limitation - but for the > purposes of RMCAT, I think we should just stick with two principles: > > - We don't design for the two-hop case. > - We advise designers of two-hop systems (like relay nodes) that if they > want to feed capacity information from a second hop back to the first > hop, they should reflect those changes SLOWLY. > > Experts, did this sound reasonable? > > Harald =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From randell-ietf@jesup.org Thu Oct 18 21:50:47 2012 Return-Path: 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 6F6F821F84F1 for ; Thu, 18 Oct 2012 21:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uGKbNCaoRok for ; Thu, 18 Oct 2012 21:50:47 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EF8A121F84EA for ; Thu, 18 Oct 2012 21:50:46 -0700 (PDT) Received: from pool-173-49-129-2.phlapa.fios.verizon.net ([173.49.129.2]:1193 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TP4Xl-000CYm-5w for rmcat@ietf.org; Thu, 18 Oct 2012 23:50:45 -0500 Message-ID: <5080DBAF.8070503@jesup.org> Date: Fri, 19 Oct 2012 00:48:47 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rmcat@ietf.org References: <507F4F91.6040409@mozilla.com> <507F740D.6050409@mti-systems.com> In-Reply-To: <507F740D.6050409@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 04:50:47 -0000 I won't bother quoting people, but I'll say that trying to evaluate a CC algorithm (even one meant for media) via a video QoE test is a really bad idea. It's way, way too subjective - the problem is far *harder* than it is for pre-recorded sequences, and there's no great agreement there on how to weight all the factors. (From what I hear). It may be *interesting* to look at, but I'd never try to use it as any sort of definitive test. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Thu Oct 18 21:54:56 2012 Return-Path: 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 CD58121F858F for ; Thu, 18 Oct 2012 21:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skXxbyyvc5Z7 for ; Thu, 18 Oct 2012 21:54:56 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 62C8821F8505 for ; Thu, 18 Oct 2012 21:54:56 -0700 (PDT) Received: from pool-173-49-129-2.phlapa.fios.verizon.net ([173.49.129.2]:1204 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TP4bn-000DNZ-QT for rmcat@ietf.org; Thu, 18 Oct 2012 23:54:55 -0500 Message-ID: <5080DCAA.4080100@jesup.org> Date: Fri, 19 Oct 2012 00:52:58 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rmcat@ietf.org References: <507F4F91.6040409@mozilla.com> <507F740D.6050409@mti-systems.com> <3354E46F-7215-443A-A36C-959EFFAF54ED@ifi.uio.no> In-Reply-To: <3354E46F-7215-443A-A36C-959EFFAF54ED@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 04:54:56 -0000 On 10/18/2012 3:45 AM, Michael Welzl wrote: > >> The CC may say "you now have N kbps to work within" to each codec, and >> this will be based on what it estimates is safe for the network given >> the current ensemble of codecs and their stated operating envelopes, >> *not* on any explicit attempt by the CC to maximize user experience. > Agreed. Note, what you describe here is an "interaction between applications and RTP flows", which is a quote from the charter, a part of a milestone due in December... is anyone working on a draft for this? I have made a proposal in the W3 bugzilla and on the list. There was a small amount of discussion; none since. I'd suggest starting from there. It may be worthwhile to re-examine the API in light of the stats proposals to avoid conflicting/overlapping data. > This is where "packet importance" to be handed over to the congestion control should also fit... (that was discussed as a part of the sender- vs. receiver-based thread) IF we decide to have that. Well, packet importance would (generally) be in the internals, not at the application/JS layer, except maybe to provide stream-level priorities. -- Randell Jesup randell-ietf@jesup.org From michawe@ifi.uio.no Fri Oct 19 00:52:18 2012 Return-Path: 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 0B80721F845E for ; Fri, 19 Oct 2012 00:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzH2h9CjBq2B for ; Fri, 19 Oct 2012 00:52:07 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id DFE2021F841F for ; Fri, 19 Oct 2012 00:52:05 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TP7NE-0002EI-L9; Fri, 19 Oct 2012 09:52:04 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TP7NE-0003zJ-0X; Fri, 19 Oct 2012 09:52:04 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: <201210181758.44757.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Fri, 19 Oct 2012 09:52:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0AC4ED0D-88AB-466F-B4EA-EC75A5EC53FB@ifi.uio.no> References: <50800364.1070908@alvestrand.no> <201210181758.44757.mirja.kuehlewind@ikr.uni-stuttgart.de> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 6 sum msgs/h 3 total rcpts 24756 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.912, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4E7A791369EC25E17DA885E4BB1E8FBD1B62D8FC X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 9990 max/h 21 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat@ietf.org, Harald Alvestrand Subject: Re: [rmcat] Multihop congestion control - two words of caution 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 07:52:18 -0000 Hi all, I feel in a bit of a dilemma answering Harald's email, because this = requires that I call myself an "expert"... yet I'm tempted to answer... = tsk! :-) Anyway, I'll try to reply the emails from Harald, Radhika = and Mirja in one go here, in the hope that I can clarify things a = little: Harald: all of what you have written sounds 100% reasonable to me. Radhika: your answer appears (to me) to miss the point, and maybe (sorry = if I'm wrong!) it's because you misunderstood the scenario? So maybe my = answer to Mirja below helps. Mirja: RTP/RTCP can let end systems take the role of an intermediate = node, to take care of data stream specific things before traffic reaches = the receiver (synchronizing, mixing, ...). Essentially, this is an = overlay network. I think Harald refers to such a case with multiple RTP = end systems, i.e. a path like this: Node1 [ RTP1 sender ] =3D> Node 2 [RTP1 receiver + RTP2 sender] =3D> = Node 3 [RTP2 receiver] ...and his description of problems goes into the behavior of node 2 = (which is, in principle, quite similar to the behavior of some PEPs = (RFC3135), I guess, e.g. TCP splitters. The decision at the BOF was not = *yet* to define what is needed to make Node 2 work correctly, which is = what we referred to as multi-hop congestion control. The exact phrasing = in the charter is: "implications on multi-hop connections will be = considered at a later stage". The reason for writing this is that Magnus = Westerlund (quite correctly, I think) stated that defining this will at = some point be needed. I hope my interpretation of Harald's scenario is correct, and I hope = that this was helpful! Cheers, Michael On 18. okt. 2012, at 17:58, Mirja Kuehlewind wrote: > Hi Harald, >=20 > i believe do not understand your scenario: >=20 >> Now consider what happens if we have two hops after each other, = possibly >> with different delays, each running their own congestion control >> algorithm - and a linkage that tries to feed congestion control >> information from the second hop back to the congestion control = algorithm >> running on the first hop. >=20 > Are we talking of end-to-end congestion control here? Then if we have=20= > congestion feedback from different nodes on one path, this feedback = signal=20 > will have the same delay. And usually there is only one bottleneck at = one=20 > point of time as there is always on link with the smallest available=20= > bandwidth. Is this the scenario your are talking about or something = else? >=20 > Mirja >=20 >=20 >=20 >>=20 >> The overall system will have a delay - but that delay won't be = visible >> to the congestion control algorithm on the first hop, so the reaction >> time and size can't be scaled appropriately. >>=20 >> The result is that the overall system is very likely to exhibit >> oscillatory behaviour - simply because the time constants we need to >> observe for a proper design are invisible to the observer. >>=20 >> We can imagine ways of working around this limitation - but for the >> purposes of RMCAT, I think we should just stick with two principles: >>=20 >> - We don't design for the two-hop case. >> - We advise designers of two-hop systems (like relay nodes) that if = they >> want to feed capacity information from a second hop back to the first >> hop, they should reflect those changes SLOWLY. >>=20 >> Experts, did this sound reasonable? >>=20 >> Harald >=20 >=20 >=20 > --=20 > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- From michawe@ifi.uio.no Fri Oct 19 00:56:24 2012 Return-Path: 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 D52CF21F85AF for ; Fri, 19 Oct 2012 00:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCWG-WrzMJt7 for ; Fri, 19 Oct 2012 00:56:24 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0D721F86FD for ; Fri, 19 Oct 2012 00:56:21 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TP7RL-0006hC-Br; Fri, 19 Oct 2012 09:56:19 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TP7RK-0005yr-Qx; Fri, 19 Oct 2012 09:56:19 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_82949183-54B8-4833-8CFD-6446313134DD" From: Michael Welzl In-Reply-To: <5080DCAA.4080100@jesup.org> Date: Fri, 19 Oct 2012 09:56:17 +0200 Message-Id: References: <507F4F91.6040409@mozilla.com> <507F740D.6050409@mti-systems.com> <3354E46F-7215-443A-A36C-959EFFAF54ED@ifi.uio.no> <5080DCAA.4080100@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 4 sum rcpts/h 8 sum msgs/h 4 total rcpts 24758 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.912, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 73C5940823FFD4384D318B5C21D9ECC92738B567 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 9991 max/h 21 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat@ietf.org Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 07:56:24 -0000 --Apple-Mail=_82949183-54B8-4833-8CFD-6446313134DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 19. okt. 2012, at 06:52, Randell Jesup wrote: > On 10/18/2012 3:45 AM, Michael Welzl wrote: >>=20 >>> The CC may say "you now have N kbps to work within" to each codec, = and >>> this will be based on what it estimates is safe for the network = given >>> the current ensemble of codecs and their stated operating envelopes, >>> *not* on any explicit attempt by the CC to maximize user experience. >> Agreed. Note, what you describe here is an "interaction between = applications and RTP flows", which is a quote from the charter, a part = of a milestone due in December... is anyone working on a draft for this? >=20 > I have made a proposal in the W3 bugzilla and on the list. There was = a small amount of discussion; none since. I'd suggest starting from = there. It may be worthwhile to re-examine the API in light of the stats = proposals to avoid conflicting/overlapping data. I think I've asked you before, and I think you probably answered =3D> so = I'm sorry for being too chaotic, but could you maybe give us that link = again? >> This is where "packet importance" to be handed over to the congestion = control should also fit... (that was discussed as a part of the sender- = vs. receiver-based thread) IF we decide to have that. >=20 > Well, packet importance would (generally) be in the internals, not at = the application/JS layer, except maybe to provide stream-level = priorities. Yes, but to me, "application" in the rmcat context is not the JS = application but the codec. This is at least where that "interactions" = deliverable originated - to address comments like this one: from: http://www.ietf.org/proceedings/84/minutes/minutes-84-rmcat " - Stephan Wenger suggested that the discussions have been behind the state of the art in joint source-channel coding. The group should consider that not all packets are equal in importance when designing congestion control algorithms. " Cheers, Michael --Apple-Mail=_82949183-54B8-4833-8CFD-6446313134DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 10/18/2012 3:45 AM, Michael Welzl = wrote:

The CC may say "you now have N = kbps to work within" to each codec, = and
this will be based on what it estimates is safe for the = network given
the current ensemble of codecs = and their stated operating = envelopes,
*not* on any explicit attempt by = the CC to maximize user = experience.
Agreed.= Note, what you describe here is an "interaction between applications = and RTP flows", which is a quote from the charter, a part of a milestone = due in December... is anyone working on a draft for = this?

I have made a proposal in the W3 bugzilla and = on the list.  There was a small amount of discussion; none since. =  I'd suggest starting from there.  It may be worthwhile to = re-examine the API in light of the stats proposals to avoid = conflicting/overlapping data.

I = think I've asked you before, and I think you probably answered =3D> = so I'm sorry for being too chaotic, but could you maybe give us that = link again?


This is where "packet = importance" to be handed over to the congestion control should also = fit... (that was discussed as a part of the sender- vs. receiver-based = thread) IF we decide to have that.

Well, packet = importance would (generally) be in the internals, not at the = application/JS layer, except maybe to provide stream-level = priorities.

Yes, but to me, = "application" in the rmcat context is not the JS application but the = codec. This is at least where that "interactions" deliverable originated = - to address comments like this = one:

"&nbs= p;- Stephan Wenger suggested that the discussions have been behind = the
   state of the art in joint source-channel = coding. The group should
   consider that not all = packets are equal in importance when designing
  =  congestion control algorithms. = "


Cheers,
Michael
<= div>
= --Apple-Mail=_82949183-54B8-4833-8CFD-6446313134DD-- From vsingh.ietf@gmail.com Fri Oct 19 03:12:11 2012 Return-Path: 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 2342221F8667 for ; Fri, 19 Oct 2012 03:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6nxTczwB5PE for ; Fri, 19 Oct 2012 03:12:10 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DEDF221F8639 for ; Fri, 19 Oct 2012 03:12:09 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so346258pbb.31 for ; Fri, 19 Oct 2012 03:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=sv1xiE3X6bv49sy30gmTi1ieV0tmyZx4q7oGwgH2ppo=; b=xFue/w2vu7JsMBHi0r5eFTptUjNLCEZ7nMDzSSrvjFTf/ikOy4nbRAVNmkCWQo5jhu UN+BSMNnOkI2qQ2DqFLurpkhS5OwbWaLwbnSqVMqXDl7c2osuNox7Pvk++Wd41iHXm6p WcgEAWOq42XN0aLymBhVFiBjDz9jxOlMquUeaZFwkm+LkpKfo/OPx7SHNIQOXUXEtbWR e4sloXMhVciTasCtEX8MrNsB454Ns6Bp63y1xk+DjGTFYzLNooYzgApQdNfHqTV3MdIj sIVNGhwt6EtIMJVsdvoUaKC2Y4qPJ+4SAOLKgRwkxry3dwO8j1HH1F49NOZw6mcctzrZ a46A== Received: by 10.68.252.133 with SMTP id zs5mr3840158pbc.152.1350641529606; Fri, 19 Oct 2012 03:12:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.60.135 with HTTP; Fri, 19 Oct 2012 03:11:49 -0700 (PDT) In-Reply-To: <2B1A13B9-6783-4AFE-A411-57899D8D1CB5@gmail.com> References: <2B1A13B9-6783-4AFE-A411-57899D8D1CB5@gmail.com> From: Varun Singh Date: Fri, 19 Oct 2012 13:11:49 +0300 Message-ID: To: "Piers O'Hanlon" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG Subject: Re: [rmcat] New Version Notification for draft-singh-rmcat-cc-eval-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 10:12:11 -0000 Hi Piers, Comments inline, On Wed, Oct 17, 2012 at 2:25 PM, Piers O'Hanlon wrote= : > Hi Varun, > > The draft looks like a good start. > > I think it would good to add evaluation of idle and data-limited behaviou= rs - as these are important as regards media transport - they were the reas= ons the original TFRC (RFC3448) was updated to RFC5348. See: http://dx.doi.= org/10.1016%2fj.comcom.2011.05.003 > "TCP-Friendly Rate Control (TFRC) for bursty media flows", Arjuna Sathias= eelan, Gorry Fairhurst, Comcom 2011 > Do you mean the audio media traffic should be modelled as having idle periods? and video because of I and P frames will have bursty behaviour? > Furthermore it would also be useful to evaluate the algorithms with respe= ct to their operation in terms of competing against a small number of flows= vs a large number - see: > On the Effectiveness of Delay-Based Congestion Avoidance, Ravi S. Prasad,= Manish Jain Georgia, Constantinos Dovrolis, PFLDnet 2004 > In [S5], I have an editors note: [many and few short TCP flows may depend on the bottleneck link capacity.] I can add a line to both cross traffic and self fairness guideline (Section 4) to evaluate the performance with small number and large number of competing flows. Cheers, Varun > Cheers, > > Piers > > > > > On 15 Oct 2012, at 21:33, Varun Singh wrote: > >> Greetings, >> >> We have submitted an initial draft outlining the criteria for evaluating >> congestion control algorithms. The metrics section is a bit light >> on details and will to expand on that in the next revision. >> >> We hope that the draft is a good starting point to get the discussion >> started about metrics and scenarios for simulation and testbed experimen= ts. >> >> Cheers, >> Varun >> >> Begin forwarded message: >> >> >> A new version of I-D, draft-singh-rmcat-cc-eval-00.txt >> has been successfully submitted by Varun Singh and posted to the >> IETF repository. >> >> Filename: draft-singh-rmcat-cc-eval >> Revision: 00 >> Title: Evaluating Congestion Control for Interactive Rea= l-time Media. >> Creation date: 2012-10-15 >> WG ID: Individual Submission >> Number of pages: 9 >> URL: >> http://www.ietf.org/internet-drafts/draft-singh-rmcat-cc-eval-00.txt >> Status: http://datatracker.ietf.org/doc/draft-singh-rmcat-cc-ev= al >> Htmlized: http://tools.ietf.org/html/draft-singh-rmcat-cc-eval-00 >> >> >> Abstract: >> The Real-time Transport Protocol (RTP) is used to transmit media in >> telephony and video conferencing applications. This document >> describes the guidelines to evaluate new congestion control >> algorithms for interactive point-to-point real-time media. >> >> >> >> >> The IETF Secretariat > --=20 http://www.netlab.tkk.fi/~varun/ From vsingh.ietf@gmail.com Fri Oct 19 03:26:36 2012 Return-Path: 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 7A23821F8575 for ; Fri, 19 Oct 2012 03:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb1Tl2bm6sAq for ; Fri, 19 Oct 2012 03:26:35 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99EED21F8567 for ; Fri, 19 Oct 2012 03:26:35 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so355070pbb.31 for ; Fri, 19 Oct 2012 03:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9isxPpa4t3Do3/dxVs3TSp1CFY87k3bVSRdfYsM/wWo=; b=qKXG9NKhi4sqJjnMYOCZe/+JBR0Jna+FOq8rTrr/tcZbLx2wyrz5cpgz7Ze+hM18Dk x7gANUxS/E5e/ekJjx4jNenkWcogbZn8W9iEnOsb2Ka8Be+JNT2BKEgZRAOrERoBDCOY i4WPUmsxIfYPSFHmvdk0e4LtNe+alCXS5YQovt8EOJWsOHAL7nYVmNP+5/D8k2aTNS0q 0xIGtbG7CT8gMK9SUjv/raRSR0mVqo+xJjj8pqAJrWFrIbcYibZrA1+OdErtp2g6bQ0c itQRLoWdTu76uuin+xZu2QKSlXoV63+tBbbV0XtVxPnCTyF/Buk8k+n3Hvk0YRWdcWQd 36Sg== Received: by 10.68.252.133 with SMTP id zs5mr3957343pbc.152.1350642395395; Fri, 19 Oct 2012 03:26:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.60.135 with HTTP; Fri, 19 Oct 2012 03:26:15 -0700 (PDT) In-Reply-To: <508004D4.5060305@alvestrand.no> References: <507F4DDF.6090405@mozilla.com> <508004D4.5060305@alvestrand.no> From: Varun Singh Date: Fri, 19 Oct 2012 13:26:15 +0300 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat@ietf.org Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 10:26:36 -0000 On Thu, Oct 18, 2012 at 4:32 PM, Harald Alvestrand wrote: > On 10/18/2012 02:31 AM, Timothy B. Terriberry wrote: >> >> Varun Singh wrote: >>> >>> Apart from delay there is also balancing throughput and loss. >>> In the scenario of a single RTP flow we could come up with a >>> simple metric but with competing traffic it may be more difficult. >>> By introducing a video quality metric in those scenarios, >>> I was intending to quantify the balance of throughput, loss and delay. >> >> >> If you want to measure video quality in the presence of changing bitrates, >> loss, and delay, you have a difficult problem on your hands. Not the least >> of which is that PSNR (or similar metrics) require a reference to compare >> against, which starts to get meaningless once you change resolution or >> framerate in the encoder (with dropping frames being a very crude form of >> changing framerate), all of which are things the encoder can do to adapt to >> changes in available bandwidth. I discussed some of this in more detail in >> my submission to the workshop: >> > > Wouldn't a simple (simplistic?) way of measuring quality in the presence of > packet drops be to always use a test rig where one end looped back the > encoded video signal to the other end? > > Thus, the one that injects the signal could compare the pre-encoding video > source to the post-decoding video sink, which I suppose is what PSNR > measurements need. > I was thinking about a similar setup when writing the document. Perhaps the Quality Metrics should not be used to compare between congestion control algorithms but compare the behaviour of the congestion control (all metrics not only quality) in different evaluation scenarios. > This is inappropriate for measurements on a live service, but might be > appropriate for generating benchmarks. -- http://www.netlab.tkk.fi/~varun/ From michawe@ifi.uio.no Fri Oct 19 03:31:28 2012 Return-Path: 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 B8E6721F860A for ; Fri, 19 Oct 2012 03:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqVaUNlKHMo0 for ; Fri, 19 Oct 2012 03:31:28 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id ABD4E21F860E for ; Fri, 19 Oct 2012 03:31:27 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TP9rS-0003ZH-Ln; Fri, 19 Oct 2012 12:31:26 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TP9rS-0001ay-3Q; Fri, 19 Oct 2012 12:31:26 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: Date: Fri, 19 Oct 2012 12:31:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4952F529-6852-4381-9F80-24C3CBC03040@ifi.uio.no> References: <507F4DDF.6090405@mozilla.com> <508004D4.5060305@alvestrand.no> To: Varun Singh X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 9 sum msgs/h 4 total rcpts 24769 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.912, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F89C3D09B3F8371E8F9BFB0B225B33C82D1DF1AD X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9998 max/h 21 blacklist 0 greylist 0 ratelimit 0 Cc: Harald Alvestrand , rmcat@ietf.org Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 10:31:28 -0000 On 19. okt. 2012, at 12:26, Varun Singh wrote: > On Thu, Oct 18, 2012 at 4:32 PM, Harald Alvestrand = wrote: >> On 10/18/2012 02:31 AM, Timothy B. Terriberry wrote: >>>=20 >>> Varun Singh wrote: >>>>=20 >>>> Apart from delay there is also balancing throughput and loss. >>>> In the scenario of a single RTP flow we could come up with a >>>> simple metric but with competing traffic it may be more difficult. >>>> By introducing a video quality metric in those scenarios, >>>> I was intending to quantify the balance of throughput, loss and = delay. >>>=20 >>>=20 >>> If you want to measure video quality in the presence of changing = bitrates, >>> loss, and delay, you have a difficult problem on your hands. Not the = least >>> of which is that PSNR (or similar metrics) require a reference to = compare >>> against, which starts to get meaningless once you change resolution = or >>> framerate in the encoder (with dropping frames being a very crude = form of >>> changing framerate), all of which are things the encoder can do to = adapt to >>> changes in available bandwidth. I discussed some of this in more = detail in >>> my submission to the workshop: >>> = >>=20 >> Wouldn't a simple (simplistic?) way of measuring quality in the = presence of >> packet drops be to always use a test rig where one end looped back = the >> encoded video signal to the other end? >>=20 >> Thus, the one that injects the signal could compare the pre-encoding = video >> source to the post-decoding video sink, which I suppose is what PSNR >> measurements need. >>=20 >=20 > I was thinking about a similar setup when writing the document. > Perhaps the Quality Metrics should not be used to compare > between congestion control algorithms but compare the > behaviour of the congestion control (all metrics not only quality) > in different evaluation scenarios. I can't parse that. Not compare between but compare the behaviour? Anyway, I still think that a quality metric makes no sense here... you = can't get rid of the fact that it's bound to the codec? Cheers, Michael From p.ohanlon@gmail.com Fri Oct 19 04:59:01 2012 Return-Path: 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 2E59F21F8485 for ; Fri, 19 Oct 2012 04:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pWsPR0oK0js for ; Fri, 19 Oct 2012 04:58:59 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42D1E21F8484 for ; Fri, 19 Oct 2012 04:58:59 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so242309wey.31 for ; Fri, 19 Oct 2012 04:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=j3ns5mxt5mu22rpJH4cAvvDv2T/RwCzXcGLDv9peM8g=; b=GCMmf0+0Mhj9IQ3X/+hdQ2qTt8UTxZm49ye42sjujv9gNsnNm0WBQQWi+07ohfoIzo Hm9Yx4ZKSOl4KjeMEmKLYL0UnD7XT+3oWbfHCAK76gHwxauALqu/HLkIgY4vFNFcXPCw PDP54PC/W7pbAgxb3hwyCEV+YWgqU3xh3X4QMi/YIXZ5/ewNQpl2G6KGmWYvO5TXJSko QaEEFy5z1aq7W+eJFNKN8A7saw5k0yn0cYSVG6WXgMCgu8RkJhsVLDQq5/hQH0DqYHzH BFSNkHj7MsnLW2bhMvSp3D/3Ufd0QcgvEHRvc+LuxUCw84l7fOY8NUdmtQnaQfZ+/5yR wLKA== Received: by 10.216.140.73 with SMTP id d51mr651057wej.217.1350647938289; Fri, 19 Oct 2012 04:58:58 -0700 (PDT) Received: from black.lan ([149.241.132.141]) by mx.google.com with ESMTPS id cn6sm3032549wib.9.2012.10.19.04.58.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 04:58:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Piers O'Hanlon In-Reply-To: Date: Fri, 19 Oct 2012 12:58:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B1A13B9-6783-4AFE-A411-57899D8D1CB5@gmail.com> To: Varun Singh X-Mailer: Apple Mail (2.1283) Cc: rmcat WG Subject: Re: [rmcat] New Version Notification for draft-singh-rmcat-cc-eval-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 11:59:01 -0000 Hi Varun, On 19 Oct 2012, at 11:11, Varun Singh wrote: > Hi Piers, >=20 > Comments inline, >=20 > On Wed, Oct 17, 2012 at 2:25 PM, Piers O'Hanlon = wrote: >> Hi Varun, >>=20 >> The draft looks like a good start. >>=20 >> I think it would good to add evaluation of idle and data-limited = behaviours - as these are important as regards media transport - they = were the reasons the original TFRC (RFC3448) was updated to RFC5348. = See: http://dx.doi.org/10.1016%2fj.comcom.2011.05.003 >> "TCP-Friendly Rate Control (TFRC) for bursty media flows", Arjuna = Sathiaseelan, Gorry Fairhurst, Comcom 2011 >>=20 >=20 > Do you mean the audio media traffic should be modelled as having idle > periods? and video because of I and P frames will have bursty > behaviour? >=20 Yes both media can have idle and data-limited periods due to silence or = low motion (depending upon codec type etc) - If we're trying stay away = from adding full QoE evaluation these terms describe more generic = behaviours that should be addressed when testing a congestion control = scheme. These were some of the original complaints about TFRC operation = that lead to the formation of this group. These behaviours are also linked to the corresponding TCP Congestion = Window Validation techniques (e.g. RFC2861) >=20 >> Furthermore it would also be useful to evaluate the algorithms with = respect to their operation in terms of competing against a small number = of flows vs a large number - see: >> On the Effectiveness of Delay-Based Congestion Avoidance, Ravi S. = Prasad, Manish Jain Georgia, Constantinos Dovrolis, PFLDnet 2004 >>=20 > In [S5], I have an editors note: > [many and few short TCP flows may depend on the bottleneck link = capacity.] >=20 > I can add a line to both cross traffic and self fairness guideline > (Section 4) to evaluate the performance with small number and large > number of competing flows. >=20 That sounds good. This issue is more of a concern as most of the = proposed schemes are likely to be primarily based upon some sort of = delay measurement which can become more problematic in certain scenarios = as mentioned in the short paper (and elsewhere). Cheers, Piers > Cheers, > Varun >=20 >> Cheers, >>=20 >> Piers >>=20 >>=20 >>=20 >>=20 >> On 15 Oct 2012, at 21:33, Varun Singh wrote: >>=20 >>> Greetings, >>>=20 >>> We have submitted an initial draft outlining the criteria for = evaluating >>> congestion control algorithms. The metrics section is a bit light >>> on details and will to expand on that in the next revision. >>>=20 >>> We hope that the draft is a good starting point to get the = discussion >>> started about metrics and scenarios for simulation and testbed = experiments. >>>=20 >>> Cheers, >>> Varun >>>=20 >>> Begin forwarded message: >>>=20 >>>=20 >>> A new version of I-D, draft-singh-rmcat-cc-eval-00.txt >>> has been successfully submitted by Varun Singh and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-singh-rmcat-cc-eval >>> Revision: 00 >>> Title: Evaluating Congestion Control for Interactive = Real-time Media. >>> Creation date: 2012-10-15 >>> WG ID: Individual Submission >>> Number of pages: 9 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-singh-rmcat-cc-eval-00.txt >>> Status: = http://datatracker.ietf.org/doc/draft-singh-rmcat-cc-eval >>> Htmlized: = http://tools.ietf.org/html/draft-singh-rmcat-cc-eval-00 >>>=20 >>>=20 >>> Abstract: >>> The Real-time Transport Protocol (RTP) is used to transmit media in >>> telephony and video conferencing applications. This document >>> describes the guidelines to evaluate new congestion control >>> algorithms for interactive point-to-point real-time media. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >=20 >=20 >=20 > --=20 > http://www.netlab.tkk.fi/~varun/ From harald@alvestrand.no Fri Oct 19 06:09:36 2012 Return-Path: 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 8278F21F85DC for ; Fri, 19 Oct 2012 06:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq2EtaB8ncYX for ; Fri, 19 Oct 2012 06:09:35 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCA521F85C0 for ; Fri, 19 Oct 2012 06:09:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5BFDB39E106; Fri, 19 Oct 2012 15:09:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX4IP-+d2QTn; Fri, 19 Oct 2012 15:09:32 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 656A639E020; Fri, 19 Oct 2012 15:09:32 +0200 (CEST) Message-ID: <5081510B.4010407@alvestrand.no> Date: Fri, 19 Oct 2012 15:09:31 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Michael Welzl References: <507F4DDF.6090405@mozilla.com> <508004D4.5060305@alvestrand.no> <4952F529-6852-4381-9F80-24C3CBC03040@ifi.uio.no> In-Reply-To: <4952F529-6852-4381-9F80-24C3CBC03040@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rmcat@ietf.org, Varun Singh Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:09:36 -0000 On 10/19/2012 12:31 PM, Michael Welzl wrote: > On 19. okt. 2012, at 12:26, Varun Singh wrote: > >> On Thu, Oct 18, 2012 at 4:32 PM, Harald Alvestrand wrote: >>> On 10/18/2012 02:31 AM, Timothy B. Terriberry wrote: >>>> Varun Singh wrote: >>>>> Apart from delay there is also balancing throughput and loss. >>>>> In the scenario of a single RTP flow we could come up with a >>>>> simple metric but with competing traffic it may be more difficult. >>>>> By introducing a video quality metric in those scenarios, >>>>> I was intending to quantify the balance of throughput, loss and delay. >>>> >>>> If you want to measure video quality in the presence of changing bitrates, >>>> loss, and delay, you have a difficult problem on your hands. Not the least >>>> of which is that PSNR (or similar metrics) require a reference to compare >>>> against, which starts to get meaningless once you change resolution or >>>> framerate in the encoder (with dropping frames being a very crude form of >>>> changing framerate), all of which are things the encoder can do to adapt to >>>> changes in available bandwidth. I discussed some of this in more detail in >>>> my submission to the workshop: >>>> >>> Wouldn't a simple (simplistic?) way of measuring quality in the presence of >>> packet drops be to always use a test rig where one end looped back the >>> encoded video signal to the other end? >>> >>> Thus, the one that injects the signal could compare the pre-encoding video >>> source to the post-decoding video sink, which I suppose is what PSNR >>> measurements need. >>> >> I was thinking about a similar setup when writing the document. >> Perhaps the Quality Metrics should not be used to compare >> between congestion control algorithms but compare the >> behaviour of the congestion control (all metrics not only quality) >> in different evaluation scenarios. > I can't parse that. Not compare between but compare the behaviour? > > Anyway, I still think that a quality metric makes no sense here... you can't get rid of the fact that it's bound to the codec? And that makes some sense.... algorithms need to be defined without reference to codecs, and some of their evaluation criteria (slef-fairness, lack of congestion collapse) need to be evaluated independent of the codec, but what impact they have on media streams encoded with existing codecs matters for real life deployments. From radhika.r.roy.civ@mail.mil Fri Oct 19 07:17:18 2012 Return-Path: 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 4554221F86C8 for ; Fri, 19 Oct 2012 07:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxkWzR77pbHx for ; Fri, 19 Oct 2012 07:17:17 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8345B21F84D8 for ; Fri, 19 Oct 2012 07:17:16 -0700 (PDT) Received: from UCOLHP3G.easf.csd.disa.mil (131.64.100.146) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 19 Oct 2012 14:19:08 +0000 Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.175]) by UCOLHP3G.easf.csd.disa.mil ([131.64.100.146]) with mapi id 14.02.0309.003; Fri, 19 Oct 2012 14:19:07 +0000 From: "Roy, Radhika R CIV (US)" To: Michael Welzl , Mirja Kuehlewind Thread-Topic: [rmcat] Multihop congestion control - two words of caution Thread-Index: AQHNrc6gaVMYuf3ibky8v3/CzQXQIJfAqLqA Date: Fri, 19 Oct 2012 14:16:19 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF485F20BF@ucolhp9h.easf.csd.disa.mil> References: <50800364.1070908@alvestrand.no> <201210181758.44757.mirja.kuehlewind@ikr.uni-stuttgart.de> <0AC4ED0D-88AB-466F-B4EA-EC75A5EC53FB@ifi.uio.no> In-Reply-To: <0AC4ED0D-88AB-466F-B4EA-EC75A5EC53FB@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0018_01CDADE1.E7C24D90" MIME-Version: 1.0 Cc: "rmcat@ietf.org" , Harald Alvestrand Subject: Re: [rmcat] Multihop congestion control - two words of caution 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:17:18 -0000 ------=_NextPart_000_0018_01CDADE1.E7C24D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Michael: Yes, in one way, I did misunderstood Harald's scenarios. The key point that I have been pointing out that we have not got any mathematical models to quantify the situations of congestions for multimedia traffic with competing goals of bandwidth and performance requirements over UDP transport. In absence of the above, we are trying something that is based on some heuristic things hoping to work. Well, I am not against this approach. All I am trying to point to the long-term approach in addressing the traffic congestions problems. BR/Radhika -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Michael Welzl Sent: Friday, October 19, 2012 3:52 AM To: Mirja Kuehlewind Cc: rmcat@ietf.org; Harald Alvestrand Subject: Re: [rmcat] Multihop congestion control - two words of caution ... Radhika: your answer appears (to me) to miss the point, and maybe (sorry if I'm wrong!) it's because you misunderstood the scenario? So maybe my answer to Mirja below helps. ... I hope my interpretation of Harald's scenario is correct, and I hope that this was helpful! Cheers, Michael ------=_NextPart_000_0018_01CDADE1.E7C24D90 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjEwMTkxNDEwMDNaMCMGCSqGSIb3DQEJBDEWBBTP3edEPXu9t+QfZnlgLco6 W6ra0zBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAGVVRQNcuZd/EliHqc/ZFrEJySerkN0wSVoDgXQbMQPZU1cQDgODWB04EqHAYm1ANusb VkO9gmLvLvGZwrP91SoryOReSbRVmToqtejjvp3HCfcNb+NGJ3+ck9jxh8nw9CAEeGjm+DCOcLcy BJw5dcpBV0HeixgK9HRMe4Ezk0QVqb2g2nzXQIS2lYJp90/Ub8+M7shHm5m5DwHdWDP3gVcqBxqW Y1xQDzDhynctrRMCKFzUgEzMKUzoWeW2EC/lYFcgBGFowG12w09egD7mDvbMA9WAqkfmzmOd2Rje x++jWLZc5pFDm96kWmSwKupk5yeKbLX5V8wWI84fM54XkVEAAAAAAAA= ------=_NextPart_000_0018_01CDADE1.E7C24D90-- From randell-ietf@jesup.org Fri Oct 19 09:19:03 2012 Return-Path: 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 9F8A321F8779 for ; Fri, 19 Oct 2012 09:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YueM8NRuJO7i for ; Fri, 19 Oct 2012 09:19:02 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7C43A21F8727 for ; Fri, 19 Oct 2012 09:19:02 -0700 (PDT) Received: from pool-173-49-129-2.phlapa.fios.verizon.net ([173.49.129.2]:3471 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TPFHf-000H0y-Lp for rmcat@ietf.org; Fri, 19 Oct 2012 11:18:53 -0500 Message-ID: <50817CF4.9060004@jesup.org> Date: Fri, 19 Oct 2012 12:16:52 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rmcat@ietf.org References: <507F4F91.6040409@mozilla.com> <507F740D.6050409@mti-systems.com> <3354E46F-7215-443A-A36C-959EFFAF54ED@ifi.uio.no> <5080DCAA.4080100@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:19:04 -0000 On 10/19/2012 3:56 AM, Michael Welzl wrote: > > On 19. okt. 2012, at 06:52, Randell Jesup wrote: > >> On 10/18/2012 3:45 AM, Michael Welzl wrote: >>> >>>> The CC may say "you now have N kbps to work within" to each codec, and >>>> this will be based on what it estimates is safe for the network given >>>> the current ensemble of codecs and their stated operating envelopes, >>>> *not* on any explicit attempt by the CC to maximize user experience. >>> Agreed. Note, what you describe here is an "interaction between >>> applications and RTP flows", which is a quote from the charter, a >>> part of a milestone due in December... is anyone working on a draft >>> for this? >> >> I have made a proposal in the W3 bugzilla and on the list. There was >> a small amount of discussion; none since. I'd suggest starting from >> there. It may be worthwhile to re-examine the API in light of the >> stats proposals to avoid conflicting/overlapping data. > > I think I've asked you before, and I think you probably answered => so > I'm sorry for being too chaotic, but could you maybe give us that link > again? https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861 It was also discussed on the lists (rtcweb or public-webrtc more likely) -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Fri Oct 19 09:27:20 2012 Return-Path: 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 292D121F8741 for ; Fri, 19 Oct 2012 09:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_00=-2.599, MANGLED_TOOL=2.3, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci+Jgf9gYu0T for ; Fri, 19 Oct 2012 09:27:19 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A93E321F8731 for ; Fri, 19 Oct 2012 09:27:19 -0700 (PDT) Received: from pool-173-49-129-2.phlapa.fios.verizon.net ([173.49.129.2]:3524 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TPFPq-0007LP-Ty for rmcat@ietf.org; Fri, 19 Oct 2012 11:27:19 -0500 Message-ID: <50817EF0.1030401@jesup.org> Date: Fri, 19 Oct 2012 12:25:20 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rmcat WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: [rmcat] draft-jesup-rmcat-reqs-00 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:27:20 -0000 Just FYI, I'm still waiting for draft-jesup-rmcat-reqs-00 to be posted; if it doesn't get posted in time I'll update draft-jesup-rtp-congestion-reqs to -01 and put everything there. (My rmcat draft is a derivative of the rtp-congestion-reqs document.) Once -00 is posted I still plan to revise it before the deadline. -- Randell Jesup randell-ietf@jesup.org From michawe@ifi.uio.no Fri Oct 19 13:24:09 2012 Return-Path: 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 59A3221F8462 for ; Fri, 19 Oct 2012 13:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRMmLylg1sg3 for ; Fri, 19 Oct 2012 13:24:08 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 83E6121F8203 for ; Fri, 19 Oct 2012 13:24:08 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TPJ6f-0007dU-GQ; Fri, 19 Oct 2012 22:23:45 +0200 Received: from 108.134.189.109.customer.cdi.no ([109.189.134.108] helo=[192.168.0.197]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TPJ6f-0002cd-0j; Fri, 19 Oct 2012 22:23:45 +0200 Message-Id: From: Michael Welzl To: Randell Jesup In-Reply-To: <50817CF4.9060004@jesup.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Oct 2012 22:23:22 +0200 References: <507F4F91.6040409@mozilla.com> <507F740D.6050409@mti-systems.com> <3354E46F-7215-443A-A36C-959EFFAF54ED@ifi.uio.no> <5080DCAA.4080100@jesup.org> <50817CF4.9060004@jesup.org> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 3 sum rcpts/h 5 sum msgs/h 3 total rcpts 24797 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8BFD5D983B7A1F8A95B1BF07F02964B315D00401 X-UiO-SPAM-Test: remote_host: 109.189.134.108 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1541 max/h 15 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat@ietf.org Subject: Re: [rmcat] Video Quality for RMCAT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 20:24:09 -0000 On Oct 19, 2012, at 6:16 PM, Randell Jesup wrote: > On 10/19/2012 3:56 AM, Michael Welzl wrote: >> >> On 19. okt. 2012, at 06:52, Randell Jesup wrote: >> >>> On 10/18/2012 3:45 AM, Michael Welzl wrote: >>>> >>>>> The CC may say "you now have N kbps to work within" to each >>>>> codec, and >>>>> this will be based on what it estimates is safe for the network >>>>> given >>>>> the current ensemble of codecs and their stated operating >>>>> envelopes, >>>>> *not* on any explicit attempt by the CC to maximize user >>>>> experience. >>>> Agreed. Note, what you describe here is an "interaction between >>>> applications and RTP flows", which is a quote from the charter, a >>>> part of a milestone due in December... is anyone working on a >>>> draft for this? >>> >>> I have made a proposal in the W3 bugzilla and on the list. There >>> was a small amount of discussion; none since. I'd suggest >>> starting from there. It may be worthwhile to re-examine the API >>> in light of the stats proposals to avoid conflicting/overlapping >>> data. >> >> I think I've asked you before, and I think you probably answered => >> so I'm sorry for being too chaotic, but could you maybe give us >> that link again? > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861 > > It was also discussed on the lists (rtcweb or public-webrtc more > likely) Thanks!! And: well, I took a look - that seems really unrelated to the type of communication needed between a congestion controller and a codec?? Cheers, Michael From lars@netapp.com Mon Oct 22 05:50:59 2012 Return-Path: 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 78B5321F8842 for ; Mon, 22 Oct 2012 05:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIbdw4xS2VRa for ; Mon, 22 Oct 2012 05:50:58 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9019221F87B2 for ; Mon, 22 Oct 2012 05:50:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,629,1344236400"; d="p7s'?scan'208";a="276596742" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 22 Oct 2012 05:50:53 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q9MCoqNj012566; Mon, 22 Oct 2012 05:50:52 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.216]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 05:50:52 -0700 From: "Eggert, Lars" To: Varun Singh Thread-Topic: [rmcat] New Version Notification for draft-singh-rmcat-cc-eval-00.txt Thread-Index: AQHNsFPdP6NINO5KW0G21P1S5ctAgQ== Date: Mon, 22 Oct 2012 12:50:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/signed; boundary="Apple-Mail=_3B7C7EEA-86EB-4B60-99E4-A312390BCBB0"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: rmcat WG Subject: Re: [rmcat] New Version Notification for draft-singh-rmcat-cc-eval-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:50:59 -0000 --Apple-Mail=_3B7C7EEA-86EB-4B60-99E4-A312390BCBB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, you may also want to take a look at the following paper, which attempted = to define some community-agreed evaluation scenarios for proposed TCP = extensions. Maybe there are some aspects in there that are applicable to = your draft. Towards a Common TCP Evaluation Suite. Lachlan Andrew, Cesar Marcondes, = Sally Floyd, Lawrence Dunn, Wang Gang, Lars Eggert, Sangtae Ha and = Injong Rhee. Proc. International Workshop on Protocols for Fast = Long-Distance Networks (PFLDnet),Manchester, UK, March 5-7, 2008. = http://eggert.org/papers/2008-pfldnet.pdf Lars= --Apple-Mail=_3B7C7EEA-86EB-4B60-99E4-A312390BCBB0 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAyMjEyNTA1OFowIwYJKoZIhvcNAQkEMRYEFLWQ VcvrmgCHa2IT5Nt7cFhpQRqeMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAHa4IEsf uEJkJTUuLCyNJ94BZ5LkWk7ZRbaCNJqzWNlU2bVNnm4x+xs6yPKvqXlWNj1GK+taUlsEXQpaAquQ 6pDQAnavv4JVWo9nmM66JJ0HB3ZbYoBHmq1yGZhRpqCqs9BtqdAiXymN9RJ9gkTSLvpCVgkf1Ds7 q7KgbvlQEi7zE06f+cseFnXG32Q7ng6BjOZJavuBnsu/xRvLLeK+w12UoyRP7PhsBrpAg6WgDhdI OULXQWOd/JKEJr4AGJ06xYzSHHH3cmqoeSKpU0/oLny1QA6aW89f31502cdtPChWOaL32HSRA8pt cxro5ht1UwNYceWC3O7O9sXduKk4lB8AAAAAAAA= --Apple-Mail=_3B7C7EEA-86EB-4B60-99E4-A312390BCBB0-- From harald@alvestrand.no Mon Oct 22 05:52:36 2012 Return-Path: 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 B6D9821F898B for ; Mon, 22 Oct 2012 05:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.437 X-Spam-Level: X-Spam-Status: No, score=-110.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ5Vb+9Hvan1 for ; Mon, 22 Oct 2012 05:52:35 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6B89A21F88AF for ; Mon, 22 Oct 2012 05:52:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 906AC39E199 for ; Mon, 22 Oct 2012 14:52:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw2SPseMWPZl for ; Mon, 22 Oct 2012 14:52:31 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A4A6339E130 for ; Mon, 22 Oct 2012 14:52:31 +0200 (CEST) Message-ID: <5085418D.3090504@alvestrand.no> Date: Mon, 22 Oct 2012 14:52:29 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rmcat@ietf.org References: <20121022124403.4530.29921.idtracker@ietfa.amsl.com> In-Reply-To: <20121022124403.4530.29921.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121022124403.4530.29921.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000508010305000202010704" Subject: [rmcat] Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-03.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:52:36 -0000 This is a multi-part message in MIME format. --------------000508010305000202010704 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit There isn't much change to this document, but some new discussion on combining information across multiple streams. Given the time with respect to the draft deadline, I didn't change the name. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-03.txt Date: Mon, 22 Oct 2012 05:44:03 -0700 From: internet-drafts@ietf.org To: harald@alvestrand.no CC: holmer@google.com A new version of I-D, draft-alvestrand-rtcweb-congestion-03.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-congestion Revision: 03 Title: A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-alvestrand-rtcweb-congestion-03.txt Status: http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-congestion Htmlized: http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-alvestrand-rtcweb-congestion-03 Abstract: This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published as an input document to the RMCAT working group on congestion control for media streams. The mailing list of that WG is rmcat@ietf.org. The IETF Secretariat --------------000508010305000202010704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit There isn't much change to this document, but some new discussion on combining information across multiple streams.

Given the time with respect to the draft deadline, I didn't change the name.

                Harald


-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-03.txt
Date: Mon, 22 Oct 2012 05:44:03 -0700
From: internet-drafts@ietf.org
To: harald@alvestrand.no
CC: holmer@google.com 


A new version of I-D, draft-alvestrand-rtcweb-congestion-03.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Filename:	 draft-alvestrand-rtcweb-congestion
Revision:	 03
Title:		 A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web
Creation date:	 2012-10-22
WG ID:		 Individual Submission
Number of pages: 18
URL:             http://www.ietf.org/internet-drafts/draft-alvestrand-rtcweb-congestion-03.txt
Status:          http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-congestion
Htmlized:        http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-alvestrand-rtcweb-congestion-03

Abstract:
   This document describes two methods of congestion control when using
   real-time communications on the World Wide Web (RTCWEB); one sender-
   based and one receiver-based.

   It is published as an input document to the RMCAT working group on
   congestion control for media streams.  The mailing list of that WG is
   rmcat@ietf.org.


                                                                                  


The IETF Secretariat



--------------000508010305000202010704-- From mzanaty@cisco.com Mon Oct 22 11:55:44 2012 Return-Path: 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 2990421F8880 for ; Mon, 22 Oct 2012 11:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBz1C2fi8piv for ; Mon, 22 Oct 2012 11:55:42 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D4E0A21F8788 for ; Mon, 22 Oct 2012 11:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5035; q=dns/txt; s=iport; t=1350932141; x=1352141741; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9YtzdysGBfEGAVS6Z3ohu+f186fhO7noGNQirplqcTI=; b=LKhExv5IYXwk3XbNjbZzMTVmcCBIGK3YK+as8No8w0JjM0daJS69KIaE mq4y5rWBiLHcOsb2t91xQTKhaSPO66pmd4CuVPvRuJkjKrN55D2ZGP58d cqVZYO1z4NpvSmSBu62zrGvdMuHwYk5s4vF34JpeYCV3VRdgKqhjrINEA M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHiVhVCtJV2b/2dsb2JhbABFwSuBCIIgAQEBAwESATYiCQUFBwQCAQgOAwQBAQsdBzIUCQgCBAENBQgTB4dcBpwIoAOLX4YPYAOIJZwagWuCb4FjFx4 X-IronPort-AV: E=Sophos;i="4.80,631,1344211200"; d="scan'208";a="134200101" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 22 Oct 2012 18:55:40 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9MItdPu010011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 18:55:40 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 13:55:33 -0500 From: "Mo Zanaty (mzanaty)" To: Michael Welzl , Mirja Kuehlewind Thread-Topic: [rmcat] Multihop congestion control - two words of caution Thread-Index: AQHNrc6g8hTOgvtDsECFE4apZyioD5fAtcEw Date: Mon, 22 Oct 2012 18:55:33 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F5BCDA5@xmb-rcd-x14.cisco.com> References: <50800364.1070908@alvestrand.no> <201210181758.44757.mirja.kuehlewind@ikr.uni-stuttgart.de> <0AC4ED0D-88AB-466F-B4EA-EC75A5EC53FB@ifi.uio.no> In-Reply-To: <0AC4ED0D-88AB-466F-B4EA-EC75A5EC53FB@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.28.46] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--55.876600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rmcat@ietf.org" , Harald Alvestrand Subject: Re: [rmcat] Multihop congestion control - two words of caution 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:55:44 -0000 Do we consider a TURN server or other UDP relay to be multi-hop? By relay, = I mean something which never alters or processes the RTP/RTCP at all. It is= certainly another hop from the network and congestion perspectives, but no= t the RTP perspective. The multi-hop case is certainly more complex, but complexity alone should n= ot determine whether we tackle it or not. The importance of the problem and= the need for a solution should be considered along with complexity. I susp= ect many major deployments of RMCAT will have multi-hop cases, and they may= perhaps even be the dominant use cases. If we punt based on complexity, th= ere will likely be wildly different behavior across these cases. (Even wild= er than double pendulums...) Mo -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of M= ichael Welzl Sent: Friday, October 19, 2012 3:52 AM To: Mirja Kuehlewind Cc: rmcat@ietf.org; Harald Alvestrand Subject: Re: [rmcat] Multihop congestion control - two words of caution Hi all, I feel in a bit of a dilemma answering Harald's email, because this require= s that I call myself an "expert"... yet I'm tempted to answer... tsk! :-)= Anyway, I'll try to reply the emails from Harald, Radhika and Mirja in= one go here, in the hope that I can clarify things a little: Harald: all of what you have written sounds 100% reasonable to me. Radhika: your answer appears (to me) to miss the point, and maybe (sorry if= I'm wrong!) it's because you misunderstood the scenario? So maybe my answe= r to Mirja below helps. Mirja: RTP/RTCP can let end systems take the role of an intermediate node, = to take care of data stream specific things before traffic reaches the rece= iver (synchronizing, mixing, ...). Essentially, this is an overlay network.= I think Harald refers to such a case with multiple RTP end systems, i.e. a= path like this: Node1 [ RTP1 sender ] =3D> Node 2 [RTP1 receiver + RTP2 sender] =3D> Node 3= [RTP2 receiver] ...and his description of problems goes into the behavior of node 2 (which = is, in principle, quite similar to the behavior of some PEPs (RFC3135), I g= uess, e.g. TCP splitters. The decision at the BOF was not *yet* to define w= hat is needed to make Node 2 work correctly, which is what we referred to a= s multi-hop congestion control. The exact phrasing in the charter is: "impl= ications on multi-hop connections will be considered at a later stage". The= reason for writing this is that Magnus Westerlund (quite correctly, I thin= k) stated that defining this will at some point be needed. I hope my interpretation of Harald's scenario is correct, and I hope that t= his was helpful! Cheers, Michael On 18. okt. 2012, at 17:58, Mirja Kuehlewind wrote: > Hi Harald, >=20 > i believe do not understand your scenario: >=20 >> Now consider what happens if we have two hops after each other, possibly >> with different delays, each running their own congestion control >> algorithm - and a linkage that tries to feed congestion control >> information from the second hop back to the congestion control algorithm >> running on the first hop. >=20 > Are we talking of end-to-end congestion control here? Then if we have=20 > congestion feedback from different nodes on one path, this feedback signa= l=20 > will have the same delay. And usually there is only one bottleneck at one= =20 > point of time as there is always on link with the smallest available=20 > bandwidth. Is this the scenario your are talking about or something else? >=20 > Mirja >=20 >=20 >=20 >>=20 >> The overall system will have a delay - but that delay won't be visible >> to the congestion control algorithm on the first hop, so the reaction >> time and size can't be scaled appropriately. >>=20 >> The result is that the overall system is very likely to exhibit >> oscillatory behaviour - simply because the time constants we need to >> observe for a proper design are invisible to the observer. >>=20 >> We can imagine ways of working around this limitation - but for the >> purposes of RMCAT, I think we should just stick with two principles: >>=20 >> - We don't design for the two-hop case. >> - We advise designers of two-hop systems (like relay nodes) that if they >> want to feed capacity information from a second hop back to the first >> hop, they should reflect those changes SLOWLY. >>=20 >> Experts, did this sound reasonable? >>=20 >> Harald >=20 >=20 >=20 > --=20 > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- From p.ohanlon@gmail.com Mon Oct 22 14:14:06 2012 Return-Path: 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 6A2E621F84C2 for ; Mon, 22 Oct 2012 14:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9DST+J+upNK for ; Mon, 22 Oct 2012 14:14:06 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5101C21F84BC for ; Mon, 22 Oct 2012 14:14:05 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2201286lam.31 for ; Mon, 22 Oct 2012 14:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=du2l77KZ43CtwKMySkIN8if+9ClpXGOvqktex0MbljY=; b=HHp9nBof5/rgGb5PQPLqxswt0Glzdv7qBpadDk2/6XQR1Bx2LqG9m8DAr+ovHQdiI+ GcPicUKvZ2OY3qJA3liaVe7Uxn2jKixk1YN/2IsPdIEvLsdP81bkS2e6PLfGTchw0xoQ SKxGBCqZkJIj2sH9IXMfD6s934yF8W/VDYZ38LGzo+QGpObTkESlJyWRnk7xBfCb1Rv8 qS+7T1uAzFrbVGs8XL2Ht5V6haCL8+/WdGBQPEcHiB7kP4HOqCyVrXUQMYDc1mjLK5IW zn8CMgF4wT0ET+ehpe7iZTYu+dlnUskKVwsfsTtckoJOr0i/ybjWD/qwx/ACt72at0bG WBfg== Received: by 10.152.47.79 with SMTP id b15mr9324114lan.57.1350940444226; Mon, 22 Oct 2012 14:14:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.89.73 with HTTP; Mon, 22 Oct 2012 14:13:44 -0700 (PDT) In-Reply-To: References: <20121022205349.31314.4287.idtracker@ietfa.amsl.com> From: "Piers O'Hanlon" Date: Mon, 22 Oct 2012 22:13:44 +0100 Message-ID: To: rmcat@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rmcat] Fwd: New Version Notification for draft-ohanlon-rmcat-dflow-01.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 21:14:06 -0000 Here's an updated version of the draft on our DFlow congestion control scheme. It is still under development and testing so comments welcome. Cheers, Piers. Begin forwarded message: From: Subject: New Version Notification for draft-ohanlon-rmcat-dflow-01.txt Date: 22 October 2012 21:53:49 GMT+01:00 To: Cc: A new version of I-D, draft-ohanlon-rmcat-dflow-01.txt has been successfully submitted by Piers O'Hanlon and posted to the IETF repository. Filename: draft-ohanlon-rmcat-dflow Revision: 01 Title: Congestion control algorithm for lower latency and lower loss media transport Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-ohanlon-rmcat-dflow-01.txt Status: http://datatracker.ietf.org/doc/draft-ohanlon-rmcat-dflow Htmlized: http://tools.ietf.org/html/draft-ohanlon-rmcat-dflow-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ohanlon-rmcat-dflow-01 Abstract: This memo provides an initial design for a congestion control algorithm, for media transport, which aims to provide for lower delay and lower loss communications. The IETF Secretariat From harald@alvestrand.no Tue Oct 23 04:16:35 2012 Return-Path: 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 2EB1B21F86DE for ; Tue, 23 Oct 2012 04:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.437 X-Spam-Level: X-Spam-Status: No, score=-110.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id is2FMbOJpNUe for ; Tue, 23 Oct 2012 04:16:33 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99521F86DD for ; Tue, 23 Oct 2012 04:16:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4D8A439E129; Tue, 23 Oct 2012 13:16:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5nWbE8QW25D; Tue, 23 Oct 2012 13:16:30 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3F4F839E07C; Tue, 23 Oct 2012 13:16:30 +0200 (CEST) Message-ID: <50867C8D.5090104@alvestrand.no> Date: Tue, 23 Oct 2012 13:16:29 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" References: <50800364.1070908@alvestrand.no> <201210181758.44757.mirja.kuehlewind@ikr.uni-stuttgart.de> <0AC4ED0D-88AB-466F-B4EA-EC75A5EC53FB@ifi.uio.no> <3879D71E758A7E4AA99A35DD8D41D3D90F5BCDA5@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F5BCDA5@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rmcat@ietf.org" , Mirja Kuehlewind , Michael Welzl Subject: Re: [rmcat] Multihop congestion control - two words of caution 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:16:35 -0000 On 10/22/2012 08:55 PM, Mo Zanaty (mzanaty) wrote: > Do we consider a TURN server or other UDP relay to be multi-hop? By relay, I mean something which never alters or processes the RTP/RTCP at all. It is certainly another hop from the network and congestion perspectives, but not the RTP perspective. > > The multi-hop case is certainly more complex, but complexity alone should not determine whether we tackle it or not. The importance of the problem and the need for a solution should be considered along with complexity. I suspect many major deployments of RMCAT will have multi-hop cases, and they may perhaps even be the dominant use cases. If we punt based on complexity, there will likely be wildly different behavior across these cases. (Even wilder than double pendulums...) I don't think of a link via a TURN server as multihop; the TURN server should have the same characteristics as a switch or router in the path (lose packets if congested, but don't attempt to shape the stream). I'd like to see guidelines (such as "go slower than X when you're a destination changing the desirable bandwidth based on something other than source/destination congestion") that avoid the double-pendulum style chaotic behaviour. I don't want to start off trying to write a controller for efficient management of double pendulums. > > Mo > > -----Original Message----- > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Michael Welzl > Sent: Friday, October 19, 2012 3:52 AM > To: Mirja Kuehlewind > Cc: rmcat@ietf.org; Harald Alvestrand > Subject: Re: [rmcat] Multihop congestion control - two words of caution > > Hi all, > > I feel in a bit of a dilemma answering Harald's email, because this requires that I call myself an "expert"... yet I'm tempted to answer... tsk! :-) Anyway, I'll try to reply the emails from Harald, Radhika and Mirja in one go here, in the hope that I can clarify things a little: > > Harald: all of what you have written sounds 100% reasonable to me. > > Radhika: your answer appears (to me) to miss the point, and maybe (sorry if I'm wrong!) it's because you misunderstood the scenario? So maybe my answer to Mirja below helps. > > Mirja: RTP/RTCP can let end systems take the role of an intermediate node, to take care of data stream specific things before traffic reaches the receiver (synchronizing, mixing, ...). Essentially, this is an overlay network. I think Harald refers to such a case with multiple RTP end systems, i.e. a path like this: > > Node1 [ RTP1 sender ] => Node 2 [RTP1 receiver + RTP2 sender] => Node 3 [RTP2 receiver] > > ...and his description of problems goes into the behavior of node 2 (which is, in principle, quite similar to the behavior of some PEPs (RFC3135), I guess, e.g. TCP splitters. The decision at the BOF was not *yet* to define what is needed to make Node 2 work correctly, which is what we referred to as multi-hop congestion control. The exact phrasing in the charter is: "implications on multi-hop connections will be considered at a later stage". The reason for writing this is that Magnus Westerlund (quite correctly, I think) stated that defining this will at some point be needed. > > I hope my interpretation of Harald's scenario is correct, and I hope that this was helpful! > > Cheers, > Michael > > > On 18. okt. 2012, at 17:58, Mirja Kuehlewind wrote: > >> Hi Harald, >> >> i believe do not understand your scenario: >> >>> Now consider what happens if we have two hops after each other, possibly >>> with different delays, each running their own congestion control >>> algorithm - and a linkage that tries to feed congestion control >>> information from the second hop back to the congestion control algorithm >>> running on the first hop. >> Are we talking of end-to-end congestion control here? Then if we have >> congestion feedback from different nodes on one path, this feedback signal >> will have the same delay. And usually there is only one bottleneck at one >> point of time as there is always on link with the smallest available >> bandwidth. Is this the scenario your are talking about or something else? >> >> Mirja >> >> >> >>> The overall system will have a delay - but that delay won't be visible >>> to the congestion control algorithm on the first hop, so the reaction >>> time and size can't be scaled appropriately. >>> >>> The result is that the overall system is very likely to exhibit >>> oscillatory behaviour - simply because the time constants we need to >>> observe for a proper design are invisible to the observer. >>> >>> We can imagine ways of working around this limitation - but for the >>> purposes of RMCAT, I think we should just stick with two principles: >>> >>> - We don't design for the two-hop case. >>> - We advise designers of two-hop systems (like relay nodes) that if they >>> want to feed capacity information from a second hop back to the first >>> hop, they should reflect those changes SLOWLY. >>> >>> Experts, did this sound reasonable? >>> >>> Harald >> >> >> -- >> ------------------------------------------------------------------- >> Dipl.-Ing. Mirja Kühlewind >> Institute of Communication Networks and Computer Engineering (IKR) >> University of Stuttgart, Germany >> Pfaffenwaldring 47, D-70569 Stuttgart >> >> tel: +49(0)711/685-67973 >> email: mirja.kuehlewind@ikr.uni-stuttgart.de >> web: www.ikr.uni-stuttgart.de >> ------------------------------------------------------------------- From michawe@ifi.uio.no Tue Oct 23 04:23:41 2012 Return-Path: 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 38E2E21F85D5 for ; Tue, 23 Oct 2012 04:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6mn+2wkHOVd for ; Tue, 23 Oct 2012 04:23:40 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id A821721F85EA for ; Tue, 23 Oct 2012 04:23:38 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TQca4-0000vb-5p; Tue, 23 Oct 2012 13:23:32 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TQca3-0005l7-NB; Tue, 23 Oct 2012 13:23:32 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: <50867C8D.5090104@alvestrand.no> Date: Tue, 23 Oct 2012 13:23:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <12AA5DA3-E4B6-4B34-95AC-1C6CC983CF54@ifi.uio.no> References: <50800364.1070908@alvestrand.no> <201210181758.44757.mirja.kuehlewind@ikr.uni-stuttgart.de> <0AC4ED0D-88AB-466F-B4EA-EC75A5EC53FB@ifi.uio.no> <3879D71E758A7E4AA99A35DD8D41D3D90F5BCDA5@xmb-rcd-x14.cisco.com> <50867C8D.5090104@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 13 sum msgs/h 6 total rcpts 24937 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.912, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B9B515A59157C8ADC6E6FE237A28A80D0C5D030D X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 10067 max/h 21 blacklist 0 greylist 0 ratelimit 0 Cc: "rmcat@ietf.org" , Mirja Kuehlewind , "Mo Zanaty \(mzanaty\)" Subject: Re: [rmcat] Multihop congestion control - two words of caution 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:23:41 -0000 On 23. okt. 2012, at 13:16, Harald Alvestrand wrote: > On 10/22/2012 08:55 PM, Mo Zanaty (mzanaty) wrote: >> Do we consider a TURN server or other UDP relay to be multi-hop? By = relay, I mean something which never alters or processes the RTP/RTCP at = all. It is certainly another hop from the network and congestion = perspectives, but not the RTP perspective. >>=20 >> The multi-hop case is certainly more complex, but complexity alone = should not determine whether we tackle it or not. The importance of the = problem and the need for a solution should be considered along with = complexity. I suspect many major deployments of RMCAT will have = multi-hop cases, and they may perhaps even be the dominant use cases. If = we punt based on complexity, there will likely be wildly different = behavior across these cases. (Even wilder than double pendulums...) >=20 > I don't think of a link via a TURN server as multihop; the TURN server = should have the same characteristics as a switch or router in the path = (lose packets if congested, but don't attempt to shape the stream). >=20 > I'd like to see guidelines (such as "go slower than X when you're a = destination changing the desirable bandwidth based on something other = than source/destination congestion") that avoid the double-pendulum = style chaotic behaviour. I don't want to start off trying to write a = controller for efficient management of double pendulums. Things don't have to get THAT bad... after all, TCP splitters do pretty = much the same job that an intermediate hop in our setup would be doing, = probably without getting into the fun of a double pendulum. Now, that's = always easy to say, with little proof out there... but we could dig = through the early literature on PEPs, I suppose, for a start... Cheers, Michael From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Oct 23 04:51:35 2012 Return-Path: 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 D03F121F86CE for ; Tue, 23 Oct 2012 04:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUf2724SDLUj for ; Tue, 23 Oct 2012 04:51:35 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id C32A921F855A for ; Tue, 23 Oct 2012 04:51:34 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id C0F11633B1; Tue, 23 Oct 2012 13:51:32 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 8E6F259A8A; Tue, 23 Oct 2012 13:51:32 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Michael Welzl Date: Tue, 23 Oct 2012 13:51:31 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <50800364.1070908@alvestrand.no> <201210181758.44757.mirja.kuehlewind@ikr.uni-stuttgart.de> <0AC4ED0D-88AB-466F-B4EA-EC75A5EC53FB@ifi.uio.no> In-Reply-To: <0AC4ED0D-88AB-466F-B4EA-EC75A5EC53FB@ifi.uio.no> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201210231351.31984.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: rmcat@ietf.org, Harald Alvestrand Subject: Re: [rmcat] Multihop congestion control - two words of caution 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:51:35 -0000 Hi Micheal, thanks for the explanation. I believe I understood the scenario now but I'm= =20 still not sure about the problem. In TCP you have separate congestion contr= ol=20 on each hop. If the second hop is slower than the first one, you also have= =20 flow control to not overload the receiver (by announcing a certain receive= =20 window). Is there a benefit in having a common congestion control over both= =20 hops? Mirja On Friday 19 October 2012 09:52:03 Michael Welzl wrote: > Hi all, > > I feel in a bit of a dilemma answering Harald's email, because this > requires that I call myself an "expert"... yet I'm tempted to answer... > tsk! :-) Anyway, I'll try to reply the emails from Harald, Radhika > and Mirja in one go here, in the hope that I can clarify things a little: > > Harald: all of what you have written sounds 100% reasonable to me. > > Radhika: your answer appears (to me) to miss the point, and maybe (sorry = if > I'm wrong!) it's because you misunderstood the scenario? So maybe my answ= er > to Mirja below helps. > > Mirja: RTP/RTCP can let end systems take the role of an intermediate node, > to take care of data stream specific things before traffic reaches the > receiver (synchronizing, mixing, ...). Essentially, this is an overlay > network. I think Harald refers to such a case with multiple RTP end > systems, i.e. a path like this: > > Node1 [ RTP1 sender ] =3D> Node 2 [RTP1 receiver + RTP2 sender] =3D> Node= 3 > [RTP2 receiver] > > ...and his description of problems goes into the behavior of node 2 (which > is, in principle, quite similar to the behavior of some PEPs (RFC3135), I > guess, e.g. TCP splitters. The decision at the BOF was not *yet* to define > what is needed to make Node 2 work correctly, which is what we referred to > as multi-hop congestion control. The exact phrasing in the charter is: > "implications on multi-hop connections will be considered at a later > stage". The reason for writing this is that Magnus Westerlund (quite > correctly, I think) stated that defining this will at some point be neede= d. > > I hope my interpretation of Harald's scenario is correct, and I hope that > this was helpful! > > Cheers, > Michael > > On 18. okt. 2012, at 17:58, Mirja Kuehlewind wrote: > > Hi Harald, > > > > i believe do not understand your scenario: > >> Now consider what happens if we have two hops after each other, possib= ly > >> with different delays, each running their own congestion control > >> algorithm - and a linkage that tries to feed congestion control > >> information from the second hop back to the congestion control algorit= hm > >> running on the first hop. > > > > Are we talking of end-to-end congestion control here? Then if we have > > congestion feedback from different nodes on one path, this feedback > > signal will have the same delay. And usually there is only one bottlene= ck > > at one point of time as there is always on link with the smallest > > available bandwidth. Is this the scenario your are talking about or > > something else? > > > > Mirja > > > >> The overall system will have a delay - but that delay won't be visible > >> to the congestion control algorithm on the first hop, so the reaction > >> time and size can't be scaled appropriately. > >> > >> The result is that the overall system is very likely to exhibit > >> oscillatory behaviour - simply because the time constants we need to > >> observe for a proper design are invisible to the observer. > >> > >> We can imagine ways of working around this limitation - but for the > >> purposes of RMCAT, I think we should just stick with two principles: > >> > >> - We don't design for the two-hop case. > >> - We advise designers of two-hop systems (like relay nodes) that if th= ey > >> want to feed capacity information from a second hop back to the first > >> hop, they should reflect those changes SLOWLY. > >> > >> Experts, did this sound reasonable? > >> > >> Harald > > > > -- > > ------------------------------------------------------------------- > > Dipl.-Ing. Mirja K=FChlewind > > Institute of Communication Networks and Computer Engineering (IKR) > > University of Stuttgart, Germany > > Pfaffenwaldring 47, D-70569 Stuttgart > > > > tel: +49(0)711/685-67973 > > email: mirja.kuehlewind@ikr.uni-stuttgart.de > > web: www.ikr.uni-stuttgart.de > > ------------------------------------------------------------------- =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From michawe@ifi.uio.no Tue Oct 23 05:22:53 2012 Return-Path: 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 032FE21F86C0 for ; Tue, 23 Oct 2012 05:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0C7hwoje2pOl for ; Tue, 23 Oct 2012 05:22:52 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id EA01B21F86BD for ; Tue, 23 Oct 2012 05:22:50 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TQdVR-0001Nc-G9; Tue, 23 Oct 2012 14:22:49 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TQdVQ-00079Z-VT; Tue, 23 Oct 2012 14:22:49 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: <201210231351.31984.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Tue, 23 Oct 2012 14:22:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <39D99E58-D635-4360-BB91-B33FEEA6AD7A@ifi.uio.no> References: <50800364.1070908@alvestrand.no> <201210181758.44757.mirja.kuehlewind@ikr.uni-stuttgart.de> <0AC4ED0D-88AB-466F-B4EA-EC75A5EC53FB@ifi.uio.no> <201210231351.31984.mirja.kuehlewind@ikr.uni-stuttgart.de> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 14 sum msgs/h 6 total rcpts 24947 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.912, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E125385F3DE70E27E9877A31259F47CA648371B0 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 10073 max/h 21 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat@ietf.org, Harald Alvestrand Subject: Re: [rmcat] Multihop congestion control - two words of caution 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 12:22:53 -0000 Hi, On 23. okt. 2012, at 13:51, Mirja Kuehlewind wrote: > Hi Micheal, >=20 > thanks for the explanation. I believe I understood the scenario now = but I'm=20 > still not sure about the problem. In TCP you have separate congestion = control=20 > on each hop. If the second hop is slower than the first one, you also = have=20 > flow control to not overload the receiver (by announcing a certain = receive=20 Right; > window). Is there a benefit in having a common congestion control over = both=20 > hops? I really don't know. Maybe? Not sure if someone suggested that? Anyway, all I was trying to explain is that this is the scenario that, = according to the charter, we're not looking at (and we keep it for the = future). This being said, personally, I'm interested in it and don't have a = problem with discussions :) I just wanted to explain/clarify. Cheers, Michael >=20 > Mirja >=20 >=20 > On Friday 19 October 2012 09:52:03 Michael Welzl wrote: >> Hi all, >>=20 >> I feel in a bit of a dilemma answering Harald's email, because this >> requires that I call myself an "expert"... yet I'm tempted to = answer... >> tsk! :-) Anyway, I'll try to reply the emails from Harald, = Radhika >> and Mirja in one go here, in the hope that I can clarify things a = little: >>=20 >> Harald: all of what you have written sounds 100% reasonable to me. >>=20 >> Radhika: your answer appears (to me) to miss the point, and maybe = (sorry if >> I'm wrong!) it's because you misunderstood the scenario? So maybe my = answer >> to Mirja below helps. >>=20 >> Mirja: RTP/RTCP can let end systems take the role of an intermediate = node, >> to take care of data stream specific things before traffic reaches = the >> receiver (synchronizing, mixing, ...). Essentially, this is an = overlay >> network. I think Harald refers to such a case with multiple RTP end >> systems, i.e. a path like this: >>=20 >> Node1 [ RTP1 sender ] =3D> Node 2 [RTP1 receiver + RTP2 sender] =3D> = Node 3 >> [RTP2 receiver] >>=20 >> ...and his description of problems goes into the behavior of node 2 = (which >> is, in principle, quite similar to the behavior of some PEPs = (RFC3135), I >> guess, e.g. TCP splitters. The decision at the BOF was not *yet* to = define >> what is needed to make Node 2 work correctly, which is what we = referred to >> as multi-hop congestion control. The exact phrasing in the charter = is: >> "implications on multi-hop connections will be considered at a later >> stage". The reason for writing this is that Magnus Westerlund (quite >> correctly, I think) stated that defining this will at some point be = needed. >>=20 >> I hope my interpretation of Harald's scenario is correct, and I hope = that >> this was helpful! >>=20 >> Cheers, >> Michael >>=20 >> On 18. okt. 2012, at 17:58, Mirja Kuehlewind wrote: >>> Hi Harald, >>>=20 >>> i believe do not understand your scenario: >>>> Now consider what happens if we have two hops after each other, = possibly >>>> with different delays, each running their own congestion control >>>> algorithm - and a linkage that tries to feed congestion control >>>> information from the second hop back to the congestion control = algorithm >>>> running on the first hop. >>>=20 >>> Are we talking of end-to-end congestion control here? Then if we = have >>> congestion feedback from different nodes on one path, this feedback >>> signal will have the same delay. And usually there is only one = bottleneck >>> at one point of time as there is always on link with the smallest >>> available bandwidth. Is this the scenario your are talking about or >>> something else? >>>=20 >>> Mirja >>>=20 >>>> The overall system will have a delay - but that delay won't be = visible >>>> to the congestion control algorithm on the first hop, so the = reaction >>>> time and size can't be scaled appropriately. >>>>=20 >>>> The result is that the overall system is very likely to exhibit >>>> oscillatory behaviour - simply because the time constants we need = to >>>> observe for a proper design are invisible to the observer. >>>>=20 >>>> We can imagine ways of working around this limitation - but for the >>>> purposes of RMCAT, I think we should just stick with two = principles: >>>>=20 >>>> - We don't design for the two-hop case. >>>> - We advise designers of two-hop systems (like relay nodes) that if = they >>>> want to feed capacity information from a second hop back to the = first >>>> hop, they should reflect those changes SLOWLY. >>>>=20 >>>> Experts, did this sound reasonable? >>>>=20 >>>> Harald >>>=20 >>> -- >>> ------------------------------------------------------------------- >>> Dipl.-Ing. Mirja K=FChlewind >>> Institute of Communication Networks and Computer Engineering (IKR) >>> University of Stuttgart, Germany >>> Pfaffenwaldring 47, D-70569 Stuttgart >>>=20 >>> tel: +49(0)711/685-67973 >>> email: mirja.kuehlewind@ikr.uni-stuttgart.de >>> web: www.ikr.uni-stuttgart.de >>> ------------------------------------------------------------------- >=20 >=20 >=20 > --=20 > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- From lars@netapp.com Wed Oct 24 06:27:30 2012 Return-Path: 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 CD37821F8B7D for ; Wed, 24 Oct 2012 06:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.398 X-Spam-Level: X-Spam-Status: No, score=-9.398 tagged_above=-999 required=5 tests=[AWL=-1.018, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-QIa7ayEWZT for ; Wed, 24 Oct 2012 06:27:27 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id D542921F88B4 for ; Wed, 24 Oct 2012 06:27:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,639,1344236400"; d="p7s'?scan'208";a="703564497" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 24 Oct 2012 06:27:27 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q9ODRQPx008721 for ; Wed, 24 Oct 2012 06:27:27 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.216]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 06:27:26 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: preliminary agenda online Thread-Index: AQHNsetO6L2K9MF2oEOzckfz5aZytw== Date: Wed, 24 Oct 2012 13:26:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_C780F01C-D76B-4E36-B8CC-30AEA31E84C9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [rmcat] preliminary agenda online 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 13:27:30 -0000 --Apple-Mail=_C780F01C-D76B-4E36-B8CC-30AEA31E84C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, a preliminary agenda for our Atlanta meeting is online at = http://www.ietf.org/proceedings/85/agenda/agenda-85-rmcat Send comments. Lars= --Apple-Mail=_C780F01C-D76B-4E36-B8CC-30AEA31E84C9 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAyNDEzMjcyNVowIwYJKoZIhvcNAQkEMRYEFKHH ide82vYwxOKpBcUxBZ+tyxhwMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAAEAlefn 9d/0Xneeuwc4TQM5Reei9Q+PdemIQTDl8pPqj+ZQepaHmMhhrOZ5okl2czDoODYBvy+5Jw94E9zH mKhpfdpNKXXvFyr3GD97RpEE7QbBKy0LO/7qlaTi8UZ0YPQ70wyuy3zdbo09s+VstMyPxSwdPbrv ZfnS4Fiq/chlvnCa4MejYS3PrI7jFPxP0yEEvV8qWm/0IEGIiokvA1zoO2+808QRDeVkrhGjVuJu mJ1HmNeIqp46LiBH+KiqE7rqX+0fbK82gYjn+ZTfi2AuLLr4MGZINULy/wEw7Z+BUnFueugsLlVd TeBpgCuLRTtdBokVlluLGz+NwJukY90AAAAAAAA= --Apple-Mail=_C780F01C-D76B-4E36-B8CC-30AEA31E84C9-- From michawe@ifi.uio.no Wed Oct 24 07:22:34 2012 Return-Path: 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 6EE5221F88F9 for ; Wed, 24 Oct 2012 07:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5NXOMDL6z8u for ; Wed, 24 Oct 2012 07:22:33 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 63C2221F86F6 for ; Wed, 24 Oct 2012 07:22:33 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TR1qh-0005km-5t; Wed, 24 Oct 2012 16:22:23 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TR1qg-0001DU-KS; Wed, 24 Oct 2012 16:22:23 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: Date: Wed, 24 Oct 2012 16:22:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <39459900-49A0-4CA2-BAD4-46D6D27E3255@ifi.uio.no> References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> <7829361A-29CE-429B-A40B-BB63B76C56C9@ifi.uio.no> To: Xiaoqing Zhu (xiaoqzhu) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 7 sum rcpts/h 15 sum msgs/h 7 total rcpts 25000 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.912, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 77683BFB1B1306F1192C540C74E37BA8751C368C X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 2 bait 0 mail/h: 7 total 10100 max/h 21 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 14:22:34 -0000 Actually... It just occurred to me that the dynamic scenario (going from = ECN-supported to non-ECN-supported) is also quite realistic. Consider a situation where you traverse two routers: router 1, followed = by router 2. Router 1 isn't usually your bottleneck, but it supports = ECN. Router 2 doesn't support ECN, but is your bottleneck most of the = time. Now, if a sudden traffic burst causes the queue of router 1 to grow, you = will start to believe that there is ECN support, and stop using delay. = But then, this queue might never grow again, all the congestion could = happen in router 2... My point is, *relying* on ECN to be there no matter how much feedback = you get is probably always the wrong thing to do. We can always only = take it as a nice extra if its available, but I think we should never = "switch to ECN mode". Cheers, Michael On 18. okt. 2012, at 05:49, Xiaoqing Zhu (xiaoqzhu) wrote: > Your points are well taken, Michael. =20 >=20 >=20 > Agree that ultimately, it would be nice to have the scheme consider a = merge of delay and ECN signals, instead of switching naively between the = two. We considered that as a stretch goal though, according to the = priorities discussed in the last BOF. We are still in the process of = improving the algorithm in that aspect.=20 >=20 > I will put in some results from ECN-based marking in the compiled file = to share. But admitted, we have not yet explored the impact of all = variations of ECN configurations. I will need to run more tests for = that.=20 >=20 > -Xiaoqing >=20 > On Oct 17, 2012, at 12:31 AM, Michael Welzl wrote: >=20 >>=20 >> On 17. okt. 2012, at 06:58, Xiaoqing Zhu (xiaoqzhu) wrote: >>=20 >>> Hi Michael,=20 >>>=20 >>> Thanks for your comments. Please find my replies inline below.=20 >>>=20 >>> Best, >>> Xiaoqing >>>=20 >>>=20 >>> On Oct 16, 2012, at 1:11 AM, Michael Welzl wrote: >>>=20 >>>> Hi, >>>>=20 >>>> I took a quick look at this: >>>>=20 >>>> I like the general idea of using as much as possible of existing = network support - but I'm critical about the actual control you propose. >>>>=20 >>>> In section 5.3.2, you suggest to replace eqn. 1 from section 5.3 = with eqn. 2 when ECN feedback is available. This means to ignore a delay = signal from now on, and interpret ECN marks in the exact same way as you = interpreted delay before - this is too simplistic, I think. After all, = ECN marks require a queue to grow, and this group intends to minimize = delay... why would you stop using delay once you have ECN in addition? >>>=20 >>>=20 >>> In our design, we considered the two cases, with or without ECN = markings, separately. Therefore, the dynamic scenario when ECN becomes = available in the middle of a video conferencing session has not yet been = fully studied. Just wondering, are cases where ECN marking are turned = on and off dynamically common in reality? =20 >>=20 >> First, anything can happen when you have a routing change. >> Second, I'm really sorry, but this wasn't what I meant. I shouldn't = have written "when" but "if". I wasn't referring to a case where we go = from no-ECN-support to ECN-support. So this is about the = ECN-always-supported case. >>=20 >>=20 >>>> In practice, using your scheme would probably mean that, as soon as = I enable RED with ECN on the bottleneck between the two end systems, the = users' observed delay grows. Not exactly an incentive? >>>>=20 >>> What you mentioned (uers observing higher delay in ECN-enabled = systems) will not happen.=20 >>>=20 >>> But rather, our simulation results have indicated that ECN with = RED-based marking yields fairly similar results as the default = delay-based scheme. They certainly do not incur higher delay, since the = endpoint will automatically back off in face of higher ECN markings, = which are indications of higher delay. The two systems (delay-based and = ECN-based) can be tuned to stabilize that the same queuing delay at the = bottleneck.=20 >>=20 >> Whether you see significant delay before you see a large enough = amount of ECN markings depends on the queue length and RED parameters, = none of which are under the end system's control. ECN is also a = probabilistic signal, so sometimes you may get delay growth but just be = lucky (or unlucky) enough to not get an ECN mark. >>=20 >> So, I'd have to see results that involve various RED settings and = queue lengths before I believe that. >>=20 >> Cheers, >> Michael >>=20 >=20 From michawe@ifi.uio.no Wed Oct 24 23:45:25 2012 Return-Path: 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 CD7A121F908E for ; Wed, 24 Oct 2012 23:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQb-+bnvPT1g for ; Wed, 24 Oct 2012 23:45:24 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id F06CD21E8037 for ; Wed, 24 Oct 2012 23:45:23 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TRHBv-0007pd-Tk; Thu, 25 Oct 2012 08:45:19 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TRHBu-0004zQ-UL; Thu, 25 Oct 2012 08:45:19 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_BDEC0611-DBCE-43C5-933E-B84EBE11DC78" From: Michael Welzl In-Reply-To: Date: Thu, 25 Oct 2012 08:45:13 +0200 Message-Id: <046762A3-6CCD-42A5-A6B0-9A65436DB86A@ifi.uio.no> References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> <7829361A-29CE-429B-A40B-BB63B76C56C9@ifi.uio.no> <39459900-49A0-4CA2-BAD4-46D6D27E3255@ifi.uio.no> To: Xiaoqing Zhu X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 5 sum rcpts/h 13 sum msgs/h 7 total rcpts 25017 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.912, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 53D773F12DE23A6E3710FB92B5A693BA08327AC1 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 10106 max/h 21 blacklist 0 greylist 0 ratelimit 0 Cc: "Rong Pan \(ropan\)" , rmcat WG , "Eggert, Lars" , Xiaoqing Zhu Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 06:45:25 -0000 --Apple-Mail=_BDEC0611-DBCE-43C5-933E-B84EBE11DC78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 25. okt. 2012, at 02:20, Xiaoqing Zhu wrote: > Michael,=20 >=20 > In general, I agree with you that we need a more graceful scheme to = accommodate both implicit and explicit congestion signals. Our current = -00 draft obviously does not solve that yet. I'll add this important = point to the "open issue" section of the draft, and also strive to find = a solution for that. =20 Sure, I think we had already agreed, I just wanted to share this = scenario that came to my mind. > However, I am not sure the dynamic scenario you describe will happen. = If a packet passes along both ECN-supported and non-ECN-supported = routers, wouldn't the ECN field bits in its header be marked as '00' = (not ECN-capable), as specified in RFC 3168? In that case, even if = congestion rises on the ECN-enabled route, the sender will still be = reacting to the rise in observed delay.=20 RFC 3168 is long and it's been a while since the last time I read it, = but: I can't recall reading what you describe here. My understanding of ECN (in a nutshell) is: ECN-capable end hosts sent = 01 or 10; ECN-incapable routers might not react to ECN at all, so anyway = you can't trust them to do something based on RFC 3168 if they don't = implement RFC 3168 :-) ; if an ECN-capable router sees a 01 or 10 = packet, it may mark it to 11; if an ECN-capable router sees a 00 packet, = it drops it instead of marking it. So, no way to reliably determine if there are some routers that do *not* = support ECN. > Also, my understanding from the previous email threads on this mailing = list seems to say that multi-hop congested links are hard scenarios to = tackle anyway. Do you think we should focus on that now, or defer it = after we obtain some satisfactory results from the simpler case of = single-congested link?=20 As I tried to explain in my earlier email about that: http://www.ietf.org/mail-archive/web/rmcat/current/msg00069.html this was about multiple hops in the overlay - multiple RTP end systems = attached to each other, to form a longer path, if you will. The underlay = can always have more than just one hop. Cheers, Michael >=20 > Thanks, > Xiaoqing >=20 >=20 > On Wed, Oct 24, 2012 at 7:22 AM, Michael Welzl = wrote: > Actually... >=20 > It just occurred to me that the dynamic scenario (going from = ECN-supported to non-ECN-supported) is also quite realistic. > Consider a situation where you traverse two routers: router 1, = followed by router 2. Router 1 isn't usually your bottleneck, but it = supports ECN. Router 2 doesn't support ECN, but is your bottleneck most = of the time. >=20 > Now, if a sudden traffic burst causes the queue of router 1 to grow, = you will start to believe that there is ECN support, and stop using = delay. But then, this queue might never grow again, all the congestion = could happen in router 2... >=20 > My point is, *relying* on ECN to be there no matter how much feedback = you get is probably always the wrong thing to do. We can always only = take it as a nice extra if its available, but I think we should never = "switch to ECN mode". >=20 > Cheers, > Michael >=20 >=20 > On 18. okt. 2012, at 05:49, Xiaoqing Zhu (xiaoqzhu) wrote: >=20 > > Your points are well taken, Michael. > > > > > > Agree that ultimately, it would be nice to have the scheme consider = a merge of delay and ECN signals, instead of switching naively between = the two. We considered that as a stretch goal though, according to the = priorities discussed in the last BOF. We are still in the process of = improving the algorithm in that aspect. > > > > I will put in some results from ECN-based marking in the compiled = file to share. But admitted, we have not yet explored the impact of all = variations of ECN configurations. I will need to run more tests for = that. > > > > -Xiaoqing > > > > On Oct 17, 2012, at 12:31 AM, Michael Welzl wrote: > > > >> > >> On 17. okt. 2012, at 06:58, Xiaoqing Zhu (xiaoqzhu) wrote: > >> > >>> Hi Michael, > >>> > >>> Thanks for your comments. Please find my replies inline below. > >>> > >>> Best, > >>> Xiaoqing > >>> > >>> > >>> On Oct 16, 2012, at 1:11 AM, Michael Welzl wrote: > >>> > >>>> Hi, > >>>> > >>>> I took a quick look at this: > >>>> > >>>> I like the general idea of using as much as possible of existing = network support - but I'm critical about the actual control you propose. > >>>> > >>>> In section 5.3.2, you suggest to replace eqn. 1 from section 5.3 = with eqn. 2 when ECN feedback is available. This means to ignore a delay = signal from now on, and interpret ECN marks in the exact same way as you = interpreted delay before - this is too simplistic, I think. After all, = ECN marks require a queue to grow, and this group intends to minimize = delay... why would you stop using delay once you have ECN in addition? > >>> > >>> > >>> In our design, we considered the two cases, with or without ECN = markings, separately. Therefore, the dynamic scenario when ECN becomes = available in the middle of a video conferencing session has not yet been = fully studied. Just wondering, are cases where ECN marking are turned = on and off dynamically common in reality? > >> > >> First, anything can happen when you have a routing change. > >> Second, I'm really sorry, but this wasn't what I meant. I shouldn't = have written "when" but "if". I wasn't referring to a case where we go = from no-ECN-support to ECN-support. So this is about the = ECN-always-supported case. > >> > >> > >>>> In practice, using your scheme would probably mean that, as soon = as I enable RED with ECN on the bottleneck between the two end systems, = the users' observed delay grows. Not exactly an incentive? > >>>> > >>> What you mentioned (uers observing higher delay in ECN-enabled = systems) will not happen. > >>> > >>> But rather, our simulation results have indicated that ECN with = RED-based marking yields fairly similar results as the default = delay-based scheme. They certainly do not incur higher delay, since the = endpoint will automatically back off in face of higher ECN markings, = which are indications of higher delay. The two systems (delay-based and = ECN-based) can be tuned to stabilize that the same queuing delay at the = bottleneck. > >> > >> Whether you see significant delay before you see a large enough = amount of ECN markings depends on the queue length and RED parameters, = none of which are under the end system's control. ECN is also a = probabilistic signal, so sometimes you may get delay growth but just be = lucky (or unlucky) enough to not get an ECN mark. > >> > >> So, I'd have to see results that involve various RED settings and = queue lengths before I believe that. > >> > >> Cheers, > >> Michael > >> > > >=20 >=20 --Apple-Mail=_BDEC0611-DBCE-43C5-933E-B84EBE11DC78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Michael, 

In general, I = agree with you that we need a more graceful scheme to accommodate both = implicit and explicit congestion signals. Our current -00 draft = obviously does not solve that yet.  I'll add this important point = to the "open issue" section of the draft, and also strive to find a = solution for that.  

Sure, I = think we had already agreed, I just wanted to share this scenario that = came to my mind.


However, I am not sure the dynamic scenario you describe will = happen. If a packet passes along both ECN-supported and = non-ECN-supported routers, wouldn't the ECN field bits in its header be = marked as '00' (not ECN-capable), as specified in RFC 3168?  In = that case, even if congestion rises on the ECN-enabled route, the sender = will still be reacting to the rise in observed = delay. 

RFC 3168 is long and = it's been a while since the last time I read it, but: I can't recall = reading what you describe here.
My understanding of ECN (in a = nutshell) is: ECN-capable end hosts sent 01 or 10; ECN-incapable routers = might not react to ECN at all, so anyway you can't trust them to do = something based on RFC 3168 if they don't implement RFC 3168  :-) =    ; if an ECN-capable router sees a 01 or 10 packet, it may = mark it to 11; if an ECN-capable router sees a 00 packet, it drops it = instead of marking it.

So, no way to reliably = determine if there are some routers that do *not* support = ECN.


Also, my understanding from the previous email threads on this = mailing list seems to say that multi-hop congested links are hard = scenarios to tackle anyway.  Do you think we should focus on that = now, or defer it after we obtain some satisfactory results from the = simpler case of single-congested = link? 

As I tried to explain = in my earlier email about that:
=
this was about multiple hops in the overlay - multiple RTP end = systems attached to each other, to form a longer path, if you will. The = underlay can always have more than just one = hop.

Cheers,
Michael


=

Thanks,
Xiaoqing


On Wed, Oct 24, 2012 at 7:22 AM, = Michael Welzl <michawe@ifi.uio.no> wrote:
Actually...

It just occurred to me that the dynamic scenario (going from = ECN-supported to non-ECN-supported) is also quite realistic.
Consider a situation where you traverse two routers: router 1, followed = by router 2. Router 1 isn't usually your bottleneck, but it supports = ECN. Router 2 doesn't support ECN, but is your bottleneck most of the = time.

Now, if a sudden traffic burst causes the queue of router 1 to grow, you = will start to believe that there is ECN support, and stop using delay. = But then, this queue might never grow again, all the congestion could = happen in router 2...

My point is, *relying* on ECN to be there no matter how much feedback = you get is probably always the wrong thing to do. We can always only = take it as a nice extra if its available, but I think we should never = "switch to ECN mode".

Cheers,
Michael


On 18. okt. 2012, at 05:49, Xiaoqing Zhu (xiaoqzhu) wrote:

> Your points are well taken, Michael.
>
>
> Agree that ultimately, it would be nice to have the scheme consider = a merge of delay and ECN signals, instead of switching naively between = the two. We considered that as a stretch goal though, according to the = priorities discussed in the last BOF. We are still in the process of = improving the algorithm in that aspect.
>
> I will put in some results from ECN-based marking in the compiled = file to share. But admitted, we have not yet explored the impact of all = variations of ECN configurations.  I will need to run more tests = for that.
>
> -Xiaoqing
>
> On Oct 17, 2012, at 12:31 AM, Michael Welzl wrote:
>
>>
>> On 17. okt. 2012, at 06:58, Xiaoqing Zhu (xiaoqzhu) wrote:
>>
>>> Hi Michael,
>>>
>>> Thanks for your comments.  Please find my replies = inline below.
>>>
>>> Best,
>>> Xiaoqing
>>>
>>>
>>> On Oct 16, 2012, at 1:11 AM, Michael Welzl wrote:
>>>
>>>> Hi,
>>>>
>>>> I took a quick look at this:
>>>>
>>>> I like the general idea of using as much as possible of = existing network support - but I'm critical about the actual control you = propose.
>>>>
>>>> In section 5.3.2, you suggest to replace eqn. 1 from = section 5.3 with eqn. 2 when ECN feedback is available. This means to = ignore a delay signal from now on, and interpret ECN marks in the exact = same way as you interpreted delay before - this is too simplistic, I = think. After all, ECN marks require a queue to grow, and this group = intends to minimize delay... why would you stop using delay once you = have ECN in addition?
>>>
>>>
>>> In our design, we considered the two cases, with or without = ECN markings, separately.  Therefore, the dynamic scenario when ECN = becomes available in the middle of a video conferencing session has not = yet been fully studied.  Just wondering, are cases where ECN = marking are turned on and off dynamically common in reality?
>>
>> First, anything can happen when you have a routing change.
>> Second, I'm really sorry, but this wasn't what I meant. I = shouldn't have written "when" but "if". I wasn't referring to a case = where we go from no-ECN-support to ECN-support. So this is about the = ECN-always-supported case.
>>
>>
>>>> In practice, using your scheme would probably mean = that, as soon as I enable RED with ECN on the bottleneck between the two = end systems, the users' observed delay grows. Not exactly an = incentive?
>>>>
>>> What you mentioned (uers observing higher delay in = ECN-enabled systems) will not happen.
>>>
>>> But rather, our simulation results have indicated that ECN = with RED-based marking yields fairly similar results as the default = delay-based scheme. They certainly do not incur higher delay, since the = endpoint will automatically back off in face of higher ECN markings, = which are indications of higher delay. The two systems (delay-based and = ECN-based) can be tuned to stabilize that the same queuing delay at the = bottleneck.
>>
>> Whether you see significant delay before you see a large enough = amount of ECN markings depends on the queue length and RED parameters, = none of which are under the end system's control. ECN is also a = probabilistic signal, so sometimes you may get delay growth but just be = lucky (or unlucky) enough to not get an ECN mark.
>>
>> So, I'd have to see results that involve various RED settings = and queue lengths before I believe that.
>>
>> Cheers,
>> Michael
>>
>



= --Apple-Mail=_BDEC0611-DBCE-43C5-933E-B84EBE11DC78-- From holmer@google.com Mon Oct 29 07:05:59 2012 Return-Path: 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 7299E21F8678 for ; Mon, 29 Oct 2012 07:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDB+t6aphm0H for ; Mon, 29 Oct 2012 07:05:58 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E23B921F85C0 for ; Mon, 29 Oct 2012 07:05:52 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7534946iec.31 for ; Mon, 29 Oct 2012 07:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=GmYK2i65yDYNrqrCuxqHSyLMPXW2NI8yr7ScNv7oowM=; b=oqcTKjNkvj0Jt0ZB1OOxfOfo5n4IMsSWO/p+jIS4ZMZcFAEZuA7NBuf7Feoj3mHKx2 ZXA6kN1m7iEQTKsFVoh0fO34N4uoiDBwn+fcfgxk0MejHHGKdkdqcJhn4OwItl8LpmTT gH7dFF6y2h6T73kLr8jvT7tmX+GaewcBsZJlkMzIt7NhH3xcPYhquNwKEsBwNhNRHpsl X+QP1ceQ/5le1nUmEHD9dfc9KGTntGuONRHmg3vAotvf2NvtQmY4Cjy9cuUM8VCG/CqG PopEj3IfkIjoA7dT26Q0FNLOailqr/hDXjY/JldzdjEvHySh68izD2muVtqegDjEXUp0 Oz2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=GmYK2i65yDYNrqrCuxqHSyLMPXW2NI8yr7ScNv7oowM=; b=a+gaR11CRWlN7JpUb/NCVFh6SjJqCv9n3f9UL1JYXjiE9ESr0lRaqDvtnI41ok4b9Z I0DEQcad6IIcs1eoGZFlXe9GyecwTLAP4P/zMnNdmk38mzKaX6g1AXcr3VfLWq7/7FBl Xq9T2li2H6Ks9sq1M3uqCB8UMJKgdMXHjqlxf8YhsxZHs2lfZbCX07AxXfhtzRJxneYl VVbzBabbjPiwr99ug2OK4AnahAXs9JADc0nCGe+zlECvvYullUXFX7ZD6Agh4/mf1rca AR04eudVYLsjf32zyXl7Beuh0U1fE6VUGVJW/VXIuoMkfQ7Ufb1/Dvkd6oDDC+Vboubb 2GyA== MIME-Version: 1.0 Received: by 10.50.217.169 with SMTP id oz9mr9635766igc.15.1351519552208; Mon, 29 Oct 2012 07:05:52 -0700 (PDT) Sender: holmer@google.com Received: by 10.50.74.169 with HTTP; Mon, 29 Oct 2012 07:05:52 -0700 (PDT) In-Reply-To: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> Date: Mon, 29 Oct 2012 15:05:52 +0100 X-Google-Sender-Auth: 8LlpmBIBWlOu3wj4OiXU_qkY8vc Message-ID: From: Stefan Holmer To: "Xiaoqing Zhu (xiaoqzhu)" Content-Type: multipart/alternative; boundary=14dae934061fd1000d04cd332add X-System-Of-Record: true X-Gm-Message-State: ALoCoQkMZXZQlUgEZ1sH/xzjm+hN0ASEW7C/FkrR4xfml7bAGW/A0mdILIiK6V14cNuCeItZ/QrXPOM+bbeZ/imCXhIX2D1aEQAi2E/zp7V0Cg7AmTS9neqnpzq3GAlvQBjrN7cwLShcrWehU48685D739NtmX/Auej6CqqyHEvMaI78ArOwS5IwwWqapRgp/+sP1j7ahFk2 Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 14:05:59 -0000 --14dae934061fd1000d04cd332add Content-Type: text/plain; charset=ISO-8859-1 Hi Xiaoqing, Interesting draft, I have a few questions related to the queuing delay part of it. "The role of the receiver is fairly straightforward. It observes and estimates end-to-end queuing delay d and ECN marking ratio p of the stream. The former can be obtained from the RTP timestamp provided by the sender." You don't provide much detail on how the end-to-end queuing delay is estimated from the timestamps. Would it be possible to be more specific? Are you employing a filter? Related to that, you seem to be running into a divide by zero in equation 1 if your queuing delay turns out to be zero. It also seems a bit bold to go directly from R_min to R_max if the queuing delay is low enough. /Stefan On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (xiaoqzhu) < xiaoqzhu@cisco.com> wrote: > And below is the notification of our submission: > > Thanks, > Xiaoqing > > -------------------------------------- > A new version of I-D, draft-zhu-rmcat-nada-00.txt > has been successfully submitted by Xiaoqing Zhu and posted to the > IETF repository. > > Filename: draft-zhu-rmcat-nada > Revision: 00 > Title: NADA: A Unified Congestion Control Scheme for Real-Time Media > Creation date: 2012-10-14 > WG ID: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt > Status: http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada > Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-00 > > > Abstract: > This document describes a scheme named network-assisted dynamic > adaptation (NADA), a novel congestion control approach for > interactive real-time media applications, such as video conferencing. > In the proposed scheme, the sender regulates its sending rate based > on either implicit or explicit congestion signaling, in a unified > approach. The scheme can reap the benefits of explicit congestion > notification markings from network nodes. It also maintains > consistent sender behavior in the absence of such markings, by > reacting to queuing delays instead. > > We present here the overall system architecture, recommended > behaviors at the sender and the receiver, as well as expected network > nodes operations. Results from extensive simulation studies of the > proposed scheme are available upon request. > > > > > The IETF Secretariat > -------------------------------------- > On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: > > Hi, > > On Oct 11, 2012, at 18:45, Xiaoqing Zhu wrote: > > My colleague and I are working on a congestion control scheme for > > real-time conferencing applications at Cisco. A brief version of that > > algorithm was presented at the IAB Workshop in Vancouver (paper #12, > > "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due > > to time constraints, however, we did not get a chance to mention the > > delay-based variant of that scheme, which may be a better fit for > > rmcat. > > > We would like to request for a slot to present in Atlanta. We will > > also submit the ID draft before Oct 15, for further discussions on > > this mailing list. > > > I look forward to seeing the draft being discussed on the list! > > Also, I'm noting your request for a slot. Because the actual CC mechanisms > are not our most pressing milestones initially - the requirements and eval > criteria are - we may decide to focus our meeting time on those other > drafts, if demand for agenda time is high. > > Lars > > > --14dae934061fd1000d04cd332add Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Xiaoqing,

Interesting draft, I have a few questions r= elated to the queuing delay part of it.

"The = role of the receiver is fairly straightforward. It observes and estimates e= nd-to-end queuing delay d and ECN marking ratio p of the stream. The former= can be obtained from the RTP timestamp provided by the sender."

You don't provide much detail on how the end-to-end= queuing delay is estimated from the timestamps. Would it be possible to be= more specific? Are you employing a filter? Related to that, you seem to be= running into a divide by zero in equation 1 if your queuing delay turns ou= t to be zero. It also seems a bit bold to go directly from R_min to R_max i= f the queuing delay is low enough.

/Stefan




On Mon, Oct 15, 2012 at= 11:43 PM, Xiaoqing Zhu (xiaoqzhu) <xiaoqzhu@cisco.com> wro= te:
And below is the notification of our submission:=A0

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename: =A0draft-zhu-rmcat-na= da
Revision: =A000
Title: =A0NADA: A Unified Congestion Control Scheme for Real-T= ime Media
Creation date: =A02012-10-14 WG ID: =A0Individual Submission
Number of pages: 10
URL: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0http://www.ietf= .org/internet-drafts/draft-zhu-rmcat-nada-00.txt
Status: =A0=A0=A0=A0=A0=A0=A0=A0=A0http://datatracker.ietf.org/doc/= draft-zhu-rmcat-nada
Htmlized: =A0=A0=A0=A0=A0=A0=A0http://tools.ietf.org/html/draft-zhu-r= mcat-nada-00


Abstract:
=A0=A0This document describes a scheme named network-assisted dynamic
=A0=A0adaptation (NADA), a novel congestion control approach for
=A0=A0interactive real-time media applications, such as video conferencing.=
=A0=A0In the proposed scheme, the sender regulates its sending rate based =A0=A0on either implicit or explicit congestion signaling, in a unified
=A0=A0approach. The scheme can reap the benefits of explicit congestion
=A0=A0notification markings from network nodes. It also maintains
=A0=A0consistent sender behavior in the absence of such markings, by
=A0=A0reacting to queuing delays instead.

=A0=A0We present here the overall system architecture, recommended
=A0=A0behaviors at the sender and the receiver, as well as expected network=
=A0=A0nodes operations. Results from extensive simulation studies of the =A0=A0proposed scheme are available upon request.




The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <zhuxq@alumni.stanford.edu> wrote:
My colleague and I are working on a congestion co= ntrol scheme for
real-time conferencing applications at Cisco. A b= rief version of that
algorithm was presented at the IAB Workshop in Va= ncouver (paper #12,
"Network-Assisted Dynamic Adaptation (NADA):= A Design Summary"). Due
to time constraints, however, we did not get a ch= ance to mention the
delay-based variant of that scheme, which may be = a better fit for
rmcat.

We would like to request for a slot to present in= Atlanta. We will
also submit the ID draft before Oct 15, for furth= er discussions on
this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC mechani= sms are not our most pressing milestones initially - the requirements and e= val criteria are - we may decide to focus our meeting time on those other d= rafts, if demand for agenda time is high.

Lars


--14dae934061fd1000d04cd332add-- From xiaoqzhu@cisco.com Mon Oct 29 07:53:21 2012 Return-Path: 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 926E921F870E for ; Mon, 29 Oct 2012 07:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWMkmBHSoYHI for ; Mon, 29 Oct 2012 07:53:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3955321F870C for ; Mon, 29 Oct 2012 07:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12942; q=dns/txt; s=iport; t=1351522400; x=1352732000; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0CS63LODKA/OSlfV44tedBvdAVTyKHblzJCvt1szGt4=; b=aj6vPH1nMBzpAh+EXmcyP0ydvQsmz5pvwz0KRcwhJbpHLXvcIb86mTHW p/X55q/ujDuSCDW0qpbxMoi4rEUPViLOrZ7TfMXiCpQqFGQaJ2cgMWlx2 q6SoDNSCRqyP0IfM2WA3jkLM+fxa4DPbSW0CY6fuFgtOAI2lLsOMQpbkf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsGAGeXjlCtJV2Z/2dsb2JhbABEgm2uEoh3AYYxgjuBCIIfAQEEEgFbCxACAQgSEB0HMhQDDgIEDgUIARmHZAEKnDufWIt1hXxhA5cOjT2Ba4Jvghk X-IronPort-AV: E=Sophos;i="4.80,672,1344211200"; d="scan'208,217";a="136459695" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 29 Oct 2012 14:53:19 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9TErJp7032286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Oct 2012 14:53:19 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Mon, 29 Oct 2012 09:53:19 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: Stefan Holmer Thread-Topic: [rmcat] send agenda requests (was Re: First meeting) Thread-Index: AQHNp9grf2quh6JMt0CYpuBNP/SHCpe1q3yAgAWVAgCAFYClAIAADUEA Date: Mon, 29 Oct 2012 14:53:19 +0000 Message-ID: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.14.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19318.004 x-tm-as-result: No--45.891800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E7175A8E3DC14048A7D3020E0338C1FA0D7B82AExmbalnx13ciscoc_" MIME-Version: 1.0 Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 14:53:21 -0000 --_000_E7175A8E3DC14048A7D3020E0338C1FA0D7B82AExmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stefan, Thanks a lot for your comments. I'll add in more details on the description= for the receiver actions. You are right, we did employ some filtering of the observed per-packet queu= ing delay, to avoid erratic reactions in the sending rate. The queuing dela= y employed in the rate calculation in Eq. (1) is actually the time-smoothed= averaging d_avg: d_avg =3D (1-alpha)*d_avg + d_n, where d_n represents the measured queuing = delay (end-to-end delay minus minimum observed value) for the n-th packet.= The parameter alpha adjusts the level of smoothness in our average process= . In our experiments, we are using alpha =3D 10e-4. Also, it's obvious that Eq.(1) wouldn't hold for for d=3D0, in which case t= he rate is chosen to be R_max. As mentioned in the paragraph below Eq. (1)= , any calculated target rate R_o greater than R_max will also be clipped to= the R_max. Initially, I omitted these details in the draft proposal for brevity. Given= your comments and concerns, looks like I'd better put them back in for cla= rity. Best, Xiaoqing On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote: Hi Xiaoqing, Interesting draft, I have a few questions related to the queuing delay part= of it. "The role of the receiver is fairly straightforward. It observes and estima= tes end-to-end queuing delay d and ECN marking ratio p of the stream. The f= ormer can be obtained from the RTP timestamp provided by the sender." You don't provide much detail on how the end-to-end queuing delay is estima= ted from the timestamps. Would it be possible to be more specific? Are you = employing a filter? Related to that, you seem to be running into a divide b= y zero in equation 1 if your queuing delay turns out to be zero. It also se= ems a bit bold to go directly from R_min to R_max if the queuing delay is l= ow enough. /Stefan On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (xiaoqzhu) > wrote: And below is the notification of our submission: Thanks, Xiaoqing -------------------------------------- A new version of I-D, draft-zhu-rmcat-nada-00.txt has been successfully submitted by Xiaoqing Zhu and posted to the IETF repository. Filename: draft-zhu-rmcat-nada Revision: 00 Title: NADA: A Unified Congestion Control Scheme for Real-Time Media Creation date: 2012-10-14 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-0= 0.txt Status: http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-00 Abstract: This document describes a scheme named network-assisted dynamic adaptation (NADA), a novel congestion control approach for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can reap the benefits of explicit congestion notification markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays instead. We present here the overall system architecture, recommended behaviors at the sender and the receiver, as well as expected network nodes operations. Results from extensive simulation studies of the proposed scheme are available upon request. The IETF Secretariat -------------------------------------- On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: Hi, On Oct 11, 2012, at 18:45, Xiaoqing Zhu > wrote: My colleague and I are working on a congestion control scheme for real-time conferencing applications at Cisco. A brief version of that algorithm was presented at the IAB Workshop in Vancouver (paper #12, "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due to time constraints, however, we did not get a chance to mention the delay-based variant of that scheme, which may be a better fit for rmcat. We would like to request for a slot to present in Atlanta. We will also submit the ID draft before Oct 15, for further discussions on this mailing list. I look forward to seeing the draft being discussed on the list! Also, I'm noting your request for a slot. Because the actual CC mechanisms = are not our most pressing milestones initially - the requirements and eval = criteria are - we may decide to focus our meeting time on those other draft= s, if demand for agenda time is high. Lars --_000_E7175A8E3DC14048A7D3020E0338C1FA0D7B82AExmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Stefan, 

Thanks a lot for your comments. I'll add in more details on the descri= ption for the receiver actions. 

You are right, we did employ some filtering of the observed per-packet= queuing delay, to avoid erratic reactions in the sending rate. The queuing= delay employed in the rate calculation in Eq. (1) is actually the time-smo= othed averaging d_avg: 

d_avg =3D (1-alpha)*d_avg + d_n, where d_n represents the measured= queuing delay  (end-to-end delay minus minimum observed value) for th= e n-th packet. The parameter alpha adjusts the level of smoothness in our a= verage process. In our experiments, we are using alpha =3D 10e-4. 

Also, it's obvious that Eq.(1) wouldn't hold for for d=3D0, in which c= ase the rate is chosen to be R_max.  As mentioned in the paragraph bel= ow Eq. (1), any calculated target rate R_o greater than R_max will also be = clipped to the R_max. 

Initially, I omitted these details in the draft proposal for brevity. = Given your comments and concerns, looks like I'd better put them back in fo= r clarity. 

Best,
Xiaoqing


On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote:

Hi Xiaoqing,

Interesting draft, I have a few questions related to the queuing delay= part of it.

"The role of the receiver is fairly straightforward. It observes = and estimates end-to-end queuing delay d and ECN marking ratio p of the str= eam. The former can be obtained from the RTP timestamp provided by the send= er."

You don't provide much detail on how the end-to-end queuing delay is e= stimated from the timestamps. Would it be possible to be more specific? Are= you employing a filter? Related to that, you seem to be running into a div= ide by zero in equation 1 if your queuing delay turns out to be zero. It also seems a bit bold to go directl= y from R_min to R_max if the queuing delay is low enough.

/Stefan




On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (= xiaoqzhu) <xiaoqzhu@cisco.com> wrote:
And below is the notification of our su= bmission: 

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename:  draft-zhu-rmcat= -nada
Revision:  00
Title:  NADA: A Unified Congestion Control Scheme for Rea= l-Time Media
Creation date:  2012-10-14=
WG ID:  Individual Submission
Number of pages: 10
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-zhu-rmcat-na= da-00.txt
Status:          http:= //datatracker.ietf.org/doc/draft-zhu-rmcat-nada
Htmlized:        http://tools.ietf= .org/html/draft-zhu-rmcat-nada-00


Abstract:
  This document describes a scheme named network-assisted dynamic=
  adaptation (NADA), a novel congestion control approach for
  interactive real-time media applications, such as video confere= ncing.
  In the proposed scheme, the sender regulates its sending rate b= ased
  on either implicit or explicit congestion signaling, in a unifi= ed
  approach. The scheme can reap the benefits of explicit congesti= on
  notification markings from network nodes. It also maintains
  consistent sender behavior in the absence of such markings, by<= br>   reacting to queuing delays instead.

  We present here the overall system architecture, recommended   behaviors at the sender and the receiver, as well as expected n= etwork
  nodes operations. Results from extensive simulation studies of = the
  proposed scheme are available upon request.




The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <zhuxq@alumni.stanford.edu> wrote:
My colleague and I are working on a congestion co= ntrol scheme for
real-time conferencing applications at Cisco. A b= rief version of that
algorithm was presented at the IAB Workshop in Va= ncouver (paper #12,
"Network-Assisted Dynamic Adaptation (NADA):= A Design Summary"). Due
to time constraints, however, we did not get a ch= ance to mention the
delay-based variant of that scheme, which may be = a better fit for
rmcat.

We would like to request for a slot to present in= Atlanta. We will
also submit the ID draft before Oct 15, for furth= er discussions on
this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC mechanisms = are not our most pressing milestones initially - the requirements and eval = criteria are - we may decide to focus our meeting time on those other draft= s, if demand for agenda time is high.

Lars



--_000_E7175A8E3DC14048A7D3020E0338C1FA0D7B82AExmbalnx13ciscoc_-- From holmer@google.com Mon Oct 29 08:23:40 2012 Return-Path: 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 501C921F8715 for ; Mon, 29 Oct 2012 08:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4npmYRxVC+x for ; Mon, 29 Oct 2012 08:23:34 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F79221F84B9 for ; Mon, 29 Oct 2012 08:23:34 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so5297342obq.31 for ; Mon, 29 Oct 2012 08:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=bmAr1zW4wrRvuq4BheCbhh/G5EXCMZO4xXgQUyHEuRI=; b=GOqQ9nGp9WP8dKDE85WHbC/WBsTMGS4S34HmO1WkwfFSI6m2VmKz9okaLwZS5rPXn6 /sYNLW6TZXUq5jzNAxbIsGnqDgPn8JXKF+TEB7x5Y4EZM/lAt/E+d7wX+/GWVGh6KTwt A7DaWRcOMBfqSlZCoA++PfAjTQP9gjydQNAhcglEiQ5gN5U1jN3A5+1fqtoOGkGY6/vE sPV7SnZ1/lLEpw3U0tgyOlRcTGhoEvy44B8XxIE5jhOqRGintlev1tMFId5IGf+65f2H YY2SQbh+fDGVyZfw1YoFp1YcQh1wPDU9ogqrCtWmci1TBNorDEqeCuWedU164nDHErCa gUlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=bmAr1zW4wrRvuq4BheCbhh/G5EXCMZO4xXgQUyHEuRI=; b=WQOPi5CPueWoosyhGqWErXwOeMe9eMK84kcQByLqE1xPaU6zpKOh8/2S8PA/IiBXxu cmloPfYCzeS/t1TdHSnf1U/mOib13g6Z5YAabxl7gJCQU8PYMhzSGiasLfGcjBIQ3tde HRayVYqVPh8fiJaP9YRKXca0tajcic52jRPS7I2iWPhh1b5hY983BdVfVeUIGTSKpKtC ZuRq8YLKxZasM83/u9wTgSwfPZRR1mdm43NsfAvgMJD0ANUJtQLfh1H8HQv6bVgspUeB cfmJUkYvYcDhZTFvX9gQs7yNplgPH3scxeREdphKZgVrP89aIGq+QFOpiACAwtJfdZFS 7oqA== MIME-Version: 1.0 Received: by 10.60.13.198 with SMTP id j6mr26107637oec.51.1351524213618; Mon, 29 Oct 2012 08:23:33 -0700 (PDT) Sender: holmer@google.com Received: by 10.76.135.225 with HTTP; Mon, 29 Oct 2012 08:23:33 -0700 (PDT) In-Reply-To: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> Date: Mon, 29 Oct 2012 16:23:33 +0100 X-Google-Sender-Auth: 6nWXAqBgb9hiBwH2wI7J_m4Kpos Message-ID: From: Stefan Holmer To: "Xiaoqing Zhu (xiaoqzhu)" Content-Type: multipart/alternative; boundary=e89a8ff253d2a8769404cd3440b3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnSbSikWEtnC6/OGQeMrtgUDDNhIinw1P3oB8Nm7mPVdlmRZEvr8LEg0ap31K8UkUfhHLh5qaCqSdzIQi5TZbb01nUSBZdGths2ZT7hYN8wgUh9y7I1fw/xpDvzaTC7p65sFCArdXYg3eOo4DwZPjrn6cQZ5grAFXV1fQyUbaN9E58aRsQF4gsLB+y2h8WY9G07HEy0 Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 15:23:40 -0000 --e89a8ff253d2a8769404cd3440b3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 29, 2012 at 3:53 PM, Xiaoqing Zhu (xiaoqzhu) wrote: > Hi Stefan, > > Thanks a lot for your comments. I'll add in more details on the > description for the receiver actions. > > You are right, we did employ some filtering of the observed per-packet > queuing delay, to avoid erratic reactions in the sending rate. The queuing > delay employed in the rate calculation in Eq. (1) is actually the > time-smoothed averaging d_avg: > > d_avg = (1-alpha)*d_avg + d_n, where d_n represents the measured queuing > delay (end-to-end delay minus minimum observed value) for the n-th packet. > The parameter alpha adjusts the level of smoothness in our average process. > In our experiments, we are using alpha = 10e-4. > Thanks. Just to be clear, d_n = receiver_time_n - timestamp_n - min_observed and min_observed is the smallest d_n seen in some window? > > Also, it's obvious that Eq.(1) wouldn't hold for for d=0, in which case > the rate is chosen to be R_max. As mentioned in the paragraph below Eq. > (1), any calculated target rate R_o greater than R_max will also be clipped > to the R_max. > > Initially, I omitted these details in the draft proposal for brevity. > Given your comments and concerns, looks like I'd better put them back in > for clarity. > > Best, > Xiaoqing > > > On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote: > > Hi Xiaoqing, > > Interesting draft, I have a few questions related to the queuing delay > part of it. > > "The role of the receiver is fairly straightforward. It observes and > estimates end-to-end queuing delay d and ECN marking ratio p of the stream. > The former can be obtained from the RTP timestamp provided by the sender." > > You don't provide much detail on how the end-to-end queuing delay is > estimated from the timestamps. Would it be possible to be more specific? > Are you employing a filter? Related to that, you seem to be running into a > divide by zero in equation 1 if your queuing delay turns out to be zero. It > also seems a bit bold to go directly from R_min to R_max if the queuing > delay is low enough. > > /Stefan > > > > > On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (xiaoqzhu) < > xiaoqzhu@cisco.com> wrote: > >> And below is the notification of our submission: >> >> Thanks, >> Xiaoqing >> >> -------------------------------------- >> A new version of I-D, draft-zhu-rmcat-nada-00.txt >> has been successfully submitted by Xiaoqing Zhu and posted to the >> IETF repository. >> >> Filename: draft-zhu-rmcat-nada >> Revision: 00 >> Title: NADA: A Unified Congestion Control Scheme for Real-Time Media >> Creation date: 2012-10-14 >> WG ID: Individual Submission >> Number of pages: 10 >> URL: >> http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt >> Status: http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada >> Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-00 >> >> >> Abstract: >> This document describes a scheme named network-assisted dynamic >> adaptation (NADA), a novel congestion control approach for >> interactive real-time media applications, such as video conferencing. >> In the proposed scheme, the sender regulates its sending rate based >> on either implicit or explicit congestion signaling, in a unified >> approach. The scheme can reap the benefits of explicit congestion >> notification markings from network nodes. It also maintains >> consistent sender behavior in the absence of such markings, by >> reacting to queuing delays instead. >> >> We present here the overall system architecture, recommended >> behaviors at the sender and the receiver, as well as expected network >> nodes operations. Results from extensive simulation studies of the >> proposed scheme are available upon request. >> >> >> >> >> The IETF Secretariat >> -------------------------------------- >> On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: >> >> Hi, >> >> On Oct 11, 2012, at 18:45, Xiaoqing Zhu >> wrote: >> >> My colleague and I are working on a congestion control scheme for >> >> real-time conferencing applications at Cisco. A brief version of that >> >> algorithm was presented at the IAB Workshop in Vancouver (paper #12, >> >> "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due >> >> to time constraints, however, we did not get a chance to mention the >> >> delay-based variant of that scheme, which may be a better fit for >> >> rmcat. >> >> >> We would like to request for a slot to present in Atlanta. We will >> >> also submit the ID draft before Oct 15, for further discussions on >> >> this mailing list. >> >> >> I look forward to seeing the draft being discussed on the list! >> >> Also, I'm noting your request for a slot. Because the actual CC >> mechanisms are not our most pressing milestones initially - the >> requirements and eval criteria are - we may decide to focus our meeting >> time on those other drafts, if demand for agenda time is high. >> >> Lars >> >> >> > > --e89a8ff253d2a8769404cd3440b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, O= ct 29, 2012 at 3:53 PM, Xiaoqing Zhu (xiaoqzhu) <xiaoqzh= u@cisco.com> wrote:
Hi Stefan,=A0

Thanks a lot for your comments. I'll add in more details on the de= scription for the receiver actions.=A0

You are right, we did employ some filtering of the observed per-packet= queuing delay, to avoid erratic reactions in the sending rate. The queuing= delay employed in the rate calculation in Eq. (1) is actually the time-smo= othed averaging d_avg:=A0

d_avg =3D (1-alpha)*d_avg + d_n, where d_n represents the measured que= uing delay =A0(end-to-end delay minus minimum observed value) for the n-th = packet. The parameter alpha adjusts the level of smoothness in our average = process. In our experiments, we are using alpha =3D 10e-4.=A0

Than= ks. Just to be clear,=A0

d_n =3D receiver_time_n -= timestamp_n - min_observed

and min_observed is th= e smallest d_n seen in some window?
=A0

Also, it's obvious that Eq.(1) wouldn't hold for for d=3D0, in= which case the rate is chosen to be R_max. =A0As mentioned in the paragrap= h below Eq. (1), any calculated target rate R_o greater than R_max will als= o be clipped to the R_max.=A0

Initially, I omitted these details in the draft proposal for brevity. = Given your comments and concerns, looks like I'd better put them back i= n for clarity.=A0

Best,
Xiaoqing


On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote:

Hi Xiaoqing,

Interesting draft, I have a few questions related to the queuing delay= part of it.

"The role of the receiver is fairly straightforward. It observes = and estimates end-to-end queuing delay d and ECN marking ratio p of the str= eam. The former can be obtained from the RTP timestamp provided by the send= er."

You don't provide much detail on how the end-to-end queuing delay = is estimated from the timestamps. Would it be possible to be more specific?= Are you employing a filter? Related to that, you seem to be running into a= divide by zero in equation 1 if your queuing delay turns out to be zero. It also seems a bit bold to go directl= y from R_min to R_max if the queuing delay is low enough.

/Stefan




On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (= xiaoqzhu) <xiaoqzhu@cisco.com> wrote:
And below is the notification of our su= bmission:=A0

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename: =A0draft-zhu-rmcat-na= da
Revision: =A000
Title: =A0NADA: A Unified Congestion Control Scheme for Real-T= ime Media
Creation date: =A02012-10-14 WG ID: =A0Individual Submission
Number of pages: 10
URL: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt
Status: =A0=A0=A0=A0=A0=A0=A0=A0=A0http://datatrac= ker.ietf.org/doc/draft-zhu-rmcat-nada
Htmlized: =A0=A0=A0=A0=A0=A0=A0http://tools.ietf.org= /html/draft-zhu-rmcat-nada-00


Abstract:
=A0=A0This document describes a scheme named network-assisted dynamic
=A0=A0adaptation (NADA), a novel congestion control approach for
=A0=A0interactive real-time media applications, such as video conferencing.=
=A0=A0In the proposed scheme, the sender regulates its sending rate based =A0=A0on either implicit or explicit congestion signaling, in a unified
=A0=A0approach. The scheme can reap the benefits of explicit congestion
=A0=A0notification markings from network nodes. It also maintains
=A0=A0consistent sender behavior in the absence of such markings, by
=A0=A0reacting to queuing delays instead.

=A0=A0We present here the overall system architecture, recommended
=A0=A0behaviors at the sender and the receiver, as well as expected network=
=A0=A0nodes operations. Results from extensive simulation studies of the =A0=A0proposed scheme are available upon request.




The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <zhuxq@alumni.stanford.edu<= /a>> wrote:
My colleague and I are working on a congestion co= ntrol scheme for
real-time conferencing applications at Cisco. A b= rief version of that
algorithm was presented at the IAB Workshop in Va= ncouver (paper #12,
"Network-Assisted Dynamic Adaptation (NADA):= A Design Summary"). Due
to time constraints, however, we did not get a ch= ance to mention the
delay-based variant of that scheme, which may be = a better fit for
rmcat.

We would like to request for a slot to present in= Atlanta. We will
also submit the ID draft before Oct 15, for furth= er discussions on
this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC mechani= sms are not our most pressing milestones initially - the requirements and e= val criteria are - we may decide to focus our meeting time on those other d= rafts, if demand for agenda time is high.

Lars




--e89a8ff253d2a8769404cd3440b3-- From xiaoqzhu@cisco.com Mon Oct 29 08:28:23 2012 Return-Path: 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 64C5F21F8707 for ; Mon, 29 Oct 2012 08:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gFIarTp++v2 for ; Mon, 29 Oct 2012 08:28:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E22C621F871D for ; Mon, 29 Oct 2012 08:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15378; q=dns/txt; s=iport; t=1351524502; x=1352734102; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=58EZsLDXgi/2U39Yb5zq+9GR6Y6vcdABd1lP0q09FRQ=; b=hsDgBgGBvCBJm182r6GLcQsLvMZ9m/NlJ6upUSlee2cwqKW0ZB+bHFRf w4UNW6Di5aJI3DPIKthROWUmjF+wp8f/QVP5mbGq7QZ3bamavnxhRuXMT I76yC/10JhaKh1r3fWHJ537sFWecPfZVUg3i107aJdar1qg3PcYTSY/VA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsGALOfjlCtJV2b/2dsb2JhbABEgm2uEoh3AYYxgjyBCIIfAQEEEgFbCxACAQgSEB0HMhQDDgIEDgUIARmHZAEKnDefXot1hXxhA5cOjT2Ba4Jvghk X-IronPort-AV: E=Sophos;i="4.80,672,1344211200"; d="scan'208,217";a="136273725" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 29 Oct 2012 15:28:21 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9TFSL1i001574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Oct 2012 15:28:21 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Mon, 29 Oct 2012 10:28:20 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: Stefan Holmer Thread-Topic: [rmcat] send agenda requests (was Re: First meeting) Thread-Index: AQHNp9grf2quh6JMt0CYpuBNP/SHCpe1q3yAgAWVAgCAFYClAIAADUEAgAAIdICAAAFVgA== Date: Mon, 29 Oct 2012 15:28:20 +0000 Message-ID: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.14.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19318.004 x-tm-as-result: No--54.310600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E7175A8E3DC14048A7D3020E0338C1FA0D7B838Fxmbalnx13ciscoc_" MIME-Version: 1.0 Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 15:28:23 -0000 --_000_E7175A8E3DC14048A7D3020E0338C1FA0D7B838Fxmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 29, 2012, at 10:23 AM, Stefan Holmer wrote: On Mon, Oct 29, 2012 at 3:53 PM, Xiaoqing Zhu (xiaoqzhu) > wrote: Hi Stefan, Thanks a lot for your comments. I'll add in more details on the description= for the receiver actions. You are right, we did employ some filtering of the observed per-packet queu= ing delay, to avoid erratic reactions in the sending rate. The queuing dela= y employed in the rate calculation in Eq. (1) is actually the time-smoothed= averaging d_avg: d_avg =3D (1-alpha)*d_avg + d_n, where d_n represents the measured queuing = delay (end-to-end delay minus minimum observed value) for the n-th packet.= The parameter alpha adjusts the level of smoothness in our average process= . In our experiments, we are using alpha =3D 10e-4. Thanks. Just to be clear, d_n =3D receiver_time_n - timestamp_n - min_observed and min_observed is the smallest d_n seen in some window? That's right. BTW, while the time-averaged filtering works well for us, fo= r now, we are also considering building in more robustness against individu= al bad samples. The Kalman filtering approach presented in your proposal se= ems to be a good candidate for that. Maybe there is a way to incorporate th= at approach here for the delay estimation as well. What do you think? Also, it's obvious that Eq.(1) wouldn't hold for for d=3D0, in which case t= he rate is chosen to be R_max. As mentioned in the paragraph below Eq. (1)= , any calculated target rate R_o greater than R_max will also be clipped to= the R_max. Initially, I omitted these details in the draft proposal for brevity. Given= your comments and concerns, looks like I'd better put them back in for cla= rity. Best, Xiaoqing On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote: Hi Xiaoqing, Interesting draft, I have a few questions related to the queuing delay part= of it. "The role of the receiver is fairly straightforward. It observes and estima= tes end-to-end queuing delay d and ECN marking ratio p of the stream. The f= ormer can be obtained from the RTP timestamp provided by the sender." You don't provide much detail on how the end-to-end queuing delay is estima= ted from the timestamps. Would it be possible to be more specific? Are you = employing a filter? Related to that, you seem to be running into a divide b= y zero in equation 1 if your queuing delay turns out to be zero. It also se= ems a bit bold to go directly from R_min to R_max if the queuing delay is l= ow enough. /Stefan On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (xiaoqzhu) > wrote: And below is the notification of our submission: Thanks, Xiaoqing -------------------------------------- A new version of I-D, draft-zhu-rmcat-nada-00.txt has been successfully submitted by Xiaoqing Zhu and posted to the IETF repository. Filename: draft-zhu-rmcat-nada Revision: 00 Title: NADA: A Unified Congestion Control Scheme for Real-Time Media Creation date: 2012-10-14 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-0= 0.txt Status: http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-00 Abstract: This document describes a scheme named network-assisted dynamic adaptation (NADA), a novel congestion control approach for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can reap the benefits of explicit congestion notification markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays instead. We present here the overall system architecture, recommended behaviors at the sender and the receiver, as well as expected network nodes operations. Results from extensive simulation studies of the proposed scheme are available upon request. The IETF Secretariat -------------------------------------- On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: Hi, On Oct 11, 2012, at 18:45, Xiaoqing Zhu > wrote: My colleague and I are working on a congestion control scheme for real-time conferencing applications at Cisco. A brief version of that algorithm was presented at the IAB Workshop in Vancouver (paper #12, "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due to time constraints, however, we did not get a chance to mention the delay-based variant of that scheme, which may be a better fit for rmcat. We would like to request for a slot to present in Atlanta. We will also submit the ID draft before Oct 15, for further discussions on this mailing list. I look forward to seeing the draft being discussed on the list! Also, I'm noting your request for a slot. Because the actual CC mechanisms = are not our most pressing milestones initially - the requirements and eval = criteria are - we may decide to focus our meeting time on those other draft= s, if demand for agenda time is high. Lars --_000_E7175A8E3DC14048A7D3020E0338C1FA0D7B838Fxmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <3FF0B6AA9A61EF4DB07371B3B91369CF@cisco.com> Content-Transfer-Encoding: quoted-printable
On Oct 29, 2012, at 10:23 AM, Stefan Holmer wrote:




On Mon, Oct 29, 2012 at 3:53 PM, Xiaoqing Zhu (x= iaoqzhu) <xiaoqzhu@cisco.com> wrote:
Hi Stefan, 

Thanks a lot for your comments. I'll add in more details on the descri= ption for the receiver actions. 

You are right, we did employ some filtering of the observed per-packet= queuing delay, to avoid erratic reactions in the sending rate. The queuing= delay employed in the rate calculation in Eq. (1) is actually the time-smo= othed averaging d_avg: 

d_avg =3D (1-alpha)*d_avg + d_n, where d_n represents the measured= queuing delay  (end-to-end delay minus minimum observed value) for th= e n-th packet. The parameter alpha adjusts the level of smoothness in our a= verage process. In our experiments, we are using alpha =3D 10e-4. 

Thanks. Just to be clear, 

d_n =3D receiver_time_n - timestamp_n - min_observed

and min_observed is the smallest d_n seen in some window?

That's right.  BTW, while the time-averaged filtering works well for u= s, for now, we are also considering building in more robustness against ind= ividual bad samples. The Kalman filtering approach presented in your propos= al seems to be a good candidate for that. Maybe there is a way to incorporate that approach here for the delay estim= ation as well.  What do you think?   


 

Also, it's obvious that Eq.(1) wouldn't hold for for d=3D0, in which c= ase the rate is chosen to be R_max.  As mentioned in the paragraph bel= ow Eq. (1), any calculated target rate R_o greater than R_max will also be = clipped to the R_max. 

Initially, I omitted these details in the draft proposal for brevity. = Given your comments and concerns, looks like I'd better put them back in fo= r clarity. 

Best,
Xiaoqing


On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote:

Hi Xiaoqing,

Interesting draft, I have a few questions related to the queuing delay= part of it.

"The role of the receiver is fairly straightforward. It observes = and estimates end-to-end queuing delay d and ECN marking ratio p of the str= eam. The former can be obtained from the RTP timestamp provided by the send= er."

You don't provide much detail on how the end-to-end queuing delay is e= stimated from the timestamps. Would it be possible to be more specific? Are= you employing a filter? Related to that, you seem to be running into a div= ide by zero in equation 1 if your queuing delay turns out to be zero. It also seems a bit bold to go directl= y from R_min to R_max if the queuing delay is low enough.

/Stefan




On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (= xiaoqzhu) <xiaoqzhu@cisco.com> wrote:
And below is the notification of our su= bmission: 

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename:  draft-zhu-rmcat= -nada
Revision:  00
Title:  NADA: A Unified Congestion Control Scheme for Rea= l-Time Media
Creation date:  2012-10-14=
WG ID:  Individual Submission
Number of pages: 10
URL:            &nbs= p;http://www.ietf.org/internet-drafts/d= raft-zhu-rmcat-nada-00.txt
Status:          http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada
Htmlized:        = http://tools.ietf.org/html/draft-zhu-rmcat-nada-00


Abstract:
  This document describes a scheme named network-assisted dynamic=
  adaptation (NADA), a novel congestion control approach for
  interactive real-time media applications, such as video confere= ncing.
  In the proposed scheme, the sender regulates its sending rate b= ased
  on either implicit or explicit congestion signaling, in a unifi= ed
  approach. The scheme can reap the benefits of explicit congesti= on
  notification markings from network nodes. It also maintains
  consistent sender behavior in the absence of such markings, by<= br>   reacting to queuing delays instead.

  We present here the overall system architecture, recommended   behaviors at the sender and the receiver, as well as expected n= etwork
  nodes operations. Results from extensive simulation studies of = the
  proposed scheme are available upon request.




The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <zhuxq@alumni.stanford.edu<= /a>> wrote:
My colleague and I are working on a congestion co= ntrol scheme for
real-time conferencing applications at Cisco. A b= rief version of that
algorithm was presented at the IAB Workshop in Va= ncouver (paper #12,
"Network-Assisted Dynamic Adaptation (NADA):= A Design Summary"). Due
to time constraints, however, we did not get a ch= ance to mention the
delay-based variant of that scheme, which may be = a better fit for
rmcat.

We would like to request for a slot to present in= Atlanta. We will
also submit the ID draft before Oct 15, for furth= er discussions on
this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC mechanisms = are not our most pressing milestones initially - the requirements and eval = criteria are - we may decide to focus our meeting time on those other draft= s, if demand for agenda time is high.

Lars





--_000_E7175A8E3DC14048A7D3020E0338C1FA0D7B838Fxmbalnx13ciscoc_-- From xiaoqzhu@cisco.com Mon Oct 29 11:26:10 2012 Return-Path: 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 065CC21F8702 for ; Mon, 29 Oct 2012 11:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLa7TyW6PwrR for ; Mon, 29 Oct 2012 11:26:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8999821F86EE for ; Mon, 29 Oct 2012 11:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16954; q=dns/txt; s=iport; t=1351535168; x=1352744768; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CQZHgFnIj9WESsqte/8FkoBa5i9vh81Ci58TBcJluic=; b=EIrhlmXL1nqd3QtT4cDlzXXtMGkwdXv1Hd3Zbiubf0GeFeDuKLAVABX4 oBWVYePDEnsojqZ/hYk8bdGg2XF1ivuQDwb+ruiD9YDDot/LeOegHZVvk 8r95cW75GlWdPP7N9DJ/0OnbvNEH+VTahBQxyZrPUyP9o/girL4Pei2En c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAHALrJjlCtJXG8/2dsb2JhbABEgm27UYQ+gQiCHgEBAQMBEgFbCwULAgEIDgoKHQcyFBECBA4FCAESB4deBgEKnASfcot1GoViYQOkS4Frgm+BZDU X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208,217";a="136609169" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 29 Oct 2012 18:26:03 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9TIQ3Wr019403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Oct 2012 18:26:03 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Mon, 29 Oct 2012 13:26:03 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: Michael Welzl Thread-Topic: [rmcat] send agenda requests (was Re: First meeting) Thread-Index: AQHNp9grf2quh6JMt0CYpuBNP/SHCpe1q3yAgAWVAgCAAK9XAIABXGsAgAAq3YCAAVQ0gIAKHsIAgACnJoCAAGt5gIAHDSIA Date: Mon, 29 Oct 2012 18:26:02 +0000 Message-ID: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> <7829361A-29CE-429B-A40B-BB63B76C56C9@ifi.uio.no> <39459900-49A0-4CA2-BAD4-46D6D27E3255@ifi.uio.no> <046762A3-6CCD-42A5-A6B0-9A65436DB86A@ifi.uio.no> In-Reply-To: <046762A3-6CCD-42A5-A6B0-9A65436DB86A@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.14.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19318.004 x-tm-as-result: No--48.519100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E7175A8E3DC14048A7D3020E0338C1FA0D7B96CDxmbalnx13ciscoc_" MIME-Version: 1.0 Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 18:26:10 -0000 --_000_E7175A8E3DC14048A7D3020E0338C1FA0D7B96CDxmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ah, okay. Thanks a lot for the clarification for the multi-hop scenario. In that case I will only worry about the scenario where ECN-capable and ECN= -incapable routers co-exist on the same path. -Xiaoqing On Oct 25, 2012, at 1:45 AM, Michael Welzl wrote: Hi, On 25. okt. 2012, at 02:20, Xiaoqing Zhu wrote: Michael, In general, I agree with you that we need a more graceful scheme to accommo= date both implicit and explicit congestion signals. Our current -00 draft o= bviously does not solve that yet. I'll add this important point to the "op= en issue" section of the draft, and also strive to find a solution for that= . Sure, I think we had already agreed, I just wanted to share this scenario t= hat came to my mind. However, I am not sure the dynamic scenario you describe will happen. If a = packet passes along both ECN-supported and non-ECN-supported routers, would= n't the ECN field bits in its header be marked as '00' (not ECN-capable), a= s specified in RFC 3168? In that case, even if congestion rises on the ECN= -enabled route, the sender will still be reacting to the rise in observed d= elay. RFC 3168 is long and it's been a while since the last time I read it, but: = I can't recall reading what you describe here. My understanding of ECN (in a nutshell) is: ECN-capable end hosts sent 01 o= r 10; ECN-incapable routers might not react to ECN at all, so anyway you ca= n't trust them to do something based on RFC 3168 if they don't implement RF= C 3168 :-) ; if an ECN-capable router sees a 01 or 10 packet, it may ma= rk it to 11; if an ECN-capable router sees a 00 packet, it drops it instead= of marking it. So, no way to reliably determine if there are some routers that do *not* su= pport ECN. Also, my understanding from the previous email threads on this mailing list= seems to say that multi-hop congested links are hard scenarios to tackle a= nyway. Do you think we should focus on that now, or defer it after we obta= in some satisfactory results from the simpler case of single-congested link= ? As I tried to explain in my earlier email about that: http://www.ietf.org/mail-archive/web/rmcat/current/msg00069.html this was about multiple hops in the overlay - multiple RTP end systems atta= ched to each other, to form a longer path, if you will. The underlay can al= ways have more than just one hop. Cheers, Michael Thanks, Xiaoqing On Wed, Oct 24, 2012 at 7:22 AM, Michael Welzl > wrote: Actually... It just occurred to me that the dynamic scenario (going from ECN-supported = to non-ECN-supported) is also quite realistic. Consider a situation where you traverse two routers: router 1, followed by = router 2. Router 1 isn't usually your bottleneck, but it supports ECN. Rout= er 2 doesn't support ECN, but is your bottleneck most of the time. Now, if a sudden traffic burst causes the queue of router 1 to grow, you wi= ll start to believe that there is ECN support, and stop using delay. But th= en, this queue might never grow again, all the congestion could happen in r= outer 2... My point is, *relying* on ECN to be there no matter how much feedback you g= et is probably always the wrong thing to do. We can always only take it as = a nice extra if its available, but I think we should never "switch to ECN m= ode". Cheers, Michael On 18. okt. 2012, at 05:49, Xiaoqing Zhu (xiaoqzhu) wrote: > Your points are well taken, Michael. > > > Agree that ultimately, it would be nice to have the scheme consider a mer= ge of delay and ECN signals, instead of switching naively between the two. = We considered that as a stretch goal though, according to the priorities di= scussed in the last BOF. We are still in the process of improving the algor= ithm in that aspect. > > I will put in some results from ECN-based marking in the compiled file to= share. But admitted, we have not yet explored the impact of all variations= of ECN configurations. I will need to run more tests for that. > > -Xiaoqing > > On Oct 17, 2012, at 12:31 AM, Michael Welzl wrote: > >> >> On 17. okt. 2012, at 06:58, Xiaoqing Zhu (xiaoqzhu) wrote: >> >>> Hi Michael, >>> >>> Thanks for your comments. Please find my replies inline below. >>> >>> Best, >>> Xiaoqing >>> >>> >>> On Oct 16, 2012, at 1:11 AM, Michael Welzl wrote: >>> >>>> Hi, >>>> >>>> I took a quick look at this: >>>> >>>> I like the general idea of using as much as possible of existing netwo= rk support - but I'm critical about the actual control you propose. >>>> >>>> In section 5.3.2, you suggest to replace eqn. 1 from section 5.3 with = eqn. 2 when ECN feedback is available. This means to ignore a delay signal = from now on, and interpret ECN marks in the exact same way as you interpret= ed delay before - this is too simplistic, I think. After all, ECN marks req= uire a queue to grow, and this group intends to minimize delay... why would= you stop using delay once you have ECN in addition? >>> >>> >>> In our design, we considered the two cases, with or without ECN marking= s, separately. Therefore, the dynamic scenario when ECN becomes available = in the middle of a video conferencing session has not yet been fully studie= d. Just wondering, are cases where ECN marking are turned on and off dynam= ically common in reality? >> >> First, anything can happen when you have a routing change. >> Second, I'm really sorry, but this wasn't what I meant. I shouldn't have= written "when" but "if". I wasn't referring to a case where we go from no-= ECN-support to ECN-support. So this is about the ECN-always-supported case. >> >> >>>> In practice, using your scheme would probably mean that, as soon as I = enable RED with ECN on the bottleneck between the two end systems, the user= s' observed delay grows. Not exactly an incentive? >>>> >>> What you mentioned (uers observing higher delay in ECN-enabled systems)= will not happen. >>> >>> But rather, our simulation results have indicated that ECN with RED-bas= ed marking yields fairly similar results as the default delay-based scheme.= They certainly do not incur higher delay, since the endpoint will automati= cally back off in face of higher ECN markings, which are indications of hig= her delay. The two systems (delay-based and ECN-based) can be tuned to stab= ilize that the same queuing delay at the bottleneck. >> >> Whether you see significant delay before you see a large enough amount o= f ECN markings depends on the queue length and RED parameters, none of whic= h are under the end system's control. ECN is also a probabilistic signal, s= o sometimes you may get delay growth but just be lucky (or unlucky) enough = to not get an ECN mark. >> >> So, I'd have to see results that involve various RED settings and queue = lengths before I believe that. >> >> Cheers, >> Michael >> > --_000_E7175A8E3DC14048A7D3020E0338C1FA0D7B96CDxmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <6A7C3100C48A9F4DB3D9ACC2B3A97BF5@cisco.com> Content-Transfer-Encoding: quoted-printable Ah, okay.  Thanks a lot for the clarification for the multi-hop scenar= io. 

In that case I will only worry about the scenario where ECN-capable an= d ECN-incapable routers co-exist on the same path. 

-Xiaoqing


On Oct 25, 2012, at 1:45 AM, Michael Welzl wrote:

Hi,


On 25. okt. 2012, at 02:20, Xiaoqing Zhu wrote:

Michael, 

In general, I agree with you that we need a more graceful scheme to ac= commodate both implicit and explicit congestion signals. Our current -00 dr= aft obviously does not solve that yet.  I'll add this important point = to the "open issue" section of the draft, and also strive to find a solution for that.  

Sure, I think we had already agreed, I just wanted to share this scena= rio that came to my mind.


However, I am not sure the dynamic scenario you describe will happen.&= nbsp;If a packet passes along both ECN-supported and non-ECN-supported rout= ers, wouldn't the ECN field bits in its header be marked as '00' (not ECN-c= apable), as specified in RFC 3168?  In that case, even if congestion rises on the ECN-enabled route, the sender w= ill still be reacting to the rise in observed delay. 

RFC 3168 is long and it's been a while since the last time I read it, = but: I can't recall reading what you describe here.
My understanding of ECN (in a nutshell) is: ECN-capable end hosts sent 01 o= r 10; ECN-incapable routers might not react to ECN at all, so anyway you ca= n't trust them to do something based on RFC 3168 if they don't implement RF= C 3168  :-)    ; if an ECN-capable router sees a 01 or 10 packet, it may mark it to 11; if an ECN-capable rou= ter sees a 00 packet, it drops it instead of marking it.

So, no way to reliably determine if there are some routers that do *no= t* support ECN.
Michael



Thanks,
Xiaoqing


On Wed, Oct 24, 2012 at 7:22 AM, Michael Welzl <= span dir=3D"ltr"> <michawe@ifi.uio= .no> wrote:
Actually...

It just occurred to me that the dynamic scenario (going from ECN-supported = to non-ECN-supported) is also quite realistic.
Consider a situation where you traverse two routers: router 1, followed by = router 2. Router 1 isn't usually your bottleneck, but it supports ECN. Rout= er 2 doesn't support ECN, but is your bottleneck most of the time.

Now, if a sudden traffic burst causes the queue of router 1 to grow, you wi= ll start to believe that there is ECN support, and stop using delay. But th= en, this queue might never grow again, all the congestion could happen in r= outer 2...

My point is, *relying* on ECN to be there no matter how much feedback you g= et is probably always the wrong thing to do. We can always only take it as = a nice extra if its available, but I think we should never "switch to = ECN mode".

Cheers,
Michael


On 18. okt. 2012, at 05:49, Xiaoqing Zhu (xiaoqzhu) wrote:

> Your points are well taken, Michael.
>
>
> Agree that ultimately, it would be nice to have the scheme consider a = merge of delay and ECN signals, instead of switching naively between the tw= o. We considered that as a stretch goal though, according to the priorities= discussed in the last BOF. We are still in the process of improving the algorithm in that aspect.
>
> I will put in some results from ECN-based marking in the compiled file= to share. But admitted, we have not yet explored the impact of all variati= ons of ECN configurations.  I will need to run more tests for that. >
> -Xiaoqing
>
> On Oct 17, 2012, at 12:31 AM, Michael Welzl wrote:
>
>>
>> On 17. okt. 2012, at 06:58, Xiaoqing Zhu (xiaoqzhu) wrote:
>>
>>> Hi Michael,
>>>
>>> Thanks for your comments.  Please find my replies inline = below.
>>>
>>> Best,
>>> Xiaoqing
>>>
>>>
>>> On Oct 16, 2012, at 1:11 AM, Michael Welzl wrote:
>>>
>>>> Hi,
>>>>
>>>> I took a quick look at this:
>>>>
>>>> I like the general idea of using as much as possible of ex= isting network support - but I'm critical about the actual control you prop= ose.
>>>>
>>>> In section 5.3.2, you suggest to replace eqn. 1 from secti= on 5.3 with eqn. 2 when ECN feedback is available. This means to ignore a d= elay signal from now on, and interpret ECN marks in the exact same way as y= ou interpreted delay before - this is too simplistic, I think. After all, ECN marks require a queue to grow, and this group inte= nds to minimize delay... why would you stop using delay once you have ECN i= n addition?
>>>
>>>
>>> In our design, we considered the two cases, with or without EC= N markings, separately.  Therefore, the dynamic scenario when ECN beco= mes available in the middle of a video conferencing session has not yet bee= n fully studied.  Just wondering, are cases where ECN marking are turned on and off dynamically common in reality?
>>
>> First, anything can happen when you have a routing change.
>> Second, I'm really sorry, but this wasn't what I meant. I shouldn'= t have written "when" but "if". I wasn't referring to a= case where we go from no-ECN-support to ECN-support. So this is about the = ECN-always-supported case.
>>
>>
>>>> In practice, using your scheme would probably mean that, a= s soon as I enable RED with ECN on the bottleneck between the two end syste= ms, the users' observed delay grows. Not exactly an incentive?
>>>>
>>> What you mentioned (uers observing higher delay in ECN-enabled= systems) will not happen.
>>>
>>> But rather, our simulation results have indicated that ECN wit= h RED-based marking yields fairly similar results as the default delay-base= d scheme. They certainly do not incur higher delay, since the endpoint will= automatically back off in face of higher ECN markings, which are indications of higher delay. The two systems (dela= y-based and ECN-based) can be tuned to stabilize that the same queuing dela= y at the bottleneck.
>>
>> Whether you see significant delay before you see a large enough am= ount of ECN markings depends on the queue length and RED parameters, none o= f which are under the end system's control. ECN is also a probabilistic sig= nal, so sometimes you may get delay growth but just be lucky (or unlucky) enough to not get an ECN mark.
>>
>> So, I'd have to see results that involve various RED settings and = queue lengths before I believe that.
>>
>> Cheers,
>> Michael
>>
>




--_000_E7175A8E3DC14048A7D3020E0338C1FA0D7B96CDxmbalnx13ciscoc_-- From p.ohanlon@gmail.com Tue Oct 30 03:09:01 2012 Return-Path: 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 CA56321F84E2 for ; Tue, 30 Oct 2012 03:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLR+XcZxSLSy for ; Tue, 30 Oct 2012 03:09:00 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3960D21F84A9 for ; Tue, 30 Oct 2012 03:09:00 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so2530172wib.13 for ; Tue, 30 Oct 2012 03:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=tB3yCH1ajpoEdvl5/2qDiRKvTz3ZWoy0Q8yMqxhBwQ0=; b=YejDxmTTlxDqTS4Euf2PT3ZKm0N/Hz73e94FM3I+3LhHOp9AV46AguiWDnz6yH1mdH +dnAveXYoiz4C8Lo108KFjaR5+SuYCSTcYYC8c3BkIogoFMt2Vu5ftdTxR1fxC32/6Zz vQpxZi0zSCJrh1wDlkH+TjDcxAdHYDfzjVUGm561bb56mXcCAL9C9rxlG1iRe6SsyCE/ 2Zm+Yr9lpu19Fjvem90sLQbIdZc+60IW6fi9x66mM1VmDrkoV4lRWNx4cH4Abt9WI5Jb FLxxQweN2fg33/i5E8TLEx7HvIvyaReaWqeSWeLmnWMKMrC3a22o32QPQ3v2r5W6UQLO xltw== Received: by 10.216.134.85 with SMTP id r63mr15813719wei.150.1351591739241; Tue, 30 Oct 2012 03:08:59 -0700 (PDT) Received: from ?IPv6:2001:470:1f09:d24:70a1:44da:3019:23ee? ([2001:470:1f09:d24:70a1:44da:3019:23ee]) by mx.google.com with ESMTPS id dq6sm13273469wib.5.2012.10.30.03.08.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 03:08:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_BE385D87-819D-4576-847F-D7D75130CF3A" From: Piers O'Hanlon In-Reply-To: Date: Tue, 30 Oct 2012 10:08:39 +0000 Message-Id: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> To: "Xiaoqing Zhu (xiaoqzhu)" X-Mailer: Apple Mail (2.1283) Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , Stefan Holmer , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 10:09:01 -0000 --Apple-Mail=_BE385D87-819D-4576-847F-D7D75130CF3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Presumably by time-smooth average you mean EWMA - so you're missing an = alpha? > d_avg =3D (1-alpha)*d_avg + d_n Should be: d_avg =3D (1-alpha)*d_avg + alpha*d_n Piers. On 29 Oct 2012, at 15:28, Xiaoqing Zhu (xiaoqzhu) wrote: >=20 > On Oct 29, 2012, at 10:23 AM, Stefan Holmer wrote: >=20 >>=20 >>=20 >>=20 >> On Mon, Oct 29, 2012 at 3:53 PM, Xiaoqing Zhu (xiaoqzhu) = wrote: >> Hi Stefan,=20 >>=20 >> Thanks a lot for your comments. I'll add in more details on the = description for the receiver actions.=20 >>=20 >> You are right, we did employ some filtering of the observed = per-packet queuing delay, to avoid erratic reactions in the sending = rate. The queuing delay employed in the rate calculation in Eq. (1) is = actually the time-smoothed averaging d_avg:=20 >>=20 >> d_avg =3D (1-alpha)*d_avg + d_n, where d_n represents the measured = queuing delay (end-to-end delay minus minimum observed value) for the = n-th packet. The parameter alpha adjusts the level of smoothness in our = average process. In our experiments, we are using alpha =3D 10e-4.=20 >>=20 >> Thanks. Just to be clear,=20 >>=20 >> d_n =3D receiver_time_n - timestamp_n - min_observed >>=20 >> and min_observed is the smallest d_n seen in some window? >=20 > That's right. BTW, while the time-averaged filtering works well for = us, for now, we are also considering building in more robustness against = individual bad samples. The Kalman filtering approach presented in your = proposal seems to be a good candidate for that. Maybe there is a way to = incorporate that approach here for the delay estimation as well. What = do you think? =20 >=20 >=20 >> =20 >>=20 >> Also, it's obvious that Eq.(1) wouldn't hold for for d=3D0, in which = case the rate is chosen to be R_max. As mentioned in the paragraph = below Eq. (1), any calculated target rate R_o greater than R_max will = also be clipped to the R_max.=20 >>=20 >> Initially, I omitted these details in the draft proposal for brevity. = Given your comments and concerns, looks like I'd better put them back in = for clarity.=20 >>=20 >> Best, >> Xiaoqing >>=20 >>=20 >> On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote: >>=20 >>> Hi Xiaoqing, >>>=20 >>> Interesting draft, I have a few questions related to the queuing = delay part of it. >>>=20 >>> "The role of the receiver is fairly straightforward. It observes and = estimates end-to-end queuing delay d and ECN marking ratio p of the = stream. The former can be obtained from the RTP timestamp provided by = the sender." >>>=20 >>> You don't provide much detail on how the end-to-end queuing delay is = estimated from the timestamps. Would it be possible to be more specific? = Are you employing a filter? Related to that, you seem to be running into = a divide by zero in equation 1 if your queuing delay turns out to be = zero. It also seems a bit bold to go directly from R_min to R_max if the = queuing delay is low enough. >>>=20 >>> /Stefan >>>=20 >>>=20 >>>=20 >>>=20 >>> On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (xiaoqzhu) = wrote: >>> And below is the notification of our submission:=20 >>>=20 >>> Thanks, >>> Xiaoqing >>>=20 >>> -------------------------------------- >>> A new version of I-D, draft-zhu-rmcat-nada-00.txt >>> has been successfully submitted by Xiaoqing Zhu and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-zhu-rmcat-nada >>> Revision: 00 >>> Title: NADA: A Unified Congestion Control Scheme for Real-Time = Media >>> Creation date: 2012-10-14 >>> WG ID: Individual Submission >>> Number of pages: 10 >>> URL: = http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt >>> Status: = http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada >>> Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-00 >>>=20 >>>=20 >>> Abstract: >>> This document describes a scheme named network-assisted dynamic >>> adaptation (NADA), a novel congestion control approach for >>> interactive real-time media applications, such as video = conferencing. >>> In the proposed scheme, the sender regulates its sending rate = based >>> on either implicit or explicit congestion signaling, in a unified >>> approach. The scheme can reap the benefits of explicit congestion >>> notification markings from network nodes. It also maintains >>> consistent sender behavior in the absence of such markings, by >>> reacting to queuing delays instead. >>>=20 >>> We present here the overall system architecture, recommended >>> behaviors at the sender and the receiver, as well as expected = network >>> nodes operations. Results from extensive simulation studies of the >>> proposed scheme are available upon request. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>> -------------------------------------- >>> On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: >>>=20 >>>> Hi, >>>>=20 >>>> On Oct 11, 2012, at 18:45, Xiaoqing Zhu = wrote: >>>>> My colleague and I are working on a congestion control scheme for >>>>> real-time conferencing applications at Cisco. A brief version of = that >>>>> algorithm was presented at the IAB Workshop in Vancouver (paper = #12, >>>>> "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). = Due >>>>> to time constraints, however, we did not get a chance to mention = the >>>>> delay-based variant of that scheme, which may be a better fit for >>>>> rmcat. >>>>>=20 >>>>> We would like to request for a slot to present in Atlanta. We will >>>>> also submit the ID draft before Oct 15, for further discussions on >>>>> this mailing list. >>>>=20 >>>> I look forward to seeing the draft being discussed on the list! >>>>=20 >>>> Also, I'm noting your request for a slot. Because the actual CC = mechanisms are not our most pressing milestones initially - the = requirements and eval criteria are - we may decide to focus our meeting = time on those other drafts, if demand for agenda time is high.=20 >>>>=20 >>>> Lars >>>=20 >>>=20 >>=20 >>=20 >=20 --Apple-Mail=_BE385D87-819D-4576-847F-D7D75130CF3A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi,

Presumably by time-smooth average you mean EWMA - so you're missing an alpha?

d_avg = (1-alpha)*d_avg + d_n

Should be:  d_avg = (1-alpha)*d_avg + alpha*d_n

Piers.

On 29 Oct 2012, at 15:28, Xiaoqing Zhu (xiaoqzhu) wrote:


On Oct 29, 2012, at 10:23 AM, Stefan Holmer wrote:




On Mon, Oct 29, 2012 at 3:53 PM, Xiaoqing Zhu (xiaoqzhu) <xiaoqzhu@cisco.com> wrote:
Hi Stefan, 

Thanks a lot for your comments. I'll add in more details on the description for the receiver actions. 

You are right, we did employ some filtering of the observed per-packet queuing delay, to avoid erratic reactions in the sending rate. The queuing delay employed in the rate calculation in Eq. (1) is actually the time-smoothed averaging d_avg: 

d_avg = (1-alpha)*d_avg + d_n, where d_n represents the measured queuing delay  (end-to-end delay minus minimum observed value) for the n-th packet. The parameter alpha adjusts the level of smoothness in our average process. In our experiments, we are using alpha = 10e-4. 

Thanks. Just to be clear, 

d_n = receiver_time_n - timestamp_n - min_observed

and min_observed is the smallest d_n seen in some window?

That's right.  BTW, while the time-averaged filtering works well for us, for now, we are also considering building in more robustness against individual bad samples. The Kalman filtering approach presented in your proposal seems to be a good candidate for that. Maybe there is a way to incorporate that approach here for the delay estimation as well.  What do you think?   


 

Also, it's obvious that Eq.(1) wouldn't hold for for d=0, in which case the rate is chosen to be R_max.  As mentioned in the paragraph below Eq. (1), any calculated target rate R_o greater than R_max will also be clipped to the R_max. 

Initially, I omitted these details in the draft proposal for brevity. Given your comments and concerns, looks like I'd better put them back in for clarity. 

Best,
Xiaoqing


On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote:

Hi Xiaoqing,

Interesting draft, I have a few questions related to the queuing delay part of it.

"The role of the receiver is fairly straightforward. It observes and estimates end-to-end queuing delay d and ECN marking ratio p of the stream. The former can be obtained from the RTP timestamp provided by the sender."

You don't provide much detail on how the end-to-end queuing delay is estimated from the timestamps. Would it be possible to be more specific? Are you employing a filter? Related to that, you seem to be running into a divide by zero in equation 1 if your queuing delay turns out to be zero. It also seems a bit bold to go directly from R_min to R_max if the queuing delay is low enough.

/Stefan




On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (xiaoqzhu) <xiaoqzhu@cisco.com> wrote:
And below is the notification of our submission: 

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename:  draft-zhu-rmcat-nada
Revision:  00
Title:  NADA: A Unified Congestion Control Scheme for Real-Time Media
Creation date:  2012-10-14
WG ID:  Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt
Status:          http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada
Htmlized:        http://tools.ietf.org/html/draft-zhu-rmcat-nada-00


Abstract:
  This document describes a scheme named network-assisted dynamic
  adaptation (NADA), a novel congestion control approach for
  interactive real-time media applications, such as video conferencing.
  In the proposed scheme, the sender regulates its sending rate based
  on either implicit or explicit congestion signaling, in a unified
  approach. The scheme can reap the benefits of explicit congestion
  notification markings from network nodes. It also maintains
  consistent sender behavior in the absence of such markings, by
  reacting to queuing delays instead.

  We present here the overall system architecture, recommended
  behaviors at the sender and the receiver, as well as expected network
  nodes operations. Results from extensive simulation studies of the
  proposed scheme are available upon request.




The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <zhuxq@alumni.stanford.edu> wrote:
My colleague and I are working on a congestion control scheme for
real-time conferencing applications at Cisco. A brief version of that
algorithm was presented at the IAB Workshop in Vancouver (paper #12,
"Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due
to time constraints, however, we did not get a chance to mention the
delay-based variant of that scheme, which may be a better fit for
rmcat.

We would like to request for a slot to present in Atlanta. We will
also submit the ID draft before Oct 15, for further discussions on
this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC mechanisms are not our most pressing milestones initially - the requirements and eval criteria are - we may decide to focus our meeting time on those other drafts, if demand for agenda time is high.

Lars






--Apple-Mail=_BE385D87-819D-4576-847F-D7D75130CF3A-- From holmer@google.com Tue Oct 30 04:22:04 2012 Return-Path: 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 18E2E21F8545 for ; Tue, 30 Oct 2012 04:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aycWplRQpMHw for ; Tue, 30 Oct 2012 04:22:01 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1660721F8518 for ; Tue, 30 Oct 2012 04:22:00 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so221208iec.31 for ; Tue, 30 Oct 2012 04:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=S18nfNkHzl/g6Cp22UrshPbIsW8+BcBt9e4Lto9o8k0=; b=ScMITD8UX8cPS5/n91GsyPJ7jIe88k0dkC2gR0kw2UPAdLU0mT6m+AqRiSbF1LFVjV Latjq3/5j+W/MZ68tlTnxF1oATmrVz9FwC+Ug+VSdQJMEerAwRPB1pIwZTWajW/juDBX mLuKsmJveomsUFt61dpnquPrzwKmm6FTR+xLT3OsIhxIoBxCVBQtR1Jb4q812j7bIRqV 5HPAAvXghIyxcHA8NBuazjAdQ4/v4RsgMz+TpyMuExoYyNv9HDt7lKB549NNABmJFIgL q34CiJtIO31AwlJV3mEdAYA69Omi2iW/466wOXxhlpSrWKh5MWbjf9P7sLD6TLEM54M8 HFWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=S18nfNkHzl/g6Cp22UrshPbIsW8+BcBt9e4Lto9o8k0=; b=dbvUQfhvFapax3siyf3BqdnlzeaKxBI9/O/lkM58gdHZrwC2mkabseCDsyp5rMkMhf AKnLNsTumHg9o104hYMgSwElhlWyZVj4hyO4oh15crHoS29pC20cTqkwj9K8K7VnCmKK f9+PAKHUGRqp1K1sc/9lRBwPyjSvjVMS0TU5ixUvb37CAcyxtRxiR4kWZ8mtO1iv1njN 3AetNvuUHoH1aKw2Ct2BDFVVeFZA5EgswJpZ2TlLCZ1/wKjV0x3U5u3NWY8zlClPYPmW lzaJBKYJdbaB1+PRF0njCvOdc4a5KH3q/nteVxQ/PayNT7wKOA+lmVorLwLBdYjCfnxA 7eMA== MIME-Version: 1.0 Received: by 10.50.217.169 with SMTP id oz9mr1123147igc.15.1351596120504; Tue, 30 Oct 2012 04:22:00 -0700 (PDT) Sender: holmer@google.com Received: by 10.50.74.169 with HTTP; Tue, 30 Oct 2012 04:22:00 -0700 (PDT) In-Reply-To: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> Date: Tue, 30 Oct 2012 12:22:00 +0100 X-Google-Sender-Auth: zo3IxtZB6tOgRYCybbnBvbOUoVc Message-ID: From: Stefan Holmer To: "Xiaoqing Zhu (xiaoqzhu)" Content-Type: multipart/alternative; boundary=14dae934061fa4783804cd44fe3e X-System-Of-Record: true X-Gm-Message-State: ALoCoQnX0vlXtAQPpo3B+rhe65ZmpNFFg6qe22OLfn1Wlpn0ZT26L85bHTCjqvYumr35wTXy+vph7eSyZZG2AUxVpp56kRCli4LlPe/HFWa9Y30WfEVg7lPCE59uIp3k7AKdXlIUZGusTJ4bVN7rknsmfWxJzhR+LrV/1jN75EGBbwHws9RM6xeVXHeo7dycvhNCUWU+eRN/ Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:22:04 -0000 --14dae934061fa4783804cd44fe3e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 29, 2012 at 4:28 PM, Xiaoqing Zhu (xiaoqzhu) wrote: > > On Oct 29, 2012, at 10:23 AM, Stefan Holmer wrote: > > > > > On Mon, Oct 29, 2012 at 3:53 PM, Xiaoqing Zhu (xiaoqzhu) < > xiaoqzhu@cisco.com> wrote: > >> Hi Stefan, >> >> Thanks a lot for your comments. I'll add in more details on the >> description for the receiver actions. >> >> You are right, we did employ some filtering of the observed per-packet >> queuing delay, to avoid erratic reactions in the sending rate. The queuing >> delay employed in the rate calculation in Eq. (1) is actually the >> time-smoothed averaging d_avg: >> >> d_avg = (1-alpha)*d_avg + d_n, where d_n represents the measured >> queuing delay (end-to-end delay minus minimum observed value) for the n-th >> packet. The parameter alpha adjusts the level of smoothness in our average >> process. In our experiments, we are using alpha = 10e-4. >> > > Thanks. Just to be clear, > > d_n = receiver_time_n - timestamp_n - min_observed > > and min_observed is the smallest d_n seen in some window? > > > That's right. BTW, while the time-averaged filtering works well for us, > for now, we are also considering building in more robustness against > individual bad samples. The Kalman filtering approach presented in your > proposal seems to be a good candidate for that. Maybe there is a way to > incorporate that approach here for the delay estimation as well. What do > you think? > > That would be an option. Note that RRTCC isn't based on one-way delay estimates but on inter-arrival time, which is changes in one-way delay. > > > >> >> Also, it's obvious that Eq.(1) wouldn't hold for for d=0, in which case >> the rate is chosen to be R_max. As mentioned in the paragraph below Eq. >> (1), any calculated target rate R_o greater than R_max will also be clipped >> to the R_max. >> >> Initially, I omitted these details in the draft proposal for brevity. >> Given your comments and concerns, looks like I'd better put them back in >> for clarity. >> >> Best, >> Xiaoqing >> >> >> On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote: >> >> Hi Xiaoqing, >> >> Interesting draft, I have a few questions related to the queuing delay >> part of it. >> >> "The role of the receiver is fairly straightforward. It observes and >> estimates end-to-end queuing delay d and ECN marking ratio p of the stream. >> The former can be obtained from the RTP timestamp provided by the sender." >> >> You don't provide much detail on how the end-to-end queuing delay is >> estimated from the timestamps. Would it be possible to be more specific? >> Are you employing a filter? Related to that, you seem to be running into a >> divide by zero in equation 1 if your queuing delay turns out to be zero. It >> also seems a bit bold to go directly from R_min to R_max if the queuing >> delay is low enough. >> >> /Stefan >> >> >> >> >> On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (xiaoqzhu) < >> xiaoqzhu@cisco.com> wrote: >> >>> And below is the notification of our submission: >>> >>> Thanks, >>> Xiaoqing >>> >>> -------------------------------------- >>> A new version of I-D, draft-zhu-rmcat-nada-00.txt >>> has been successfully submitted by Xiaoqing Zhu and posted to the >>> IETF repository. >>> >>> Filename: draft-zhu-rmcat-nada >>> Revision: 00 >>> Title: NADA: A Unified Congestion Control Scheme for Real-Time Media >>> Creation date: 2012-10-14 >>> WG ID: Individual Submission >>> Number of pages: 10 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada >>> Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-00 >>> >>> >>> Abstract: >>> This document describes a scheme named network-assisted dynamic >>> adaptation (NADA), a novel congestion control approach for >>> interactive real-time media applications, such as video conferencing. >>> In the proposed scheme, the sender regulates its sending rate based >>> on either implicit or explicit congestion signaling, in a unified >>> approach. The scheme can reap the benefits of explicit congestion >>> notification markings from network nodes. It also maintains >>> consistent sender behavior in the absence of such markings, by >>> reacting to queuing delays instead. >>> >>> We present here the overall system architecture, recommended >>> behaviors at the sender and the receiver, as well as expected network >>> nodes operations. Results from extensive simulation studies of the >>> proposed scheme are available upon request. >>> >>> >>> >>> >>> The IETF Secretariat >>> -------------------------------------- >>> On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: >>> >>> Hi, >>> >>> On Oct 11, 2012, at 18:45, Xiaoqing Zhu >>> wrote: >>> >>> My colleague and I are working on a congestion control scheme for >>> >>> real-time conferencing applications at Cisco. A brief version of that >>> >>> algorithm was presented at the IAB Workshop in Vancouver (paper #12, >>> >>> "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due >>> >>> to time constraints, however, we did not get a chance to mention the >>> >>> delay-based variant of that scheme, which may be a better fit for >>> >>> rmcat. >>> >>> >>> We would like to request for a slot to present in Atlanta. We will >>> >>> also submit the ID draft before Oct 15, for further discussions on >>> >>> this mailing list. >>> >>> >>> I look forward to seeing the draft being discussed on the list! >>> >>> Also, I'm noting your request for a slot. Because the actual CC >>> mechanisms are not our most pressing milestones initially - the >>> requirements and eval criteria are - we may decide to focus our meeting >>> time on those other drafts, if demand for agenda time is high. >>> >>> Lars >>> >>> >>> >> >> > > --14dae934061fa4783804cd44fe3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, O= ct 29, 2012 at 4:28 PM, Xiaoqing Zhu (xiaoqzhu) <xiaoqzh= u@cisco.com> wrote:

On Oct 29, 2012, at 10:23 AM, Stefan Holmer wrote:




On Mon, Oct 29, 2012 at 3:53 PM, Xiaoqing Zhu (x= iaoqzhu) <xiaoqzhu@cisco.com> wrote:
Hi Stefan,=A0

Thanks a lot for your comments. I'll add in more details on the de= scription for the receiver actions.=A0

You are right, we did employ some filtering of the observed per-packet= queuing delay, to avoid erratic reactions in the sending rate. The queuing= delay employed in the rate calculation in Eq. (1) is actually the time-smo= othed averaging d_avg:=A0

d_avg =3D (1-alpha)*d_avg + d_n, where d_n represents the measured que= uing delay =A0(end-to-end delay minus minimum observed value) for the n-th = packet. The parameter alpha adjusts the level of smoothness in our average = process. In our experiments, we are using alpha =3D 10e-4.=A0

Thanks. Just to be clear,=A0

d_n =3D receiver_time_n - timestamp_n - min_observed

and min_observed is the smallest d_n seen in some window?

That's right. =A0BTW, while the time-averaged filtering works well for = us, for now, we are also considering building in more robustness against in= dividual bad samples. The Kalman filtering approach presented in your propo= sal seems to be a good candidate for that. Maybe there is a way to incorporate that approach here for the delay estim= ation as well. =A0What do you think? =A0=A0


That woul= d be an option. Note that RRTCC isn't based on one-way delay estimates = but on inter-arrival time, which is changes in one-way delay.
=A0

=A0

Also, it's obvious that Eq.(1) wouldn't hold for for d=3D0, in= which case the rate is chosen to be R_max. =A0As mentioned in the paragrap= h below Eq. (1), any calculated target rate R_o greater than R_max will als= o be clipped to the R_max.=A0

Initially, I omitted these details in the draft proposal for brevity. = Given your comments and concerns, looks like I'd better put them back i= n for clarity.=A0

Best,
Xiaoqing


On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote:

Hi Xiaoqing,

Interesting draft, I have a few questions related to the queuing delay= part of it.

"The role of the receiver is fairly straightforward. It observes = and estimates end-to-end queuing delay d and ECN marking ratio p of the str= eam. The former can be obtained from the RTP timestamp provided by the send= er."

You don't provide much detail on how the end-to-end queuing delay = is estimated from the timestamps. Would it be possible to be more specific?= Are you employing a filter? Related to that, you seem to be running into a= divide by zero in equation 1 if your queuing delay turns out to be zero. It also seems a bit bold to go directl= y from R_min to R_max if the queuing delay is low enough.

/Stefan




On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (= xiaoqzhu) <xiaoqzhu@cisco.com> wrote:
And below is the notification of our su= bmission:=A0

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename: =A0draft-zhu-rmcat-na= da
Revision: =A000
Title: =A0NADA: A Unified Congestion Control Scheme for Real-T= ime Media
Creation date: =A02012-10-14 WG ID: =A0Individual Submission
Number of pages: 10
URL: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt
Status: =A0=A0=A0=A0=A0=A0=A0=A0=A0http://datatrac= ker.ietf.org/doc/draft-zhu-rmcat-nada
Htmlized: =A0=A0=A0=A0=A0=A0=A0http://tools.ietf.org= /html/draft-zhu-rmcat-nada-00


Abstract:
=A0=A0This document describes a scheme named network-assisted dynamic
=A0=A0adaptation (NADA), a novel congestion control approach for
=A0=A0interactive real-time media applications, such as video conferencing.=
=A0=A0In the proposed scheme, the sender regulates its sending rate based =A0=A0on either implicit or explicit congestion signaling, in a unified
=A0=A0approach. The scheme can reap the benefits of explicit congestion
=A0=A0notification markings from network nodes. It also maintains
=A0=A0consistent sender behavior in the absence of such markings, by
=A0=A0reacting to queuing delays instead.

=A0=A0We present here the overall system architecture, recommended
=A0=A0behaviors at the sender and the receiver, as well as expected network=
=A0=A0nodes operations. Results from extensive simulation studies of the =A0=A0proposed scheme are available upon request.




The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <zhuxq@alumni.stanford.edu<= /a>> wrote:
My colleague and I are working on a congestion co= ntrol scheme for
real-time conferencing applications at Cisco. A b= rief version of that
algorithm was presented at the IAB Workshop in Va= ncouver (paper #12,
"Network-Assisted Dynamic Adaptation (NADA):= A Design Summary"). Due
to time constraints, however, we did not get a ch= ance to mention the
delay-based variant of that scheme, which may be = a better fit for
rmcat.

We would like to request for a slot to present in= Atlanta. We will
also submit the ID draft before Oct 15, for furth= er discussions on
this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC mechani= sms are not our most pressing milestones initially - the requirements and e= val criteria are - we may decide to focus our meeting time on those other d= rafts, if demand for agenda time is high.

Lars






--14dae934061fa4783804cd44fe3e-- From xiaoqzhu@cisco.com Tue Oct 30 07:36:14 2012 Return-Path: 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 56CDA21F845A for ; Tue, 30 Oct 2012 07:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeOiOXZkyWtu for ; Tue, 30 Oct 2012 07:36:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A7F9021F8449 for ; Tue, 30 Oct 2012 07:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17311; q=dns/txt; s=iport; t=1351607772; x=1352817372; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8Z3nDdkebiGT/x2a9hIJQnkqJuSPF2fNqMKTPdH87Cg=; b=b7GqSYDQhJJQwGd2hQvONoR9dFGwsIRFihbz38tE9mK+wKlK++bggwyI MWc0Jub4Bz0Ghgi9/dVOHC/k132wqVycrrZcIr6QK1U2t+vA9Bo55py9U 4yMpvBkH0VReHJ87jpYOvf/tMsITYhGWIm4l7TTvRh8vAI4p0m9Z8tBy/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIGAIrkj1CtJXG9/2dsb2JhbABEgm2uZIh5AYYugk+BCIIfAQEEEgFbCxACAQgSEB0HMhQDDgIEDgUIARmHZAEKnHWPZ5A7i3eFfGEDlw+NPYFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208,217";a="133907808" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 30 Oct 2012 14:36:12 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9UEaC1E008533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 14:36:12 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 09:36:11 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "Piers O'Hanlon" Thread-Topic: [rmcat] send agenda requests (was Re: First meeting) Thread-Index: AQHNp9grf2quh6JMt0CYpuBNP/SHCpe1q3yAgAWVAgCAFYClAIAADUEAgAAIdICAAAFVgIABOQSAgABKwIA= Date: Tue, 30 Oct 2012 14:36:10 +0000 Message-ID: References: <201210021809.19685.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.84.184] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19320.004 x-tm-as-result: No--57.207800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E7175A8E3DC14048A7D3020E0338C1FA0D7BB19Fxmbalnx13ciscoc_" MIME-Version: 1.0 Cc: rmcat WG , Xiaoqing Zhu , "Eggert, Lars" , Stefan Holmer , "Rong Pan \(ropan\)" Subject: Re: [rmcat] send agenda requests (was Re: First meeting) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:36:14 -0000 --_000_E7175A8E3DC14048A7D3020E0338C1FA0D7BB19Fxmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oops. Sorry about the typo. Yes, there is the alpha for the second term. Best, Xiaoqing On Oct 30, 2012, at 5:08 AM, Piers O'Hanlon wrote: Hi, Presumably by time-smooth average you mean EWMA - so you're missing an alph= a? d_avg =3D (1-alpha)*d_avg + d_n Should be: d_avg =3D (1-alpha)*d_avg + alpha*d_n Piers. On 29 Oct 2012, at 15:28, Xiaoqing Zhu (xiaoqzhu) wrote: On Oct 29, 2012, at 10:23 AM, Stefan Holmer wrote: On Mon, Oct 29, 2012 at 3:53 PM, Xiaoqing Zhu (xiaoqzhu) > wrote: Hi Stefan, Thanks a lot for your comments. I'll add in more details on the description= for the receiver actions. You are right, we did employ some filtering of the observed per-packet queu= ing delay, to avoid erratic reactions in the sending rate. The queuing dela= y employed in the rate calculation in Eq. (1) is actually the time-smoothed= averaging d_avg: d_avg =3D (1-alpha)*d_avg + d_n, where d_n represents the measured queuing = delay (end-to-end delay minus minimum observed value) for the n-th packet.= The parameter alpha adjusts the level of smoothness in our average process= . In our experiments, we are using alpha =3D 10e-4. Thanks. Just to be clear, d_n =3D receiver_time_n - timestamp_n - min_observed and min_observed is the smallest d_n seen in some window? That's right. BTW, while the time-averaged filtering works well for us, fo= r now, we are also considering building in more robustness against individu= al bad samples. The Kalman filtering approach presented in your proposal se= ems to be a good candidate for that. Maybe there is a way to incorporate th= at approach here for the delay estimation as well. What do you think? Also, it's obvious that Eq.(1) wouldn't hold for for d=3D0, in which case t= he rate is chosen to be R_max. As mentioned in the paragraph below Eq. (1)= , any calculated target rate R_o greater than R_max will also be clipped to= the R_max. Initially, I omitted these details in the draft proposal for brevity. Given= your comments and concerns, looks like I'd better put them back in for cla= rity. Best, Xiaoqing On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote: Hi Xiaoqing, Interesting draft, I have a few questions related to the queuing delay part= of it. "The role of the receiver is fairly straightforward. It observes and estima= tes end-to-end queuing delay d and ECN marking ratio p of the stream. The f= ormer can be obtained from the RTP timestamp provided by the sender." You don't provide much detail on how the end-to-end queuing delay is estima= ted from the timestamps. Would it be possible to be more specific? Are you = employing a filter? Related to that, you seem to be running into a divide b= y zero in equation 1 if your queuing delay turns out to be zero. It also se= ems a bit bold to go directly from R_min to R_max if the queuing delay is l= ow enough. /Stefan On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (xiaoqzhu) > wrote: And below is the notification of our submission: Thanks, Xiaoqing -------------------------------------- A new version of I-D, draft-zhu-rmcat-nada-00.txt has been successfully submitted by Xiaoqing Zhu and posted to the IETF repository. Filename: draft-zhu-rmcat-nada Revision: 00 Title: NADA: A Unified Congestion Control Scheme for Real-Time Media Creation date: 2012-10-14 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-0= 0.txt Status: http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-00 Abstract: This document describes a scheme named network-assisted dynamic adaptation (NADA), a novel congestion control approach for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can reap the benefits of explicit congestion notification markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays instead. We present here the overall system architecture, recommended behaviors at the sender and the receiver, as well as expected network nodes operations. Results from extensive simulation studies of the proposed scheme are available upon request. The IETF Secretariat -------------------------------------- On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote: Hi, On Oct 11, 2012, at 18:45, Xiaoqing Zhu > wrote: My colleague and I are working on a congestion control scheme for real-time conferencing applications at Cisco. A brief version of that algorithm was presented at the IAB Workshop in Vancouver (paper #12, "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due to time constraints, however, we did not get a chance to mention the delay-based variant of that scheme, which may be a better fit for rmcat. We would like to request for a slot to present in Atlanta. We will also submit the ID draft before Oct 15, for further discussions on this mailing list. I look forward to seeing the draft being discussed on the list! Also, I'm noting your request for a slot. Because the actual CC mechanisms = are not our most pressing milestones initially - the requirements and eval = criteria are - we may decide to focus our meeting time on those other draft= s, if demand for agenda time is high. Lars --_000_E7175A8E3DC14048A7D3020E0338C1FA0D7BB19Fxmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <4564F8C02A74E44A840A32BE109F0642@cisco.com> Content-Transfer-Encoding: quoted-printable Oops. Sorry about the typo.  Yes, there is the alpha for the second te= rm.

Best,
Xiaoqing
  
On Oct 30, 2012, at 5:08 AM, Piers O'Hanlon wrote:

Hi,

Presumably by time-smooth average you mean EWMA - so you're missing an= alpha?

d_avg =3D (1-alpha)*d_avg + d_n

Should be:  d_avg =3D (1-alpha)*d_avg + alpha*d_n

Piers.

On 29 Oct 2012, at 15:28, Xiaoqing Zhu (xiaoqzhu) wrote:


On Oct 29, 2012, at 10:23 AM, Stefan Holmer wrote:




On Mon, Oct 29, 2012 at 3:53 PM, Xiaoqing Zhu (x= iaoqzhu) <xiaoqzhu@cisco.com> wrote:
Hi Stefan, 

Thanks a lot for your comments. I'll add in more details on the descri= ption for the receiver actions. 

You are right, we did employ some filtering of the observed per-packet= queuing delay, to avoid erratic reactions in the sending rate. The queuing= delay employed in the rate calculation in Eq. (1) is actually the time-smo= othed averaging d_avg: 

d_avg =3D (1-alpha)*d_avg + d_n, where d_n represents the measured= queuing delay  (end-to-end delay minus minimum observed value) for th= e n-th packet. The parameter alpha adjusts the level of smoothness in our a= verage process. In our experiments, we are using alpha =3D 10e-4. 

Thanks. Just to be clear, 

d_n =3D receiver_time_n - timestamp_n - min_observed

and min_observed is the smallest d_n seen in some window?

That's right.  BTW, while the time-averaged filtering works well for u= s, for now, we are also considering building in more robustness against ind= ividual bad samples. The Kalman filtering approach presented in your propos= al seems to be a good candidate for that. Maybe there is a way to incorporate that approach here for the delay estim= ation as well.  What do you think?   


 

Also, it's obvious that Eq.(1) wouldn't hold for for d=3D0, in which c= ase the rate is chosen to be R_max.  As mentioned in the paragraph bel= ow Eq. (1), any calculated target rate R_o greater than R_max will also be = clipped to the R_max. 

Initially, I omitted these details in the draft proposal for brevity. = Given your comments and concerns, looks like I'd better put them back in fo= r clarity. 

Best,
Xiaoqing


On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote:

Hi Xiaoqing,

Interesting draft, I have a few questions related to the queuing delay= part of it.

"The role of the receiver is fairly straightforward. It observes = and estimates end-to-end queuing delay d and ECN marking ratio p of the str= eam. The former can be obtained from the RTP timestamp provided by the send= er."

You don't provide much detail on how the end-to-end queuing delay is e= stimated from the timestamps. Would it be possible to be more specific? Are= you employing a filter? Related to that, you seem to be running into a div= ide by zero in equation 1 if your queuing delay turns out to be zero. It also seems a bit bold to go directl= y from R_min to R_max if the queuing delay is low enough.

/Stefan




On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (= xiaoqzhu) <xiaoqzhu@cisco.com> wrote:
And below is the notification of our su= bmission: 

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename:  draft-zhu-rmcat= -nada
Revision:  00
Title:  NADA: A Unified Congestion Control Scheme for Rea= l-Time Media
Creation date:  2012-10-14=
WG ID:  Individual Submission
Number of pages: 10
URL:            &nbs= p;http://www.ietf.org/internet-drafts/d= raft-zhu-rmcat-nada-00.txt
Status:          http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada
Htmlized:        = http://tools.ietf.org/html/draft-zhu-rmcat-nada-00


Abstract:
  This document describes a scheme named network-assisted dynamic=
  adaptation (NADA), a novel congestion control approach for
  interactive real-time media applications, such as video confere= ncing.
  In the proposed scheme, the sender regulates its sending rate b= ased
  on either implicit or explicit congestion signaling, in a unifi= ed
  approach. The scheme can reap the benefits of explicit congesti= on
  notification markings from network nodes. It also maintains
  consistent sender behavior in the absence of such markings, by<= br>   reacting to queuing delays instead.

  We present here the overall system architecture, recommended   behaviors at the sender and the receiver, as well as expected n= etwork
  nodes operations. Results from extensive simulation studies of = the
  proposed scheme are available upon request.




The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <zhuxq@alumni.stanford.edu<= /a>> wrote:
My colleague and I are working on a congestion co= ntrol scheme for
real-time conferencing applications at Cisco. A b= rief version of that
algorithm was presented at the IAB Workshop in Va= ncouver (paper #12,
"Network-Assisted Dynamic Adaptation (NADA):= A Design Summary"). Due
to time constraints, however, we did not get a ch= ance to mention the
delay-based variant of that scheme, which may be = a better fit for
rmcat.

We would like to request for a slot to present in= Atlanta. We will
also submit the ID draft before Oct 15, for furth= er discussions on
this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC mechanisms = are not our most pressing milestones initially - the requirements and eval = criteria are - we may decide to focus our meeting time on those other draft= s, if demand for agenda time is high.

Lars







--_000_E7175A8E3DC14048A7D3020E0338C1FA0D7BB19Fxmbalnx13ciscoc_--