From lars@netapp.com Mon Jan 7 03:38:56 2013 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 EA5CA21F8738 for ; Mon, 7 Jan 2013 03:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 WJdw0gQj6CQr for ; Mon, 7 Jan 2013 03:38:56 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8447621F8734 for ; Mon, 7 Jan 2013 03:38:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,423,1355126400"; d="scan'208";a="5310307" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 07 Jan 2013 03:38:56 -0800 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r07BctQH006571; Mon, 7 Jan 2013 03:38:55 -0800 (PST) Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.8.16]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0328.009; Mon, 7 Jan 2013 03:38:55 -0800 From: "Eggert, Lars" To: " WG" Thread-Topic: [rmcat] "homework assignments" from IETF-85 Thread-Index: AQHNvfpweml2qvM2s0a99s5Nslx2yJg+oVAA Date: Mon, 7 Jan 2013 11:38:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <53C8B249E806A64189F49450CC762347@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Mirja_K=FChlewind?= Subject: Re: [rmcat] "homework assignments" from IETF-85 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, 07 Jan 2013 11:38:57 -0000 Hi, and happy 2013. It'd be great to see some progress on the action items we i= dentified during the IETYF-85 session... On Nov 8, 2012, at 22:44, "Eggert, Lars" wrote: > There were a few take-away items that for various folks to work on that I= 'd like to summarize: >=20 > * Colin and J=F6rg will inform the WG about what kinds of path informatio= n, i.e., potential inputs to a CC mechanism, are available based on RTP/RTC= P >=20 > * Michael is the go-to guy for maintaining a list of the architectural qu= estions we'll need to decide on sooner or later >=20 > * Randell got feedback on his requirements ID, which he'll incorporate in= a revision. Afterwards, we'll probably decide if the trajectory of this ID= aligns with our milestone and make a formal call for WG adoption. >=20 > * Similarly, Varun will incorporate the feedback into a revision of his e= valuation criteria ID, after which we'll do a similarly decision about adop= tion. Lars= From holmer@google.com Mon Jan 7 04:56:39 2013 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 BF30921F87ED for ; Mon, 7 Jan 2013 04:56:39 -0800 (PST) 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 Xhu6rGyVJnsJ for ; Mon, 7 Jan 2013 04:56:38 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 402EB21F8546 for ; Mon, 7 Jan 2013 04:56:37 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so8515917bku.31 for ; Mon, 07 Jan 2013 04:56:37 -0800 (PST) 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; bh=w2ChK+WkCOrvouP9j0MKCW7L6gIvMKi4ViuwLtcoWo8=; b=hzycU/dax+N2OaJW0RhDEN2N63Y/rH/zUVHcXEopn8VNECC/Nx1vzKblQYtg1sWklH 1jpFQJD5jeyVrP/lM/awJIZJvxd+nCXBJ+6IQddYMnL22493vzuH+ihyQ2TYjlDYxVh0 L8sCK9mYVrtAtwU9+M5hFGdeu6LIkbtqU6n34oB4Xy3sTdy0EvteCq9xyYwhp4kShOYh 48dOhW9ZH7JKc8neoaImIb+RBpr4S/jgbiaWlOrM0v6eh39UctIHdS4qymi64pdogYI3 moyf6owGIp2mve9mxW8Nxe0RV+eSZh9ff3zo8SxxpJ8saRn0pCOypa23POIISvKJkH7r K8pQ== 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-gm-message-state; bh=w2ChK+WkCOrvouP9j0MKCW7L6gIvMKi4ViuwLtcoWo8=; b=SXUcUuFmjc+njwbEzLp31ZE2awwimgXGKhLvPbztwUVSpjyCGPAZweLB7ISTXRt0HY nFpABnbLTJphTctuSzcWdfzmEgUfXM7vQG4somKWb674Cge+6j8Z3HE01pEkInBrT5Qf 6+qZvHw5D2dCdwwlSpVgTrNADWOGOnkaQIjd6dZZvaVg0sXKD9wqLjtNVtWYX3xCLgjp AJG4zkSmV0qnKdAMc8DY/Uh7TvHaf1ugjCqw5QX1Qw5GZ3LBB+XA+4xNUxkq2RD3TBAj ABFbpv+tmNLD4SRlEcT8Ic+mmeVtMDbcyIfZlU6kK9kjYDjC/cR52bYu2Z07yYIANliE g8cQ== MIME-Version: 1.0 Received: by 10.204.147.217 with SMTP id m25mr29793692bkv.17.1357563396763; Mon, 07 Jan 2013 04:56:36 -0800 (PST) Sender: holmer@google.com Received: by 10.205.115.81 with HTTP; Mon, 7 Jan 2013 04:56:36 -0800 (PST) In-Reply-To: <0FCEA7FA-7DC3-4D18-9D24-B41DDBB4F5B7@ifi.uio.no> References: <0FCEA7FA-7DC3-4D18-9D24-B41DDBB4F5B7@ifi.uio.no> Date: Mon, 7 Jan 2013 13:56:36 +0100 X-Google-Sender-Auth: 0prQQDuOj_JwK1Fk9nVQZ63mSMk Message-ID: From: Stefan Holmer To: Michael Welzl Content-Type: multipart/alternative; boundary=0015174a05d006309a04d2b25c8b X-Gm-Message-State: ALoCoQn4p/YM4BMMoKV3T24nSqpEhMaDasdDMmFfgwCGN1TzYc0x84x3f8czNebo6xh4biY08t87MOJpovFSP4g2lhWZUAGVdTKE9PrjJBkrRy/DU+lr8qfJb31dZG5NVVqzVTyzwrZNlBgMsho2mseBq5cF+R0fSEGiMCuNxT3bFpHtMCKHi/verd1B3ZnPeEMkjjD/reuH Cc: "rmcat@ietf.org WG" Subject: Re: [rmcat] Several comments about RRTCC 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, 07 Jan 2013 12:56:39 -0000 --0015174a05d006309a04d2b25c8b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Some comments. On Sat, Dec 29, 2012 at 2:30 PM, Michael Welzl wrote: > Dear all, > > I / we have found a number of potential issues with > draft-alvestrand-rtcweb-congestion-03, and would like to share them with > the group. I have shared some but not all of these thoughts directly with > the authors in the past, but I think it's useful to have them put togethe= r > in a list. > > 1) > The RRTCC acronym. The draft luckily doesn't contain it, but I think the > mechanism should have an acronym anyway. I have to search through my > mailbox every time to see if RRTCC is really what it was called=85 may I > propose "DemiResi" ? (Delay minimization with reduced signaling) > "Resi" also gives you plenty of nice associations to mountains=85 cows=85 > yodeling=85 red-white plaid skirts and Lederhosen! Easier to remember th= an > RRTCC, no doubt! To get you guys used to the idea, I will call it DemiRes= i > in my text below :-) > Fine with me, although I haven't had any problems remembering RRTCC (very similar to RTC). :) > > > 2) > Given that minimizing the amount of feedback seems to be a goal, this > feedback becomes very important. Losing a TCP ACK isn't a big deal, but > losing a DemiResi feedback message is. Given the minimal space needed > (essentially, one bit =85 plus a little more, to avoid ambiguity etc.), I > think we should introduce "acks-of-acks", i.e. a message that says "I got > your feedback". Yes, that message would only appear at the receiver withi= n > one RTT, but if the sender's timeout (2x t_max_fb_interval) is larger th= an > an RTT, it could help to make the receiver retransmit its feedback early > when that message is missing. Personally I'm not convinced that it's a go= od > idea to send less than a message / RTT anyway, in which case such > ACKs-of-ACKs could still be useful, as they would disambiguate forward fr= om > backward loss. For instance, the next message could then tell the sender > "don't reduce your rate because of the loss that you see, it's only the > backward path". > Sounds like a reasonable approach to me. > > > 3) > The TCP steady-state throughput equation from RFC3448 (in what follows, I > will call it "TFRC equation") is rather sensitive to the correct usage of > p, the packet loss event ratio. The way it is used in the draft, p is > packet loss but not the loss event ratio. Correct usage would require > sending loss events from the receiver to the sender (DCCP has a way to do > this), or, which would strike me as being much simpler, calculating this > equation on the receiver side. The receiver has all the information about > packet loss available. This would require the receiver to have some notio= n > of the RTT, which it could get e.g. if item 2) above is implemented. > I agree that such a mechanism makes sense to have on the receiving side. We initially put it on the sending side to have some type of compatibility with receivers which did not implement the delay-based algorithm, but the plan has been to also take the loss signal into account at the receiver. Haven't gotten there yet though... > > > 4) > The text on page 12 of the draft reads as if it would be impossible for > the receive-side estimate of the available bandwidth A(i) to go below the > value obtained with the TFRC equation. If it does, however, DemiResi > becomes like some form of TFRC, even in the absence of other TCPs. Can we > be sure that this won't happen? It could be an idea to fall back to such > TFRC-like behavior only if loss is large enough to indicate that we're > competing with TCP=85 we might not always, and when we're not, we should = keep > delay low. > It should be interpreted as "As(i) can't go above A(i), and As(i) will only go below what TFRC ( let's call it TFRC(i)) says if A(i) is less than TFRC(i)." Therefore we shouldn't have the problem you mention, but we will also not be able to use this mechanism to compete with TCP. It should however be useful in a scenario where we don't get a reliable delay-signal due to AQM. > > 5) > The thresholds on page 12 seem troublesome to me: the behavior stays > unchanged in the 2-10% loss regime (this is high loss!), it is reduced in > proportion to the loss ratio in case of above 10% (seems reasonable, exce= pt > that 10% is already quite extreme), BUT: "As long as less than 2% of the > packets have been lost As(i) will be increased as As(i)=3D1.05(As(i-1)+10= 00)" > =85. this latter item means that, as long as we're below 2% loss, the > mechanism increases its rate, making 2% its loss target?! This strikes m= e > as rather odd for a mechanism that's supposed to avoid loss and delay and > keep queues low. Again, if this is done for interoperation with TCP, it > could be an idea to do it only when loss is above a certain percentage (a= s > it would be caused by TCP). > I agree that those thresholds may have to be changed. The 2% threshold could indeed be interpreted as some kind of target for the AQM case, which I agree is a bad idea. I think scaling down all of these thresholds makes a lot of sense. > > > 6) > Rather obviously, ECN should be incorporated... > > > Surely there's more stuff to find. I guess my main criticism is that we > still don't have a paper, a technical report, simulation code or a simple > standalone implementation to play with. Simply not enough data. > > I hope this was constructive... > > Cheers, > Michael > > --0015174a05d006309a04d2b25c8b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Some comments.

On Sat, Dec 29, 2012= at 2:30 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
Dear all,

I / we have found a number of potential issues with draft-alvestrand-rtcweb= -congestion-03, and would like to share them with the group. I have shared = some but not all of these thoughts directly with the authors in the past, b= ut I think it's useful to have them put together in a list.

1)
The RRTCC acronym. The draft luckily doesn't contain it, but I think th= e mechanism should have an acronym anyway. I have to search through my mail= box every time to see if RRTCC is really what it was called=85 may I propos= e "DemiResi" ? =A0(Delay minimization with reduced signaling) =A0= =A0 "Resi" also gives you plenty of nice associations to mountai= ns=85 cows=85 yodeling=85 red-white plaid skirts and Lederhosen! =A0Easier = to remember than RRTCC, no doubt! To get you guys used to the idea, I will = call it DemiResi in my text below =A0:-)

Fine with me, although I haven't= had any problems remembering RRTCC (very similar to RTC). :)
=A0=


2)
Given that minimizing the amount of feedback seems to be a goal, this feedb= ack becomes very important. Losing a TCP ACK isn't a big deal, but losi= ng a DemiResi feedback message is. Given the minimal space needed (essentia= lly, one bit =85 plus a little more, to avoid ambiguity etc.), I think we s= hould introduce "acks-of-acks", i.e. a message that says "I = got your feedback". Yes, that message would only appear at the receive= r within one RTT, but if the sender's timeout (2x t_max_fb_interval) = =A0is larger than an RTT, it could help to make the receiver retransmit its= feedback early when that message is missing. Personally I'm not convin= ced that it's a good idea to send less than a message / RTT anyway, in = which case such ACKs-of-ACKs could still be useful, as they would disambigu= ate forward from backward loss. For instance, the next message could then t= ell the sender "don't reduce your rate because of the loss that yo= u see, it's only the backward path".

Sounds like a reasonable approach to= me.
=A0


3)
The TCP steady-state throughput equation from RFC3448 (in what follows, I w= ill call it "TFRC equation") is rather sensitive to the correct u= sage of p, the packet loss event ratio. The way it is used in the draft, p = is packet loss but not the loss event ratio. Correct usage would require se= nding loss events from the receiver to the sender (DCCP has a way to do thi= s), or, which would strike me as being much simpler, calculating this equat= ion on the receiver side. The receiver has all the information about packet= loss available. This would require the receiver to have some notion of the= RTT, which it could get e.g. if item 2) above is implemented.

I agree that such a mechanism makes = sense to have on the receiving side. We initially put it on the sending sid= e to have some type of compatibility with receivers which did not implement= the delay-based algorithm, but the plan has been to also take the loss sig= nal into account at the receiver. Haven't gotten there yet though...
=A0


4)
The text on page 12 of the draft reads as if it would be impossible for the= receive-side estimate of the available bandwidth A(i) to go below the valu= e obtained with the TFRC equation. If it does, however, DemiResi becomes li= ke some form of TFRC, even in the absence of other TCPs. Can we be sure tha= t this won't happen? It could be an idea to fall back to such TFRC-like= behavior only if loss is large enough to indicate that we're competing= with TCP=85 we might not always, and when we're not, we should keep de= lay low.

It should be=A0interpreted=A0as &quo= t;As(i) can't go above A(i), and As(i) will only go below what TFRC ( l= et's call it TFRC(i)) says if A(i) is less than TFRC(i)."

Therefore we shouldn't have the problem you mentio= n, but we will also not be able to use this mechanism to compete with TCP. = It should however be useful in a scenario where we don't get a reliable= delay-signal due to AQM.



5)
The thresholds on page 12 seem troublesome to me: the behavior stays unchan= ged in the 2-10% loss regime (this is high loss!), it is reduced in proport= ion to the loss ratio in case of above 10% (seems reasonable, except that 1= 0% is already quite extreme), BUT: "As long as less than 2% of the pac= kets have been lost As(i) will be increased as As(i)=3D1.05(As(i-1)+1000)&q= uot;
=85. this latter item means that, as long as we're below 2% loss, the m= echanism increases its rate, making 2% its loss target?! =A0This strikes me= as rather odd for a mechanism that's supposed to avoid loss and delay = and keep queues low. Again, if this is done for interoperation with TCP, it= could be an idea to do it only when loss is above a certain percentage (as= it would be caused by TCP).

I agree that those thresholds may ha= ve to be changed. The 2% threshold could indeed be interpreted as some kind= of target for the AQM case, which I agree is a bad idea. I think scaling d= own all of these thresholds makes a lot of sense.
=A0


6)
Rather obviously, ECN should be incorporated...


Surely there's more stuff to find. I guess my main criticism is that we= still don't have a paper, a technical report, simulation code or a sim= ple standalone implementation to play with. Simply not enough data.

I hope this was constructive...

Cheers,
Michael


