From michawe@ifi.uio.no Thu Aug 1 06:07: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 6D4AB21F99A9 for ; Thu, 1 Aug 2013 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RkgJ4RZ4t6D for ; Thu, 1 Aug 2013 06:07:16 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id CE66521F9E9F for ; Thu, 1 Aug 2013 06:05:32 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1V4sZM-0003XU-JP for rmcat@ietf.org; Thu, 01 Aug 2013 15:05:28 +0200 Received: from dhcp-9384.meeting.ietf.org ([130.129.11.132]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1V4sZM-00030f-4r for rmcat@ietf.org; Thu, 01 Aug 2013 15:05:28 +0200 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <31915F4B-827C-4D8E-B34F-67F895C0F5A4@ifi.uio.no> Date: Thu, 1 Aug 2013 15:05:27 +0200 To: "rmcat@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 10 sum msgs/h 3 total rcpts 6373 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D2E109911AEBC65AFBBA41A62C8CD67283F0E6C0 X-UiO-SPAM-Test: remote_host: 130.129.11.132 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 10 max/h 6 blacklist 0 greylist 0 ratelimit 0 Subject: [rmcat] Issues with draft-welzl-rmcat-coupled-cc-01 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 13:07:58 -0000 Hi, Thanks to everyone who gave comments on our draft, = draft-welzl-rmcat-coupled-cc-01, in the RMCAT meeting just now. I'm glad = to see that this raised some interest! I think it would be great if we could continue the discussion on the = list. So, if you have specific concerns or questions, please shoot! e.g. the draft has been called "confusing" and "complicated"; we = actually tried hard to make this as easy to read as possible, so we'd = greatly appreciate getting more concrete hints about what parts should = be improved. At the end of the presentation, Lars raised a concern about the = complexity about what he called "another control loop interacting with = the control loops". Here I have to agree, obviously our mechanism = changes the dynamics of the controllers involved, and we're doing our = best to evaluate what this really entails; this work is only just = beginning. As you have seen, in simple scenarios with TFRC (which we = used because we didn't have code of a more suitable RMCAT mechanism = available to simulate,, plus its dynamics are relatively well known), = the overall effect seems to be pretty positive. But yes, it will have = to be evaluated with every new mechanism to really see the dynamic = behaviour arising from it. In theory, it should even be possible to = couple different congestion controllers with our scheme, and then the = dynamics are even less obvious :) Cheers, Michael From coverdale@sympatico.ca Thu Aug 1 10:10:34 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 B57A221E80BF for ; Thu, 1 Aug 2013 10:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBMuwaLgBzOt for ; Thu, 1 Aug 2013 10:10:28 -0700 (PDT) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by ietfa.amsl.com (Postfix) with ESMTP id 193BB11E810A for ; Thu, 1 Aug 2013 10:10:24 -0700 (PDT) Received: from BLU0-SMTP34 ([65.55.116.72]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Aug 2013 10:10:24 -0700 X-EIP: [+Uxj15ixHzPdqeYSYjX2cWU4TXy8dn9r] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([46.189.28.117]) by BLU0-SMTP34.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Aug 2013 10:10:21 -0700 From: Paul Coverdale To: Date: Thu, 1 Aug 2013 19:10:14 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01CE8EEA.C25AB8E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6O2fzgvHSmZMC4T8iY1d+c89d3Nw== Content-Language: en-us X-OriginalArrivalTime: 01 Aug 2013 17:10:21.0637 (UTC) FILETIME=[01502F50:01CE8EDA] Subject: [rmcat] Quality metric X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 17:10:34 -0000 ------=_NextPart_000_001B_01CE8EEA.C25AB8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit During the RMCAT WG session today the topic of a quality metric for evaluating RMCAT solutions was discussed. I believe that such a tool exists in ITU-T Rec. G.1070 "Opinion model for video-telephony applications". This is essentially the video quality equivalent of the E-model (Rec. G.107), widely used as a planning tool for assessing voice quality. G.1070 takes as input a number of parameters impacting QoE (both audio and video) including end to end delay, coding distortion, and packet loss and provides outputs of multimedia quality (MMq), speech quality accounting for the influence of video quality (Sq(Vq)), and video quality accounting for the influence of speech quality (Vq(Sq)), on a 1to 5 scale (essentially an estimate of MOS). If anyone is interested, I can provide more details. Best regards, ...Paul ------=_NextPart_000_001B_01CE8EEA.C25AB8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During the = RMCAT WG session today the topic of a quality metric for evaluating = RMCAT solutions was discussed. I believe that such a tool exists in = ITU-T Rec. G.1070 “Opinion model for video-telephony = applications”. This is essentially the video quality equivalent of = the E-model (Rec. G.107), widely used as a planning tool for assessing = voice quality.

 

G.1070 takes = as input a number of parameters impacting QoE (both audio and video) = including end to end delay, coding distortion, and packet loss and = provides outputs of multimedia quality (MMq), speech quality accounting = for the influence of video quality (Sq(Vq)), and video quality = accounting for the influence of speech quality (Vq(Sq)), on a 1to 5 = scale (essentially an estimate of MOS).

 

If anyone is = interested, I can provide more details.

 

Best = regards,

 

...Paul

 

 

------=_NextPart_000_001B_01CE8EEA.C25AB8E0-- From coverdale@sympatico.ca Thu Aug 1 10:29:08 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 E38DD11E80F9 for ; Thu, 1 Aug 2013 10:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e07rooltP2mL for ; Thu, 1 Aug 2013 10:29:02 -0700 (PDT) Received: from blu0-omc3-s31.blu0.hotmail.com (blu0-omc3-s31.blu0.hotmail.com [65.55.116.106]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9EA21F856A for ; Thu, 1 Aug 2013 10:29:01 -0700 (PDT) Received: from BLU0-SMTP66 ([65.55.116.73]) by blu0-omc3-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Aug 2013 10:28:55 -0700 X-EIP: [Z2Esubk4hooPV4zbeOk7fM0r8Dnpvqc8] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([46.189.28.117]) by BLU0-SMTP66.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Aug 2013 10:28:52 -0700 From: Paul Coverdale To: Date: Thu, 1 Aug 2013 19:28:46 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01CE8EED.588508F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6O2fzgvHSmZMC4T8iY1d+c89d3Nw== Content-Language: en-us X-OriginalArrivalTime: 01 Aug 2013 17:28:52.0483 (UTC) FILETIME=[976DD530:01CE8EDC] Subject: [rmcat] Quality metric X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 17:29:09 -0000 ------=_NextPart_000_0026_01CE8EED.588508F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit During the RMCAT WG session today the topic of a quality metric for evaluating RMCAT solutions was discussed. I believe that such a tool exists in ITU-T Rec. G.1070 "Opinion model for video-telephony applications". This is essentially the video quality equivalent of the E-model (Rec. G.107), widely used as a planning tool for assessing voice quality. G.1070 takes as input a number of parameters impacting QoE (both audio and video) including end to end delay, coding distortion, and packet loss and provides outputs of multimedia quality (MMq), speech quality accounting for the influence of video quality (Sq(Vq)), and video quality accounting for the influence of speech quality (Vq(Sq)), on a 1to 5 scale (essentially an estimate of MOS). If anyone is interested, I can provide more details. Best regards, ...Paul ------=_NextPart_000_0026_01CE8EED.588508F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During the = RMCAT WG session today the topic of a quality metric for evaluating = RMCAT solutions was discussed. I believe that such a tool exists in = ITU-T Rec. G.1070 “Opinion model for video-telephony = applications”. This is essentially the video quality equivalent of = the E-model (Rec. G.107), widely used as a planning tool for assessing = voice quality.

 

G.1070 takes = as input a number of parameters impacting QoE (both audio and video) = including end to end delay, coding distortion, and packet loss and = provides outputs of multimedia quality (MMq), speech quality accounting = for the influence of video quality (Sq(Vq)), and video quality = accounting for the influence of speech quality (Vq(Sq)), on a 1to 5 = scale (essentially an estimate of MOS).

 

If anyone is = interested, I can provide more details.

 

Best = regards,

 

...Paul

 

 

------=_NextPart_000_0026_01CE8EED.588508F0-- From randell-ietf@jesup.org Thu Aug 1 11:09:49 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 D899321E8117 for ; Thu, 1 Aug 2013 11:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNhK2Z3kgsAt for ; Thu, 1 Aug 2013 11:09:44 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 11CD821E81FB for ; Thu, 1 Aug 2013 11:09:43 -0700 (PDT) Received: from pool-108-52-103-189.phlapa.fios.verizon.net ([108.52.103.189]:3385 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1V4xJm-000DlV-VN for rmcat@ietf.org; Thu, 01 Aug 2013 13:09:43 -0500 Message-ID: <51FAA413.8060403@jesup.org> Date: Thu, 01 Aug 2013 14:08:19 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: rmcat WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: none Subject: [rmcat] NADA question that didn't get asked due to time X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 18:09:50 -0000 This jabber question didn't get to be echoed due to time (about NADA): When competing against TCP with droptail, do you kinow why the first NADA flow doesn't change when a second was added? Was there some floor that stopped it from driving into the ground? What are the dynamics of the resultant steady-state transfer characteristics between TCP and NADA flows? Have you tried two TCP flows? -- Randell Jesup randell-ietf@jesup.org From michawe@ifi.uio.no Thu Aug 1 16:07:02 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 5769021E835F for ; Thu, 1 Aug 2013 16:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GOFFYYlBjN6 for ; Thu, 1 Aug 2013 16:06:47 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id F2EFB11E8182 for ; Thu, 1 Aug 2013 15:38:26 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1V51Vp-00026Y-5N for rmcat@ietf.org; Fri, 02 Aug 2013 00:38:25 +0200 Received: from [46.189.28.122] (helo=[10.25.11.80]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1V51Vo-0004IA-GK for rmcat@ietf.org; Fri, 02 Aug 2013 00:38:25 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: <31915F4B-827C-4D8E-B34F-67F895C0F5A4@ifi.uio.no> Date: Fri, 2 Aug 2013 00:38:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31915F4B-827C-4D8E-B34F-67F895C0F5A4@ifi.uio.no> To: "rmcat@ietf.org WG" X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 6 sum rcpts/h 9 sum msgs/h 6 total rcpts 6382 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6083C31302193D90CB889ABA1AD223AC46BAEF43 X-UiO-SPAM-Test: remote_host: 46.189.28.122 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 47 max/h 8 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [rmcat] Issues with draft-welzl-rmcat-coupled-cc-01 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 23:07:02 -0000 Following up, in hallway conversations, I learned that the meaning of "greedy" and = "non-greedy" traffic was not clear to some. "Greedy" traffic is FTP-like traffic which always sends as fast as the = congestion controller allows. "non-greedy" traffic is traffic that is = limited by the application because the application does not always have = traffic to send at a rate at which the congestion controller demands it. We used these two traffic types as a simple starting point, and are = planning to use more realistic RMCAT traffic later. Cheers, Michael On Aug 1, 2013, at 3:05 PM, Michael Welzl wrote: > Hi, >=20 > Thanks to everyone who gave comments on our draft, = draft-welzl-rmcat-coupled-cc-01, in the RMCAT meeting just now. I'm glad = to see that this raised some interest! >=20 > I think it would be great if we could continue the discussion on the = list. So, if you have specific concerns or questions, please shoot! > e.g. the draft has been called "confusing" and "complicated"; we = actually tried hard to make this as easy to read as possible, so we'd = greatly appreciate getting more concrete hints about what parts should = be improved. >=20 > At the end of the presentation, Lars raised a concern about the = complexity about what he called "another control loop interacting with = the control loops". Here I have to agree, obviously our mechanism = changes the dynamics of the controllers involved, and we're doing our = best to evaluate what this really entails; this work is only just = beginning. As you have seen, in simple scenarios with TFRC (which we = used because we didn't have code of a more suitable RMCAT mechanism = available to simulate,, plus its dynamics are relatively well known), = the overall effect seems to be pretty positive. But yes, it will have = to be evaluated with every new mechanism to really see the dynamic = behaviour arising from it. In theory, it should even be possible to = couple different congestion controllers with our scheme, and then the = dynamics are even less obvious :) >=20 > Cheers, > Michael >=20 From lars@netapp.com Fri Aug 2 00:23: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 C903111E8251 for ; Fri, 2 Aug 2013 00:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[AWL=-2.403, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asqxvLf2S9x6 for ; Fri, 2 Aug 2013 00:23:15 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8D711E8279 for ; Fri, 2 Aug 2013 00:23:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,799,1367996400"; d="asc'?scan'208";a="38392715" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 02 Aug 2013 00:23:10 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 2 Aug 2013 00:23:10 -0700 From: "Eggert, Lars" To: Michael Welzl Thread-Topic: [rmcat] Issues with draft-welzl-rmcat-coupled-cc-01 Thread-Index: AQHOjsFCfD4EQwk0N0ualH9iIx17EZmBZ30AgACSjYA= Date: Fri, 2 Aug 2013 07:23:08 +0000 Message-ID: <13E210B5-9B23-4F5C-884C-4F8102580E9C@netapp.com> References: <31915F4B-827C-4D8E-B34F-67F895C0F5A4@ifi.uio.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: multipart/signed; boundary="Apple-Mail=_C545D69A-4D58-484C-A278-4A6E80CAF097"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "rmcat@ietf.org WG" Subject: Re: [rmcat] Issues with draft-welzl-rmcat-coupled-cc-01 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 07:23:20 -0000 --Apple-Mail=_C545D69A-4D58-484C-A278-4A6E80CAF097 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, ah. I wish you would have used "application-limited" and "bulk" to = describe those types, which would have been clearer to me at least. Lars On Aug 2, 2013, at 0:38, Michael Welzl wrote: > Following up, >=20 > in hallway conversations, I learned that the meaning of "greedy" and = "non-greedy" traffic was not clear to some. > "Greedy" traffic is FTP-like traffic which always sends as fast as the = congestion controller allows. "non-greedy" traffic is traffic that is = limited by the application because the application does not always have = traffic to send at a rate at which the congestion controller demands it. >=20 > We used these two traffic types as a simple starting point, and are = planning to use more realistic RMCAT traffic later. >=20 > Cheers, > Michael >=20 >=20 > On Aug 1, 2013, at 3:05 PM, Michael Welzl wrote: >=20 >> Hi, >>=20 >> Thanks to everyone who gave comments on our draft, = draft-welzl-rmcat-coupled-cc-01, in the RMCAT meeting just now. I'm glad = to see that this raised some interest! >>=20 >> I think it would be great if we could continue the discussion on the = list. So, if you have specific concerns or questions, please shoot! >> e.g. the draft has been called "confusing" and "complicated"; we = actually tried hard to make this as easy to read as possible, so we'd = greatly appreciate getting more concrete hints about what parts should = be improved. >>=20 >> At the end of the presentation, Lars raised a concern about the = complexity about what he called "another control loop interacting with = the control loops". Here I have to agree, obviously our mechanism = changes the dynamics of the controllers involved, and we're doing our = best to evaluate what this really entails; this work is only just = beginning. As you have seen, in simple scenarios with TFRC (which we = used because we didn't have code of a more suitable RMCAT mechanism = available to simulate,, plus its dynamics are relatively well known), = the overall effect seems to be pretty positive. But yes, it will have = to be evaluated with every new mechanism to really see the dynamic = behaviour arising from it. In theory, it should even be possible to = couple different congestion controllers with our scheme, and then the = dynamics are even less obvious :) >>=20 >> Cheers, >> Michael >>=20 >=20 --Apple-Mail=_C545D69A-4D58-484C-A278-4A6E80CAF097 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQCVAwUBUfteTdZcnpRveo1xAQKN3QQAj6E8YfryBwx94i2EIgIX5k+0DJf9A8ju GkARSxb/jjxTd1FunoN7g1o34RS1L4WR1lcbSyLt9B79Pp8HdT9bAv8pIMKBLyg3 Fr9nRi/m82rQ17ZTwWN39+pu1ONEoFQNBP5LJNl4+1IdU/Dmcdl7cF9ReXMfEmyX /sKO+YqyvsE= =Bdfd -----END PGP SIGNATURE----- --Apple-Mail=_C545D69A-4D58-484C-A278-4A6E80CAF097-- From vsingh.ietf@gmail.com Fri Aug 2 00:56:21 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 ECDFD11E8286 for ; Fri, 2 Aug 2013 00:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAL7UHA5E6tG for ; Fri, 2 Aug 2013 00:56:19 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7C63B11E8296 for ; Fri, 2 Aug 2013 00:56:06 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so618491obc.17 for ; Fri, 02 Aug 2013 00:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=iy/5EEd/1sGGcu3tNAp0Z8IjCxTCWpdOdheDYYSKWqs=; b=hcramnmyp1rXmGXkGKSAKtG/GZ/NUPSQtCckhyN1A4y8kYsJFOyDJUEMEN5vvZHOa7 uOx9n3sR65nHQHsTBOor0kG7lAM3MwI6tlQY5OxEtooUpT/e2B57jFvZQyLoknd8Lg0m 6azpxuVsRj+UAvTf5zcH6qtXpbe0eSTl4mNH9zgdnInsvibwf1Q0WLRJzs8Zri0C2KKn YNH2u+YK3QuB3ICy00GDBWBc0TqZWcVJWLOLYTzFosYdIIOnK93zf6zle0Jp0OkGoRo5 uHcHJfL5X1VTd3m/4Zfo5EqxNoPe//1iGPQxff7+w/ivAMSxl0pWkF2NSYIO1JceYMoJ 0uuA== X-Received: by 10.50.16.102 with SMTP id f6mr151777igd.41.1375430165602; Fri, 02 Aug 2013 00:56:05 -0700 (PDT) References: <31915F4B-827C-4D8E-B34F-67F895C0F5A4@ifi.uio.no> <13E210B5-9B23-4F5C-884C-4F8102580E9C@netapp.com> From: Varun Singh Mime-Version: 1.0 (1.0) In-Reply-To: <13E210B5-9B23-4F5C-884C-4F8102580E9C@netapp.com> Date: Fri, 2 Aug 2013 09:56:01 +0200 Message-ID: <-1155760833109600324@unknownmsgid> To: "Eggert, Lars" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rmcat@ietf.org WG" , Michael Welzl Subject: Re: [rmcat] Issues with draft-welzl-rmcat-coupled-cc-01 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 07:56:21 -0000 Yes, my assumption was that both the flows were media, greedy and non-greedy were characteristics of the media application. (Since all flows use tfrc.) Regards, Varun ---- http://www.netlab.tkk.fi/~varun > On 2.8.2013, at 9.23, "Eggert, Lars" wrote: > > Hi, > > ah. I wish you would have used "application-limited" and "bulk" to descri= be those types, which would have been clearer to me at least. > > Lars > > >> On Aug 2, 2013, at 0:38, Michael Welzl wrote: >> >> Following up, >> >> in hallway conversations, I learned that the meaning of "greedy" and "no= n-greedy" traffic was not clear to some. >> "Greedy" traffic is FTP-like traffic which always sends as fast as the c= ongestion controller allows. "non-greedy" traffic is traffic that is limite= d by the application because the application does not always have traffic t= o send at a rate at which the congestion controller demands it. >> >> We used these two traffic types as a simple starting point, and are plan= ning to use more realistic RMCAT traffic later. >> >> Cheers, >> Michael >> >> >>> On Aug 1, 2013, at 3:05 PM, Michael Welzl wrote: >>> >>> Hi, >>> >>> Thanks to everyone who gave comments on our draft, draft-welzl-rmcat-co= upled-cc-01, in the RMCAT meeting just now. I'm glad to see that this raise= d some interest! >>> >>> I think it would be great if we could continue the discussion on the li= st. So, if you have specific concerns or questions, please shoot! >>> e.g. the draft has been called "confusing" and "complicated"; we actual= ly tried hard to make this as easy to read as possible, so we'd greatly app= reciate getting more concrete hints about what parts should be improved. >>> >>> At the end of the presentation, Lars raised a concern about the complex= ity about what he called "another control loop interacting with the control= loops". Here I have to agree, obviously our mechanism changes the dynamics= of the controllers involved, and we're doing our best to evaluate what thi= s really entails; this work is only just beginning. As you have seen, in si= mple scenarios with TFRC (which we used because we didn't have code of a mo= re suitable RMCAT mechanism available to simulate,, plus its dynamics are r= elatively well known), the overall effect seems to be pretty positive. But= yes, it will have to be evaluated with every new mechanism to really see t= he dynamic behaviour arising from it. In theory, it should even be possible= to couple different congestion controllers with our scheme, and then the d= ynamics are even less obvious :) >>> >>> Cheers, >>> Michael > From michawe@ifi.uio.no Fri Aug 2 01:19:22 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 0AB9C21E8271 for ; Fri, 2 Aug 2013 01:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOF2ffnGf0iL for ; Fri, 2 Aug 2013 01:19:16 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 01B9A11E81B0 for ; Fri, 2 Aug 2013 01:19:16 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1V5AZt-0005Fk-ON; Fri, 02 Aug 2013 10:19:13 +0200 Received: from dhcp-9384.meeting.ietf.org ([130.129.11.132]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1V5AZt-0007FC-2K; Fri, 02 Aug 2013 10:19:13 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: <-1155760833109600324@unknownmsgid> Date: Fri, 2 Aug 2013 10:19:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6D12FE6B-5CD3-4F6F-8AA5-00EDEBAC366D@ifi.uio.no> References: <31915F4B-827C-4D8E-B34F-67F895C0F5A4@ifi.uio.no> <13E210B5-9B23-4F5C-884C-4F8102580E9C@netapp.com> <-1155760833109600324@unknownmsgid> To: Varun Singh X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 6386 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3340B9B524DD98CFC25CD0A38F6A118217219114 X-UiO-SPAM-Test: remote_host: 130.129.11.132 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 12 max/h 6 blacklist 0 greylist 0 ratelimit 0 Cc: "rmcat@ietf.org WG" , "Eggert, Lars" Subject: Re: [rmcat] Issues with draft-welzl-rmcat-coupled-cc-01 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:19:22 -0000 Apologies. The intention was to start with something simple, then go to = more realistic media traffic profiles. We were also told that the variable names aren't good - e.g. CR means = "calculated rate", which is supposed to be an input: the rate that a = congestion controller has calculated. It could, however, be = misunderstood to mean the rate that the FSE has calculated. We're going = to improve that. Any more comments are very welcome, please keep them = coming! BTW, regarding the dynamics of the scheme, I don't think it's correct to = call it a "control loop", as our "Flow State Exchange" (FSE) only = operates on the time scale of the congestion controllers that use it. As = with RFC2140, this is really only about a few shared variables. We think = it makes sense to consider the code that you have seen as a part of the = FSE, but it could really be included *in* the congestion control = mechanisms just as well. Then it's just the code that a congestion = control mechanism uses to read and update the variables. Cheers, Michael On Aug 2, 2013, at 9:56 AM, Varun Singh wrote: > Yes, my assumption was that both the flows were media, greedy and > non-greedy were characteristics of the media application. (Since all > flows use tfrc.) >=20 > Regards, > Varun >=20 > ---- > http://www.netlab.tkk.fi/~varun >=20 >> On 2.8.2013, at 9.23, "Eggert, Lars" wrote: >>=20 >> Hi, >>=20 >> ah. I wish you would have used "application-limited" and "bulk" to = describe those types, which would have been clearer to me at least. >>=20 >> Lars >>=20 >>=20 >>> On Aug 2, 2013, at 0:38, Michael Welzl wrote: >>>=20 >>> Following up, >>>=20 >>> in hallway conversations, I learned that the meaning of "greedy" and = "non-greedy" traffic was not clear to some. >>> "Greedy" traffic is FTP-like traffic which always sends as fast as = the congestion controller allows. "non-greedy" traffic is traffic that = is limited by the application because the application does not always = have traffic to send at a rate at which the congestion controller = demands it. >>>=20 >>> We used these two traffic types as a simple starting point, and are = planning to use more realistic RMCAT traffic later. >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>>> On Aug 1, 2013, at 3:05 PM, Michael Welzl = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> Thanks to everyone who gave comments on our draft, = draft-welzl-rmcat-coupled-cc-01, in the RMCAT meeting just now. I'm glad = to see that this raised some interest! >>>>=20 >>>> I think it would be great if we could continue the discussion on = the list. So, if you have specific concerns or questions, please shoot! >>>> e.g. the draft has been called "confusing" and "complicated"; we = actually tried hard to make this as easy to read as possible, so we'd = greatly appreciate getting more concrete hints about what parts should = be improved. >>>>=20 >>>> At the end of the presentation, Lars raised a concern about the = complexity about what he called "another control loop interacting with = the control loops". Here I have to agree, obviously our mechanism = changes the dynamics of the controllers involved, and we're doing our = best to evaluate what this really entails; this work is only just = beginning. As you have seen, in simple scenarios with TFRC (which we = used because we didn't have code of a more suitable RMCAT mechanism = available to simulate,, plus its dynamics are relatively well known), = the overall effect seems to be pretty positive. But yes, it will have = to be evaluated with every new mechanism to really see the dynamic = behaviour arising from it. In theory, it should even be possible to = couple different congestion controllers with our scheme, and then the = dynamics are even less obvious :) >>>>=20 >>>> Cheers, >>>> Michael >>=20 From ldecicco@gmail.com Sun Aug 4 01:55:58 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 90DCF21F8443 for ; Sun, 4 Aug 2013 01:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx+OH8+5NWe2 for ; Sun, 4 Aug 2013 01:55:57 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 56A7221F9AED for ; Sun, 4 Aug 2013 01:55:57 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m46so1635172wev.36 for ; Sun, 04 Aug 2013 01:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZKRC1WR9E03QAEkk27a6GBULREZ58zdYJw+fk8ixR4M=; b=bgR1baimkrSx5caiQ1Xx5J1e+siT5/gISZ4anJ/WWUiOBjNzSRooCcCNEBuq411BaZ ZbtqV+DDgVP2ZihlpmLhr8e3j8dZzqE5+0gun6Fo1JeHiMIgqXVAsdeYnAt4tp5aR8Cz bOB25j8ChHIn386tbRN35E8b6NRy/Ljxj6TOViMPGT8IWPwpv+apexK9kcUIEUR7hnor 1sl7a4e06EuLqluN+OZQOtgtW4Ox3RLT/8eKfiZpcEC9VFnKygOyYE17hAWVcq6pFdVp ZmehAzRV/ou2lggmoetqlWVNF7gNLqmaxBN2kZcQLtWLMBOmvlysTOvwBSoltPU/207d P80g== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr10013211wjn.23.1375606556376; Sun, 04 Aug 2013 01:55:56 -0700 (PDT) Received: by 10.216.64.198 with HTTP; Sun, 4 Aug 2013 01:55:56 -0700 (PDT) In-Reply-To: <51FAA413.8060403@jesup.org> References: <51FAA413.8060403@jesup.org> Date: Sun, 4 Aug 2013 10:55:56 +0200 Message-ID: From: Luca De Cicco To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat WG Subject: Re: [rmcat] NADA question that didn't get asked due to time X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 08:55:58 -0000 Dear all, I got a question about the slides: what's the bottleneck buffer size used in the simulations? Have you checked the performance of a NADA flow with a single TCP flow using a drop tail queue with different buffer sizes? Best, -- Luca De Cicco, PhD, Eng. Politecnico di Bari Dipartimento di Elettrotecnica ed Elettronica Via Re David, 200 - Bari - ITALY Office: +39 080 596 3851 http://c3lab.poliba.it/index.php/LDC On Thu, Aug 1, 2013 at 8:08 PM, Randell Jesup wrote: > This jabber question didn't get to be echoed due to time (about NADA): > > > When competing against TCP with droptail, do you kinow why the first NADA > flow doesn't change when a second was added? > > Was there some floor that stopped it from driving into the ground? What are > the dynamics of the resultant steady-state transfer characteristics between > TCP and NADA flows? Have you tried two TCP flows? > > -- > Randell Jesup > randell-ietf@jesup.org > From lars@netapp.com Mon Aug 5 01:50:46 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 6685D21F9D93 for ; Mon, 5 Aug 2013 01:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.111 X-Spam-Level: X-Spam-Status: No, score=-8.111 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPvsjdgvv-t9 for ; Mon, 5 Aug 2013 01:50:32 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCAE21F9D1F for ; Mon, 5 Aug 2013 01:50:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,817,1367996400"; d="asc'?scan'208";a="78534934" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 05 Aug 2013 01:50:27 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Mon, 5 Aug 2013 01:50:27 -0700 From: "Eggert, Lars" To: "rmcat@ietf.org WG" Thread-Topic: please check draft minutes Thread-Index: AQHOkbjUOy3OQyxS8UK5GF6e9LrrVA== Date: Mon, 5 Aug 2013 08:50:26 +0000 Message-ID: <15D29CBE-F20F-46F4-9E77-55F4A03B003A@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_F546D7ED-E378-4237-BEF6-EF5B0904029C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [rmcat] please check draft minutes 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, 05 Aug 2013 08:50:46 -0000 --Apple-Mail=_F546D7ED-E378-4237-BEF6-EF5B0904029C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, attached are our draft minutes from Berlin (THANK YOU BRIAN). Please = check them carefully and send corrections to Mirja and me. Lars Chair Slides discussion: = ------------------------------------------------------------------------- RTCWEB + RMCAT: Ted Hardie: one thing I would add to slide 8 in chairs presentation: work in MMUSIC = that RTCWEB asked for: what do do with large number of flows for NAT = state. MMUSIC has adopted a solution: Unified Plan draft adopted earlier = this week. Higher expectation that we can go forward with RTCWEB with = large numbers of flows. May be conditions where a single flow has = packets with different DSCP code points due to multiplexing. Lars: For RMCAT, we operate with six tuples? Mirja: It doesn't matter: map algorithm to protocols. David Black: multiple DSCP per 5-tuple, have worked with Fluffy; the = case is AF classes. This is done today. Plan: not to bundle beyond this. = RMCAT should be able to deal with 5-tuples. Multiple DSCPs are only dro Zahed: for RMCAT for should ... (overrun) Fluffy: not the right place to discuss Gorry: +1, has been discussed in TSV Did RTCWEB desi.. no Colin Perkins: ...circuit breakers will be discussed tomorrow Mirja: we should be independent of decisions taken there Lars: if you're not on both Michael: what is a circuit breaker? Fluffy: I'll explain it to you Colin: Will we have separate CC for the data channel? Lars: I don't think we have consensus Mirja: If so we'll only look at the interactive. Status of the Evaluation Criteria Design Team Michael Ramalho 10 min (discussion after next presentation) = ------------------------------------------------------------------------- On test topology: ----------------------- Lars: I'd assume that we have two-way media in rmcat Michael: We're testing one direction now, will consider two-way. Colin: The assumption is that there's loss due to bottleneck? Michael: No, there can be additional loss at the impairment sources Lars (as jesup@jabber.org): we want to live with other delay flows = except maybe if we're not in a Codel/etc environment (just for = clarification) Jana: is this the topology? the point is it has only one bottleneck. Zahed: where we have other signals (e.g. ECN) we can use them. we don't = necessarily only want to use delay. On initial experiments: ----------------------- Colin: infinite data seems strange given real time flows.=20 Michael: we realize this... we want to run in a rate envelope that rmcat = will specify, if we introduce too many things, we have too much = uncertainty. Colin: can't encode video for the future, limited by codec, that's not = infinite. Michael: We can load this up with e.g. holography Mo: Infinite amount is not the right word, it's VBR versus CBR. We're = still considering target rates, we're not going to vary the rate. Lars: We're trying to start with a simplistic scenario. The most = interesting feedback: Is there anything fundamentally wrong? We're not = trying to model everything yet, that has shown to be intractable. Toerless: Does it make you and Colin happy to say "there is a flow that = would consistently like to see more data sent than congestion permits" Colin: If that's the definition, this is fundamentally broken. Not = appropriate for set of flows we have. Lars: Let us note there is a point for discussion. Michael: Please join the design team meetings. Lars: When you say output data charateristic: is this what comes into = RMCAT, or what RMCAT puts on to the wire. 1/100ms is a requirement of = the solution, not a scenario parameter. Mirja: You assume that CC is aware of this value, or is this an = evaluation criterion? Michael: Evaluaiton criterion.=20 Zahed: These are the scenarios, we started with fairness as an issue, we = wanted to be simplistic. Fairness requirement led to choose some of = these figures. On open issues: --------------- Zahed: We haven't discussed this (DSCP) in the design team meeting. Lars: The WG has not made a DSCP request David Black: Submitted draft to TSVWG, will be discussed there R=FCdiger Gelb: please state requirements instead of solutions Lars: we may have to take more time in Vancouver to discuss this Evaluating Congestion Control for Interactive Real-time Media Varun Singh draft-singh-rmcat-cc-eval (milestone eval-criteria)=20 30 min + 10 min discussion = ------------------------------------------------------------------------- On Unfairness: -------------- Zahed: unfairness should be defined on a per scenario basis. Varun: should we have generic metrics at all? Zahed: You can devise all the metrics, then look at a per-scenario = basis. Colin: This is a plausible unfairness metric. It might be useful to = define a numeric metric which would=20 Lars: This is really a test, not a metric. Colin: Metric would be useful. Micheal Welzl: I like this, but it should contain a notion of time, in = terms of RTT. On Open Issues: Quality ----------------------- Varun: Is quality off the table? Mo: I thought we had consensus it's off the table. Lars: We're struggling enough with packet characteristic metrics, but = media quality would be nice. An appendix or conclusions section noting = this as open... Colin: One of the outputs has to be that rmcat is useful for interactive = video. Zahed: I agree with the chair, it's hard to define, but we should keep = options open. A solution that doesn't give good video quality... It = should be in the document. Lars: say that metrics in document are packet flow characteristics, = algorithms brought to WG must evaluate quality but leave exactly how up = to them. Xiaoquing Zhu: Video quality dependent on video content as well as = network params... You need to keep the comparis Ken Carlberg: Carriers still use MOS scores. Did this ever come up? Varun: It came up for audio,=20 Bob: What about MOS for video? Mirja: We also don't have test scenarios. We probably don't want to do = that. Varun: MOS for video: send to list. Sequences available. But we didn't = do that. Lars: We want to see an indication of video quality from candidates, = maybe a metric will fall out of that. Xiaoquing: Why are we considering only drop-tail queues? AQM WG is = forming. Varun: Eval probably shouldn't look into other ones until they're mature = enough. Lars: Charter says effective use of ECN in scope, that requires AQM Lars (as Randal): TCP cross-traffic will need to include long term = flows, and also short-term/bursty queues. The requirements document = says we need to work well with AQM queues - algorithms for delay-based = could easily fail badly in an AQM situation Lars: Not sure if evaluating multiple delay-based flows makes sense. Randal (via jabber room): disagree with lars: we do need to consider = delay-based flows other than the selected one, since people use = algorithms on the net which aren't appoved/specced by the IETF = (frightening, I know ;-) Lars: We shouldn't prioritize it... I don't want to rathole on this. Ken Carlberg: What about roaming? Varun: Comes down to how we want to model it.=20 Lars: Metrics will be common across different scenarios, may make sense = in a different draft. Topologies could also=20 Mirja: I would like to move this somehow forward. Comments on the mic = add more and more. If splitting this up makes sense to speed it up, then = let's consider that.=20 Lars: Pleased with progress since Orlando, but we are so not done yet. = Is there anything else we can do to have work occur in the next twelve = weeks. Mirja: Who has read the document? Six. No basis to adopt at this time as = a WG doc. Xiaoquing: More consensus on evaluation scenario side, less around how = to evaluate. Makes sense split into scenario and criteria.=20 Lars: these will be tightly linked. Let's discuss. Coupled congestion control for RTP media Safiqul Islam draft-welzl-rmcat-coupled-cc (milestone group-cc)=20 20 min + 10 min discussion = ------------------------------------------------------------------------- Lars: This seems to be at least an order of magnitude more complex than = RFC2140. Why? Michael Welzl: This uses unused bandwidth, fairness across RTTs, etc; = main goal not to change main CC, update rate based on feedback. =20 Mirja: No interface to application, only between congestion controllers? Michael Welzl: Yes. Zahed: We should discuss the fundamentals, if these are not right... Lars: Input to fairness decision is number of bytes over fixed time, = with respect to throughput. Michael Welzl: yes Mirja: Assume that for one flow you give the rate, and there will be no = CC.=20 Safiqul: When a flow has a new calculated rate, it sends it to FSE, and = FSE adjusts the rate. Lars: There's a control loop linking the control loop of each flow. Michael: In that sense it's like 2140, but it's asynchronous. Mirja: I'm not sure if we should keep these control elements so = separately, I'd like to understand what different possibilities we have. Mo: Distributed congestion control without flow state exchange. Zahed: We could do the aggregation anywhere. Michael: THe point is to not do weighted CC, it will compete and = fluctuate. Mirja: Hard to understand how this affects the control of the CC it's = connected to. Safiqul: we'll evaluate that next. Lars: need realistic traffic and realistic cc. Mirja: Do you want to give input to evaluation criteria? Michael Welzl: hope to discuss in the hallway. Mo: What is the actual state that is currently exchanged. What happens = when you rely on more things? What happens when you replace TFRC? Lars: Chair's prerogative: cut the discussion. Hesitant here: We're = struggling with building a single control loop CC, and this proposal = links two loops, and adds complication at a time that that's not what we = need. I hope we can come back to this. I don't think we have the cycles = in the next few months. We hope group CC will help. When we have no idea = about the mechanism, it's hard to evaluate. We can talk further offline. NADA: Implementation Status and Interaction with AQM Schemes Xiaoqing Zhu draft-zhu-rmcat-nada=20 15 min + 10 min = ------------------------------------------------------------------------- Lars: Would be interesting to see delay measurements for competing NADA = streams Xiaoqing: We can evaluate that. Jim Gettys: fq-codel is radically more interesting than codel. = simulators in ns3 only. codel implementation in linux is for testing, we = don't expect it's deployable. Poorly documented codel pitfalls, make = sure you read the webpage over it, talk to Dave Taht and myself Rong Pan: Should we forget about ns2 evaluation of Codel?=20 Jim Gettys: Fine to see how they'll interact, but default won't be codel = by itself. Randal: when competing against TCP with droptail, do you kinow why the = first NADA flow doesn't change when a second was added? Was there some = floor that stopped it from driving into the ground? (asked after end of = meeting) --Apple-Mail=_F546D7ED-E378-4237-BEF6-EF5B0904029C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQCVAwUBUf9nT9ZcnpRveo1xAQJ6BAP7BikOoTkw+EhvUPV3tY82GG9BRtjYWC2q qFxVzsNGTGZ5G5IgglN/xiLFLlR2cHQA/LIs9YI4bjNCaKVCZOY1OQIBO1K5PVM9 tU/KKHXECHOqGtgUOgREBBOq0Ye7zaGfTmJYmxJv5KI3Tgdy+uBadoIuxroRrqIE A6us+mp4q/o= =MseZ -----END PGP SIGNATURE----- --Apple-Mail=_F546D7ED-E378-4237-BEF6-EF5B0904029C-- From ldecicco@gmail.com Mon Aug 5 04:13:59 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 7743E21F9DF6 for ; Mon, 5 Aug 2013 04:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9vb96Mod64n for ; Mon, 5 Aug 2013 04:13:55 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE0221F9B4B for ; Mon, 5 Aug 2013 04:13:54 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hq12so1375137wib.10 for ; Mon, 05 Aug 2013 04:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MyuSKsOkusM7LgAMEhPcNo7zwcGv7ViwNEpnN5lCNIg=; b=cAKj5BVuxPuM22eTnv0e342Df/PoSN33OCASOw638I1Q0dcB9j/MI77plEC7QmEONk 2eYFm80TjZCv4MyAccVQVAQD2/EZ59ZJqu/KgyflZtCIyuLUdnoK1W4QTlPLseQtZMVt uejB1M61XvJF1/lxMRqSVeXl6W9bLSdKizZmSUdw7vRyxcNzX7ogS4kBDeTctPZcgC8z acJLxQjUNt2xB0aSLW1VoeWCm8A6ubdUV0KUstW5vyrHI+iz49EY21wBRdU/h226lf1A dD/TtbHmlWQakZ/BRp5BkmVwz5Kjzc6QrPc+250IORi7e8rsA+QfXDHjqwCOG/BIeXUk JEzw== MIME-Version: 1.0 X-Received: by 10.180.185.166 with SMTP id fd6mr6453907wic.5.1375701233289; Mon, 05 Aug 2013 04:13:53 -0700 (PDT) Received: by 10.216.64.198 with HTTP; Mon, 5 Aug 2013 04:13:53 -0700 (PDT) In-Reply-To: <15D29CBE-F20F-46F4-9E77-55F4A03B003A@netapp.com> References: <15D29CBE-F20F-46F4-9E77-55F4A03B003A@netapp.com> Date: Mon, 5 Aug 2013 13:13:53 +0200 Message-ID: From: Luca De Cicco To: "Eggert, Lars" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rmcat@ietf.org WG" Subject: Re: [rmcat] please check draft minutes 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, 05 Aug 2013 11:13:59 -0000 Dear all, the m3u link http://ietf87streaming.dnsalias.net/ietf/ietf873.m3u I've found on http://tools.ietf.org/wg/rmcat/agenda seems to be a dead link. Is the audio of the RMCAT session available somewhere else? Thanks, Luca On Mon, Aug 5, 2013 at 10:50 AM, Eggert, Lars wrote: > Hi, > > attached are our draft minutes from Berlin (THANK YOU BRIAN). Please chec= k them carefully and send corrections to Mirja and me. > > Lars > > > Chair Slides discussion: > ------------------------------------------------------------------------- > RTCWEB + RMCAT: > Ted Hardie: > one thing I would add to slide 8 in chairs presentation: work in MMUSIC t= hat RTCWEB asked for: what do do with large number of flows for NAT state. = MMUSIC has adopted a solution: Unified Plan draft adopted earlier this week= . Higher expectation that we can go forward with RTCWEB with large numbers = of flows. May be conditions where a single flow has packets with different = DSCP code points due to multiplexing. > > Lars: For RMCAT, we operate with six tuples? > Mirja: It doesn't matter: map algorithm to protocols. > > David Black: multiple DSCP per 5-tuple, have worked with Fluffy; the case= is AF classes. This is done today. Plan: not to bundle beyond this. RMCAT = should be able to deal with 5-tuples. Multiple DSCPs are only dro > > Zahed: for RMCAT for should ... (overrun) > Fluffy: not the right place to discuss > Gorry: +1, has been discussed in TSV > > Did RTCWEB desi.. no > > Colin Perkins: ...circuit breakers will be discussed tomorrow > Mirja: we should be independent of decisions taken there > Lars: if you're not on both > > Michael: what is a circuit breaker? > Fluffy: I'll explain it to you > > Colin: Will we have separate CC for the data channel? > Lars: I don't think we have consensus > Mirja: If so we'll only look at the interactive. > > > Status of the Evaluation Criteria Design Team > Michael Ramalho > 10 min (discussion after next presentation) > ------------------------------------------------------------------------- > On test topology: > ----------------------- > > Lars: I'd assume that we have two-way media in rmcat > > Michael: We're testing one direction now, will consider two-way. > > Colin: The assumption is that there's loss due to bottleneck? > > Michael: No, there can be additional loss at the impairment sources > > Lars (as jesup@jabber.org): we want to live with other delay flows except= maybe if we're not in a Codel/etc environment (just for clarification) > > Jana: is this the topology? the point is it has only one bottleneck. > > Zahed: where we have other signals (e.g. ECN) we can use them. we don't n= ecessarily only want to use delay. > > On initial experiments: > ----------------------- > > Colin: infinite data seems strange given real time flows. > > Michael: we realize this... we want to run in a rate envelope that rmcat = will specify, if we introduce too many things, we have too much uncertainty= . > > Colin: can't encode video for the future, limited by codec, that's not in= finite. > > Michael: We can load this up with e.g. holography > > Mo: Infinite amount is not the right word, it's VBR versus CBR. We're sti= ll considering target rates, we're not going to vary the rate. > > Lars: We're trying to start with a simplistic scenario. The most interest= ing feedback: Is there anything fundamentally wrong? We're not trying to mo= del everything yet, that has shown to be intractable. > > Toerless: Does it make you and Colin happy to say "there is a flow that w= ould consistently like to see more data sent than congestion permits" > > Colin: If that's the definition, this is fundamentally broken. Not approp= riate for set of flows we have. > > Lars: Let us note there is a point for discussion. > > Michael: Please join the design team meetings. > > Lars: When you say output data charateristic: is this what comes into RMC= AT, or what RMCAT puts on to the wire. 1/100ms is a requirement of the solu= tion, not a scenario parameter. > > Mirja: You assume that CC is aware of this value, or is this an evaluatio= n criterion? > > Michael: Evaluaiton criterion. > > Zahed: These are the scenarios, we started with fairness as an issue, we = wanted to be simplistic. Fairness requirement led to choose some of these f= igures. > > On open issues: > --------------- > > Zahed: We haven't discussed this (DSCP) in the design team meeting. > > Lars: The WG has not made a DSCP request > > David Black: Submitted draft to TSVWG, will be discussed there > > R=FCdiger Gelb: please state requirements instead of solutions > > Lars: we may have to take more time in Vancouver to discuss this > > > Evaluating Congestion Control for Interactive Real-time Media > Varun Singh > draft-singh-rmcat-cc-eval (milestone eval-criteria) > 30 min + 10 min discussion > ------------------------------------------------------------------------- > > On Unfairness: > -------------- > > Zahed: unfairness should be defined on a per scenario basis. > > Varun: should we have generic metrics at all? > > Zahed: You can devise all the metrics, then look at a per-scenario basis. > > Colin: This is a plausible unfairness metric. It might be useful to defin= e a numeric metric which would > > Lars: This is really a test, not a metric. > > Colin: Metric would be useful. > > Micheal Welzl: I like this, but it should contain a notion of time, in te= rms of RTT. > > On Open Issues: Quality > ----------------------- > > Varun: Is quality off the table? > > Mo: I thought we had consensus it's off the table. > > Lars: We're struggling enough with packet characteristic metrics, but med= ia quality would be nice. An appendix or conclusions section noting this as= open... > > Colin: One of the outputs has to be that rmcat is useful for interactive = video. > > Zahed: I agree with the chair, it's hard to define, but we should keep op= tions open. A solution that doesn't give good video quality... It should be= in the document. > > Lars: say that metrics in document are packet flow characteristics, algor= ithms brought to WG must evaluate quality but leave exactly how up to them. > > Xiaoquing Zhu: Video quality dependent on video content as well as networ= k params... You need to keep the comparis > > Ken Carlberg: Carriers still use MOS scores. Did this ever come up? > > Varun: It came up for audio, > > Bob: What about MOS for video? > > Mirja: We also don't have test scenarios. We probably don't want to do th= at. > > Varun: MOS for video: send to list. Sequences available. But we didn't do= that. > > Lars: We want to see an indication of video quality from candidates, mayb= e a metric will fall out of that. > > Xiaoquing: Why are we considering only drop-tail queues? AQM WG is formin= g. > > Varun: Eval probably shouldn't look into other ones until they're mature = enough. > > Lars: Charter says effective use of ECN in scope, that requires AQM > > Lars (as Randal): TCP cross-traffic will need to include long term flows,= and also short-term/bursty queues. The requirements document says we need= to work well with AQM queues - algorithms for delay-based could easily fai= l badly in an AQM situation > > Lars: Not sure if evaluating multiple delay-based flows makes sense. > > Randal (via jabber room): disagree with lars: we do need to consider dela= y-based flows other than the selected one, since people use algorithms on t= he net which aren't appoved/specced by the IETF (frightening, I know ;-) > > Lars: We shouldn't prioritize it... I don't want to rathole on this. > > Ken Carlberg: What about roaming? > > Varun: Comes down to how we want to model it. > > Lars: Metrics will be common across different scenarios, may make sense i= n a different draft. Topologies could also > > Mirja: I would like to move this somehow forward. Comments on the mic add= more and more. If splitting this up makes sense to speed it up, then let's= consider that. > > Lars: Pleased with progress since Orlando, but we are so not done yet. Is= there anything else we can do to have work occur in the next twelve weeks. > > Mirja: Who has read the document? Six. No basis to adopt at this time as = a WG doc. > > Xiaoquing: More consensus on evaluation scenario side, less around how to= evaluate. Makes sense split into scenario and criteria. > > Lars: these will be tightly linked. Let's discuss. > > Coupled congestion control for RTP media > Safiqul Islam > draft-welzl-rmcat-coupled-cc (milestone group-cc) > 20 min + 10 min discussion > ------------------------------------------------------------------------- > > Lars: This seems to be at least an order of magnitude more complex than R= FC2140. Why? > > Michael Welzl: This uses unused bandwidth, fairness across RTTs, etc; mai= n goal not to change main CC, update rate based on feedback. > > Mirja: No interface to application, only between congestion controllers? > > Michael Welzl: Yes. > > Zahed: We should discuss the fundamentals, if these are not right... > > Lars: Input to fairness decision is number of bytes over fixed time, with= respect to throughput. > > Michael Welzl: yes > > Mirja: Assume that for one flow you give the rate, and there will be no C= C. > > Safiqul: When a flow has a new calculated rate, it sends it to FSE, and F= SE adjusts the rate. > > Lars: There's a control loop linking the control loop of each flow. > > Michael: In that sense it's like 2140, but it's asynchronous. > > Mirja: I'm not sure if we should keep these control elements so separatel= y, I'd like to understand what different possibilities we have. > > Mo: Distributed congestion control without flow state exchange. > > Zahed: We could do the aggregation anywhere. > > Michael: THe point is to not do weighted CC, it will compete and fluctuat= e. > > Mirja: Hard to understand how this affects the control of the CC it's con= nected to. > > Safiqul: we'll evaluate that next. > > Lars: need realistic traffic and realistic cc. > > Mirja: Do you want to give input to evaluation criteria? > > Michael Welzl: hope to discuss in the hallway. > > Mo: What is the actual state that is currently exchanged. What happens wh= en you rely on more things? What happens when you replace TFRC? > > Lars: Chair's prerogative: cut the discussion. Hesitant here: We're strug= gling with building a single control loop CC, and this proposal links two l= oops, and adds complication at a time that that's not what we need. I hope = we can come back to this. I don't think we have the cycles in the next few = months. We hope group CC will help. When we have no idea about the mechanis= m, it's hard to evaluate. We can talk further offline. > > NADA: Implementation Status and Interaction with AQM Schemes > Xiaoqing Zhu > draft-zhu-rmcat-nada > 15 min + 10 min > ------------------------------------------------------------------------- > > Lars: Would be interesting to see delay measurements for competing NADA s= treams > > Xiaoqing: We can evaluate that. > > Jim Gettys: fq-codel is radically more interesting than codel. simulators= in ns3 only. codel implementation in linux is for testing, we don't expect= it's deployable. Poorly documented codel pitfalls, make sure you read the = webpage over it, talk to Dave Taht and myself > > Rong Pan: Should we forget about ns2 evaluation of Codel? > > Jim Gettys: Fine to see how they'll interact, but default won't be codel = by itself. > > Randal: when competing against TCP with droptail, do you kinow why the fi= rst NADA flow doesn't change when a second was added? Was there some floor= that stopped it from driving into the ground? (asked after end of meeting) From lars@netapp.com Mon Aug 5 04:29:33 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 1615F21F9D22 for ; Mon, 5 Aug 2013 04:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.87 X-Spam-Level: X-Spam-Status: No, score=-8.87 tagged_above=-999 required=5 tests=[AWL=1.729, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4seJ0T5uaMi for ; Mon, 5 Aug 2013 04:29:28 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id B69F821F9DF7 for ; Mon, 5 Aug 2013 04:29:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,817,1367996400"; d="asc'?scan'208";a="78562067" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 05 Aug 2013 04:29:26 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Mon, 5 Aug 2013 04:29:26 -0700 From: "Eggert, Lars" To: Luca De Cicco Thread-Topic: audio (was Re: [rmcat] please check draft minutes) Thread-Index: AQHOkc8KVm2UyhZLm06QRRmkctwROg== Date: Mon, 5 Aug 2013 11:29:25 +0000 Message-ID: <60A5E124-E954-4ECE-9726-878EB0FF6A8F@netapp.com> References: <15D29CBE-F20F-46F4-9E77-55F4A03B003A@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_42179E42-CFBB-47F8-A95D-47D953993460"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "rmcat@ietf.org WG" Subject: [rmcat] audio (was Re: please check draft minutes) 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, 05 Aug 2013 11:29:33 -0000 --Apple-Mail=_42179E42-CFBB-47F8-A95D-47D953993460 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On Aug 5, 2013, at 13:13, Luca De Cicco wrote: > the m3u link http://ietf87streaming.dnsalias.net/ietf/ietf873.m3u I've > found on http://tools.ietf.org/wg/rmcat/agenda > seems to be a dead link. it's not a dead link, it's a link to the live stream. Which is by = definition only active during the session. > Is the audio of the RMCAT session available > somewhere else? The recordings are (or will be) at https://www.ietf.org/audio/ietf87/ Lars --Apple-Mail=_42179E42-CFBB-47F8-A95D-47D953993460 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQCVAwUBUf+MjdZcnpRveo1xAQL30wP+LlAUgV2dKqL6LUmYAw+bkH6zspXzF70/ yL9gjtjSCTncADrArmjRq10mCa7Z+AO6HsUrqebNrplJQJVTys6fNecFE8OwH1Vp SU3DRDuJLIdYG4rXD7JwZ+ODKG6Lu02SYE4eqQoZPKincTJhSYBUZEYnmWo7xc4L iEP/sC6R1xU= =DNVl -----END PGP SIGNATURE----- --Apple-Mail=_42179E42-CFBB-47F8-A95D-47D953993460-- From xiaoqzhu@cisco.com Mon Aug 5 12:20:53 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 D18C421F9967 for ; Mon, 5 Aug 2013 12:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.82 X-Spam-Level: X-Spam-Status: No, score=-7.82 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKGIxZDu20tB for ; Mon, 5 Aug 2013 12:20:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8D08F21F9D65 for ; Mon, 5 Aug 2013 12:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27515; q=dns/txt; s=iport; t=1375730445; x=1376940045; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DcUVVLEapg7ECcEGFn4MOhX2wskpufmSdplE41nisAw=; b=TYKyWMtCg1esFZSa/XYmEdlJPTwbD3Unq67Q8id8UJIifzc/+q1M2dCu k4aAqOY6wG2OpW89X6k6YYdfAxkYPS3UP3bKWqcGAGkrM45YQhX9/+AYK jtRpnANG1V++odUnQz/mTINTw3h0mK66ef9umJvMI+Ee9Xlc+jeZntMbH 0=; X-Files: qdelay.png, delay.png : 7076, 8146 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFADr6/1GtJXG//2dsb2JhbABbgkIKGSGBBb51gSEWdIIkAQEBAwEFdAULAgEIBBkBAQECJAIFEA8MJQIECgQEAQgGh3wGAbU5j2gxB4MZdAONeoNGAZdugxeCKg X-IronPort-AV: E=Sophos;i="4.89,820,1367971200"; d="png'150?scan'150,208,217,150";a="243802753" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 05 Aug 2013 19:20:45 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r75JKiAj022308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 19:20:44 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 14:20:44 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: Randell Jesup Thread-Topic: [rmcat] NADA question that didn't get asked due to time Thread-Index: AQHOjxSNiwjkFKp57kOCzyNIknoAl5mHV3aA Date: Mon, 5 Aug 2013 19:20:24 +0000 Message-ID: References: <51FAA413.8060403@jesup.org> In-Reply-To: <51FAA413.8060403@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.152.12.56] Content-Type: multipart/related; boundary="_005_E7175A8E3DC14048A7D3020E0338C1FA124A5FE4xmbalnx13ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Cc: rmcat WG , "Rong Pan \(ropan\)" Subject: Re: [rmcat] NADA question that didn't get asked due to time 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, 05 Aug 2013 19:20:53 -0000 --_005_E7175A8E3DC14048A7D3020E0338C1FA124A5FE4xmbalnx13ciscoc_ Content-Type: multipart/alternative; boundary="_000_E7175A8E3DC14048A7D3020E0338C1FA124A5FE4xmbalnx13ciscoc_" --_000_E7175A8E3DC14048A7D3020E0338C1FA124A5FE4xmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Randell, Sorry that we didn't get to this question during the presentation, due to t= ime constraints. Please find the answers below, inline. Thanks, Xiaoqing On Aug 1, 2013, at 1:08 PM, Randell Jesup wrote: > This jabber question didn't get to be echoed due to time (about NADA): > > > When competing against TCP with droptail, do you kinow why the first NADA= flow doesn't change when a second was added? When the TCP flow becomes active at 20s in our simulation, queuing delay qu= ickly rises from below 50ms to around 200ms (corresponding to a full queue)= . That explains the quick drop in rate in the first NADA flow. At time t=3D= 40s, when the second NADA flow becomes active, the queuing delay remains th= e same (since it's already at full queue), and the flows experience slightl= y higher packet losses. As a result, first NADA flow only reduces its rate = slightly. Instead, the TCP flow backs off its rate to accommodate the new N= ADA flow. I am attaching the both the queueing delay trace (qdelay.png) and the trace= on one-way delay and composite congestion signal (delay.png) to help expla= in this. > > Was there some floor that stopped it from driving into the ground? We set the R_min for NADA flows to be 100Kbps in these simulations. When al= l three flows (2 NADA flows and 1 TCP) are active over the 4Mbps link, the = NADA flows get 0.7Mbps and 1.4Mbps respectively, so they are not hitting th= e floors yet. > What are the dynamics of the resultant steady-state transfer characterist= ics between TCP and NADA flows? As can be observed from the delay traces, the queue is mainly driven by the= saw-tooth behavior of the TCP flow, and NADA flows basically converge on t= he rate dictated by the composite congestion signal (delay + loss). Is th= at what you are asking for in this question? > Have you tried two TCP flows? > Good suggestion. Not yet. > -- > Randell Jesup > randell-ietf@jesup.org > [cid:adef81ab-823a-446a-8f24-624c1e4896e1@emea.cisco.com] [cid:1f7c1c91-519a-4282-99fa-7fcd7db3906e@emea.cisco.com] --_000_E7175A8E3DC14048A7D3020E0338C1FA124A5FE4xmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Randell,

Sorry that we didn't get to this question during the presentation, due to t= ime constraints. Please find the answers below, inline.

Thanks,
Xiaoqing


On Aug 1, 2013, at 1:08 PM, Randell Jesup wrote:

> This jabber question didn't get to be echoed due to time (about NADA):=
>
>
> When competing against TCP with droptail, do you kinow why the first N= ADA flow doesn't change when a second was added?

When the TCP flow becomes active at 20s in our simulation, queuing delay qu= ickly rises from below 50ms to around 200ms (corresponding to a full queue)= . That explains the quick drop in rate in the first NADA flow. At time t=3D= 40s, when the second NADA flow becomes active, the queuing delay remains the same (since it's already at full que= ue), and the flows experience slightly higher packet losses. As a result, f= irst NADA flow only reduces its rate slightly. Instead, the TCP flow backs = off its rate to accommodate the new NADA flow.

I am attaching the both the queueing delay trace (qdelay.png) and the trace= on one-way delay and composite congestion signal (delay.png) to help expla= in this.


>
> Was there some floor that stopped it from driving into the ground?


We set the R_min for NADA flows to be 100Kbps in these simulations. When al= l three flows (2 NADA flows and 1 TCP) are active over the 4Mbps link, the = NADA flows get 0.7Mbps and 1.4Mbps respectively, so they are not hitting th= e floors yet.


> What are the dynamics of the resultant steady-state transfer character= istics between TCP and NADA flows? 


As can be observed from the delay traces, the queue is mainly driven by the= saw-tooth behavior of the TCP flow, and NADA flows basically converge on t= he rate dictated by the composite congestion signal (delay + loss).&nbs= p;  Is that what you are asking for in this question?  

> Have you tried two TCP flows?
>

Good suggestion. Not yet.


> --
> Randell Jesup
> randell-ietf@jesup.org
>


=

=


--_000_E7175A8E3DC14048A7D3020E0338C1FA124A5FE4xmbalnx13ciscoc_-- --_005_E7175A8E3DC14048A7D3020E0338C1FA124A5FE4xmbalnx13ciscoc_ Content-Type: image/png; name="qdelay.png" Content-Description: qdelay.png Content-Disposition: inline; filename="qdelay.png"; size=7076; creation-date="Mon, 05 Aug 2013 19:20:24 GMT"; modification-date="Mon, 05 Aug 2013 19:20:24 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgCAMAAAACDyzWAAABLFBMVEX//////8D//4D//wD/wMD/ oHD/oGD/oED/gEDAwACAgACAYP+AYMCAQICAQCCAICCAIACgIP+gICDAAMDAAACg/yCg4OCA4OD/ oAD/gAAA/wD/YGDAwKD/gKD/AP//AADA/8DAwMDAoAD/gID/gGCAwP//QED/QADAgGDAgADAYMCA wODAYAAAgIDAICCg0OCgoKCAgIAggCCAgEBggIBggGBggCAgQIAgQEAgICBgYGBgIICAAICAAABg wKBgwABgoMBAwIDjsMAAYAAAAP8AAMCAYICAYGCAYBAAAIBAgABAQECAYAAwYIBA/4AAgADAYIAA YIAAwMAAwGD/gP+AQACggP8AgED/wCAgIMDu7gDAQAAA7u7AAP8AgP8AwAD/AACgoKAAAAD///+V uBHlAAAAAXRSTlMAQObYZgAAGiZJREFUeJztnQGa6ioMRt/iuhHt/vfw7mhbKRAIkACh//nundEa /6IeS1o7M//tAAzkv9EDAM8GAoKhQEAwFAgIhgIBwVAgIBgKBARDgYBgKBAQDKVMwPc/vl/P70rD Ak+hSMCvdfuh3XENgAbqBHyf8kFA0EZxD3hsAb/fnDn4DUCeVgGviMM+R8BSk0vWajLaanbfYZfu hDiX7lMwnu1VsicW8L73AQHXzJ5awO80fkzmtzkdz/Yq2RMLWBYtx8tktGq2USBgx2hG9m03roDk /QoSv6WlQ2g49mZUwGXhC3gvqxYwiNn9j7dit/k9V72BEHAuVARMpvx2I89v3wO61/Xvv/00zjvw u1+L64CAU/Ld+JxWOVskr8JbeN12/n+76vyuOUcqvO2au/A2Ib/3lICOgVuW+1iDx25CwGV7wC/u J5yRV/uqIT79jG6f4im3Td/vyu3wmmvn7+MG59sOAW1EKwlI3f2+IUsLeL9ybCR/W073WighNQ7W Qw2WmBBwcaITXbmA9zn0Pi/fY27X3jcBvf4QPeAjiG36vFfb6RHDe6enYL/W/3brCM+dEAj4MJzX 99zfuG/CroWx+77d+7k237eA3idZkQ0nUel/q3+YwRITAi7eA/5Bv6gNLzex19KY2QIE7BgtJGAb 0XPwxmFUQBBg9D0JAVcBAuajAfAxKqDRtztOxwqAgB2jIWCIUQFBgNH3JARcBQiYjwbAx6iARt/u 6AEDIGDHaAgYYlRAEGD0PQkBVwEC5qMB8DEqoNG3O3rAAAjYMRoChhgVEAQYfU9CwFWAgPloAHyM Cmj07Y4eMAACdoyGgCFGBQQBRt+TEHAVIGA+GgAfowIafbujBwyAgB2jIWCIUQFBgNH3JARcBQiY jwbAx6iARt/u6AEDIGDHaAgYYlRAEGD0PQkBVwEC5qMB8DEqoNG3O3rAAAjYMRoChhgVEAQYfU9C wFWAgPloAHyMCmj07Y4eMAACdoyGgCFGBfz8VVDVfHMYfU9CwFWAgPloSSDgGhgV8KUnIHrArkDA MFoPCBhgVEBMwQHoAfPRkkBADwiYj5ZEU0DI3Q+jAur2gCb7S6NAwDAaAnbEqIDdp2CJtenO7OgB 89GSQEAPCJiPlmQOAYsGgX2bCEYF7N4DQkAlIGAYHRcwujoI2IpRAQdMwbHVFQ1iUxiyE4keMB8t iU0BpccMAYuiJekrIOFO0WJlAY1iVECZHjAaEe0BCXlGC6gxq3fm4QJGMhQFFDmayFi/JYwKKDP5 UBkxAaPyzCQgesB8tCQCApLbDwh4BwJG6CrgViQgOV+XCMgqxRRcFi2HSA8Yf/liPeAQAfO1GvvV vVlUwIaXLy5gfJNUZFqxgNlihUm9O60Cvv8RfKOiJVETMPbaEwIWbeqorWhidPkaJ/GZPeCfb//+ 37+R0ZJICEgIAQE9IGCEjZoWjxslBaTWVTTXpsYbH0OuuFDpORHoAb/mvX/fruX/eP29e+S/vE4p 4iXHq5dO+bx84Q3Hvd1l21+dt2w/BQiT/y0Li1+XgKwHuDEewhZfkZ0v71vLdlIo4Pu72XMlPG8p CyriEpA8jsKYv+Lbjxd7C0gkkIsLtoCsjVvZNnVS2ndCzq9jpmByDq0WkD8FFwmYbBkiGfliL/G5 PeA+QsBNQEDqNeYLSHWGEJBNs4Dvcw7uexgmIyBn/mIL+L3KFTCxuWQLyCouU3pWrB6I1hMw7AFH CBhdYUPitKwoILuDZwu4R2sLBSTWVzS46sRpMSpgagreOAJSW7Vftnt9j9aqCZgaHJn4zB6wLFoQ COgXQcB8tCBpAZkNVEcBeRu1zArDQEzBRdFypHrARgF1ekAISLCkgHv2hUm8fI0CEqaV6MJyCwJW RAuiJ2AwBZO1egK638giLxE9YD5aEFpAZgfvfotm52tHCrgFRRAwHy3IJWBEgE4CFjV7+gIaxaiA r5SA32/J+ydevqAHpAUkl0JANqYFjJx0sLEETL18h4DXTWRtiYBFuww8Afd8kQWMCnhJIi/gPlpA 1sYtFBA9YD5aEELAjTc1pbcf2+ZuWoUEZIyKNbj7oCBgUbQg3QSkEwsELOrYKgU0ilEBX7SA54XU 3VNVL6aAJbu7CgL6F6yynID+hRhJTS8Bt3RtSbNXIiDrPQQBq6IFyQtYP4GNFtC/wCtCD5iPFiQu oKNd4uXbMq9xm4Cx4pKODQLqRQvSIOCmKCCxqZMWMPcIDGFUQKIHdK5VCxj0gEStkoAst1gbehtA wCC6TcBocZGA4aW6IhsYFZCcgmMXY3dNFbkC0rWzCYgeMB8tSJOAmaK7gEQttbsbKy44bMzdjQov QcB8tCATCJhYOkJAoxgVMNoDOnNrg4AvDQGzg/qV8vbj80VGsC+g81oIC7jtcwq4QcDKaEFOAfe7 gG4Bfc9M0UABWW+heBF6wHy0IC0C5orqBSSavRIBc4PbIWB9tCAQkJk4O0YFfMUFdCqqBbz1gHS3 RQgYK2Z9uOFVpopZRVZ4nIDZ1xgCdsWogJEpeCNcCO+YKzrsu+s9vYDoAfPRgsQE9AqoO2aLOAJu EFAGCBjPzguYWoopmI1RAd0e8NwUCQn4+gm4SQmYGxR7cDt7Z98Kqwi4rSAgazcKAtZHCxIR0C+g 7pgtuuSbVcBoEXrAfLQgl4Cnhf6rVfjyeXc9kulDvkoC0tecxRCwNlqQKQUk9jb6CGgUowK+6gXM Fb1uAubuyTFNWkBGkR0eJiDjaDUE7IpRAW9T8Bbxj55dWUWRPZtqAemP84L1Mtwii9AD5qMFGSzg NlBA4ioEzEcL8hMwNv/uLQJuLAGTS3fijjkB84PjFRnCqICvOgE5R6t/f9p8RgG5x9vN8DQB/eth 1ewCpq+bw6iA3hQcLeAspNSNLFcXkLVxowVED5iPFmQ9AXmfZj9XQPdvoddGC+IISBVwFs4lYH5s j52C318ao+V4VQnIOlz9EhaQ/jgvMxTWI3iIgF/3Cg2EgMFKBQRkFJmCKSBZXRQtiJ6A9VNw/Ihz LwFX7wElogXRE3BjCBg/7QUCVvAkAXkf2PEETC+ldjwwBQfwBXyXKjVdD1i9KFg+SkD2WWd2KDgM Y34nBAJOCF/Av3/TCFg5BTMWxQ9r7+oC8vtTomj1HvBdPAdDwFRFfr0Q8F74mYPbogWpEDCmFmu3 JLyhZHeXLSBjJE+egu3vhEwtYMEeOm+4VjB6GKZOwNqq4IZxAjKKbGFUwLopmFFFtoAcAaPFXAEZ i5KWLt0DLvFRHASsZQIBZzsZQVFATmBMQOr0aVEBOfezxXNOx+KduL9t1NsdAqpg9ITU1QSs3kN/ joAS0YLUCFhdFdyiICBrbCkBl+4BhaIFMSMg/ZN1udVCQPFoQYoFZP7oEkvA6Il/pICcdAEBjWJU wPIekC0goweEgHJAQL+KJWDkImGaqIC8O5rCqIA1U3B9lX9TdGPYIiB3Dz1VhB4wHy0IBPSXQcB8 tCCrCcgaG6bgxmg5anpARtVfaGkP2FFA7j0tUXA+YOEZ+W61+NOkJiA938T3d0UE5O4gMYrM0XxG 9HmawuejutvnxZoCKk3BvMCogJu2gLmi1XtA4mdCzvNkjiu7I+lyAm7BJTEBWWODgGH129kCJgWU NrBUQGIEBQLujoCRpfe7RmXVFdAoJVNw9ISYawv4naKdms8dXn/vntenuf9cEvpy9oB0yaedc69G R/A97ny7+qLWe63tFvUxwL31XnIfxllMJe+J4s17RJGxWPsSV4reCYmekHUtPOzrswUs3glhbXu2 1E5I7RaweBTEUlaRPZoPw9wFnHgKZlSlh5nu9hoEZLUH2aLle0DeFGxcwPQqr1VHl0aTIGCGRgG9 4y/0YRgISK+gZWwPm4JrfyhpeA9IDcBz6dP25xIhoCSPEZBR9b3CEJC/FALmaO4BWdGjp2By/dGN WSZxUgEf0QPWRusImEyFgHJMIWBTtJaAyQLqSnnV/WaegGkvo7XpsT19Cm48G0ajB9QRUKQHPK9u LAFZY3u6gE2/H3B9Af3BXIvp1eUGx3oEDxKw5TekmpiCc4PMCBgt7ijg6j3gEwTMrTJW1yxg2w7S gwSc7zAMBHzSFEydDcOKNtEDHpdre8BoMQTMYfQwzNME5FlqkUdMwXRlxRQcP7IyXkD0gIno4QK2 Vd1uZx1v4QvIfXM8XkCimldsQcDsGMcKyCgyiVEBi3rARGGkKtcDigtYMLZkkU2MTsEqAh7RmdoS AYnPRzKL6LEli2xi+2yYZAFn7awX+V4wq4CP6AFro0cLyKjKD7FKQHJQ+cFBwFvddwtYsg2EgF0F NApTwPdJXfToHpBRdV3K9IDxWTUYC1fA1vbgMQJ+v5rcCUnV1QjIWVogIGNsEPBbVv8X04dOwYUC ZmqnFXDtHrBiBoaAYgKy5um1Baw4DAgBqc4wvSQ6tsdPwY3Rg3tARtUvTLAHJLaL6SWRm3jztE0g oF8EAbtiVMCCKThZFhEwXcs83iIqIK+HWLwHbIseK2BzlVPC3NvgCshyi/UOgoCpaAhIrEVQQKMY FbCgByytSveA4gIWjS1WZNxACOhX2RLwutGqiEYFlJ6COQN8roBz9IBT/W4YeQE5q4wVNgkosIf+ GAHn+t0wfAG5VZxVxgqfIKAmRn81B78HTK85UtWzB+y8DZ8RCOhXTScg63Ga3Rs2+kNJJVNwOoZT 9asJ19lDwNyodmUBp+gB5/rdMOMEjCdAwFq6HIbJuFLDXAISG8ZVBNSkbAtYOQXLCyjcA7pRyR6Q FDBeLCFg5rl7jIAtPSAE9AZFXc+NrbpqXgr2guujp5+CWeOrEDBcugVVjWN7TA9oVEDBl09AQG9R 70dQy3gBa34sGAIyBGwf2zOm4OkEZPeA3JfPiU7VNgr4ui0qH1uqamkBG6OHCpjM+d68NQoYGQkE ZFIkYO2B6HFTcG7FZxVvlYVzbW4KZgnIfQRr94BH4TxT8CAB2Zu6TyUEZFC2F2xQwFwMp+qqLdnU cQQUGNvRg64+BVvdCakQMNUDlpgWW+z3gKVjo6riYzBBmYCV0SsLWLQYAgYsfiBafwqmF8fGZ1PA KXrAluhhAmbXWyZgNK5oMQT0gYA7V0DiYVQLKLOH/pgpuCV6WA+YXW1EU/rtXixgsPB1F7B4bHQV BExFTy/gLTpRPELAdBEE5EQPnIKzMZwqZ53ESPjF8cv1Y0MPyIiGgLf1RS7Xj+2vgDgWKQYEDIGA TtX53yJGBRzVA8aXju4BHyOguU9CeglIJftAwIC1z4Zhd1DcdbKXpkYVuUzV5sN7CDhFD2jybJiZ BWQd4YOAZ9lkZ8PwBOS/fNx1UhlcbgIyavPZD5mCbZ4NUyVgaQ9Y8tK/IKCP0bNhuALmcpYQcHuE gC3R46bgfEzfl05JQE5cAxP0gPtkvxtGUED5saXXF7lI1jLG9hgBbe6E5GP6zl2/lbH6U8bYegio SZffkDqoByzYfrjRjUNL8YKAPmsLmM2BgKMpEdDaFFwnoCqugIxa1iPYntED7qWfxEHA+PqCS4la CCgTDQGd9Z0XGAJynrazaPkpuCUaPeCZ7QiYr4aAUtEQ8MyGgD7NAn4bw2MH5bafYmMK7nocercp 4Mw94Cne5//xLYiGgL/1+ReSxRAwf3f7AsoNKk+pgPyiZ0/BH/ne57frln+8/t49n5f5c0nqy9kD 0iUfAbNRXwFvy16yIw1GtR9PCaeY8axtx6MMHoeBL/FPd+sEfDsSnrdcNWN2QkomMDe6aWBpindC +EXLbwGpU1LnnYIrBVTFpoBT9IDUSfkzC8iLERsTAwjoU/pjmV79KeWMh2FY6+w8c8kLGCQbo1FA XvSoHpARFBZ16QGLNm4slhfw3NTVRMsfbcsLyHz5hgnIqIaAt8LSH4q7CSj+/OgJqIpNAafpAWuj hwg4JUUCViVrMIeATT8TIv38bBCQSLZGpx9KkhdQ7QjKPD1gEesL2PQzIRDwmw0BfSBgV2wKOEUP 2PZDSRDwCwT06fRDSRDwy/W5mSkBNTF6GMZ4DwgBL8oEfMIU3EdA8WgImCg2JaAqNgUc3wO+qZOx eNEQ8AQC+kDArtgUUBOmgGQ1K9qUgOgBu4Ie0KeDgBojf4aAldGmBFTFpoDje8BP5bvhLyVBwC+n gFrJOkwh4P1HLsuiIeCJTQE1sXsygspEtnfqAeWjIWAiGgKe2RDQx+4JqVoCqmJTwCl6wPKfSoKA IRDQx+5hGAgYSbYHV8DGP1ZoSED0gF1hCjjhZ8EQ8MbqAlLVrGhTAqpiU8AJekAIKAME9MEU3JXP kFUGbvDJ+AABffR7QJVxLy5gWzQEPLMhoA8E7IpNASfoAduiIeAJBPSBgF2xKaAmENAHPWBXIKAP BOwKBOyKTQHRAwZYFlBn3BAwEQ0BT2wKqAkE9FHvAXWGDQET0RDwzIaAPhCwKzYFRA8YAAFjyVpA wAAIGEu2CAT0QQ/YFQjoAwG7AgG7YlNA9IABEDCWrAUEDDAsoNKwDT4ZHyCgj3YPqGQKBExEQ8Az GwL6QMCu2BQQPWAABIwkqwEBAyBgJNkkENAHPWBXTAsoGnmiLKDWdhsCJqJNCaiK3q/2Rw+YiIaA JxDQBwJ2xaaAmkBAH/UeUCfa4jGBPyCgj1EBrW4CIWBXbAqIHjAAAkailYIhYAQIGIlWCtYFAvqg B+wKBPSBgF2BgF2xKSB6wAAIGIlWCoaAEQwLqBetlayKDQGDexvuAbWyISAdDQHPbAjoAwG7MqWA 2XuiB4SAnGi1e0JACMiJ7n9PASCgz/N6QAiYBQLmebSA599yvf1FV6MCqmJTwPl7wEO7r4NhNAQ8 gYA+gltAPQHDD7AgYCS6/z0FkNsC/vv/+fcT8I/X37vnI+DnUt2Xr4Dusn/XX/4yoS8vjdDzy98D UYqvT/4IqPigyS/vW8t2UrsTctjXvgUMtxJdt4Dqv6JXiZYt4MBNoLCAElPwYAFVsSmghR4QAo7m 0QKex19EDsNAwCoePwUnok0JqNoDKmZDQDraEzDzeCFgFdVPh+JZ2gwGCJh7vJiCq1AU0EAPmI6G gB2AgHQ0BOwApmAyejMlIHrArvQRcNcQUAkI2BUIuAroAcloaQFbT65ZEwhIRkPAHmAKJqOFBdx0 BUQP2BUI6AMBuwIBVwE9IBkdCph8wBCwCghIRkPAHmAKJqPLBQyO+nkCaj5l6AG7AgF9IGBXIOAq oAckoyFgD/QEVH22IeAqQEAy2paA6AEjBZXRDOYTMKIXBGQAAcnoUgGD5xJTMAMISEZrCCg1yHWA gGQ0BOwBBCSjbQmIHjBSUBnNYA4B735BwBqaBCz8cF4QCLgKDQJm7gsBISADCEhGcwR0b4aANUBA MtqWgA/sAR8v4AYB24GAZLQtAa2iJqDu0w0BVwECktEQsAcQkIy2JSB6wOD2dQU8LkFAASAgGR0R cLsunkucmzEF1wAByehAwD0r4P0hQ0AG8gLGXh1xhgp4qsQRMLoFBT9UBAxeHXEGC7hfD3G73exv 8ogpXIMn94C3jOjmQZxJBNzTAlI9pAYQ8Fr+WAGDps9d4m0PwYGMgJFeGwL6AjY82QsjIGB8Z281 ATcIqIKCgPuiAu6UgNeX6zGHS9QFfGYPGFHtu/xJAm4QsIEWAXdCwMh0JM0oAbfjYlzA39f+Alql VcDz63WQYXEBval3Ozf4nnoQkIuQgAe/5UsKuG+ueGcX4groefp7X0I+giYBnSf5fCG2pQV0mzun AaEF9L4pNlOP7AHd1+K3VXiOgN8lELAFCEhGKwgIAsQE3M+5+Fi8roAbBBQEApLRELAHzQKe+x7X tePG5wp47pChB+TQKODdMwh4Lr8J+OseIWBArSXbUwX0T0TICujOyiCgXsDzu5uwoICbcw0CygMB yWjXK1+w38beKwwE/bWFUgNcCwhIRisIiB4wAAKS0YSAW0bALRRwg4AksgI6ty4qoPMeiwq4u2/B /XcXTMEEEJCMhoA9gIBkdFpA/ybv0UJAJhCQjC4S0H+0cQHRAwZAQDK6QMBwCwcBmbQKGA9Qn3Rm EPBHVMD7EkzBBDoCxl4SUSDgKkBAMjouYEwlCFhPs4DUzQsLGNyFLSB6wIA6S7J2QUAIyAMCktFN AvpPEaZgAghIRkPAHkBAMrpQwMhC8hq4gIBktIKA6AEDqizJ22VfwGP8sgKGwxZDMVo1W0/A6iM8 HGQFfP/Di97uAjoPuE7AHQLGqbGEsXkzJeCffT8DKQHP2+MChqkQkAUE9ATc3tvFfn2qLdRPQMCA rZZsbH5PpQFpAd+OgADkkRXwvUcSAShArAcEoAYICIYidhgGgBrEDkQDUAMEBEOBgGAoEBAMBQKC ocgJqLZPfAQr5X8PJilEaw5bK/sbp5NOZMudjqV1VPAIVsp/a0VrDlsr+5RDI53KfriAb1UBd6Wn RekpOT5ZVUknsyUF1Dsu/R2zfP6ZqxL9vp5tnfeNQvYpyVvhWbmy7tmCAqqdmnA82/L5zquot5Wy lH32Zxrp15RwfzHnn4Kv7lU+/zhDyNI0qZut2AM6L+PtxZxfQM1majcoiWa2uoDhizn/YZj31U0p 7uMoRNs7DOM906Lp12Tjv5g4EA2GAgHBUCAgGAoEBEOBgGAoEBAMBQKCoUBAMBQICIYCAcFQIGCW 2AdS8U+pGB9dJUvcG9VObZsMCEhyfl6Zd+28Qktz/WaelFf32x5iIASkSJ8NEhUwF1dUAgEfzm+z dp0m7Fh5bhzPUzveV6W38B53C/PON/mdsfl2ry8OBCS5TcH+uauXHe6GMnU6nWtV/ERY/1xNCAh+ rsUF/P3gx72cK+BtE+hv+CAgcAW8a+UurBDwNw37a9t/cis+sHmAgBRR10gB6UonjlMSTvJrAwFJ nJ0Jdw/EP7P82v24n25O2BWE3dd4rfYp/kFAMBYICIYCAcFQICAYCgQEQ/kfbqAXE3T9k30AAAAA SUVORK5CYII= --_005_E7175A8E3DC14048A7D3020E0338C1FA124A5FE4xmbalnx13ciscoc_ Content-Type: image/png; name="delay.png" Content-Description: delay.png Content-Disposition: inline; filename="delay.png"; size=8146; creation-date="Mon, 05 Aug 2013 19:20:24 GMT"; modification-date="Mon, 05 Aug 2013 19:20:24 GMT" Content-ID: <1f7c1c91-519a-4282-99fa-7fcd7db3906e@emea.cisco.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgCAMAAAACDyzWAAABLFBMVEX//////8D//4D//wD/wMD/ oHD/oGD/oED/gEDAwACAgACAYP+AYMCAQICAQCCAICCAIACgIP+gICDAAMDAAACg/yCg4OCA4OD/ oAD/gAAA/wD/YGDAwKD/gKD/AP//AADA/8DAwMDAoAD/gID/gGCAwP//QED/QADAgGDAgADAYMCA wODAYAAAgIDAICCg0OCgoKCAgIAggCCAgEBggIBggGBggCAgQIAgQEAgICBgYGBgIICAAICAAABg wKBgwABgoMBAwIDjsMAAYAAAAP8AAMCAYICAYGCAYBAAAIBAgABAQECAYAAwYIBA/4AAgADAYIAA YIAAwMAAwGD/gP+AQACggP8AgED/wCAgIMDu7gDAQAAA7u7AAP8AgP8AwAD/AACgoKAAAAD///+V uBHlAAAAAXRSTlMAQObYZgAAHlRJREFUeJztnQm6oyAQhOdwHCQJ97/DvMSNpZtFaDarvpks2JaI /4MWTfJPQ1BH/etdAejZAoBQVwFAqKsAINRVABDqKgAIdRUAhLoKAEJdBQChrsoD8POn7fF4FqoW 9BRlAbhRp3fs9ncQVKB7AH4O+AAgVKbsHHDvAbcnYwz+QFBcpQCeFjt9BoC5JOdsdUrrWb3bVjv3 JMR4ZQ/BaO1VvAcG0D77AIBreg8N4DaM74O5NaajtVfxHhjAPOt6ek9pPa23oABgQ+tpvQU1KYBQ A2VM6d6f/QWAEKd0qqjpvNRVvRIA+HhdJ5bXk32eaU34auuNisrelrf1KQBEDijobV9V9afYjmuv H3uVXQBwXOtZvI3ZXeON2SEGAMzdllcyBYCQrPbR9nwZvuQAAKGaMoZg71Y7AAjJ6xhePyZnxkmI d9GVvq0lbVteyRQAIgds6i0oANjQelpvQU0KILSKACDUVQAQ6qpJAUQOmO8teG9BwSfRAGBD61kA zJ5TeR6AUIaK7i1wViDfWdOAr6jsynnVBYCLqezeAvoSiONixgNAyFHZvQX2Cj6Abnxu5bySKQBE DpjlXXJvQWgFADiXdR/vwnsL3BU+tt+x8GHXgqEMld1bYK9Av8s/b74q55UAQIhXwWDLGHolABDi BQA3IQds6S1ZbQDY0HpWbwBIyPlwFTSpACDUVbMC6H68FJpUkwL4lgNw0jwNOWCCdT0BwJbeANAX huBFBAChrgKAUFdNCiBywJbeyAE9yQIIuJtZzwqg6BCM4b2hAGAzb2BNCQCWeGdVAgBSmhRA0RyQ 8Ga2lgmgQg7oCQB61gCwofWsALYegpnN5QJ4u0rrCgAmedOb877yPdcWAoBp3lkA1qD1MZoUwPY5 YBUAa9fZNEQOGLeuJ0kACVB40roCqABgnnVF1TiY7KntlABOKgBIWVMAEsFZXMoAOD2BzwaQmVsp AzAQDAA9TQpgjRyQOXxEDkj8xl7AoROAyAHj1vW0PIBJoQAw07qiwgcz6VBzQCQDmEfaX1kWgPFY iYmd5poaQK750w4MABxBzwWQPXxeuaoBoMoCMIktAJhrXU9vOQD9HHAOAJEDxq3rqTmA1LYYpLjg 2gAqAJhrXVHFAHJntswQTGyLQ6oTgJNqcgCTr2WQMSIAssEZAKawlec4rFYEMD2BSgaQ6m0BYA1N CuC7FED+8JE54AQAIgeMW9dTSwAVAJSznhXA4iE4AEQxgFxwMoBJtGIIzreuqACASWeHYgAGggEg IQBIL3I3BQCFNCmAigdQFQJI5YCaZoooDXWXqbhwHuEg5IBx63oaAECaEgaeJKZyghUAvGFdT4UA +ofP87be6woAUh587fIBnFRrApgyfmUAeD3aYXIARoMB4B3reuIBVCMCqEQATHccWM8FUDOH7+0M 4YoFkC4tBjAlWPlByAHj1vV0Akidbj4EQKdWADBuXU8sgGm5UfAYlwJIFHMeTOXMJy4mx3FkLQYg MTQxa6cCyB5qKQAVABSzrqdyADUbpSwCWR56AqgA4C3retoTPRdAVQHA96QAIgeMW9dTMYD7M7HQ BlBxscx2SNKy+qtUAN2ghwL4+ZP3xFnXUwjA/UV47f2Z8zaO8CwATqpCAL+8/f23n1jreooBWHL4 SgCkScsBMHUPdDRoDgFAcvFNABnSACCvCjngRt7nejrL//T+5g/1H76H6X1gci7YwPm9tRfYD+dq f0/+0rcB4L4h/csMvRr8rEhnJ/io1W4VfFDHuoHgcy/NDb0l2nlvEiHnj5WyHcoE8LN1eyaEx5I8 oyzRPaDVcwXXTTgJOXtATcbmdHWZPSC9QSoGJyE7b72GYH0XQB0IEgEwVikvNhvASVUhB9RDAXi+ DK0qCCAVnJOxAcBMAD/HGNxjGmYOADNOGaKVsw0BYJ51PVEAWilhGMDrpb/cygF5HoYD8KE5YJZ1 PdUBkIxyAWRC5QCM7oEmdwAAxq3r6QJQ2WXXm+CqoShlEDgigGl/Z7NoHQDVIgAG65a0A1PpcQDG B+r7ACoAmK1HAhiMehsABkZEBkAquA2AyAHj1vXUHUAFAOtoGQBVOoA6HKUuAkMAEqU0aaoNgJNq LQDNAH7NSJQAgLFKmVvO2gMAmGVdTweAejkA8/YAAGZZ15MggG8bQCaUAZAKrg8g+Ro5YNy6njwA Hf7YwxfHFAB6AoCeDADVWVAHQJ0CoOoGYGJHP42WANDO1vYAdsVYlLJEh4oAmMQWACywricXQJe/ agAyoQCwlgCgq+PLifIBZEgzi4O8lAGIHDBuXU93AUzIFAUAjNWKrBwArG9dTxaA7mi5BfDrRaLS ACRKaQATTizIymEIrm9dTwSAbgC3XjSqJ4CxugHAIut6agCgDgCoJABM6Z2dSgHAPOt6ugmgG8fn gLoLgLG6hQBEDhi3ricTQIq/lQFkggBg3LqeTgB1dQDVpABOqscBGI0qAZAKrg1g6O2EehSAXlwQ QJsIaQC9neD2QEeDptL0AJKnIImHjwNQxwEMlnYBEDlg3LqepgIwUqtzswDwp3UB9OPoKN0LwGjd vEIMwVnW9eQASAUwKyVEneUAUF4AkFqTKL8LIN+NepVLqRsALLGuJxtAMoBZKRalbgOo+gKIHDBu XU/tAXy9XsR6ALBU8wOYlixp4jwzB8DXyyTwJoAWxNR2I3WjgmYfgx8GYFIUUf6yALyM7G5RGeF0 aQjAeN0I3gBgjnU9dQBQXficRg6WRrQf60BMbbbOHsylBQBkAuh1YlGKBPDLXzqALxtATRUT2y3c A+SAcet6ugEgNV+dCODrB+A1sB5GVr9odXVm8VWqVTGAftHxCgDGrevpJoCpUT6AegPwdQTtxRSA dndpdpY8gBnpgVezuQUAqSi7/HeUv0U2gE6/aHSLdvFZqrXigCkAcHICASAVZZVvx/hgbg/SXr9o dIt2sWlSBKAfFMoqJ9GjAEyLcgB82QDaMF79olJGhNFdnlhub2oDeCGNHDBuXU9SAKrtNyqN8pcL 0sbX6yLtQHGnzukuTXC14rrAewC+AGCedT0JAmiXGyce5/vtHMPB61cji1YXVl0BQLvAmR2aUo8B kEoBWQBPXTmWNfXnYLlBqVxaHVj1TiO7P+6WiSAvBADmWNdTGwDjE8pmvxgoNrbHAeiWEKcXzh4Y HSxlOYmeBGBa1JnweOwQq7n9ohtge7C4EJUjTnD9vw7TETlg3Lqe5AF00DFDlQmg8gudYHt7iQC6 m/eijCR0ewUA49b1JAjg9sI7/rUAJMdgCkB/ysYF8HKceBB+EIAJURZ/bGgpgD4tSee3FH/mhM+c egqAZAfIRpFnANa2PVsGQFUAoBNqBvnn257nJAKAbtSbHtOqAUiMwdQMs58vGkHu+fb3PXLAuHU9 iQGodwADoaZVAoCeCTm/4k6wvPze8gryz7dl00AA6EkGwGsEDoWWAujZkx1gBEDXf9pB+DkAJkRV BFB5q13vXFiIDvCIdSYRzeVeoV/nGdQEQLr7KZEogMxUnRPlvK4HoDHDZ8aaJ0gRKmcSALRdvwkP eSgjALonGyEAXVhsAA++rtMLy9PJ9poAOH0O2B9AugZEVzQEgE6sd78rWS0AyFsPCqB7tUOdBzlo WA6gP79izfB5sfv9htQF4iYASgoAOqaaBZDK9mIAqlwA3Rm+o5rf273o68PXmkStx9eDAXxZHzbX LQHk5leIGb6j9EXhZwM4JYEA0PIM5YDUqFoJQLNO5B4w+DUCEDmgpwoAvtz7ifcOsAmA9FweU8rs gBP1BoCsdXcAvWsNmrjeegZVBZCplQ3+VXgfwEmTwMcCeFzu8gFkxrIcAHUUQGKG2ZliAYD1rGUA DLpGD59/vTV4DsIAqG8DaG33KCCnmCkjqhwAstYSAJLDqhVgvqE7wC3qmvndcsB2AJ7btd5Tm0kA 8C13FoIc0FNlAJ1rDWFHBkAyOACgvd3QFDNhRJQzJ081BAA9lQJIXW9lQPAcawFoXuMITjHrQAva fSodM7QAoD5IYK41eI7VADyuccSmmDUALLQeAEB7qXPB37zUwB5EbsKF2F4qgOaGM/eAigKAnPXw AF4k8AkPzVSYNHfDRI0VB30ugG+5ayHIAT2VAehf8Dfe3AKQIS0FwIQZPv4cBAAmWU8FYMxxVAD1 nGPwQwC0lpF3nEQrCQBF9AQA2Q5wGgD5ugHAFOuxAGRueTqiRswBUwBkPs9cQ8gBPRUAyN1xUggg GRwHkN8LAJho8Pk9fLU9E9YzABi207cA9DwlAfxqwjG4FMDPDuD+5nypRwWQu+UpFUD6rgNZAAN1 ezqAH6MHBIBucRqA4e1F6vZ0AM8h+Pf/9+8C8Kv39qsHf830e1Xr4QCQDfkdmO3tN/BcsPF3vDUW qKOSb36Te5y5YPtG1be7g1uw2pdStTproJhdMBYEdvVa8N7vyKrazjrYJKUPHytlO3QHwP3F5/MZ sAc0A/mbPs+oyElIZg/I1urabHh7Vt1CUd96C52FjH8Ssr8Ycwh2AEyICjkOC+BP843BtYfgMQE8 XgZu+ozWMQQgQxoAjKv0JMSefxlxGsaIC911nAggfVoBAG9r/YloG8B4VDgHzASQrRVfQiwJ7Kid AwolgUPngCnW7QF8mdd7Wf5sAPdXANATAPR0B0Dizk8KwMAmibhCAAObTaubu2i6MXhhAMMfuz1s ziAA2EVrAmh+zsIAkLJJriEAFNGyACoHQDI7ogCM5YBuqSJKUwEM7UMugFu9RZLAIXJA6qJJqnUH ANX5rS9bGP3RH1kA/QrKAXj8yOKqAH4+9HW7NOvWAL4OAF/7MeY+b3lnCHZLCwGMbC81yjjVYmOH VBqA5zTzPes+AG7YqdDHzbMBJJI9AFikRADZ6CTr9gDqc9wNftxcEEAFAJO04knI6wAw8NW2p43z IpIDPhPAAXLAMut+AEa2fQNAr7QFgGwQBWB9AscA8JP7628dAUwdXL3DF95kHwAz92CyMThjGma8 kxB62QsATqR0AH8fALln3RHA8Kb7AxivWzDoUQDmjsH9ANQlADbMASv0zk0AHCIHtD/vkWfdFMDX QABy27NWzqhbSpTAWcgQAI54EkIuugFgUv1oph4BoKSmnoYhF1lfvlsZQGpQHQJAc0pgVQCzLwb3 AfDVAUBifbqC9wAM1+pwWh3A/LsRJgWQzwEfC+AQOeCIt2NRS+xvf45suS+AqdldIIgGsDaBQwCY eQqsOwH4KgYwc5vCAPLXeyxHWQAltdoQ3ANACpKOAM6VBK4H4BmQsGVhALntne9qAageAGCJ9eAA 2geZTXhYppYHcIwcsMC6HYDuDzCsAGAghgOwMoH9ARz0jmi/3AEwuf9I3mZqTRS5aasoUrmBAJTU 1J8J8cudH2B4JoBTJYGtPhVXmUDmsLu/ANIEQAa1FADL6/YUAIsnorsBGLPxorJzQGEAQzH7crcO 6+WAhdYNATQCdDqAZtkdAKngtgBqG8C6BAJATzSA3m8g3QEwEJze1aUBWKFuTQCU1OoARm3ST5Ga A6jiQTSAMyWBiwFoBiSg1RPAeO8MAGtZNwLQ+xGuWwAGcsB00moBmL4HkgAiB/QEAE3HLdIorZwE AkBPDIBmQFb/kbbNygBGNzcKgJJaCED/R5AeC+BESSAAlAOQ2R7xmtlc4h6oRwCYfzGuPYBOREb/ YaheDshsj3jNbG4UAIfIAT/ZBHYHML7ZCQAMB/EA1iRwCAD34HEB9H+HML7VpE7mCs4DkNke9TpQ uaQgYQAlBQALAeS5ZLZHveYql7oHvt16AB6/SnjHuhGAsQjSJgvA9GIAmKgsAO9atwCQ+CHMjMNn KJQDch6pxSIAKnEAh8kB71o/EUB2e2E3OzjuzQNYkcAxACz7WGYDAGMRtE0GQI8FUFKtPhcsDSD1 U8BtAMzR5ZDQJEUATpMEtvqG1A4Aph3jkQFMaDYAmGLdBEAvIu3wpeeAzwVwiBzwk30ePAeAXtSE ANrWm2omgUMAqLO/H6slgNSPod8EMBhdqEkBlNQi0zAzAhgPzgnyQpcEcNgh2G9tAQDLBQA9PR1A P0oy4ZkUwP454Cf/ZqymABIJT97hM9QEwNTKJTjyAFYjEAB68gAkInIOXyOZACYEjwKgpFp9PRsA 3LZ3bTghOCfIj10JQD46KVgaQOqPPW2bALC3lpiGqQpgqxwwIXgUAPvngL/IzF9rbQogFQEAaxE4 BICFv5Y5D4CSmhRASa1wMwLZ0qMDmBJcBuAcSSAAnB5A1nExAMedByQbOhlAt6hFDni3boEgSQCH yAHzP5XUHcA0H1dzAaiDAFYicAwAC6xlAaTb+TaAkhIA0LU2NMVZSCqAA/9MAwA0rU0tBODI14Lp Zp4fwLzKrQ4gF51k3QfARB9Xw+SANQCsQ+AAOeDAABa18tAA3rI2tRKA4w7BU6Tau85J4zYAzjAG rwBgXWtJXQBKWduaoG3mn4aZoJFPAUBPANBVgxywIYBVGmeAHLDMWhLAqX4eHAB6KgZwyws/509a X4aTAiip1gBOMAaXAniAt92w+jG/PqEVgHWdRQUAPRUCuN+kGgZQAcBd/L17tawdjd86dYbgH3yf 4+lc8qf3+9s277/m+b6q9nAA+H7/NXFV57+Ep66f+fCj5F29Nb4PW2u4C/4SlIGbhJ7Zuwfgx4Dw WHK8UCnftJinswesnwI2OQkRs3ZUp3nGPwmJDcEzASip5gCOPwbPD2BdY1kBQE+lJyHHz4eEpmEA 4CEA6KnFRPRcAMrngCIfhGIBrNBAQ+eACdYA8FB7AKs0EAD0dAA41znIrABKCgC2FAD0ND2AdX2F 1QXAsZsIALpqkQOKWfuqASByQE8AkLYmBAAnA1BSkwIoKQDYUn0AHLqN5gZw8Mb1BAA9AUBXq+WA FUYJ5ICeTgDr2n4FAD0BQE+CAEpqUgAlBQBb6tcMMl/KGgJw5FYCgC0FAD0BQFfiOWBrAMtbCTmg JwBIWtMCgFMBKKkdQDFrWkOPwQCwpQCgp6kBHLplKfUBcOi/08kBrOv6k3QOKPTTOJIAIgf0BAAp a04AcCYAJdUNwHEbCgC2FAD0BABbqhOAI5+FAEBXC+aApQAiB/QEAClrVoVjMAD0NPUQLGbNauAk cGYAB25WRr0AHDgJBIAtBQA9zQ1gXdNNwjmgUAooCiByQE8AkLAOqGywAICeBAGUVDcAxx2DAWBL AUBPALClAKAnAOhKPAcUsw6pKAlEDugJABLWIQHAWq6n5Wu+acCOAA47BgPAlgKAnqYGsK5nA3UF cMzmmhbAvwaVOZRr5oBFACIH9AQACeuwAGBNfQGUOpSCmhRASQHAlhL46e7LOhIwaBIIAFsKAHoC gK5kc8B+ABaMwcgBPQFA3zoWAQArCkOwbx2LGHMMngJAf20A6FvHIh4OYEm7+2tPCqDYzVhJHzXh AOzakADQlWTC854TwAVywLK/MgAY130A43UCgBiCE5yjIUwSKFenFM0JoAKAvnM8BgDeFAGgBoCu czwGAN5UUwDXzQGZMRg5YFQAMC4AyFtnAkhNO2MIjjsnBN0EUFJDAuif8wLAuHNCEABMURKALwDo OicEkWMwAHTUGcCFc8C7AD4uB0wCUOpYCgMoZZ3mDAAT1BlAUc0JoKQ6ABjbXwAo50yNwQ8EMLzD iQD2vYvopgCgKwDoSjQHlLNObI1bAC6WAwJACRUBGFkXAC4zBMspGUCPQLmPCaQIAC4iAMhbVwZQ KQDoK7U1AGAFABVyQE+SACIHBIBRpQPoEggAHXUGcFJJAiip8QAk2sMuAoCUklsDAAJACQFA3nou ABfPAf0xGDmgLQB4S88G8PPT9uxbzwXgpEpvjXwAJVULwPPpIhAAtlQOgDaBawD4OeADgH30dAB/ /3//LgC/er+/e/j+/v9mEttbtb8iH37tYZdtTXS83QF8m2UVH94SpvIPGa3x13Z86xIP3vGo9fCx UrZDd09Cdvqm7wFXPwnxusBoDyjaQVYGEENwLz0bwGsIBoCdlNMa6wF4zL+kTsOE9ggA3tLDAQxa 5wOo/CInADmgozwATQIBoC0AeEsAkLeeC8BJldUajwaQAMyS8n9VBADGJQeg7Dz1GADafAHAG8oE 0CDwGQBee0wANhSAD8gBHwjg69plGjDzDQC8obzWyANw/NuxwtZzATipcgG8CIwDeLNKSRoFQPMk GQDeEADkrQUAHPOXH3sqE5MnAvg632UCqJoC+Igc0OwC4/Nii+SAdQGsVUtPANBznh/A71eKlwCo GwI4qXIHyvC8WIlznvoCuL/IAlABQEr5AAaS8iLnPLUC8ErbbADV/pQDoAaAvgAgb80CqFgArZ1u C+AzckBjDI4DuEIO+DsR2d8BQAHdAJBPyo8F+9EBgBiCo6oP4HV0ymoWVlMAX9s7ACigfEwIAJ1m fwSAStMAsleHASCpOwC6Q5L7d38cnRr149QQQG0AeE2/pAKojL9S5IC+bgOo4gAukgPue8wAqK5o AHhDN/opCkD3pg/9BADVUABOqlsA7sdDGx2B6bjaELztsQWgtgA8HtRx6fgsfl0Xk/fltWq5ikoA PFr3MQBefB0Ans9btNEiTsm5fq1arqI7mNgAvrRN3NEvLASg3qAy+GIBVC6AW7E+GqxWJX09Jwc8 OoSzdZUy58AuAFfJAbc9Pm5N2O5p3sF77ft/Rm+X7vySA9BalfT1UACVCeDRHexHaT0AT75e19M1 Lp+4OUgqo8FqVXIZ3RoojeNhHIRjPN6H5gWG4Gsv9s5v31917OH1WusDM200hdFEBs6QodoAvs4C 2SmHrgBau3v2cGf2dwJ4LNevc/1alVxG95pkB1BfrassGH90rgDg2T7b/pz7e/6dnfut1TUBY3SU e2JyMCmYlTwoBzw7BKO9LQKP7Kh2ZQ21B/BlAnicgOgIgOek1N4eANBVZQDVcRjWBPCcf78uBJ0E KvOSsTVpeJzHYA6Q0M2s5OTrPBbnifB+VBYDUHMAarPn1xeAyizZMkQASKgKgNoFUIt/BHswAN2/ yHOo1ueFOvBH6u55GQWgNgFc4UqICaB7D4axqyZtF4DKBPCIRg7oqhKARjNfAE4/EW0BeOJGAqh9 AK97+RUAZHW7n3IB3N48F8Ajcm+Da4i2AIRc3W4Ws72NwnWHYB5A7QGoHQAVAOQEAHlrANhAAJC3 ZgBUBQAiB3RVF0C9fA6oGQDPZjBSwmNdABhQKYD68QBqnQEg5EoSwMKqBdUdQB0A8CzT1yoAkFZl AI2lqwBoULY/BwHUADBLYgAKN/jIAF5l+loFOSAtSQBXyAE1C6C9iABQAcAECQIo2iSDAej3+DSA kKubzWKlPByAkuoKoFMCAAtUDCDtAACdEgDICADy1jEAL8UB1MgBaUkCuGwO6K0CAG/rHoAqBqBe AcBXfQAhV+UAshG36pMqcQCVsgFUAFBEAJCxVur8EqbtbSaAbhoMAGkBQMZanZ8wPd7WABA5oCtJ AKfOAW0AFQAU0i0AE+ZVZwZwn9Y7v+rAnuZjASQK2XfQIXVfMV/RegPARQQAfeswgNSgkQRgrfqt JQDoW+/0vdIBJK/8UHHIAV1JAjhtDnh++5+mAEwVAEyRCH16bgDPLzn8vrtJH5QoIf7EUx5hAJV5 zgH8BOUxRdFmP3at76EW14IhiNWkACIHbOk9aw5Yy4jQpK09qTcAhJYVAIS6CgBCXTUpgJMmPJN6 Iwf0NGlrT+oNAKFlBQChrgKAUFdNCuCkCc+k3sgBW3pPWu11mqQEwM+fAtb1tExrT+E9DYBf+i4C 0dqreANAf0tTWs/qPROAxhj8gaC46gL40YQjBGWo2hAMQXcEAKGuqjYNA0F3VG0iGoLuCABCXQUA oa4CgFBXAUCoq+oBKHZOvBsL+W+TSQLWktWW8t7sZNwZ73q3Y0nNCu7GQv4fKWvJakt5H3BIuHPe DwfwIwqgFmoWoSbZr6yKuLPeNQGUm5fe6lzf//AVsf6crS3zdyPgfUDyEWiV08v2rgig2K0Je2vX 9zeOolwvNZP3kZ9JuJ9Dgn0wxx+Cz+y1vv9+h9BMw6Sst2AOaBxG62COD6BkMqUnhETSWxxA/2CO Pw3zObMpwXMcAev5pmGclq7qfg427sHERDTUVQAQ6ioACHUVAIS6CgBCXQUAoa4CgFBXAUCoqwAg 1FUAEOoqAFhJwctW5kKxe9bmFAAs0/mVOyGu7GUg0BQALFUCTwCQFwAs1XGH23kzsXZvJLluxfyY 76GvAGCpTKroO1zdmzABoCEAWCoSQKsLdDs+AGgIAJbKBvAahv0QdICEAGCpGAC9JPAsBICmAGCp qOTPvZvdPDMBf5YAINRVABDqKgAIdRUAhLoKAEJd9R926SgS8EvHjgAAAABJRU5ErkJggg== --_005_E7175A8E3DC14048A7D3020E0338C1FA124A5FE4xmbalnx13ciscoc_-- From xiaoqzhu@cisco.com Mon Aug 5 12:27:42 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 52E8021F8E8E for ; Mon, 5 Aug 2013 12:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXjvbXry9l1G for ; Mon, 5 Aug 2013 12:27:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB2F21F9DA1 for ; Mon, 5 Aug 2013 12:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1620; q=dns/txt; s=iport; t=1375730857; x=1376940457; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=95VfWcEnKRKWlaRwQUMX4ECg4oo0/BY87FFqtq0wnT4=; b=KQFIjiSMGx0RTb8a1ztmdEIRn8UDhaCSpI0vbu7Gvo978UDcReIJMVhl rWAJs27SDVl+mpFbdhU9CRXbPuAFEmDpka+imdeDLFn8SYsmVrXnQqoUo sXluKZ8jzfTRjO9BUdD5Pf3KKJuf/RBde4XempJQtfwQuyH9xHtZN1x9I A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAJ77/1GtJXHB/2dsb2JhbABBFwOCZSE1UL51gSEWdIIkAQEBAwE6PwUJAgIBCBgKFBAWHCUCBAoEBQiIAgYBCzK0eASPYgIhEAcRgwh0A5kKkCWDF4Iq X-IronPort-AV: E=Sophos;i="4.89,820,1367971200"; d="scan'208";a="243719597" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 05 Aug 2013 19:27:37 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r75JRawo003290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 19:27:36 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 14:27:35 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: Luca De Cicco Thread-Topic: [rmcat] NADA question that didn't get asked due to time Thread-Index: AQHOjxSNiwjkFKp57kOCzyNIknoAl5mFFoUAgAJC2wA= Date: Mon, 5 Aug 2013 19:27:16 +0000 Message-ID: References: <51FAA413.8060403@jesup.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.12.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Randell Jesup , rmcat WG , "Rong Pan \(ropan\)" Subject: Re: [rmcat] NADA question that didn't get asked due to time 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, 05 Aug 2013 19:27:42 -0000 Dear Luca,=20 Please find our answer as below.=20 Thanks, Xiaoqing On Aug 4, 2013, at 3:55 AM, Luca De Cicco wrote: > Dear all, >=20 > I got a question about the slides: >=20 > what's the bottleneck buffer size used in the simulations? The bottleneck buffer size is set to 100 packets with a typical packet size= of 1000 bytes. Over a 4Mbps link, that corresponds to 200ms of delay when = the queue is full.=20 >=20 > Have you checked the performance of a NADA flow with a single TCP flow > using a drop tail queue with different buffer sizes? We only have results for NADA against TCP over Droptail with the current bu= ffer size (slide #15 in our presentation). =20 Haven't tried with varying the buffer size -- thanks for the suggestion.=20 >=20 > Best, > -- > Luca De Cicco, PhD, Eng. > Politecnico di Bari > Dipartimento di Elettrotecnica ed Elettronica > Via Re David, 200 - Bari - ITALY > Office: +39 080 596 3851 > http://c3lab.poliba.it/index.php/LDC >=20 >=20 > On Thu, Aug 1, 2013 at 8:08 PM, Randell Jesup wr= ote: >> This jabber question didn't get to be echoed due to time (about NADA): >>=20 >>=20 >> When competing against TCP with droptail, do you kinow why the first NAD= A >> flow doesn't change when a second was added? >>=20 >> Was there some floor that stopped it from driving into the ground? What = are >> the dynamics of the resultant steady-state transfer characteristics betw= een >> TCP and NADA flows? Have you tried two TCP flows? >>=20 >> -- >> Randell Jesup >> randell-ietf@jesup.org >>=20 From harald@alvestrand.no Mon Aug 19 05:08:02 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 67C5511E8227 for ; Mon, 19 Aug 2013 05:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XOzWllmjB7w for ; Mon, 19 Aug 2013 05:07:57 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 628CF11E822A for ; Mon, 19 Aug 2013 05:07:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6703339E453 for ; Mon, 19 Aug 2013 14:07:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER8LGaRdXWr1 for ; Mon, 19 Aug 2013 14:07:31 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 480E739E091 for ; Mon, 19 Aug 2013 14:07:31 +0200 (CEST) Message-ID: <52120A82.705@alvestrand.no> Date: Mon, 19 Aug 2013 14:07:30 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: rmcat@ietf.org References: <20130819120402.5703.16798.idtracker@ietfa.amsl.com> In-Reply-To: <20130819120402.5703.16798.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130819120402.5703.16798.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010508060002010603030808" Subject: [rmcat] Fwd: New Version Notification for draft-alvestrand-rmcat-congestion-01.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 12:08:02 -0000 This is a multi-part message in MIME format. --------------010508060002010603030808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Just a heads-up that this draft will remain in the archives for another 6 months (unless updated). There are no technical changes, but we thought it would not be good to let it expire. -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rmcat-congestion-01.txt Date: Mon, 19 Aug 2013 05:04:02 -0700 From: internet-drafts@ietf.org To: Stefan Holmer , Harald Alvestrand , Henrik Lundin <>, Harald T.Alvestrand , Henrik Lundin A new version of I-D, draft-alvestrand-rmcat-congestion-01.txt has been successfully submitted by Henrik Lundin and posted to the IETF repository. Filename: draft-alvestrand-rmcat-congestion Revision: 01 Title: A Google Congestion Control Algorithm for Real-Time Communication Creation date: 2013-08-19 Group: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-alvestrand-rmcat-congestion-01.txt Status: http://datatracker.ietf.org/doc/draft-alvestrand-rmcat-congestion Htmlized: http://tools.ietf.org/html/draft-alvestrand-rmcat-congestion-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-alvestrand-rmcat-congestion-01 Abstract: This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published as an input document to the RMCAT working group on congestion control for media streams. The mailing list of that WG is rmcat@ietf.org. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------010508060002010603030808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Just a heads-up that this draft will remain in the archives for another 6 months (unless updated).

There are no technical changes, but we thought it would not be good to let it expire.


-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rmcat-congestion-01.txt
Date: Mon, 19 Aug 2013 05:04:02 -0700
From: internet-drafts@ietf.org
To: Stefan Holmer <holmer@google.com>, Harald Alvestrand <harald@alvestrand.no>, Henrik Lundin <>, Harald T.Alvestrand <harald@alvestrand.no>, Henrik Lundin <None@ietfa.amsl.com> 


A new version of I-D, draft-alvestrand-rmcat-congestion-01.txt
has been successfully submitted by Henrik Lundin and posted to the
IETF repository.

Filename:	 draft-alvestrand-rmcat-congestion
Revision:	 01
Title:		 A Google Congestion Control Algorithm for Real-Time Communication
Creation date:	 2013-08-19
Group:		 Individual Submission
Number of pages: 18
URL:             http://www.ietf.org/internet-drafts/draft-alvestrand-rmcat-congestion-01.txt
Status:          http://datatracker.ietf.org/doc/draft-alvestrand-rmcat-congestion
Htmlized:        http://tools.ietf.org/html/draft-alvestrand-rmcat-congestion-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-alvestrand-rmcat-congestion-01

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

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


                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------010508060002010603030808--