--0015174a05d006309a04d2b25c8b-- From holmer@google.com Mon Jan 7 05:07:20 2013 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 AB4B621F870A for ; Mon, 7 Jan 2013 05:07:20 -0800 (PST) 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 jtC0aVrLpNAV for ; Mon, 7 Jan 2013 05:07:19 -0800 (PST) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3598821F8703 for ; Mon, 7 Jan 2013 05:07:19 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id ji2so8391052bkc.29 for ; Mon, 07 Jan 2013 05:07:18 -0800 (PST) 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; bh=O/sDiOP4VQrhzkwzs3nA89fqPtPgD64AXmgpH92goHM=; b=KqTM0iU0C8Y9g9tkvGxI0V8SlBPE3KqkqUqKr6VlA91D+e8wDk/tBxMAWInqdgbwoa LeXn6ieP++jTOOgnd53nqjLchTfgslCbxMDQPs8UmoHZ1lyajc+8FHB1vyCVoFDHWLi/ KtjRJqPQRG5d+PMXrxZhw3AlS1MkPq6Hj8C6TSYU50xWaO+m9yoP4PRuPyLVno7ln2K3 qmwLvJpmoD+2+VTt5MDiBpvTgMYYI+oYDEba7JjITvkMrJrCEhJVkrSDymNocuyEGkeZ jxeJEF3O/xeVLSmqt+PTIkhTEQTE5WCt+6LykYjF0Un3WgZ83RIUwyzQdzLgt6eAvx6P FsOw== 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-gm-message-state; bh=O/sDiOP4VQrhzkwzs3nA89fqPtPgD64AXmgpH92goHM=; b=HGGxjTra/dRpyZCJlnjQKidleBfEHgldWu3SsqGnsat50a60iIayurZus3lgwpcaSh jQBKMEiR4GmLDQHVUUJeJ+YjXk3gd4uWz7ZpqA6LKKmr3fzQ1hEM83lClYXvp/whSHMb U+ERPm/TW/oAOkXptnzVskV0Gy7+njmruPawrWNidRcvRPxzmIS0CxhKkQGx2f2DHkJP WuFGLsSUviaOvubpSmAEgSzeWollXUdN1as7Upi+dADk4903PrWuaqL6s+w9ZWmhoOdI NpY+zw9agvSKuU4EALk/KG9XzHpxcbHabWb3L00uo6arylAYGTGSf2SexyBWe9TtSEva lWeQ== MIME-Version: 1.0 Received: by 10.204.147.217 with SMTP id m25mr29816493bkv.17.1357564038052; Mon, 07 Jan 2013 05:07:18 -0800 (PST) Sender: holmer@google.com Received: by 10.205.115.81 with HTTP; Mon, 7 Jan 2013 05:07:17 -0800 (PST) In-Reply-To: <226C9AC4-1699-4784-BCCA-54F9BF603B48@ifi.uio.no> References: <0FCEA7FA-7DC3-4D18-9D24-B41DDBB4F5B7@ifi.uio.no> <50E161C8.8040009@gmail.com> <226C9AC4-1699-4784-BCCA-54F9BF603B48@ifi.uio.no> Date: Mon, 7 Jan 2013 14:07:17 +0100 X-Google-Sender-Auth: TdoFis7mHqcMvT2yHkbjga8Osqs Message-ID: From: Stefan Holmer To: Michael Welzl Content-Type: multipart/alternative; boundary=0015174a05d03f7c9304d2b2825e X-Gm-Message-State: ALoCoQmtTI1bbvJMLS6Vq+BLCIZ03IbuFTFpF5fVA+p9MTv1I8Xc1ApsD9R/r3CTVWRYuIOG3NLczZ1Qax05RscPkQvbqJvBLcCMJGVIOYciW4wtEejuhpUJIT9kPU0+DQOIbwJWKX1k895LMI9LhUQnrQSBuEQRE6tcMT6Hhn5ZoXfvdTwQRDs8baXtVTwhOJ86w1KxeXXq Cc: rmcat WG , Sergio Garcia Murillo Subject: Re: [rmcat] Several comments about RRTCC 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, 07 Jan 2013 13:07:20 -0000 --0015174a05d03f7c9304d2b2825e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Dec 31, 2012 at 12:06 PM, Michael Welzl wrote: > > On Dec 31, 2012, at 10:58 AM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > > > El 29/12/2012 14:30, Michael Welzl escribi=F3: > >> [..] > >> 5) > >> The thresholds on page 12 seem troublesome to me: the behavior stays > unchanged in the 2-10% loss regime (this is high loss!), it is reduced in > proportion to the loss ratio in case of above 10% (seems reasonable, exce= pt > that 10% is already quite extreme), BUT: "As long as less than 2% of the > packets have been lost As(i) will be increased as As(i)=3D1.05(As(i-1)+10= 00)" > >> =85. this latter item means that, as long as we're below 2% loss, the > mechanism increases its rate, making 2% its loss target?! This strikes m= e > as rather odd for a mechanism that's supposed to avoid loss and delay and > keep queues low. Again, if this is done for interoperation with TCP, it > could be an idea to do it only when loss is above a certain percentage (a= s > it would be caused by TCP). > > > > If i understood the paper correctly, if both sender and receiver > implements it, the overuse detector will be triggered before the 2-10% > ratio is reached, so in theory it is safe to increase the rate as the > packets lost would not be associated to congestion. The problem comes whe= n > the receiver doesn't not implement its part, and then I agree with you th= at > a 2-10% loss without any extra mechanism would provide a very bad > experience. If FEC/RED are used, then maybe the loss is not noticeable, b= ut > haven't tried that myself yet. Also, there may be some other codec specif= ic > solutions that could make the 2-10% loss to not be a problem, like > periodic intra refresh, disposable frames, etc.. > > Assuming that up to 2% loss isn't necessarily due to congestion also mean= s > that the mechanism rather heavily relies on delay. Whether we use OWD, IP= G=85 > either way, it's a pretty unreliable signal, e.g. noise can be introduced > by multiple bottlenecked links, and it loses granularity when AQM is used > or queues are short. I'm not arguing against the general use of a delay > measure - but I'm not sure I like the idea of assuming: unless a delay > based over-use detector fires, losses are not due to congestion. > > > >> [..] > >> > >> Surely there's more stuff to find. I guess my main criticism is that w= e > still don't have a paper, a technical report, simulation code or a simple > standalone implementation to play with. Simply not enough data. > >> > > > > I have been trying to implement the algorithm myself in my MCU and foun= d > quite some problems, especially with the initial values of the parameters= , > but after checking the google webrtc implementation I have quite positive > results with the overuse detector. Haven't got much luck yet with the > bitrate estimator. I am also starting to implement some testing tools to > help me in the implementation and troubleshooting, I will keep you posted > when they are stable enough for playing. > > Cool! > > I'll leave it to the authors to answer your notes below (my own answer > would be "not sure, would have to dig deeper into the scheme again"). > > Cheers, > Michael > > > > Maybe it is stupid, but on the bitrate estimator, given that "Not until > over-use has been detected for at least gamma_2 milliseconds and at least > gamma_3 frames, a definitive over-use will be signaled.", couldn't we use > the bitrate received during that period as a valid bitrate estimation of > the available bandwidth? > Not sure what you mean, but it sounds very similar to what we are actually doing. If we detect an over-use, the actual throughput calculated over some window (0.5 to 1 second) is used as an estimate of the available bandwidth, as described on page 10: A_hat(i) =3D alpha*R_hat(i). The factor alpha (< 1= ) is used to make sure that we decrease the estimate to a rate somewhat lower than what we believe the available bandwidth is so that the queues will have a chance to drain. > > > > On a last note, I believe that the algorithm will work much better if > the codecs are able to produce output bitrates as closed as the target > bitrate as possible (i.e. almost CBR). Which seems to be confirmed by a > comment in google's code: > Indeed it's better to have a codec which produces what you are requesting from it. You can also have a smoother/pacer after the encoder to make sure packets are paced out according to the estimated available bandwidth (with the penalty of increased delay). > > > > // We try to filter out very late frames. For instance periodic key > > // frames doesn't fit the Gaussian model well. > > > > Best regards > > Sergio > > --0015174a05d03f7c9304d2b2825e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Mon, Dec 31, 2012 at 12= :06 PM, Michael Welzl <michawe@ifi.uio.no>= wrote:

On Dec 31, 2012, at 10:58 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:

> El 29/12/2012 14:30, Michael Welzl escribi=F3:
>> [..]
>> 5)
>> The thresholds on page 12 seem troublesome to me: the behavior sta= ys unchanged in the 2-10% loss regime (this is high loss!), it is reduced i= n proportion to the loss ratio in case of above 10% (seems reasonable, exce= pt that 10% is already quite extreme), BUT: "As long as less than 2% o= f the packets have been lost As(i) will be increased as As(i)=3D1.05(As(i-1= )+1000)"
>> =85. this latter item means that, as long as we're below 2% lo= ss, the mechanism increases its rate, making 2% its loss target?! =A0This s= trikes me as rather odd for a mechanism that's supposed to avoid loss a= nd delay and keep queues low. Again, if this is done for interoperation wit= h TCP, it could be an idea to do it only when loss is above a certain perce= ntage (as it would be caused by TCP).
>
> If i understood the paper correctly, if both sender and receiver imple= ments it, the overuse detector will be triggered before the 2-10% ratio is = reached, so in theory it is safe to increase the rate as the packets lost w= ould not be associated to congestion. The problem comes when the receiver d= oesn't not implement its part, and then I agree with you that a 2-10% l= oss without any extra mechanism would provide a very bad experience. If FEC= /RED are used, then maybe the loss is not noticeable, but haven't tried= that myself yet. Also, there may be some other codec specific solutions th= at could make the =A02-10% loss to not be a problem, like periodic intra re= fresh, disposable frames, etc..

Assuming that up to 2% loss isn't necessarily due to congestion a= lso means that the mechanism rather heavily relies on delay. Whether we use= OWD, IPG=85 either way, it's a pretty unreliable signal, e.g. noise ca= n be introduced by multiple bottlenecked links, and it loses granularity wh= en AQM is used or queues are short. I'm not arguing against the general= use of a delay measure - but I'm not sure I like the idea of assuming:= unless a delay based over-use detector fires, losses are not due to conges= tion.


>> [..]
>>
>> Surely there's more stuff to find. I guess my main criticism i= s that we still don't have a paper, a technical report, simulation code= or a simple standalone implementation to play with. Simply not enough data= .
>>
>
> I have been trying to implement the algorithm myself in my MCU and fou= nd quite some problems, especially with the initial values of the parameter= s, but after checking the google webrtc implementation I have quite positiv= e results with the overuse detector. =A0Haven't got much luck yet with = the bitrate estimator. I am also starting to implement some testing tools t= o help me in the implementation and troubleshooting, I will keep you posted= when they are stable enough for playing.

Cool!

I'll leave it to the authors to answer your notes below (my own answer = would be "not sure, would have to dig deeper into the scheme again&quo= t;).

Cheers,
Michael


> Maybe it is stupid, but on the bitrate estimator, given that "Not= until over-use has been detected for at least gamma_2 milliseconds and at = least gamma_3 frames, a definitive over-use will be signaled.", couldn= 't we use the bitrate received during that period as a valid bitrate es= timation of the available bandwidth?

Not sure what you mean, = but it sounds very similar to what we are actually doing. If we detect an o= ver-use, the actual throughput calculated over some window (0.5 to 1 second= ) is used as an estimate of the available bandwidth, as described on page 1= 0:=A0A_ha= t(i) =3D alpha*R_hat(i).=A0The factor alpha (< 1) is used to make sure tha= t we decrease the estimate to a rate somewhat lower than what we believe th= e available bandwidth is so that the queues will have a chance to drain.
=A0
>
> On a last note, I believe that the algorithm will work much better if = the codecs are able to produce output bitrates as closed as the target bitr= ate as possible (i.e. almost CBR). Which seems to be confirmed by a comment= in google's code:

Indeed it's better t= o have a codec which produces what you are requesting from it. You can also= have a smoother/pacer after the encoder to make sure packets are paced out= according to the estimated available bandwidth (with the penalty of increa= sed delay).
=A0
>
> =A0// We try to filter out very late frames. For instance periodic key=
> =A0// frames doesn't fit the Gaussian model well.
>
> Best regards
> Sergio


--0015174a05d03f7c9304d2b2825e-- From michawe@ifi.uio.no Mon Jan 7 05:56:25 2013 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 3594221F86CC for ; Mon, 7 Jan 2013 05:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 uT1c6hMMdxJj for ; Mon, 7 Jan 2013 05:56:24 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 86EA321F86C2 for ; Mon, 7 Jan 2013 05:56:23 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TsCwu-0008H0-1n; Mon, 07 Jan 2013 14:41:08 +0100 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 1TsCws-0005ku-IE; Mon, 07 Jan 2013 14:41:08 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D085C9BC-FEB7-490B-A6D8-A5A2FF6CDADE" From: Michael Welzl In-Reply-To: Date: Mon, 7 Jan 2013 14:40:52 +0100 Message-Id: References: <0FCEA7FA-7DC3-4D18-9D24-B41DDBB4F5B7@ifi.uio.no> To: Stefan Holmer X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 4 sum rcpts/h 12 sum msgs/h 6 total rcpts 1200 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.1, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.124, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EAFC6074B7D0EE136ACB7AC95AA66A20A3A91BD0 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -50 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 349 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: "rmcat@ietf.org WG" Subject: Re: [rmcat] Several comments about RRTCC 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, 07 Jan 2013 13:56:25 -0000 --Apple-Mail=_D085C9BC-FEB7-490B-A6D8-A5A2FF6CDADE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, In line: On 7. jan. 2013, at 13:56, Stefan Holmer wrote: > Some comments. >=20 > On Sat, Dec 29, 2012 at 2:30 PM, Michael Welzl = wrote: > Dear all, >=20 > I / we have found a number of potential issues with = draft-alvestrand-rtcweb-congestion-03, and would like to share them with = the group. I have shared some but not all of these thoughts directly = with the authors in the past, but I think it's useful to have them put = together in a list. >=20 > 1) > The RRTCC acronym. The draft luckily doesn't contain it, but I think = the mechanism should have an acronym anyway. I have to search through my = mailbox every time to see if RRTCC is really what it was called=85 may I = propose "DemiResi" ? (Delay minimization with reduced signaling) = "Resi" also gives you plenty of nice associations to mountains=85 cows=85 = yodeling=85 red-white plaid skirts and Lederhosen! Easier to remember = than RRTCC, no doubt! To get you guys used to the idea, I will call it = DemiResi in my text below :-) >=20 > Fine with me, although I haven't had any problems remembering RRTCC = (very similar to RTC). :) Ohhhh then PLEASE call it DemiResi! I'd love that name! :-) (I'll admit that that's because I'll have to laugh every time I hear it = :-) ) > =20 > 2) > Given that minimizing the amount of feedback seems to be a goal, this = feedback becomes very important. Losing a TCP ACK isn't a big deal, but = losing a DemiResi feedback message is. Given the minimal space needed = (essentially, one bit =85 plus a little more, to avoid ambiguity etc.), = I think we should introduce "acks-of-acks", i.e. a message that says "I = got your feedback". Yes, that message would only appear at the receiver = within one RTT, but if the sender's timeout (2x t_max_fb_interval) is = larger than an RTT, it could help to make the receiver retransmit its = feedback early when that message is missing. Personally I'm not = convinced that it's a good idea to send less than a message / RTT = anyway, in which case such ACKs-of-ACKs could still be useful, as they = would disambiguate forward from backward loss. For instance, the next = message could then tell the sender "don't reduce your rate because of = the loss that you see, it's only the backward path". >=20 > Sounds like a reasonable approach to me. Cool! So then we need to define that "I got your feedback message" = somewhere... > =20 > 3) > The TCP steady-state throughput equation from RFC3448 (in what = follows, I will call it "TFRC equation") is rather sensitive to the = correct usage of p, the packet loss event ratio. The way it is used in = the draft, p is packet loss but not the loss event ratio. Correct usage = would require sending loss events from the receiver to the sender (DCCP = has a way to do this), or, which would strike me as being much simpler, = calculating this equation on the receiver side. The receiver has all the = information about packet loss available. This would require the receiver = to have some notion of the RTT, which it could get e.g. if item 2) above = is implemented. >=20 > I agree that such a mechanism makes sense to have on the receiving = side. We initially put it on the sending side to have some type of = compatibility with receivers which did not implement the delay-based = algorithm, but the plan has been to also take the loss signal into = account at the receiver. Haven't gotten there yet though... > =20 >=20 >=20 > 4) > The text on page 12 of the draft reads as if it would be impossible = for the receive-side estimate of the available bandwidth A(i) to go = below the value obtained with the TFRC equation. If it does, however, = DemiResi becomes like some form of TFRC, even in the absence of other = TCPs. Can we be sure that this won't happen? It could be an idea to fall = back to such TFRC-like behavior only if loss is large enough to indicate = that we're competing with TCP=85 we might not always, and when we're = not, we should keep delay low. >=20 > It should be interpreted as "As(i) can't go above A(i), and As(i) will = only go below what TFRC ( let's call it TFRC(i)) says if A(i) is less = than TFRC(i)." >=20 > Therefore we shouldn't have the problem you mention, but we will also = not be able to use this mechanism to compete with TCP. It should however = be useful in a scenario where we don't get a reliable delay-signal due = to AQM. I don't get that. I had thought that the idea is to at least be as = aggressive as TFRC in the absence of a reliable delay-signal? I thought = that this, in principle (minus the problem I mention above), is a nice = idea, and you'd automatically get that if As(i) >=3D TFRC(i), and this = is actually what the text on page 12 says. But what you say above is: = As(i) <=3D TFRC(i) ?! >=20 > 5) > The thresholds on page 12 seem troublesome to me: the behavior stays = unchanged in the 2-10% loss regime (this is high loss!), it is reduced = in proportion to the loss ratio in case of above 10% (seems reasonable, = except that 10% is already quite extreme), BUT: "As long as less than 2% = of the packets have been lost As(i) will be increased as = As(i)=3D1.05(As(i-1)+1000)" > =85. this latter item means that, as long as we're below 2% loss, the = mechanism increases its rate, making 2% its loss target?! This strikes = me as rather odd for a mechanism that's supposed to avoid loss and delay = and keep queues low. Again, if this is done for interoperation with TCP, = it could be an idea to do it only when loss is above a certain = percentage (as it would be caused by TCP). >=20 > I agree that those thresholds may have to be changed. The 2% threshold = could indeed be interpreted as some kind of target for the AQM case, = which I agree is a bad idea. I think scaling down all of these = thresholds makes a lot of sense. > =20 >=20 >=20 > 6) > Rather obviously, ECN should be incorporated... >=20 >=20 > Surely there's more stuff to find. I guess my main criticism is that = we still don't have a paper, a technical report, simulation code or a = simple standalone implementation to play with. Simply not enough data. >=20 > I hope this was constructive... >=20 > Cheers, > Michael >=20 >=20 Cheers, Michael --Apple-Mail=_D085C9BC-FEB7-490B-A6D8-A5A2FF6CDADE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Some = comments.

On Sat, Dec 29, 2012 at 2:30 PM, Michael Welzl = <michawe@ifi.uio.no> = wrote:
Dear all,

I / we have found a number of potential issues with = draft-alvestrand-rtcweb-congestion-03, and would like to share them with = the group. I have shared some but not all of these thoughts directly = with the authors in the past, but I think it's useful to have them put = together in a list.

1)
The RRTCC acronym. The draft luckily doesn't contain it, but I think the = mechanism should have an acronym anyway. I have to search through my = mailbox every time to see if RRTCC is really what it was called=85 may I = propose "DemiResi" ?  (Delay minimization with reduced signaling) =     "Resi" also gives you plenty of nice associations to = mountains=85 cows=85 yodeling=85 red-white plaid skirts and Lederhosen! =  Easier to remember than RRTCC, no doubt! To get you guys used to = the idea, I will call it DemiResi in my text below  :-)

Fine with me, although I = haven't had any problems remembering RRTCC (very similar to RTC). = :)

Ohhhh then PLEASE = call it DemiResi! I'd love that name!  :-)
(I'll admit = that that's because I'll have to laugh every time I hear it  :-) =   )


 
2)
Given that minimizing the amount of feedback seems to be a goal, this = feedback becomes very important. Losing a TCP ACK isn't a big deal, but = losing a DemiResi feedback message is. Given the minimal space needed = (essentially, one bit =85 plus a little more, to avoid ambiguity etc.), = I think we should introduce "acks-of-acks", i.e. a message that says "I = got your feedback". Yes, that message would only appear at the receiver = within one RTT, but if the sender's timeout (2x t_max_fb_interval) =  is larger than an RTT, it could help to make the receiver = retransmit its feedback early when that message is missing. Personally = I'm not convinced that it's a good idea to send less than a message / = RTT anyway, in which case such ACKs-of-ACKs could still be useful, as = they would disambiguate forward from backward loss. For instance, the = next message could then tell the sender "don't reduce your rate because = of the loss that you see, it's only the backward path".

Sounds like a reasonable = approach to me.

Cool! = So then we need to define that "I got your feedback message" = somewhere...


 
3)
The TCP steady-state throughput equation from RFC3448 (in what follows, = I will call it "TFRC equation") is rather sensitive to the correct usage = of p, the packet loss event ratio. The way it is used in the draft, p is = packet loss but not the loss event ratio. Correct usage would require = sending loss events from the receiver to the sender (DCCP has a way to = do this), or, which would strike me as being much simpler, calculating = this equation on the receiver side. The receiver has all the information = about packet loss available. This would require the receiver to have = some notion of the RTT, which it could get e.g. if item 2) above is = implemented.

I agree that such a = mechanism makes sense to have on the receiving side. We initially put it = on the sending side to have some type of compatibility with receivers = which did not implement the delay-based algorithm, but the plan has been = to also take the loss signal into account at the receiver. Haven't = gotten there yet though...
 


4)
The text on page 12 of the draft reads as if it would be impossible for = the receive-side estimate of the available bandwidth A(i) to go below = the value obtained with the TFRC equation. If it does, however, DemiResi = becomes like some form of TFRC, even in the absence of other TCPs. Can = we be sure that this won't happen? It could be an idea to fall back to = such TFRC-like behavior only if loss is large enough to indicate that = we're competing with TCP=85 we might not always, and when we're not, we = should keep delay low.

It should = be interpreted as "As(i) can't go above A(i), and As(i) will = only go below what TFRC ( let's call it TFRC(i)) says if A(i) is less = than TFRC(i)."

Therefore we shouldn't have the problem you = mention, but we will also not be able to use this mechanism to compete = with TCP. It should however be useful in a scenario where we don't get a = reliable delay-signal due to = AQM.

I don't get = that. I had thought that the idea is to at least be as aggressive as = TFRC in the absence of a reliable delay-signal? I thought that this, in = principle (minus the problem I mention above), is a nice idea, and you'd = automatically get that if As(i) >=3D TFRC(i), and this is actually = what the text on page 12 says. But what you say above is: As(i) <=3D = TFRC(i) ?!



5)
The thresholds on page 12 seem troublesome to me: the behavior stays = unchanged in the 2-10% loss regime (this is high loss!), it is reduced = in proportion to the loss ratio in case of above 10% (seems reasonable, = except that 10% is already quite extreme), BUT: "As long as less than 2% = of the packets have been lost As(i) will be increased as = As(i)=3D1.05(As(i-1)+1000)"
=85. this latter item means that, as long as we're below 2% loss, the = mechanism increases its rate, making 2% its loss target?!  This = strikes me as rather odd for a mechanism that's supposed to avoid loss = and delay and keep queues low. Again, if this is done for interoperation = with TCP, it could be an idea to do it only when loss is above a certain = percentage (as it would be caused by TCP).

I agree that those = thresholds may have to be changed. The 2% threshold could indeed be = interpreted as some kind of target for the AQM case, which I agree is a = bad idea. I think scaling down all of these thresholds makes a lot of = sense.
 


6)
Rather obviously, ECN should be incorporated...


Surely there's more stuff to find. I guess my main criticism is that we = still don't have a paper, a technical report, simulation code or a = simple standalone implementation to play with. Simply not enough = data.

I hope this was constructive...

Cheers,
Michael


=

Cheers,
Michael

=
= --Apple-Mail=_D085C9BC-FEB7-490B-A6D8-A5A2FF6CDADE-- From holmer@google.com Mon Jan 7 07:13:29 2013 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 3129921F8614 for ; Mon, 7 Jan 2013 07:13:29 -0800 (PST) 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 V-ZfSxzWAxGk for ; Mon, 7 Jan 2013 07:13:27 -0800 (PST) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9D26521F856C for ; Mon, 7 Jan 2013 07:13:24 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id jm19so8630973bkc.36 for ; Mon, 07 Jan 2013 07:13:23 -0800 (PST) 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; bh=4crR1sgcfbKPV8NZ/oie8hhQ+IwI8Rmmeu4JUHemJSE=; b=pBw9E+e5ILfzGwGcPCT3ad9emPCoAekfSjJeG88OcWvXSRKswXuulBOkr/KtuSuaeX DmUVXVwYRA+7GNEUIX6ZX7s5IVDgej1gPgNAv4hbiEDHWqCiY3l9Xf/4UzqQzn98CvOG S/DJ9jSPfKo/2oQaAmQEsG1lXjVC2po6gG6wfsucgAHOU3/feHX2GxY/jU3+C6WrR+ys c9KXQoayFlegxx+sDhKrm8y6s+iLrtfRz8Ob6LRYVTQH9qdrgFjc7Zz38XhwMN9nbRCc VTkmjavES/V2TxNRRQpiOKGPYAfTzsu5gINUvJYx+Ce24XGwpUnRnVEBjqE7l6jdbqut dXxA== 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-gm-message-state; bh=4crR1sgcfbKPV8NZ/oie8hhQ+IwI8Rmmeu4JUHemJSE=; b=WhJjeBwjvk08p26qGhbmHNDOwlpJijJ2jpWSgUegBMWBMXoh6QPTWPxnejxPHs6tI5 hzmc+YYmkU7Whbb7HaEvu/SPzU2RzDpX+h1Z6OMw0B5W0Tm7GrKvKWalFl8Hd2Q+hoou cbavYKNlAftlD4Dy0pOgOoiZRu65LjBCyqTcQahE1/VsGAF1ERe8UwhTIvOXkFSc+SAV 2HTe9E/f2xF+NI8w6jWVqOkZL5e82QwBAnSYps2yGDzn9HaT+ITFzfezxlYo9CmwSZIF C6Ozgv5xIhy+e5Dnhe0RsnUxsp0nqrZW7hk0x3WkHMibo42cLX3Eq+gem5Xea+8bROgf zPDw== MIME-Version: 1.0 Received: by 10.204.151.21 with SMTP id a21mr30831438bkw.124.1357571603455; Mon, 07 Jan 2013 07:13:23 -0800 (PST) Sender: holmer@google.com Received: by 10.205.115.81 with HTTP; Mon, 7 Jan 2013 07:13:23 -0800 (PST) In-Reply-To: References: <0FCEA7FA-7DC3-4D18-9D24-B41DDBB4F5B7@ifi.uio.no> Date: Mon, 7 Jan 2013 16:13:23 +0100 X-Google-Sender-Auth: x_o0eAu6qhyPrsrODKneUZCrpxg Message-ID: From: Stefan Holmer To: Michael Welzl Content-Type: multipart/alternative; boundary=0015175d67862e5d9a04d2b4458c X-Gm-Message-State: ALoCoQlbKk/ce53stIBumWWQ/0rtcVYAfDxxPan9LQLWV/FBaQros4Bmqmb1hxlLGhMWZUa+dS4W/KMinSMJfd8x5Z/RHlPrAEPpktpO7bpAQCLoQe8ZtfIGUcxvLecZhNKUoKyq5UARHbWjw/r/mi/brKaX/2MFGAIKiFjd0xh1UXetrboobZDUgwX0ckzym+6WFf478kOd Cc: "rmcat@ietf.org WG" Subject: Re: [rmcat] Several comments about RRTCC 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, 07 Jan 2013 15:13:29 -0000 --0015175d67862e5d9a04d2b4458c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jan 7, 2013 at 2:40 PM, Michael Welzl wrote: > Hi, > > In line: > > > On 7. jan. 2013, at 13:56, Stefan Holmer wrote: > > Some comments. > > On Sat, Dec 29, 2012 at 2:30 PM, Michael Welzl wrote= : > >> Dear all, >> >> I / we have found a number of potential issues with >> draft-alvestrand-rtcweb-congestion-03, and would like to share them with >> the group. I have shared some but not all of these thoughts directly wit= h >> the authors in the past, but I think it's useful to have them put togeth= er >> in a list. >> >> 1) >> The RRTCC acronym. The draft luckily doesn't contain it, but I think the >> mechanism should have an acronym anyway. I have to search through my >> mailbox every time to see if RRTCC is really what it was called=85 may I >> propose "DemiResi" ? (Delay minimization with reduced signaling) >> "Resi" also gives you plenty of nice associations to mountains=85 cows= =85 >> yodeling=85 red-white plaid skirts and Lederhosen! Easier to remember t= han >> RRTCC, no doubt! To get you guys used to the idea, I will call it DemiRe= si >> in my text below :-) >> > > Fine with me, although I haven't had any problems remembering RRTCC (very > similar to RTC). :) > > > Ohhhh then PLEASE call it DemiResi! I'd love that name! :-) > (I'll admit that that's because I'll have to laugh every time I hear it > :-) ) > > > > >> 2) >> Given that minimizing the amount of feedback seems to be a goal, this >> feedback becomes very important. Losing a TCP ACK isn't a big deal, but >> losing a DemiResi feedback message is. Given the minimal space needed >> (essentially, one bit =85 plus a little more, to avoid ambiguity etc.), = I >> think we should introduce "acks-of-acks", i.e. a message that says "I go= t >> your feedback". Yes, that message would only appear at the receiver with= in >> one RTT, but if the sender's timeout (2x t_max_fb_interval) is larger t= han >> an RTT, it could help to make the receiver retransmit its feedback early >> when that message is missing. Personally I'm not convinced that it's a g= ood >> idea to send less than a message / RTT anyway, in which case such >> ACKs-of-ACKs could still be useful, as they would disambiguate forward f= rom >> backward loss. For instance, the next message could then tell the sender >> "don't reduce your rate because of the loss that you see, it's only the >> backward path". >> > > Sounds like a reasonable approach to me. > > > Cool! So then we need to define that "I got your feedback message" > somewhere... > > > > >> 3) >> The TCP steady-state throughput equation from RFC3448 (in what follows, = I >> will call it "TFRC equation") is rather sensitive to the correct usage o= f >> p, the packet loss event ratio. The way it is used in the draft, p is >> packet loss but not the loss event ratio. Correct usage would require >> sending loss events from the receiver to the sender (DCCP has a way to d= o >> this), or, which would strike me as being much simpler, calculating this >> equation on the receiver side. The receiver has all the information abou= t >> packet loss available. This would require the receiver to have some noti= on >> of the RTT, which it could get e.g. if item 2) above is implemented. >> > > I agree that such a mechanism makes sense to have on the receiving side. > We initially put it on the sending side to have some type of compatibilit= y > with receivers which did not implement the delay-based algorithm, but the > plan has been to also take the loss signal into account at the receiver. > Haven't gotten there yet though... > > >> >> >> 4) >> The text on page 12 of the draft reads as if it would be impossible for >> the receive-side estimate of the available bandwidth A(i) to go below th= e >> value obtained with the TFRC equation. If it does, however, DemiResi >> becomes like some form of TFRC, even in the absence of other TCPs. Can w= e >> be sure that this won't happen? It could be an idea to fall back to such >> TFRC-like behavior only if loss is large enough to indicate that we're >> competing with TCP=85 we might not always, and when we're not, we should= keep >> delay low. >> > > It should be interpreted as "As(i) can't go above A(i), and As(i) will > only go below what TFRC ( let's call it TFRC(i)) says if A(i) is less tha= n > TFRC(i)." > > Therefore we shouldn't have the problem you mention, but we will also not > be able to use this mechanism to compete with TCP. It should however be > useful in a scenario where we don't get a reliable delay-signal due to AQ= M. > > > I don't get that. I had thought that the idea is to at least be as > aggressive as TFRC in the absence of a reliable delay-signal? I thought > that this, in principle (minus the problem I mention above), is a nice > idea, and you'd automatically get that if As(i) >=3D TFRC(i), and this is > actually what the text on page 12 says. But what you say above is: As(i) = <=3D > TFRC(i) ?! > I can see how that text can be misinterpreted... It's not clear in the draft what we do when TFRC(i) > A(i). In our implementation the last thing we do is to limit As(i) to be less than or equal to A(i), so therefore we _can_ choose an As(i) < TFRC(i) if A(i) < TFRC(i). > > > >> 5) >> The thresholds on page 12 seem troublesome to me: the behavior stays >> unchanged in the 2-10% loss regime (this is high loss!), it is reduced i= n >> proportion to the loss ratio in case of above 10% (seems reasonable, exc= ept >> that 10% is already quite extreme), BUT: "As long as less than 2% of the >> packets have been lost As(i) will be increased as As(i)=3D1.05(As(i-1)+1= 000)" >> =85. this latter item means that, as long as we're below 2% loss, the >> mechanism increases its rate, making 2% its loss target?! This strikes = me >> as rather odd for a mechanism that's supposed to avoid loss and delay an= d >> keep queues low. Again, if this is done for interoperation with TCP, it >> could be an idea to do it only when loss is above a certain percentage (= as >> it would be caused by TCP). >> > > I agree that those thresholds may have to be changed. The 2% threshold > could indeed be interpreted as some kind of target for the AQM case, whic= h > I agree is a bad idea. I think scaling down all of these thresholds makes= a > lot of sense. > > >> >> >> 6) >> Rather obviously, ECN should be incorporated... >> >> >> Surely there's more stuff to find. I guess my main criticism is that we >> still don't have a paper, a technical report, simulation code or a simpl= e >> standalone implementation to play with. Simply not enough data. >> >> I hope this was constructive... >> >> Cheers, >> Michael >> >> > > Cheers, > Michael > > --0015175d67862e5d9a04d2b4458c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Mon, Jan 7, 2013 at 2:4= 0 PM, Michael Welzl <michawe@ifi.uio.no> w= rote:
Hi,
=
In line:


On 7. jan. 2013, at 13:56, Stefan Holmer wrote:

Some comments.

On Sat, Dec 29, 2012 at 2:30 PM, Michael= Welzl <michawe@ifi.uio.no> wrote:
Dear all,

I / we have found a number of potential issues with draft-alvestrand-rtcweb= -congestion-03, and would like to share them with the group. I have shared = some but not all of these thoughts directly with the authors in the past, b= ut I think it's useful to have them put together in a list.

1)
The RRTCC acronym. The draft luckily doesn't contain it, but I think th= e mechanism should have an acronym anyway. I have to search through my mail= box every time to see if RRTCC is really what it was called=85 may I propos= e "DemiResi" ? =A0(Delay minimization with reduced signaling) =A0= =A0 "Resi" also gives you plenty of nice associations to mountai= ns=85 cows=85 yodeling=85 red-white plaid skirts and Lederhosen! =A0Easier = to remember than RRTCC, no doubt! To get you guys used to the idea, I will = call it DemiResi in my text below =A0:-)

Fine with me, although I haven't had a= ny problems remembering RRTCC (very similar to RTC). :)

Ohhhh then PLEASE call it DemiResi! I= 'd love that name! =A0:-)
(I'll admit that that's because I'll have to laugh every t= ime I hear it =A0:-) =A0 )


=A0
2)
Given that minimizing the amount of feedback seems to be a goal, this feedb= ack becomes very important. Losing a TCP ACK isn't a big deal, but losi= ng a DemiResi feedback message is. Given the minimal space needed (essentia= lly, one bit =85 plus a little more, to avoid ambiguity etc.), I think we s= hould introduce "acks-of-acks", i.e. a message that says "I = got your feedback". Yes, that message would only appear at the receive= r within one RTT, but if the sender's timeout (2x t_max_fb_interval) = =A0is larger than an RTT, it could help to make the receiver retransmit its= feedback early when that message is missing. Personally I'm not convin= ced that it's a good idea to send less than a message / RTT anyway, in = which case such ACKs-of-ACKs could still be useful, as they would disambigu= ate forward from backward loss. For instance, the next message could then t= ell the sender "don't reduce your rate because of the loss that yo= u see, it's only the backward path".

Sounds like a reasonable approach to me.

Cool! So then we ne= ed to define that "I got your feedback message" somewhere...


=A0
3)
The TCP steady-state throughput equation from RFC3448 (in what follows, I w= ill call it "TFRC equation") is rather sensitive to the correct u= sage of p, the packet loss event ratio. The way it is used in the draft, p = is packet loss but not the loss event ratio. Correct usage would require se= nding loss events from the receiver to the sender (DCCP has a way to do thi= s), or, which would strike me as being much simpler, calculating this equat= ion on the receiver side. The receiver has all the information about packet= loss available. This would require the receiver to have some notion of the= RTT, which it could get e.g. if item 2) above is implemented.

I agree that such a mechanism makes sense = to have on the receiving side. We initially put it on the sending side to h= ave some type of compatibility with receivers which did not implement the d= elay-based algorithm, but the plan has been to also take the loss signal in= to account at the receiver. Haven't gotten there yet though...
=A0


4)
The text on page 12 of the draft reads as if it would be impossible for the= receive-side estimate of the available bandwidth A(i) to go below the valu= e obtained with the TFRC equation. If it does, however, DemiResi becomes li= ke some form of TFRC, even in the absence of other TCPs. Can we be sure tha= t this won't happen? It could be an idea to fall back to such TFRC-like= behavior only if loss is large enough to indicate that we're competing= with TCP=85 we might not always, and when we're not, we should keep de= lay low.

It should be=A0interpreted=A0as "As(i= ) can't go above A(i), and As(i) will only go below what TFRC ( let'= ;s call it TFRC(i)) says if A(i) is less than TFRC(i)."

Therefore we shouldn't have the problem you mention, but= we will also not be able to use this mechanism to compete with TCP. It sho= uld however be useful in a scenario where we don't get a reliable delay= -signal due to AQM.

I don't get th= at. I had thought that the idea is to at least be as aggressive as TFRC in = the absence of a reliable delay-signal? I thought that this, in principle (= minus the problem I mention above), is a nice idea, and you'd automatic= ally get that if As(i) >=3D TFRC(i), and this is actually what the text = on page 12 says. But what you say above is: As(i) <=3D TFRC(i) ?!

I can see how that= text can be misinterpreted... It's not clear in the draft what we do w= hen TFRC(i) > A(i). In our implementation the last thing we do is to lim= it As(i) to be less than or equal to A(i), so therefore we _can_ choose an = As(i) < TFRC(i) if A(i) < TFRC(i).
=A0



5)
The thresholds on page 12 seem troublesome to me: the behavior stays unchan= ged in the 2-10% loss regime (this is high loss!), it is reduced in proport= ion to the loss ratio in case of above 10% (seems reasonable, except that 1= 0% is already quite extreme), BUT: "As long as less than 2% of the pac= kets have been lost As(i) will be increased as As(i)=3D1.05(As(i-1)+1000)&q= uot;
=85. this latter item means that, as long as we're below 2% loss, the m= echanism increases its rate, making 2% its loss target?! =A0This strikes me= as rather odd for a mechanism that's supposed to avoid loss and delay = and keep queues low. Again, if this is done for interoperation with TCP, it= could be an idea to do it only when loss is above a certain percentage (as= it would be caused by TCP).

I agree that those thresholds may have to = be changed. The 2% threshold could indeed be interpreted as some kind of ta= rget for the AQM case, which I agree is a bad idea. I think scaling down al= l of these thresholds makes a lot of sense.
=A0


6)
Rather obviously, ECN should be incorporated...


Surely there's more stuff to find. I guess my main criticism is that we= still don't have a paper, a technical report, simulation code or a sim= ple standalone implementation to play with. Simply not enough data.

I hope this was constructive...

Cheers,
Michael



Cheers,
Michael


--0015175d67862e5d9a04d2b4458c-- From holmer@google.com Tue Jan 8 00:05:31 2013 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 ABE0921F881A for ; Tue, 8 Jan 2013 00:05:31 -0800 (PST) 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 mDKxXON5TiNX for ; Tue, 8 Jan 2013 00:05:28 -0800 (PST) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6A45321F8569 for ; Tue, 8 Jan 2013 00:05:27 -0800 (PST) Received: by mail-bk0-f54.google.com with SMTP id je9so49428bkc.27 for ; Tue, 08 Jan 2013 00:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ANy57p7WsgCT7Itso/12dmwCSaPrzJM4eG13RYuFYUc=; b=VqCqjjuCbadp7qtfnV+fDmoNL4q4lkpQFMZY7ktr8knbbjGoGqzK9ESsZO4xfk7ol0 nd9QbWpv5oYjNAaVszE5PLjiiWB1MG4B4HWtfQzz1bLAd+f40eERnBqnVZ1/Av2XGZFK pViDWNKDK1Yu08KL83H8+osEznuYNYmJYUJs0Hx9Lyo2q2IoL0dflVDHql8LaB4pwFKW q53hjM67MJ6YTDJrP/BCcK5Q+/31ldLNQP5D3W0yvnnVvurHE/3Fl2Z3BuRJ6q9xfwoN 9fhIOddODAfvxKO89MYaP1RNt7LdZZG4P5HrI+c1E4TEtmBOCoQRRPGy2JhrBdvBYY4h R7eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ANy57p7WsgCT7Itso/12dmwCSaPrzJM4eG13RYuFYUc=; b=IZNVzkp46OlRyGjGqAAUTUB6NM8gb8h8vZ9zOXyHYpyOXQocpkSDCCS8L4xCXg1uYO uyq+qn7QoMACk0+6d2UDdONGH+xGt1pYMc1A/DZ//Saodx6DZ/Eko85EUjiwK7KyG/67 g8qH5p6iqezgU00VnquSZZGw1zFKJK+m7l4lqkXGhyAyY3l0H8E0K4pWgPl4LJbdbxro pOMQU/UxuIHf9ZAFGk6DMW8bsompfCT3RR+eMKxCiNo2eQIutDg3lb+C7JR4mA2bbREn +6nhCSpF2ENZSOKlw08QZ/pwZOLNXRxFFfA9+oEBVEKgu67n/BJOwWTEPrvMu4NMVbn2 Zksg== MIME-Version: 1.0 Received: by 10.204.147.217 with SMTP id m25mr31313637bkv.17.1357632326030; Tue, 08 Jan 2013 00:05:26 -0800 (PST) Received: by 10.205.115.81 with HTTP; Tue, 8 Jan 2013 00:05:25 -0800 (PST) In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F64D3E9@xmb-rcd-x14.cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50CEFCBD.9030104@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F647D5B@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D90F64D3E9@xmb-rcd-x14.cisco.com> Date: Tue, 8 Jan 2013 09:05:25 +0100 Message-ID: From: Stefan Holmer To: "Mo Zanaty (mzanaty)" Content-Type: multipart/alternative; boundary=0015174a05d08755b904d2c26831 X-Gm-Message-State: ALoCoQnXokwo/RWtFpmWh2ZY2hXhs6CLF36QUFR5u/sFV+pRlN0efpH66cJ68g2uQzYAOtSVEYAPHSexuTYK+HmzF7j9g7mK39h+EfmezmHSR6Kff6fFClDW0E6Nond4ATLbuZNj0uSV3qHhQuNV2iykhxIfTv9sGwppJ7nM12/FvlALLopCg7Gq4X2CEpa4DT1g7i2upcMS Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Send timestamps 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, 08 Jan 2013 08:05:31 -0000 --0015174a05d08755b904d2c26831 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry for the late reply, holidays... On Sat, Dec 22, 2012 at 10:31 PM, Mo Zanaty (mzanaty) wr= ote: > Hi Stefan,**** > > ** ** > > I thought some more about your problem, and I think it is caused by your > desire to map to NTP. While it may seem intuitively logical to map all > received packets to a single absolute NTP timeline, this may be > unnecessary, and possibly even harmful. What you really care about > computing is d(i)=3Dt(i)-t(i-1)-(T(i)-T(i-1)). If you map T(i) to NTP bef= ore > computing deltas, you unnecessarily introduce conversion and mapping > errors, which may be harmful or negligible. If you simply compute deltas = on > T(i) directly, you avoid this. If you want to process multiple streams, > just compute deltas per stream before feeding the computed d(i) into a > single filter. Do you agree this would solve your problem? > Sure, it's a possible solution to the problem, but I'm not convinced it's a good one. If you receive two streams, A and B, with the following packets: [A1] [B1] [A2] [A3] [B2] .... You will get d(i)'s which are overlapping. For instance, d_a(1) =3D t_a(2) = - t_a(1) - (T_a(2) - T_a(1)), and d_b(1) both partly cover the same time slice. d_a(3) and d_b(2) will be even worse where the time slice covered by d_a(3) will be accounted for twice since it's also accounted for by d_b(2). I think it would be much simpler and more intuitive to be able to compute the differences between all packets coming from the same sending client, and we wouldn't get any weird bias issues due to the overlap problem. > **** > > ** ** > > Some more comments below, but these details are mostly orthogonal to the > core issue above.**** > > ** ** > > > Perhaps. I don't see why rewriting the full (RTP timestamp, NTP > timestamp) tuple is necessary for other reasons though.**** > > ** ** > > The server needs to rewrite NTP in RTCP SR if it wants to compute RTT. > Instead of rewriting NTP on the wire, it could rewrite internally (i.e. > maintain state internally for the NTP offset between source and server, s= o > the NTP echoed in RTCP RR from receivers can be converted from source to > server time). But this seems like equivalent or higher complexity (and > possibly fragility) to maintain internal rewrites than rewrite on the wir= e. > So I would not consider this an advantage. > Depends. It is an advantage if you want to be able to process audio and video streams independently. > **** > > ** ** > > More fundamental than any timestamps, servers must usually (always?) > rewrite RTCP SR because they are rarely (never?) blindly forwarding all R= TP > packets for the life of the session. For example, a source projection mix= er > that switches video sources at keyframe boundaries based on active speake= r > audio levels. The source RTCP SRs will be periodic, not on keyframe > boundaries, so what the mixer decides to forward can differ from what the > source sent in that RTCP interval. The mixer effectively terminates and > regenerates all RTCP with rules more complex than its simple RTP forwardi= ng > behavior, so it can=92t simply forward RTCP. > If the server simply chooses a set of streams to relay to the receiving client this shouldn't be an issue. If the server chooses to stop relaying stream A and start relaying stream B, the receiver will either already have received RTCP SR from stream B before, in which case it can sync with any related audio stream. If it has not received any RTCP SR from stream B, it will have to wait for one before syncing. Or am I missing your point here? > **** > > ** ** > > > The deltas only have a meaning in relation to the corresponding RTP > timestamp.**** > > ** ** > > Actually, the RFC 5450 offsets only relate to themselves, not directly to > the RTP timestamp. See the example in section 3 where =93the choice of x = is > essentially arbitrary=94. Also see the AVT archives circa 2005-2006 (sear= ch > for draft-singer-rtp-hdrext) for discussions about =93true offset=94 as d= efined > by Ron vs. =93deviation compared to a static delay=94 as defined by Magnu= s > (which is what the final RFC wording reflects).**** > > ** ** > > The problem RFC 5450 attempted to solve is exactly the same as RMCAT now > wants to solve with send timestamps, to separate source and network jitte= r, > for =93transmission rate adaptation=94 (Magnus=92 words). > Yes, I agree that RFC 5450 tries to solve a similar (or even the same) problem. But I also believe that doing it the RFC 5450 way has limitations. I think there are benefits of being able to compare send timestamps of different RTP streams if we know they're sent from the same sender, which I don't think is possible if you want to have separate processing of audio and video streams in your media servers. > **** > > ** ** > > Happy Holidays!**** > > Mo**** > > ** ** > > ** ** > > *From:* Stefan Holmer [mailto:holmer@google.com] > *Sent:* Monday, December 17, 2012 4:21 PM > *To:* Mo Zanaty (mzanaty) > *Cc:* Harald Alvestrand; rmcat@ietf.org > > *Subject:* Re: [rmcat] Send timestamps**** > > ** ** > > ** ** > > ** ** > > On Mon, Dec 17, 2012 at 9:15 PM, Mo Zanaty (mzanaty) > wrote:**** > > So we=92re back to two pendulums two months after deciding multi-hop is > initially out of scope. I=92m glad, because it will likely be a major (or > perhaps even dominant) deployment scenario, which we should not defer bas= ed > on complexity alone.**** > > **** > > If we introduce a new send timestamp extension (which I=92m unsure of the > benefits over RFC 5450), I think it should be in NTP units not RTP media > clock units. There is a precedent (in RTCP) for NTP timestamps that are > synced across multiple RTP sessions, but there is no such precedent for > synced RTP timestamps. Different media types with different media clocks > would also present problems for synced RTP timestamps.**** > > **** > > But even with this new send timestamp extension (using absolute synced NT= P > timestamps), I don=92t think it avoids Stefan=92s problem of rewriting ev= ery > RTP and RTCP packet at the server. Every RTP packet must still be rewritt= en > with the new extension using the server=92s NTP time, and every RTCP SR > packet must still be rewritten for several reasons beyond congestion > control.**** > > ** ** > > Perhaps. I don't see why rewriting the full (RTP timestamp, NTP timestamp= ) > tuple is necessary for other reasons though.**** > > ** ** > > The problem as I see it is when we, at the receiving client B, are to > compute the delta between packets generated by A and packets generated by > C. Even if we convert them both to NTP, their NTP timestamps aren't likel= y > to be in sync. They can be if S has rewritten the RTCP SRs so that the NT= P > timestamp of streams from A and C now are based on the clock of S (NTP > timestamp S). But when that has been done we also have to rewrite the RTC= P > SR of all other streams from A and C which we at some point would like to > have synchronized playback with, which will require all those streams to > also go through S. So basically we will not be able to have to servers, S= 1 > and S2, which for example handle video and audio streams respectively.***= * > > ** ** > > Maybe not a big issue, but to me it feels like a limitation without > benefits. I don't see the point of requiring that timestamps used for > congestion control should be set in relation to the RTP timestamps which = is > meant for doing synchronized playback.**** > > **** > > **** > > So I really don=92t see any benefit that a new extension would provide > beyond RFC 5450. Perhaps I=92m missing it.**** > > **** > > I=92m also missing why you need to convert to NTP time in order to =93joi= ntly > process all RTP streams=94, because only the deltas really matter not the > actual NTP time, and RFC 5450 gives you all you need for deltas.**** > > ** ** > > The deltas only have a meaning in relation to the corresponding RTP > timestamp. RTP timestamps of different streams (SSRCs) have different > random offsets, and therefore can't be compared before converted to NTP. = At > least if you want to calculate the delta between packets belonging from t= wo > different streams.**** > > **** > > **** > > > If we want to jointly process all RTP streams from A to B (at the > receiver, B) we can convert the RTP timestamps of all streams to NTP usin= g > the (RTP timestamp, NTP timestamp) tuple in the RTCP SR report.**** > > **** > > Mo**** > > **** > > **** > > *From:* rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] *On Behalf > Of *Harald Alvestrand > *Sent:* Monday, December 17, 2012 6:07 AM**** > > > *To:* rmcat@ietf.org > *Subject:* Re: [rmcat] Send timestamps**** > > **** > > Separating the timestamp used as a congestion signal from timestamps that > may be used for other purposes would seem to me to be an advantage in ter= ms > of architectural cleanliness.**** > > > > RTP timestamps need to reflect media time. In a situation with relay node= s > and changing paths, this may have uncomfortable amounts of variation from > the time the packets enter the last hop to the recipient. > > Given that we won't have all systems deploying the new extension from Day > One, we need to be able to fall back to the RTP timestamp (it's better th= an > nothing), but it seems we shouldn't marry it more than we have to. > > Harald > > On 12/17/2012 12:00 PM, Stefan Holmer wrote:**** > > I'll try to clarify with an example: **** > > **** > > Let's say we have two clients (A and B) in a call. We want to estimate th= e > bandwidth from A to B by looking at the variations in one-way delay, whic= h > we can measure by comparing deltas in RTP timestamp to deltas in > receive-time. The problem with using RTP timestamps is that those represe= nt > capture time and not the send time of a frame, so we get a lot of noise > related to variations in, e.g., video encoding time. To get around that w= e > introduce RFC 5450 and now we can > measure something much closer to actual network time. If we want to joint= ly > process all RTP streams from A to B (at the receiver, B) we can convert t= he > RTP timestamps of all streams to NTP using the (RTP timestamp, NTP > timestamp) tuple in the RTCP SR report.**** > > **** > > Now let's add a server (let's call it S) in between client A and B. This > server simply relays RTP packets (and might do some rewriting as well). N= ow > we want to estimate the bandwidth between A and S, and between S and B. S > will have to change the timestamp offset (RFC 5450) of the RTP packets to > correspond to its send-time, but besides that all is fine.**** > > **** > > Now let's add a third client (C). S will relay packets from both A and C > to B, so ideally we should jointly process all of those packets when > estimating the bandwidth between S to B. However, packets sent from A wil= l > be based on the tuple (RTP timestamp A, NTP timestamp A) and packets sent > from C will be based on (RTP timestamp C, NTP timestamp C), so we can't > just convert to NTP at B and compare them. This can be solved in the serv= er > by rewriting RTP and NTP timestamps to (RTP timestamp S, NTP timestamp S) > before relaying to B, which requires rewriting both RTP packets and RTCP > packets. This is fine as long as you rewrite _all_ streams from the same > sending client in the same way, otherwise you won't be able to synchroniz= e > them. Therefore all streams must go through the same server.**** > > **** > > I'm suggesting that we could introduce a new "send timestamp" which > doesn't relate to the RTP timestamp (which is used for synchronized > playback). Whenever a packet is sent (no matter if it's sent from A, C or > S) it will be stamped with the send-time taken from the clock of that > sender, for instance at 1 kHz or 90 kHz. Since it's not related to the RT= P > timestamp we won't have to rewrite the (RTP, NTP) tuple, and actually, we > don't even have to convert to NTP at the receiver since all send timestam= ps > are taken directly from the same clock. Removing the relation to the RTP > timestamp is what I mean with an "absolute" timestamp (i.e., not relative > to RTP timestamp).**** > > **** > > /Stefan**** > > **** > > On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) > wrote:**** > > Please clarify =93absolute=94. Do you mean another RTP timestamp using th= e > same units but a random offset from the main RTP timestamp, and no implie= d > sync across multiple RTP sessions? Or NTP timestamps with NTP units and > implied sync across all RTP sessions (within the same sync domain, > currently defined to be CNAME)?**** > > **** > > Please also clarify =93relay conference server=94, as there are many RTP > topologies for conferencing. I think you are probably referring to a sour= ce > projection mixer. Rewriting RTCP is standard practice for those, as well = as > most mixers. In fact, I can=92t envision when it would be possible to bli= ndly > relay RTCP in any mixer/topology. So I=92m not sure what complications yo= u > see arising from the use of RFC 5450.**** > > **** > > Mo**** > > **** > > *From:* rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] *On Behalf > Of *Stefan Holmer > *Sent:* Tuesday, December 04, 2012 4:23 AM > *To:* rmcat WG > *Subject:* [rmcat] Send timestamps**** > > **** > > Hi,**** > > **** > > In draft-alvestrand-rtcweb-congestion-01 we > proposed using a send timestamp RTP header extension for measuring the > packet inter-arrival time offset. In 02 this > was revised to instead reference RFC 5450, > which specifies a header extension for specifying the send timestamp as a= n > offset relative to the RTP timestamp.**** > > **** > > Thinking further about this, there seems to be a couple of benefits with > defining a new, absolute, send timestamp header extension. If a relay > approach to conference servers are used, the relaying server can simply > rewrite the send timestamp of a packet to correspond to the time it was > relayed. Doing so the receiver can jointly process all streams being > received from the relay server, even though they were initially captured > and sent by different senders (with different clocks). **** > > **** > > With a send timestamp offset, accomplishing the same thing would require > rewriting both the timestamp offset and the NTP time in the corresponding > RTCP SR reports. And to keep video synchronized with audio the RTCP packe= t > for the audio streams must also be rewritten in a similar way. This may n= ot > even be possible if the audio stream is relayed through a different serve= r. > **** > > **** > > Do you see any problems with using an RTP header extension with absolute > send timestamps? Are there any benefits with the send timestamp offset > header extension I might be missing?**** > > **** > > /Stefan**** > > **** > > **** > > ** ** > --0015174a05d08755b904d2c26831 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Sorry for the late reply, holidays...

On Sat, Dec 22, 2012 = at 10:31 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com&g= t; wrote:

Hi Stefan,

=A0

I thought some more about your problem,= and I think it is caused by your desire to map to NTP. While it may seem i= ntuitively logical to map all received packets to a single absolute NTP timeline, this may be unnecessary, and possibly even harmful.= What you really care about computing is d(i)=3Dt(i)-t(i-1)-(T(i)-T(i-1)). = If you map T(i) to NTP before computing deltas, you unnecessarily introduce= conversion and mapping errors, which may be harmful or negligible. If you simply compute deltas on T(i) directl= y, you avoid this. If you want to process multiple streams, just compute de= ltas per stream before feeding the computed d(i) into a single filter. Do y= ou agree this would solve your problem?


Sure, it's a possible solu= tion to the problem, but I'm not convinced it's a good one. If you = receive two streams, A and B, with the following packets:
[A1] [B1] [A2] [A3] [B2] ....=A0
You will get d(i)'s which ar= e overlapping. For instance, d_a(1) =3D t_a(2) - t_a(1) - (T_a(2) - T_a(1))= , and d_b(1) both partly cover the same time slice. d_a(3) and d_b(2) will = be even worse where the time slice covered by d_a(3) will be accounted for = twice since it's also accounted for by d_b(2). I think it would be much= simpler and more intuitive to be able to compute the differences between a= ll packets coming from the same sending client, and we wouldn't get any= weird bias issues due to the overlap problem.
=A0

=A0

Some more comments below, but these det= ails are mostly orthogonal to the core issue above.

=A0

> Perhaps. I don't see why rewriting the full (RTP time= stamp, NTP timestamp) tuple is necessary for other reasons though.

=A0

The server needs to rewrite NTP i= n RTCP SR if it wants to compute RTT. Instead of rewriting NTP on the wire,= it could rewrite internally (i.e. maintain state internally for the NTP offset between source and server, so the NTP echoed in RTCP RR fro= m receivers can be converted from source to server time). But this seems li= ke equivalent or higher complexity (and possibly fragility) to maintain int= ernal rewrites than rewrite on the wire. So I would not consider this an advantage.


Depends. It is an advantage if you want= to be able to process audio and video streams independently.
=A0

=A0

More fundamental than any timestamps, s= ervers must usually (always?) rewrite RTCP SR because they are rarely (neve= r?) blindly forwarding all RTP packets for the life of the session. For example, a source projection mixer that switches video source= s at keyframe boundaries based on active speaker audio levels. The source R= TCP SRs will be periodic, not on keyframe boundaries, so what the mixer dec= ides to forward can differ from what the source sent in that RTCP interval. The mixer effectively terminat= es and regenerates all RTCP with rules more complex than its simple RTP for= warding behavior, so it can=92t simply forward RTCP.


If the server simply chooses a set o= f streams to relay to the receiving client this shouldn't be an issue. = If the server chooses to stop relaying stream A and start relaying stream B= , the receiver will either already have received RTCP SR from stream B befo= re, in which case it can sync with any related audio stream. If it has not = received any RTCP SR from stream B, it will have to wait for one before syn= cing. Or am I missing your point here?
=A0

=A0

> The deltas only have a meaning in relation to the corresp= onding RTP timestamp.

=A0

Actually, the RFC 5450 offsets on= ly relate to themselves, not directly to the RTP timestamp. See the example= in section 3 where =93the choice of x is essentially arbitrary=94. Also see the AVT archives circa 2005-2006 (search for draft-singer-rtp-hdr= ext) for discussions about =93true offset=94 as defined by Ron vs. =93devia= tion compared to a static delay=94 as defined by Magnus (which is what the = final RFC wording reflects).

=A0

The problem RFC 5450 attempted to solve= is exactly the same as RMCAT now wants to solve with send timestamps, to s= eparate source and network jitter, for =93transmission rate adaptation=94 (Magnus=92 words).

<= br>
Yes, I agree that RFC 5450 tries to solve a similar (or= even the same) problem. But I also believe that doing it the RFC 5450 way = has limitations. I think there are benefits of being able to compare send t= imestamps of different RTP streams if we know they're sent from the sam= e sender, which I don't think is possible if you want to have separate = processing of audio and video streams in your media servers.
=A0

=A0

Happy Holidays!

Mo

=A0

=A0

From: Stefan H= olmer [mailto:holmer@google.com]
Sent: Monday, December 17, 2012 4:21 PM
To: Mo Zanaty (mzanaty)
Cc: Harald Alvestrand; rmcat@ietf.org


Subject: Re: [rmcat] Send timestamps

=A0

=A0

=A0=

On Mon, Dec 17, 2012 at 9:15 PM, Mo Zanat= y (mzanaty) <mzanaty@cisco.com> wrote:

So we=92re back to two pendulums two mo= nths after deciding multi-hop is initially out of scope. I=92m glad, becaus= e it will likely be a major (or perhaps even dominant) deployment scenario, = which we should not defer based on complexity alone.

=A0

If we introduce a new send timestamp ex= tension (which I=92m unsure of the benefits over RFC 5450), I think it shou= ld be in NTP units not RTP media clock units. There is a precedent (in RTCP) = for NTP timestamps that are synced across multiple RTP sessions, but there = is no such precedent for synced RTP timestamps. Different media types with = different media clocks would also present problems for synced RTP timestamps.

=A0

But even with this new send timestamp e= xtension (using absolute synced NTP timestamps), I don=92t think it avoids Stefan=92s problem of rewriting every RTP and RTCP packet at the server. E= very RTP packet must still be rewritten with the new extension using the se= rver=92s NTP time, and every RTCP SR packet must still be rewritten for sev= eral reasons beyond congestion control.

=A0

Perhaps. I don't see why rewriting th= e full (RTP timestamp, NTP timestamp) tuple is necessary for other reasons = though.

=A0

The problem as I see it is when we, at th= e receiving client B, are to compute the delta between packets generated by= A and packets generated by C. Even if we convert them both to NTP, their NTP timestamps aren't likely to be in sync. They can be = if S has rewritten the RTCP SRs so that the NTP timestamp of streams from A= and C now are based on the clock of S (NTP timestamp S). But when that has= been done we also have to rewrite the RTCP SR of all other streams from A and C which we at some point would lik= e to have synchronized playback with, which will require all those streams = to also go through S. So basically we will not be able to have to servers, = S1 and S2, which for example handle video and audio streams respectively.

=A0

Maybe not a big issue, but to me it feels= like a limitation without benefits. I don't see the point of requiring= that timestamps used for congestion control should be set in relation to the RTP timestamps which is meant for doing synchronized playb= ack.

=A0

=A0

So I really don=92t see any benefit tha= t a new extension would provide beyond RFC 5450. Perhaps I=92m missing it.<= /span>

=A0

I=92m also missing why you need to conv= ert to NTP time in order to =93jointly process all RTP streams=94, because = only the deltas really matter not the actual NTP time, and RFC 5450 gives you a= ll you need for deltas.

=A0

The deltas only have a meaning in relatio= n to the corresponding RTP timestamp. RTP timestamps of different streams (= SSRCs) have different random offsets, and therefore can't be compared before converted to NTP. At least if you want to calculate the= delta between packets belonging from two different streams.<= /span>

=A0

=A0

> If we want to jointly process all = RTP streams from A to B (at the receiver, B) we can convert the RTP timesta= mps of all streams to NTP using the (RTP timestamp, NTP timestamp) tuple in th= e RTCP SR report.

=A0

Mo

=A0

=A0

From: rmcat-bounces@ietf.org [mailto:= rmcat-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: Monday, December 17, 2012 6:07 AM


To: rmcat@ietf.org
Subject: Re: [rmcat] Send timestamps

=A0

Separating the timestamp used as a congestion signal= from timestamps that may be used for other purposes would seem to me to be= an advantage in terms of architectural cleanliness.



RTP timestamps need to reflect media time. In a situation with relay nodes = and changing paths, this may have uncomfortable amounts of variation from t= he time the packets enter the last hop to the recipient.

Given that we won't have all systems deploying the new extension from D= ay One, we need to be able to fall back to the RTP timestamp (it's bett= er than nothing), but it seems we shouldn't marry it more than we have = to.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Harald

On 12/17/2012 12:00 PM, Stefan Holmer wrote:

I'll try to clarify with an example:

=A0

Let's say we have two clients (A and = B) in a call. We want to estimate the bandwidth from A to B by looking at t= he variations in one-way delay, which we can measure by comparing deltas in R= TP timestamp to deltas in receive-time. The problem with using RTP timestam= ps is that those represent capture time and not the send time of a frame, s= o we get a lot of noise related to variations in, e.g., video encoding time. To get around that we introdu= ce=A0RFC 5450=A0and now we can measure something much closer to actual network time. If we wan= t to jointly process all RTP streams from A to B (at the receiver, B) we ca= n convert the RTP timestamps of all streams to NTP using the (RTP timestamp= , NTP timestamp) tuple in the RTCP SR report.

=A0

Now let's add a server (let's cal= l it S) in between client A and B. This server simply relays RTP packets (a= nd might do some rewriting as well). Now we want to estimate the bandwidth between = A and S, and between S and B. S will have to change the timestamp offset (R= FC 5450) of the RTP packets to correspond to its send-time, but besides tha= t all is fine.

=A0

Now let's add a third client (C). S w= ill relay packets from both A and C to B, so ideally we should jointly proc= ess all of those packets when estimating the bandwidth between S to B. However= , packets sent from A will be based on the tuple (RTP timestamp A, NTP time= stamp A) and packets sent from C will be based on (RTP timestamp C, NTP tim= estamp C), so we can't just convert to NTP at B and compare them. This can be solved in the server by rewritin= g RTP and NTP timestamps to (RTP timestamp S, NTP timestamp S) before relay= ing to B, which requires rewriting both RTP packets and RTCP packets. This = is fine as long as you rewrite _all_ streams from the same sending client in the same way, otherwise you won= 9;t be able to synchronize them. Therefore all streams must go through the = same server.

=A0

I'm suggesting that we could introduc= e a new "send timestamp" which doesn't relate to the RTP time= stamp (which is used for synchronized playback). Whenever a packet is sent (no matter if i= t's sent from A, C or S) it will be stamped with the send-time taken fr= om the clock of that sender, for instance at 1 kHz or 90 kHz. Since it'= s not related to the RTP timestamp we won't have to rewrite the (RTP, NTP) tuple, and actually, we don't even have= to convert to NTP at the receiver since all send timestamps are taken dire= ctly from the same clock. Removing the relation to the RTP timestamp is wha= t I mean with an "absolute" timestamp (i.e., not relative to RTP timestamp).

=A0

/Stefan

=A0=

On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanat= y (mzanaty) <mzanaty@cisco.com> wrote:

Please clarify =93absolute=94. Do you m= ean another RTP timestamp using the same units but a random offset from the main RTP timestamp, and no implied sync across multiple RTP sessions? Or N= TP timestamps with NTP units and implied sync across all RTP sessions (with= in the same sync domain, currently defined to be CNAME)?

=A0

Please also clarify =93relay conference= server=94, as there are many RTP topologies for conferencing. I think you = are probably referring to a source projection mixer. Rewriting RTCP is standar= d practice for those, as well as most mixers. In fact, I can=92t envision w= hen it would be possible to blindly relay RTCP in any mixer/topology. So I= =92m not sure what complications you see arising from the use of RFC 5450.

=A0

Mo

=A0

From: rmcat-bounces@ietf.org [mailto:= rmcat-bounces@ietf.org] On Behalf Of Stefan Holmer
Sent: Tuesday, December 04, 2012 4:23 AM
To: rmcat WG
Subject: [rmcat] Send timestamps

=A0

Hi,

=A0

In draft-alvestrand-rtc= web-congestion-01=A0we proposed using a send timestamp RTP header extension for measuring the pac= ket inter-arrival time offset. In 02=A0this was revised to instead reference RFC 5450, which specifies a header extension for specifying the send timestamp as an offset relative t= o the RTP timestamp.

=A0

Thinking further about this, there seems = to be a couple of benefits with defining a new, absolute, send timestamp header extension. If a relay approach to conference servers are used, the = relaying server can simply rewrite the send timestamp of a packet to corres= pond to the time it was relayed. Doing so the receiver can jointly process = all streams being received from the relay server, even though they were initially captured and sent by dif= ferent senders (with different clocks).=A0

=A0

With a send timestamp offset, accomplishi= ng the same thing would require rewriting both the timestamp offset and the NTP time in the corresponding RTCP SR reports. And to keep video synch= ronized with audio the RTCP packet for the audio streams must also be rewri= tten in a similar way. This may not even be possible if the audio stream is= relayed through a different server.

=A0

Do you see any problems with using an RTP= header extension with absolute send timestamps? Are there any benefits with the send timestamp offset header extension I might be missing?=

=A0

/Stefan

=A0

=A0

=A0


--0015174a05d08755b904d2c26831-- From lars@netapp.com Tue Jan 8 03:02:57 2013 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 92BBC21F8E45 for ; Tue, 8 Jan 2013 03:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.53 X-Spam-Level: X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 QZrAI5HC9g-u for ; Tue, 8 Jan 2013 03:02:56 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id B9E1921F8E1C for ; Tue, 8 Jan 2013 03:02:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,430,1355126400"; d="scan'208";a="5645957" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 08 Jan 2013 03:02:47 -0800 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r08B2lIO002794 for ; Tue, 8 Jan 2013 03:02:47 -0800 (PST) Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.8.16]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0328.009; Tue, 8 Jan 2013 03:02:46 -0800 From: "Eggert, Lars" To: " WG" Thread-Topic: send agenda requests for IETF-86 Thread-Index: AQHN7Y+wvs5Unv0j50WdTZXpwWNL1w== Date: Tue, 8 Jan 2013 11:02:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <96E0047779D34D4F842E7EA7054AC06F@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rmcat] send agenda requests for IETF-86 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: Tue, 08 Jan 2013 11:02:57 -0000 Hi, we asked for a 2.5h slot for RMCAT in Orlando. Please send Mirja and me req= uests for agenda time ASAP. Note that we will again prioritize discussion o= f topics related to our next milestones, which are cc-requirements, eval-cr= iteria, rtcp-requirements (if needed), and app-interactions. (See http://tr= ac.tools.ietf.org/wg/rmcat/trac/wiki/RearrangedCharter for which milestones= are meant with these short tags.) For any topic *not* related to those first milestones, a request for agenda= time is best motivated by the early availability of a related ID and an ac= tive discussion on the list. Thanks, Lars= From michawe@ifi.uio.no Tue Jan 8 03:52:23 2013 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 CADFE21F8CD1 for ; Tue, 8 Jan 2013 03:52:23 -0800 (PST) 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=[AWL=0.000, 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 KAVhqCatNgdV for ; Tue, 8 Jan 2013 03:52:23 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 38D5621F86CC for ; Tue, 8 Jan 2013 03:52:23 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TsXjC-0007u9-1x; Tue, 08 Jan 2013 12:52:22 +0100 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 1TsXjB-0003Q2-M7; Tue, 08 Jan 2013 12:52:22 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: Date: Tue, 8 Jan 2013 12:52:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D81B7A3-F980-4832-ADFF-42DCD9041E52@ifi.uio.no> References: To: "rmcat-chairs@tools.ietf.org" X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 8 sum msgs/h 4 total rcpts 1219 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.124, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9DE5E5CA9FDE946015FC6307B3166CA1FD02A2AF X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -50 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 361 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: "rmcat@ietf.org WG" Subject: Re: [rmcat] send agenda requests for IETF-86 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, 08 Jan 2013 11:52:23 -0000 Hi, I would like to make a request to present a first draft on "Identifying = and controlling groups of flows", which I'm currently writing. I actually wanted to get this done before Christmas, but that just = didn't work out. I'm trying to get this done ASAP now. Cheers, Michael On 8. jan. 2013, at 12:02, Eggert, Lars wrote: > Hi, >=20 > we asked for a 2.5h slot for RMCAT in Orlando. Please send Mirja and = me requests for agenda time ASAP. Note that we will again prioritize = discussion of topics related to our next milestones, which are = cc-requirements, eval-criteria, rtcp-requirements (if needed), and = app-interactions. (See = http://trac.tools.ietf.org/wg/rmcat/trac/wiki/RearrangedCharter for = which milestones are meant with these short tags.) >=20 > For any topic *not* related to those first milestones, a request for = agenda time is best motivated by the early availability of a related ID = and an active discussion on the list. >=20 > Thanks, > Lars From harald@alvestrand.no Tue Jan 8 05:44:43 2013 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 2391E21F8475 for ; Tue, 8 Jan 2013 05:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.198 X-Spam-Level: X-Spam-Status: No, score=-110.198 tagged_above=-999 required=5 tests=[AWL=0.400, 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 Lj9PVoJ+bXQn for ; Tue, 8 Jan 2013 05:44:42 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF6421F842B for ; Tue, 8 Jan 2013 05:44:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD88E39E235 for ; Tue, 8 Jan 2013 14:44:31 +0100 (CET) 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 ncSwBoE-ufTv for ; Tue, 8 Jan 2013 14:44:29 +0100 (CET) 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 5AA8839E16A for ; Tue, 8 Jan 2013 14:44:29 +0100 (CET) Message-ID: <50EC22BC.6020402@alvestrand.no> Date: Tue, 08 Jan 2013 14:44:28 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <0FCEA7FA-7DC3-4D18-9D24-B41DDBB4F5B7@ifi.uio.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080002010209090509030507" Subject: Re: [rmcat] Several comments about RRTCC 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, 08 Jan 2013 13:44:43 -0000 This is a multi-part message in MIME format. --------------080002010209090509030507 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Some inlines... On 01/07/2013 01:56 PM, Stefan Holmer wrote: > Some comments. > > On Sat, Dec 29, 2012 at 2:30 PM, Michael Welzl > wrote: > > Dear all, > > I / we have found a number of potential issues with > draft-alvestrand-rtcweb-congestion-03, and would like to share > them with the group. I have shared some but not all of these > thoughts directly with the authors in the past, but I think it's > useful to have them put together in a list. > > 1) > The RRTCC acronym. The draft luckily doesn't contain it, but I > think the mechanism should have an acronym anyway. I have to > search through my mailbox every time to see if RRTCC is really > what it was called… may I propose "DemiResi" ? (Delay > minimization with reduced signaling) "Resi" also gives you > plenty of nice associations to mountains… cows… yodeling… > red-white plaid skirts and Lederhosen! Easier to remember than > RRTCC, no doubt! To get you guys used to the idea, I will call it > DemiResi in my text below :-) > > > Fine with me, although I haven't had any problems remembering RRTCC > (very similar to RTC). :) I frankly can't bring myself to care, but if you want to make a new label, shouldn't we attach it to the end product rather to the input proposal? > > > > 2) > Given that minimizing the amount of feedback seems to be a goal, > this feedback becomes very important. Losing a TCP ACK isn't a big > deal, but losing a DemiResi feedback message is. Given the minimal > space needed (essentially, one bit … plus a little more, to avoid > ambiguity etc.), I think we should introduce "acks-of-acks", i.e. > a message that says "I got your feedback". Yes, that message would > only appear at the receiver within one RTT, but if the sender's > timeout (2x t_max_fb_interval) is larger than an RTT, it could > help to make the receiver retransmit its feedback early when that > message is missing. Personally I'm not convinced that it's a good > idea to send less than a message / RTT anyway, in which case such > ACKs-of-ACKs could still be useful, as they would disambiguate > forward from backward loss. For instance, the next message could > then tell the sender "don't reduce your rate because of the loss > that you see, it's only the backward path". > > > Sounds like a reasonable approach to me. As I keep reminding people .... a message/RTT devolves to a message/message for short-RTT scenarios. While many short-RTT scenarios are also high-bandwidth, not all are. > > > 3) > The TCP steady-state throughput equation from RFC3448 (in what > follows, I will call it "TFRC equation") is rather sensitive to > the correct usage of p, the packet loss event ratio. The way it is > used in the draft, p is packet loss but not the loss event ratio. > Correct usage would require sending loss events from the receiver > to the sender (DCCP has a way to do this), or, which would strike > me as being much simpler, calculating this equation on the > receiver side. The receiver has all the information about packet > loss available. This would require the receiver to have some > notion of the RTT, which it could get e.g. if item 2) above is > implemented. > > > I agree that such a mechanism makes sense to have on the receiving > side. We initially put it on the sending side to have some type of > compatibility with receivers which did not implement the delay-based > algorithm, but the plan has been to also take the loss signal into > account at the receiver. Haven't gotten there yet though... Having the sender do something reasonable when the receiver just stops sending feedback is a required feature, I think. > > > > 4) > The text on page 12 of the draft reads as if it would be > impossible for the receive-side estimate of the available > bandwidth A(i) to go below the value obtained with the TFRC > equation. If it does, however, DemiResi becomes like some form of > TFRC, even in the absence of other TCPs. Can we be sure that this > won't happen? It could be an idea to fall back to such TFRC-like > behavior only if loss is large enough to indicate that we're > competing with TCP… we might not always, and when we're not, we > should keep delay low. > > > It should be interpreted as "As(i) can't go above A(i), and As(i) will > only go below what TFRC ( let's call it TFRC(i)) says if A(i) is less > than TFRC(i)." > > Therefore we shouldn't have the problem you mention, but we will also > not be able to use this mechanism to compete with TCP. It should > however be useful in a scenario where we don't get a reliable > delay-signal due to AQM. > > > > 5) > The thresholds on page 12 seem troublesome to me: the behavior > stays unchanged in the 2-10% loss regime (this is high loss!), it > is reduced in proportion to the loss ratio in case of above 10% > (seems reasonable, except that 10% is already quite extreme), BUT: > "As long as less than 2% of the packets have been lost As(i) will > be increased as As(i)=1.05(As(i-1)+1000)" > …. this latter item means that, as long as we're below 2% loss, > the mechanism increases its rate, making 2% its loss target?! > This strikes me as rather odd for a mechanism that's supposed to > avoid loss and delay and keep queues low. Again, if this is done > for interoperation with TCP, it could be an idea to do it only > when loss is above a certain percentage (as it would be caused by > TCP). > > > I agree that those thresholds may have to be changed. The 2% threshold > could indeed be interpreted as some kind of target for the AQM case, > which I agree is a bad idea. I think scaling down all of these > thresholds makes a lot of sense. Seems like an area for running experiments to me. > > > 6) > Rather obviously, ECN should be incorporated... > > > Surely there's more stuff to find. I guess my main criticism is > that we still don't have a paper, a technical report, simulation > code or a simple standalone implementation to play with. Simply > not enough data. > > I hope this was constructive... > > Cheers, > Michael > > --------------080002010209090509030507 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Some inlines...

On 01/07/2013 01:56 PM, Stefan Holmer wrote:
Some comments.

On Sat, Dec 29, 2012 at 2:30 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
Dear all,

I / we have found a number of potential issues with draft-alvestrand-rtcweb-congestion-03, and would like to share them with the group. I have shared some but not all of these thoughts directly with the authors in the past, but I think it's useful to have them put together in a list.

1)
The RRTCC acronym. The draft luckily doesn't contain it, but I think the mechanism should have an acronym anyway. I have to search through my mailbox every time to see if RRTCC is really what it was called… may I propose "DemiResi" ?  (Delay minimization with reduced signaling)     "Resi" also gives you plenty of nice associations to mountains… cows… yodeling… red-white plaid skirts and Lederhosen!  Easier to remember than RRTCC, no doubt! To get you guys used to the idea, I will call it DemiResi in my text below  :-)

Fine with me, although I haven't had any problems remembering RRTCC (very similar to RTC). :)

I frankly can't bring myself to care, but if you want to make a new label, shouldn't we attach it to the end product rather to the input proposal?
 


2)
Given that minimizing the amount of feedback seems to be a goal, this feedback becomes very important. Losing a TCP ACK isn't a big deal, but losing a DemiResi feedback message is. Given the minimal space needed (essentially, one bit … plus a little more, to avoid ambiguity etc.), I think we should introduce "acks-of-acks", i.e. a message that says "I got your feedback". Yes, that message would only appear at the receiver within one RTT, but if the sender's timeout (2x t_max_fb_interval)  is larger than an RTT, it could help to make the receiver retransmit its feedback early when that message is missing. Personally I'm not convinced that it's a good idea to send less than a message / RTT anyway, in which case such ACKs-of-ACKs could still be useful, as they would disambiguate forward from backward loss. For instance, the next message could then tell the sender "don't reduce your rate because of the loss that you see, it's only the backward path".

Sounds like a reasonable approach to me.

As I keep reminding people .... a message/RTT devolves to a message/message for short-RTT scenarios. While many short-RTT scenarios are also high-bandwidth, not all are.

 


3)
The TCP steady-state throughput equation from RFC3448 (in what follows, I will call it "TFRC equation") is rather sensitive to the correct usage of p, the packet loss event ratio. The way it is used in the draft, p is packet loss but not the loss event ratio. Correct usage would require sending loss events from the receiver to the sender (DCCP has a way to do this), or, which would strike me as being much simpler, calculating this equation on the receiver side. The receiver has all the information about packet loss available. This would require the receiver to have some notion of the RTT, which it could get e.g. if item 2) above is implemented.

I agree that such a mechanism makes sense to have on the receiving side. We initially put it on the sending side to have some type of compatibility with receivers which did not implement the delay-based algorithm, but the plan has been to also take the loss signal into account at the receiver. Haven't gotten there yet though...

Having the sender do something reasonable when the receiver just stops sending feedback is a required feature, I think.
 


4)
The text on page 12 of the draft reads as if it would be impossible for the receive-side estimate of the available bandwidth A(i) to go below the value obtained with the TFRC equation. If it does, however, DemiResi becomes like some form of TFRC, even in the absence of other TCPs. Can we be sure that this won't happen? It could be an idea to fall back to such TFRC-like behavior only if loss is large enough to indicate that we're competing with TCP… we might not always, and when we're not, we should keep delay low.

It should be interpreted as "As(i) can't go above A(i), and As(i) will only go below what TFRC ( let's call it TFRC(i)) says if A(i) is less than TFRC(i)."

Therefore we shouldn't have the problem you mention, but we will also not be able to use this mechanism to compete with TCP. It should however be useful in a scenario where we don't get a reliable delay-signal due to AQM.



5)
The thresholds on page 12 seem troublesome to me: the behavior stays unchanged in the 2-10% loss regime (this is high loss!), it is reduced in proportion to the loss ratio in case of above 10% (seems reasonable, except that 10% is already quite extreme), BUT: "As long as less than 2% of the packets have been lost As(i) will be increased as As(i)=1.05(As(i-1)+1000)"
…. this latter item means that, as long as we're below 2% loss, the mechanism increases its rate, making 2% its loss target?!  This strikes me as rather odd for a mechanism that's supposed to avoid loss and delay and keep queues low. Again, if this is done for interoperation with TCP, it could be an idea to do it only when loss is above a certain percentage (as it would be caused by TCP).

I agree that those thresholds may have to be changed. The 2% threshold could indeed be interpreted as some kind of target for the AQM case, which I agree is a bad idea. I think scaling down all of these thresholds makes a lot of sense.

Seems like an area for running experiments to me.

 


6)
Rather obviously, ECN should be incorporated...


Surely there's more stuff to find. I guess my main criticism is that we still don't have a paper, a technical report, simulation code or a simple standalone implementation to play with. Simply not enough data.

I hope this was constructive...

Cheers,
Michael



--------------080002010209090509030507-- From michawe@ifi.uio.no Tue Jan 8 06:28:19 2013 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 B3BF021F8583 for ; Tue, 8 Jan 2013 06:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ZrEdvlap7BWo for ; Tue, 8 Jan 2013 06:28:18 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id AD65C21F842E for ; Tue, 8 Jan 2013 06:28:17 -0800 (PST) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TsaA4-0000aT-Fo; Tue, 08 Jan 2013 15:28:16 +0100 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 1TsaA3-0004Gt-92; Tue, 08 Jan 2013 15:28:16 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D32CAABD-2B65-48B0-880F-3BA1F021E7ED" From: Michael Welzl In-Reply-To: <50EC22BC.6020402@alvestrand.no> Date: Tue, 8 Jan 2013 15:28:14 +0100 Message-Id: <5D810FC6-ECE4-402D-9AFB-8025897EF753@ifi.uio.no> References: <0FCEA7FA-7DC3-4D18-9D24-B41DDBB4F5B7@ifi.uio.no> <50EC22BC.6020402@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 1225 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.1, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.124, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5B6041F0D2786AADFDDEEFA5C7FA3CCBF5018E8B X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -50 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 364 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat@ietf.org Subject: Re: [rmcat] Several comments about RRTCC 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, 08 Jan 2013 14:28:19 -0000 --Apple-Mail=_D32CAABD-2B65-48B0-880F-3BA1F021E7ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 8. jan. 2013, at 14:44, Harald Alvestrand wrote: > Some inlines... >=20 > On 01/07/2013 01:56 PM, Stefan Holmer wrote: >> Some comments. >>=20 >> On Sat, Dec 29, 2012 at 2:30 PM, Michael Welzl = wrote: >> Dear all, >>=20 >> I / we have found a number of potential issues with = draft-alvestrand-rtcweb-congestion-03, and would like to share them with = the group. I have shared some but not all of these thoughts directly = with the authors in the past, but I think it's useful to have them put = together in a list. >>=20 >> 1) >> The RRTCC acronym. The draft luckily doesn't contain it, but I think = the mechanism should have an acronym anyway. I have to search through my = mailbox every time to see if RRTCC is really what it was called=85 may I = propose "DemiResi" ? (Delay minimization with reduced signaling) = "Resi" also gives you plenty of nice associations to mountains=85 cows=85 = yodeling=85 red-white plaid skirts and Lederhosen! Easier to remember = than RRTCC, no doubt! To get you guys used to the idea, I will call it = DemiResi in my text below :-) >>=20 >> Fine with me, although I haven't had any problems remembering RRTCC = (very similar to RTC). :) >=20 > I frankly can't bring myself to care, but if you want to make a new = label, shouldn't we attach it to the end product rather to the input = proposal? Well honestly that wasn't so serious, and I don't really care either. = It's nice to have an acronym when talking about it. >> =20 >>=20 >>=20 >> 2) >> Given that minimizing the amount of feedback seems to be a goal, this = feedback becomes very important. Losing a TCP ACK isn't a big deal, but = losing a DemiResi feedback message is. Given the minimal space needed = (essentially, one bit =85 plus a little more, to avoid ambiguity etc.), = I think we should introduce "acks-of-acks", i.e. a message that says "I = got your feedback". Yes, that message would only appear at the receiver = within one RTT, but if the sender's timeout (2x t_max_fb_interval) is = larger than an RTT, it could help to make the receiver retransmit its = feedback early when that message is missing. Personally I'm not = convinced that it's a good idea to send less than a message / RTT = anyway, in which case such ACKs-of-ACKs could still be useful, as they = would disambiguate forward from backward loss. For instance, the next = message could then tell the sender "don't reduce your rate because of = the loss that you see, it's only the backward path". >>=20 >> Sounds like a reasonable approach to me. >=20 > As I keep reminding people .... a message/RTT devolves to a = message/message for short-RTT scenarios. While many short-RTT scenarios = are also high-bandwidth, not all are. Just to be sure we're not losing the context: there are two issues in my = text above - 1) we shouldn't generally send less feedback than 1 message = per RTT; 2) if we do, we should at least have some sort of = "ACK-of-ACK". #1 was a sort of side comment, and item #2 is what this = was really about, and what Stefan replied to. You're replying to #1 = here. Here's my answer to what you say: My concern is the notion of a DesiResi ;-) sender that transmits a = lot and competes with TCP connections on the same path, which, in the = absence of extreme RTT variation, will have a timeout a bit above an = RTT. DesiResi's sender might not react for several RTTs and just keep = sending, while the TCPs will all experience a timeout. The resulting = behavior could be a level of unfairness that is user-perceivable and = just not good. Now, even TCP doesn't HAVE to send data every RTT, and when it doesn't, = there's also no feedback... nothing wrong with that, neither for TCP nor = for DesiResi. So my statement "Personally I'm not convinced that it's a = good idea to send less than a message / RTT anyway" is too strict, it = should be limited to the case of: sender's rate >=3D 1 message / RTT. >> 3) >> The TCP steady-state throughput equation from RFC3448 (in what = follows, I will call it "TFRC equation") is rather sensitive to the = correct usage of p, the packet loss event ratio. The way it is used in = the draft, p is packet loss but not the loss event ratio. Correct usage = would require sending loss events from the receiver to the sender (DCCP = has a way to do this), or, which would strike me as being much simpler, = calculating this equation on the receiver side. The receiver has all the = information about packet loss available. This would require the receiver = to have some notion of the RTT, which it could get e.g. if item 2) above = is implemented. >>=20 >> I agree that such a mechanism makes sense to have on the receiving = side. We initially put it on the sending side to have some type of = compatibility with receivers which did not implement the delay-based = algorithm, but the plan has been to also take the loss signal into = account at the receiver. Haven't gotten there yet though... >=20 > Having the sender do something reasonable when the receiver just stops = sending feedback is a required feature, I think. I think we all agree on that, but anyway, it seems to me that what you = say here is unrelated to the text just above it. This is about how, and = where, to calculate the TFRC equation. >> 4) >> The text on page 12 of the draft reads as if it would be impossible = for the receive-side estimate of the available bandwidth A(i) to go = below the value obtained with the TFRC equation. If it does, however, = DemiResi becomes like some form of TFRC, even in the absence of other = TCPs. Can we be sure that this won't happen? It could be an idea to fall = back to such TFRC-like behavior only if loss is large enough to indicate = that we're competing with TCP=85 we might not always, and when we're = not, we should keep delay low. >>=20 >> It should be interpreted as "As(i) can't go above A(i), and As(i) = will only go below what TFRC ( let's call it TFRC(i)) says if A(i) is = less than TFRC(i)." >>=20 >> Therefore we shouldn't have the problem you mention, but we will also = not be able to use this mechanism to compete with TCP. It should however = be useful in a scenario where we don't get a reliable delay-signal due = to AQM. >>=20 >>=20 >>=20 >> 5) >> The thresholds on page 12 seem troublesome to me: the behavior stays = unchanged in the 2-10% loss regime (this is high loss!), it is reduced = in proportion to the loss ratio in case of above 10% (seems reasonable, = except that 10% is already quite extreme), BUT: "As long as less than 2% = of the packets have been lost As(i) will be increased as = As(i)=3D1.05(As(i-1)+1000)" >> =85. this latter item means that, as long as we're below 2% loss, the = mechanism increases its rate, making 2% its loss target?! This strikes = me as rather odd for a mechanism that's supposed to avoid loss and delay = and keep queues low. Again, if this is done for interoperation with TCP, = it could be an idea to do it only when loss is above a = certain percentage (as it would be caused by TCP). >>=20 >> I agree that those thresholds may have to be changed. The 2% = threshold could indeed be interpreted as some kind of target for the AQM = case, which I agree is a bad idea. I think scaling down all of these = thresholds makes a lot of sense. >=20 > Seems like an area for running experiments to me. I agree >=20 >> =20 >>=20 >>=20 >> 6) >> Rather obviously, ECN should be incorporated... >>=20 >>=20 >> Surely there's more stuff to find. I guess my main criticism is that = we still don't have a paper, a technical report, simulation code or a = simple standalone implementation to play with. Simply not enough data. >>=20 >> I hope this was constructive... >>=20 >> Cheers, >> Michael >>=20 >>=20 >=20 --Apple-Mail=_D32CAABD-2B65-48B0-880F-3BA1F021E7ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
=20 =20
Some inlines...

On 01/07/2013 01:56 PM, Stefan Holmer wrote:
Some comments.

On Sat, Dec 29, 2012 at 2:30 PM, Michael Welzl <michawe@ifi.uio.no> = wrote:
Dear all,

I / we have found a number of potential issues with draft-alvestrand-rtcweb-congestion-03, and would like to share them with the group. I have shared some but not all of these thoughts directly with the authors in the past, but I think it's useful to have them put together in a list.

1)
The RRTCC acronym. The draft luckily doesn't contain it, but I think the mechanism should have an acronym anyway. I have to search through my mailbox every time to see if RRTCC is really what it was called=85 may I propose "DemiResi" ?  (Delay minimization with reduced = signaling)     "Resi" also gives you plenty of nice = associations to mountains=85 cows=85 yodeling=85 red-white plaid skirts = and Lederhosen!  Easier to remember than RRTCC, no doubt! = To get you guys used to the idea, I will call it DemiResi in my text below  :-)

Fine with me, although I haven't had any problems remembering RRTCC (very similar to RTC). :)

I frankly can't bring myself to care, but if you want to make a new label, shouldn't we attach it to the end product rather to the input proposal?

Well honestly that = wasn't so serious, and I don't really care either. It's nice to have an = acronym when talking about it.


 


2)
Given that minimizing the amount of feedback seems to be a goal, this feedback becomes very important. Losing a TCP ACK isn't a big deal, but losing a DemiResi feedback message is. Given the minimal space needed (essentially, one bit =85 plus a little more, to avoid ambiguity etc.), = I think we should introduce "acks-of-acks", i.e. a message that says "I got your feedback". Yes, that message would only appear at the receiver within one RTT, but if the sender's timeout (2x t_max_fb_interval)  is larger = than an RTT, it could help to make the receiver retransmit its feedback early when that message is missing. Personally I'm not convinced that it's a good idea to send less than a message / RTT anyway, in which case such ACKs-of-ACKs could still be useful, as they would disambiguate forward from backward loss. For instance, the next message could then tell the sender "don't reduce your rate because of the loss that you see, it's only the backward path".

Sounds like a reasonable approach to = me.

As I keep reminding people .... a message/RTT devolves to a message/message for short-RTT scenarios. While many short-RTT scenarios are also high-bandwidth, not all = are.

Just to be sure we're not = losing the context: there are two issues in my text above - 1) we = shouldn't generally send less feedback than 1 message per RTT; =  2) if we do, we should at least have some sort of "ACK-of-ACK". #1 = was a sort of side comment, and item #2 is what this was really about, = and what Stefan replied to. You're replying to #1 = here.

Here's my answer to what you = say:
My concern is the notion of a DesiResi  ;-)   = sender that transmits a lot and competes with TCP connections on the = same path, which, in the absence of extreme RTT variation, will have a = timeout a bit  above an RTT. DesiResi's sender might not react for = several RTTs and just keep sending, while the TCPs will all experience a = timeout. The resulting behavior could be a level of unfairness that is = user-perceivable and just not good.

Now, even = TCP doesn't HAVE to send data every RTT, and when it doesn't, there's = also no feedback... nothing wrong with that, neither for TCP nor for = DesiResi. So my statement "Personally I'm not convinced that it's a good = idea to send less than a message / RTT anyway" is too strict, it should = be limited to the case of: sender's rate >=3D 1 message / = RTT.


=20
3)
The TCP steady-state throughput equation from RFC3448 (in what follows, I will call it "TFRC equation") is rather sensitive to the correct usage of p, the packet loss event ratio. The way it is used in the draft, p is packet loss but not the loss event ratio. Correct usage would require sending loss events from the receiver to the sender (DCCP has a way to do this), or, which would strike me as being much simpler, calculating this equation on the receiver side. The receiver has all the information about packet loss available. This would require the receiver to have some notion of the RTT, which it could get e.g. if item 2) above is implemented.

I agree that such a mechanism makes sense to have on the receiving side. We initially put it on the sending side to have some type of compatibility with receivers which did not implement the delay-based algorithm, but the plan has been to also take the loss signal into account at the receiver. Haven't gotten there yet though...

Having the sender do something reasonable when the receiver just stops sending feedback is a required feature, I = think.

I think we all agree on = that, but anyway, it seems to me that what you say here is unrelated to = the text just above it. This is about how, and where, to calculate the = TFRC equation.


4)
The text on page 12 of the draft reads as if it would be impossible for the receive-side estimate of the available bandwidth A(i) to go below the value obtained with the TFRC equation. If it does, however, DemiResi becomes like some form of TFRC, even in the absence of other TCPs. Can we be sure that this won't happen? It could be an idea to fall back to such TFRC-like behavior only if loss is large enough to indicate that we're competing with TCP=85 we = might not always, and when we're not, we should keep delay = low.

It should be interpreted as "As(i) = can't go above A(i), and As(i) will only go below what TFRC ( let's call it TFRC(i)) says if A(i) is less than TFRC(i)."

Therefore we shouldn't have the problem you mention, but we will also not be able to use this mechanism to compete with TCP. It should however be useful in a scenario where we don't get a reliable delay-signal due to AQM.



5)
The thresholds on page 12 seem troublesome to me: the behavior stays unchanged in the 2-10% loss regime (this is high loss!), it is reduced in proportion to the loss ratio in case of above 10% (seems reasonable, except that 10% is already quite extreme), BUT: "As long as less than 2% of the packets have been lost As(i) will be increased as As(i)=3D1.05(As(i-1)+1000)"
=85. this latter item means that, as long as we're below = 2% loss, the mechanism increases its rate, making 2% its loss target?!  This strikes me as rather odd for a = mechanism that's supposed to avoid loss and delay and keep queues low. Again, if this is done for interoperation with TCP, it could be an idea to do it only when loss is above a certain percentage (as it would be caused by TCP).

I agree that those thresholds may have to be changed. The 2% threshold could indeed be interpreted as some kind of target for the AQM case, which I agree is a bad idea. I think scaling down all of these thresholds makes a lot of sense.

Seems like an area for running experiments to = me.

I = agree



 


6)
Rather obviously, ECN should be incorporated...


Surely there's more stuff to find. I guess my main criticism is that we still don't have a paper, a technical report, simulation code or a simple standalone implementation to play with. Simply not enough data.

I hope this was constructive...

Cheers,
Michael




= --Apple-Mail=_D32CAABD-2B65-48B0-880F-3BA1F021E7ED-- From harald@alvestrand.no Wed Jan 16 08:15:23 2013 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 213A321F8AE3 for ; Wed, 16 Jan 2013 08:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.489 X-Spam-Level: X-Spam-Status: No, score=-110.489 tagged_above=-999 required=5 tests=[AWL=0.109, 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 BRlXecDCRfya for ; Wed, 16 Jan 2013 08:15:22 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CB9E321F8AD8 for ; Wed, 16 Jan 2013 08:15:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7C9B539E241 for ; Wed, 16 Jan 2013 17:15:20 +0100 (CET) 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 tJdVwBVuDXHV for ; Wed, 16 Jan 2013 17:15:18 +0100 (CET) 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 2473739E0CE for ; Wed, 16 Jan 2013 17:15:18 +0100 (CET) Message-ID: <50F6D215.9070007@alvestrand.no> Date: Wed, 16 Jan 2013 17:15:17 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <20130116132619.26398.97306.idtracker@ietfa.amsl.com> In-Reply-To: <20130116132619.26398.97306.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130116132619.26398.97306.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020402070206080900050905" Subject: [rmcat] Fwd: New Version Notification for draft-alvestrand-rmcat-remb-02.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, 16 Jan 2013 16:15:23 -0000 This is a multi-part message in MIME format. --------------020402070206080900050905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Just a notification that this draft will stick in the I-D directories for another 6 months. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rmcat-remb-02.txt Date: Wed, 16 Jan 2013 05:26:19 -0800 From: internet-drafts@ietf.org To: harald@alvestrand.no A new version of I-D, draft-alvestrand-rmcat-remb-02.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rmcat-remb Revision: 02 Title: RTCP message for Receiver Estimated Maximum Bitrate Creation date: 2013-01-16 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-alvestrand-rmcat-remb-02.txt Status: http://datatracker.ietf.org/doc/draft-alvestrand-rmcat-remb Htmlized: http://tools.ietf.org/html/draft-alvestrand-rmcat-remb-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-alvestrand-rmcat-remb-02 Abstract: This document proposes an RTCP message for use in experimentally- deployed congestion control algorithms for RTP-based media flows. The IETF Secretariat --------------020402070206080900050905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Just a notification that this draft will stick in the I-D directories for another 6 months.

       Harald


-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rmcat-remb-02.txt
Date: Wed, 16 Jan 2013 05:26:19 -0800
From: internet-drafts@ietf.org
To: harald@alvestrand.no 


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

Filename:	 draft-alvestrand-rmcat-remb
Revision:	 02
Title:		 RTCP message for Receiver Estimated Maximum Bitrate
Creation date:	 2013-01-16
WG ID:		 Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-alvestrand-rmcat-remb-02.txt
Status:          http://datatracker.ietf.org/doc/draft-alvestrand-rmcat-remb
Htmlized:        http://tools.ietf.org/html/draft-alvestrand-rmcat-remb-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-alvestrand-rmcat-remb-02

Abstract:
   This document proposes an RTCP message for use in experimentally-
   deployed congestion control algorithms for RTP-based media flows.


                                                                                  


The IETF Secretariat


--------------020402070206080900050905-- From michawe@ifi.uio.no Sat Jan 19 01:58:09 2013 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 6443121F843E for ; Sat, 19 Jan 2013 01:58:09 -0800 (PST) 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 MOeWFedgJqMc for ; Sat, 19 Jan 2013 01:58:08 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [129.240.10.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8B20521F8202 for ; Sat, 19 Jan 2013 01:58:08 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1TwVBf-00008f-D7 for rmcat@ietf.org; Sat, 19 Jan 2013 10:58:07 +0100 Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.100]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TwVBe-0005iG-Ng for rmcat@ietf.org; Sat, 19 Jan 2013 10:58:07 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 19 Jan 2013 10:58:06 +0100 References: <20130119095614.17091.17595.idtracker@ietfa.amsl.com> To: "rmcat@ietf.org WG" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 3 sum rcpts/h 6 sum msgs/h 6 total rcpts 1484 max rcpts/h 20 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: 8CC9609B7DC8A571A41712EF922452508D6E937F X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 65 max/h 5 blacklist 0 greylist 0 ratelimit 0 Subject: [rmcat] Fwd: New Version Notification for draft-welzl-rmcat-coupled-cc-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: Sat, 19 Jan 2013 09:58:09 -0000 Hi all, See below the announcement of a draft I just posted, to address the = milestone on "identifying and controlling groups of flows". I'm curious to hear your thoughts! Cheers, Michael Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-welzl-rmcat-coupled-cc-00.txt > Date: January 19, 2013 10:56:14 AM GMT+01:00 > To: michawe@ifi.uio.no >=20 >=20 > A new version of I-D, draft-welzl-rmcat-coupled-cc-00.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Filename: draft-welzl-rmcat-coupled-cc > Revision: 00 > Title: Coupled congestion control for RTP media > Creation date: 2013-01-19 > WG ID: Individual Submission > Number of pages: 14 > URL: = http://www.ietf.org/internet-drafts/draft-welzl-rmcat-coupled-cc-00.txt > Status: = http://datatracker.ietf.org/doc/draft-welzl-rmcat-coupled-cc > Htmlized: = http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-00 >=20 >=20 > Abstract: > When multiple congestion controlled RTP sessions traverse the same > network bottleneck, it can be beneficial to combine their controls > such that the total on-the-wire behavior is improved. This document > describes such a method for flows that have the same sender, in a = way > that is as flexible and simple as possible while minimizing the > amount of changes needed to existing RTP applications. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From hassnaamoustafa@gmail.com Mon Jan 28 10:25:57 2013 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 90D1121F86EF for ; Mon, 28 Jan 2013 10:25:56 -0800 (PST) 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 5XlkQHMKQAae for ; Mon, 28 Jan 2013 10:25:56 -0800 (PST) Received: from mail-wi0-f195.google.com (mail-wi0-f195.google.com [209.85.212.195]) by ietfa.amsl.com (Postfix) with ESMTP id D242E21F86C5 for ; Mon, 28 Jan 2013 10:25:55 -0800 (PST) Received: by mail-wi0-f195.google.com with SMTP id hj6so756794wib.10 for ; Mon, 28 Jan 2013 10:25:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=qYKPQpyieneemMCw9ESLksQFm8In8jqTtBhtEip320A=; b=xeWEJAD/k/Wl+Q+LUPO79gqaPZNGqqDSuoTJXmoSKnQ+QMsEUl4rcz7zkOBd7VRwdY lD+o1sgIkExBgAD+tw2kVbtffdLRTjDUBdRBb0EIxutZMTuSDJ58JHgQVbgdNKVJIVoQ Zt1Q6JIuoekVgv8myj0U0dMOBf44vkU2F1F8AvbQCY2a/946ooRWLGSx/p6Hcvq+7u/3 VobzlTgcbFlz3knCpK5YCxTUwoezDHYLlPsSn64+w9btsUZu+WwEHaBAlIsxxLliji9U Nm6z1i6S7uruEuqu9RKOwTtZUHL5E1IUYbvS4ICiiJEtrohTn4x8IDQxXfAKPqp+gXHp VEcg== MIME-Version: 1.0 X-Received: by 10.180.85.226 with SMTP id k2mr11467500wiz.34.1359397555076; Mon, 28 Jan 2013 10:25:55 -0800 (PST) Received: by 10.180.96.170 with HTTP; Mon, 28 Jan 2013 10:25:54 -0800 (PST) Date: Mon, 28 Jan 2013 10:25:54 -0800 Message-ID: From: Hassnaa Moustafa To: rmcat@ietf.org Content-Type: multipart/alternative; boundary=f46d0442823060fdf304d45d680d Subject: [rmcat] draft-alvestrand-rmcat-remb 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, 28 Jan 2013 18:25:57 -0000 --f46d0442823060fdf304d45d680d Content-Type: text/plain; charset=ISO-8859-1 Hi, After reading the draft on (RTCP message for Receiver Estimated Maximum Bit Rate "draft-alvestrand-rmcat-remb"), it's not clear for me what is the target/scope of "multiple media streams" mentioned in the draft, is there a specific use-case fpr that "for example video conferences with more than one stream")? Regards, Hassnaa --f46d0442823060fdf304d45d680d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
After=A0reading=A0the draft on (RTCP message for Receiver Estimated Ma= ximum Bit Rate "draft-alvestrand-rmcat-remb"), it's not clear= for me what is the target/scope of=A0 "multiple media streams" m= entioned=A0in the draft, is there a specific use-case fpr that "for ex= ample video conferences with more than one stream")?
=A0
Regards,
Hassnaa
--f46d0442823060fdf304d45d680d-- From hassnaamoustafa@gmail.com Mon Jan 28 10:29:48 2013 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 64AC621F8901 for ; Mon, 28 Jan 2013 10:29:48 -0800 (PST) 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 WEgEiyo-kaB7 for ; Mon, 28 Jan 2013 10:29:48 -0800 (PST) Received: from mail-wg0-f66.google.com (mail-wg0-f66.google.com [74.125.82.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5C821F87FA for ; Mon, 28 Jan 2013 10:29:46 -0800 (PST) Received: by mail-wg0-f66.google.com with SMTP id 16so638419wgi.5 for ; Mon, 28 Jan 2013 10:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=WqemBZ/G+5Lczik+4IwNmhwF+D5xeGnRduRIJJHmHxo=; b=PEcS9d127sHfnv5NeMOuIUhCzxHciiRTC1VudY+b52gXdOhQZxRNe3hTtznIX7Qfh7 pd3+0ltZfzzpFQ1l/Qvyy9fbGHgMq1uqnd2UvrH0sHw4TMR551JBgCkTHHqvJlf2h9ts kO5tDY2Kp/MT9BEo/t3KKzJazfk67fTOXsuYtHbOilsRB8vO60ZFRD1C+B8Jd7ow3T8k ddlpkCApLTlHHQBmeEx18FhwJZ6EpZi3ujuSeTqBKn8BJemMXs4z6mJ1FOd5xi72YdC1 jz0/m7+rpz5dUEmHLOr9YYRmjyeRRieRuscsEgA7DlbuhJJ27Z3XPRUb2cRgUn4kvnIY yy+A== MIME-Version: 1.0 X-Received: by 10.180.33.202 with SMTP id t10mr11628560wii.3.1359397782072; Mon, 28 Jan 2013 10:29:42 -0800 (PST) Received: by 10.180.96.170 with HTTP; Mon, 28 Jan 2013 10:29:42 -0800 (PST) Date: Mon, 28 Jan 2013 10:29:42 -0800 Message-ID: From: Hassnaa Moustafa To: rmcat@ietf.org Content-Type: multipart/alternative; boundary=f46d04428f8ae8ac7e04d45d753c Subject: [rmcat] Draft 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, 28 Jan 2013 18:29:48 -0000 --f46d04428f8ae8ac7e04d45d753c Content-Type: text/plain; charset=ISO-8859-1 Hi, After reading the draft on Network-Assisted Dynamic Adaptation Congestion Control Scheme , I would like to know if the proposed algorithm considers working with multiple media streams ? Regards, Hassnaa --f46d04428f8ae8ac7e04d45d753c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0=20
Hi,=
After read= ing the draft on Network-Assisted Dynamic Adaptation Con= gestion Control Scheme=A0<draft-zhu-rmcat-nada>, I would like to know= if the proposed algorithm considers working with multiple media streams ? =
=A0=
Regards,
Hassnaa
--f46d04428f8ae8ac7e04d45d753c-- From hassnaamoustafa@gmail.com Mon Jan 28 10:33:27 2013 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 6499B21F899E for ; Mon, 28 Jan 2013 10:33:27 -0800 (PST) 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 BMdv9FMYVFRM for ; Mon, 28 Jan 2013 10:33:26 -0800 (PST) Received: from mail-wg0-f65.google.com (mail-wg0-f65.google.com [74.125.82.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEA521F8718 for ; Mon, 28 Jan 2013 10:33:26 -0800 (PST) Received: by mail-wg0-f65.google.com with SMTP id e12so638348wge.8 for ; Mon, 28 Jan 2013 10:33:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=7ceuMxHNvG2FXUKW1HiPeFk1KdOEIn2l9Ge/AITG6pE=; b=knnvnfx2ylLG8Zv1yPlPvMX26siCyulCWtVKIqTEhlHqkZwzuA9EI3VFRf6e9a4M4s +FUWsdNQN3/9HsdZNY8z4LKX7qeZBaFmWSADuldA9Tlp0aoiloAk/eefoNiXDLKC1rxB eDGU04QhPo53PQPPalVF79X4Sw51vIX/q9Y9WUik/gMY9Z6wTPa3Uy0oKb9ztCG6uBht CSnXVKWDBwUxCjy2EnlKGVb2dcdQvjwCGCuP4FEIEupb05/kjzsuXBKrBvb5pbHTWdoi OclP/h+bs05aI1bfg1sB0/XEa5V5Sx2RfibC7wHfIGxH0UjxKi4Gf81a+XbnbRprPOyu T39A== MIME-Version: 1.0 X-Received: by 10.195.13.11 with SMTP id eu11mr23160870wjd.39.1359398005701; Mon, 28 Jan 2013 10:33:25 -0800 (PST) Received: by 10.180.96.170 with HTTP; Mon, 28 Jan 2013 10:33:25 -0800 (PST) Date: Mon, 28 Jan 2013 10:33:25 -0800 Message-ID: From: Hassnaa Moustafa To: rmcat@ietf.org Content-Type: multipart/alternative; boundary=047d7bd91a843cfdc304d45d83ba Subject: [rmcat] draft-ohanlon-rmcat-dflow 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, 28 Jan 2013 18:33:27 -0000 --047d7bd91a843cfdc304d45d83ba Content-Type: text/plain; charset=ISO-8859-1 Hi, I have a question on the draft on Congestion Control Mechanism delay-based : the draft mentions the use of TFRC and TCP congestion mechanisms as the current building blocks (and mentions that while the draft will progress, other mechanisms could be proposed) --> my question is on the reason for being currently based on TFRC and TCP although the implentation problems that might exist with TFRC and TCP, is there a specific use-case for that ? Regards, Hassnaa --047d7bd91a843cfdc304d45d83ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
I have a question on the draft on=A0Congestion Control Mec= hanism delay-based=A0 <draft-ohanlon-rmcat-dflow>: the draft mentions= the use of TFRC and TCP congestion mechanisms as the current building bloc= ks (and mentions that while the draft will progress, other mechanisms could= be proposed) --> my question is on the reason for being currently based= on TFRC and TCP although the implentation problems that might exist with T= FRC and TCP, is there a specific use-case for that ?
=A0
=A0
Regards,
Hassnaa
=A0
--047d7bd91a843cfdc304d45d83ba-- From p.ohanlon@gmail.com Mon Jan 28 12:47:44 2013 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 03CB021F87A4 for ; Mon, 28 Jan 2013 12:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.571 X-Spam-Level: *** X-Spam-Status: No, score=3.571 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_LH_HOME=3.714, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 0ktf94kUORwA for ; Mon, 28 Jan 2013 12:47:43 -0800 (PST) Received: from mail-we0-x22c.google.com (we-in-x022c.1e100.net [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 53EEE21F879E for ; Mon, 28 Jan 2013 12:47:43 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so1833499wey.17 for ; Mon, 28 Jan 2013 12:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=hLFUS09T8qbkyN3rLrpO8M/UrUnVJlYorM/bcJiiGOo=; b=JsRbRZQBpas6BB1ZGu/+/9njOOlbggptuDk5UMldhJEhnFabhjcyJFzO23k4ECRpad ois6OFS63jBtBeJ4DolpnVyhaUGWrvY2ydAmdwD1aiVomLd2T4FprBjIGNoMLgPyAq3A tnm83OYvaaAvgvc/IxntR3jWBUBSy1ojWcqRyBf5+XptakDGdhMU7HRF++0Nkloez5MW QwSQx9ei+JEaNsbslK1QVhnWWz6kZCgXlwG4NH202Yh2B4On4fxz8/gQP/4v1ZRc/jsC vjJrfYbbdQox4/JmUOvM6+kIe3ql+2GxnmmfOlSskfpE5EhSO4aOANRBUAWpDf/ZAcRM r0Hw== X-Received: by 10.180.14.10 with SMTP id l10mr11988666wic.7.1359406062487; Mon, 28 Jan 2013 12:47:42 -0800 (PST) Received: from black.lan ([149.241.135.231]) by mx.google.com with ESMTPS id g2sm15320776wiy.0.2013.01.28.12.47.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 12:47:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Piers O'Hanlon In-Reply-To: Date: Mon, 28 Jan 2013 20:47:35 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <30D0A4A2-CD1F-4792-B9F4-F4E272275054@gmail.com> References: To: Hassnaa Moustafa X-Mailer: Apple Mail (2.1283) Cc: rmcat@ietf.org Subject: Re: [rmcat] draft-ohanlon-rmcat-dflow 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, 28 Jan 2013 20:47:44 -0000 Hi Hassnaa, Thanks for your question. On 28 Jan 2013, at 18:33, Hassnaa Moustafa wrote: > Hi, > =20 > I have a question on the draft on Congestion Control Mechanism = delay-based : the draft mentions the use of = TFRC and TCP congestion mechanisms as the current building blocks (and = mentions that while the draft will progress, other mechanisms could be = proposed) --> my question is on the reason for being currently based on = TFRC and TCP although the implentation problems that might exist with = TFRC and TCP, is there a specific use-case for that ? > =20 The thinking is that TFRC provides a reasonable solution for media = transport where delay is not an issue, such as streaming media delivery, = where it provides for a smoother rate which does not fluctuate as much = as TCP. So we took this as a baseline behaviour in loss based = environments, but when delay based operation may be used we aim to = provide for lower delay and still provide for a smoother rate. I'm not sure which implementation issues you are referring to with TFRC = and TCP? Both have been implemented in a number of systems - clearly TCP = has very broad deployment. TFRC, like most rate based approaches, does = have some potential issues with implementation of timers in small RTT = environments.=20 Regards, Piers > =20 > Regards, > Hassnaa > =20