From fuji246@gmail.com Mon Mar 4 20:41: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 1985321F86E6 for ; Mon, 4 Mar 2013 20:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-4dffGrhxXl for ; Mon, 4 Mar 2013 20:41:58 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id BDDAE21F86E3 for ; Mon, 4 Mar 2013 20:41:57 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id m4so4532219lbo.28 for ; Mon, 04 Mar 2013 20:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lbxBL33V8BtWDNuh5kdgN57A1+to6nEb9DRKhhHRvCI=; b=sXS2i7vUTnwDY2lAyXODTrKHuWIWSRhbdf980M1OZI3lvpTChwmIKATW5Z519HyPfz g3BjUHCVsgQO3+V4JJnYBWHGq0hSlcLQ/idmgEZpPRwXaF0UXKgauzVCi8uCY5NKiIcw hEWagiKZxJaE1PJgT41rP6OA5xG0Fem9l6ivZwMyHYbMThz1/1hiQp19dq1ww9cNrTEu drB+L1btWhRXTC8+YZLBAcyujibRNkBL0c5wi1rk8bWcMhTw8pfnjsXafbT0GEGcZ+Kf zuUugCAYYxyKiAwM+dJCT+0p10JMvW+t4KCixwR86HAJ7Bpe1cnSo/N5MtrJsZpHM0cr CFzA== MIME-Version: 1.0 X-Received: by 10.112.88.10 with SMTP id bc10mr5365950lbb.70.1362458516663; Mon, 04 Mar 2013 20:41:56 -0800 (PST) Received: by 10.114.25.231 with HTTP; Mon, 4 Mar 2013 20:41:56 -0800 (PST) In-Reply-To: <8471CA16-DC31-4AFD-ABEF-558ABB79AE31@csperkins.org> References: <20130218232842.19535.91395.idtracker@ietfa.amsl.com> <8471CA16-DC31-4AFD-ABEF-558ABB79AE31@csperkins.org> Date: Tue, 5 Mar 2013 12:41:56 +0800 Message-ID: From: Fu Jiantao To: Colin Perkins Content-Type: multipart/alternative; boundary=f46d04016975e839cf04d7261766 Cc: rmcat@ietf.org Subject: Re: [rmcat] Fwd: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 04:41:59 -0000 --f46d04016975e839cf04d7261766 Content-Type: text/plain; charset=ISO-8859-1 Hi Colin, I've got the following comments: 1."there is little point in providing feedback more often than the codec can adapt", i think there is no need to send those overlimits data onto the network if we've got feedback that the network is congested, so i think it make sense if there is traffic shaper on the sender side, those overlimit packets can buffered and dropped at the sender side, rather than sending them to the network which affects other traffics. 2. How about ack in a given interval, this can be treat as variant of per-frame ack(several frames per ack). This is another kind which has less load than per-frame ack. 3. There can be adaptive feedback which feedback when there is need to do so, for example, when the given interval is not enough for the adaption(the queuing delay goes large very fast), the feedback can be accelerated in this case. 4. The feedback strategy has some relationship with sender-based/receiver-based, is this in the scope of this draft? Thanks Jeromy 2013/2/26 Colin Perkins > I submitted the following draft that talks about the types of congestion > control feedback that can be sent using RTCP as is currently specified, and > their suitability for implementing congestion control for unicast > multimedia applications. In particular, it talks about the rate of > congestion feedback that can be supported. > > Comments are welcome. I'm also happy to present this in Orlando, if the > chairs think it useful. > > Colin > > > > > Begin forwarded message: > > From: internet-drafts@ietf.org > > Subject: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-00.txt > > Date: 18 February 2013 23:28:42 GMT > > To: i-d-announce@ietf.org > > Reply-To: internet-drafts@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : On the Use of RTP Control Protocol (RTCP) > Feedback for Unicast Multimedia Congestion Control > > Author(s) : Colin Perkins > > Filename : draft-perkins-rmcat-rtp-cc-feedback-00.txt > > Pages : 8 > > Date : 2013-02-18 > > > > Abstract: > > This memo discusses the types of congestion control feedback that it > > is possible to send using the RTP Control Protocol (RTCP), and their > > suitability of use in implementing congestion control for unicast > > multimedia applications. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-perkins-rmcat-rtp-cc-feedback > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-perkins-rmcat-rtp-cc-feedback-00 > > > -- > Colin Perkins > http://csperkins.org/ > > > > --f46d04016975e839cf04d7261766 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Colin,

=A0=A0 I&#= 39;ve got the following comments:

=A0 1."there is little point in providing feedback more often than the codec can adapt", i think=20 there is no need to send those overlimits data onto the network if we'v= e got feedback that the network is congested, so i think it make sense if there is traffic shaper on the sender side, those overlimit packets can buffered and dropped at the sender side, rather than sending them to=20 the network which affects other traffics.

=A0 2. How about ack in a given interval, this can be treat as=20 variant of per-frame ack(several frames per ack). This is another kind=20 which has less load than per-frame ack.

=A0 3. There can be=20 adaptive feedback which feedback when there is need to do so, for=20 example, when the given interval is not enough for the adaption(the=20 queuing delay goes large very fast), the feedback can be accelerated in=20 this case.

=A0 4. The feedback strategy has some relationship with sender-ba= sed/receiver-based, is this in the scope of this draft?


Th= anks

Jeromy


2013/2/26 Colin Perkins <csp@csperkins.org>
I submitted the following draft that talks about the types of congestion co= ntrol feedback that can be sent using RTCP as is currently specified, and t= heir suitability for implementing congestion control for unicast multimedia= applications. In particular, it talks about the rate of congestion feedbac= k that can be supported.

Comments are welcome. I'm also happy to present this in Orlando, if the= chairs think it useful.

Colin




Begin forwarded message:
> From: internet-drafts@ietf= .org
> Subject: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-00.txt
> Date: 18 February 2013 23:28:42 GMT
> To: i-d-announce@ietf.org=
> Reply-To: internet-drafts@= ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : On the Use of RTP Control Prot= ocol (RTCP) Feedback for Unicast Multimedia Congestion Control
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Colin Perkins
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-perkins-rmcat-rtp-cc-feedb= ack-00.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-18
>
> Abstract:
> This memo discusses the types of congestion control feedback that it > is possible to send using the RTP Control Protocol (RTCP), and their > suitability of use in implementing congestion control for unicast
> multimedia applications.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-perkins= -rmcat-rtp-cc-feedback
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-perkins-rmcat-rt= p-cc-feedback-00


--
Colin Perkins
http://csperkins.org/




--f46d04016975e839cf04d7261766-- From fuji246@gmail.com Tue Mar 5 01:17:51 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 8A4C321F887F for ; Tue, 5 Mar 2013 01:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4zzCSKutG0HC for ; Tue, 5 Mar 2013 01:17:50 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3D03E21F8873 for ; Tue, 5 Mar 2013 01:17:50 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id fq13so5812099lab.7 for ; Tue, 05 Mar 2013 01:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=tQ1ojEFcg1za15EmfxEHeULzDRtAMy/nfoP/dpE+CP4=; b=cGYCUpd3uGIyWOic0iQGqvE5e2jpYHzYaUU04Yn/+TZA/qKTLcwwxiREtHQNhzyJUB l30qR0q+VJBvn8GQYz73vvBF1Li7UWM+skNREiOCZOTAA4fgQD+/tYSdN7W1hDTquwIP heE2mD1Rlov6wOzyz4phP9E95+vUraFd77m11OcCW7PAleJfOpzGklzJpEUlU7RBBX34 3oWwzHkYVXRAGhiOZLNd/YI3071QUEh4ND115tU6dSJSARpawxWRiadT7GgWVCAAjWWE la6FWLgfEGq5tXt8DlqRB5LL8FxDNWrv1GJu1BsEjW3stD67KLTwzKOWG9PQR2sBkssV CUrw== MIME-Version: 1.0 X-Received: by 10.152.110.6 with SMTP id hw6mr20873907lab.43.1362475069172; Tue, 05 Mar 2013 01:17:49 -0800 (PST) Received: by 10.114.25.231 with HTTP; Tue, 5 Mar 2013 01:17:49 -0800 (PST) In-Reply-To: <023D88F2-1A6E-47C2-91B2-8B56DEEC70B1@g11.org.uk> References: <023D88F2-1A6E-47C2-91B2-8B56DEEC70B1@g11.org.uk> Date: Tue, 5 Mar 2013 17:17:49 +0800 Message-ID: From: Fu Jiantao To: rmcat WG Content-Type: multipart/alternative; boundary=bcaec54b48d083754e04d729f2c2 Subject: Re: [rmcat] requirements (was Re: time to get active) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:17:51 -0000 --bcaec54b48d083754e04d729f2c2 Content-Type: text/plain; charset=ISO-8859-1 Another concern for the requirement There maybe sometimes UDP is blocked, and ICE may use TCP connection(see http://tools.ietf.org/html/rfc4571 for how to use rtp/rtcp on TCP), this is a practical user scenario, is there any consideration for this case? I'm not sure whether this is in the scope of rmcat. Thanks! Jeromy 2013/2/28 ken carlberg > well, perhaps I can get the ball rolling in terms of a headache to chew on > :-) > > The second requirement in draft-jesup-rmcat-reqs-01.txt is... > > 2. The algorithm must be fair to other flows, both realtime flows > (such as other instances of itself), and TCP flows, both long- > lived and bursts such as the traffic generated by a typical web > browsing session. Note that 'fair' is a rather hard-to-define > term. > > A. The algorithm must not overreact to short-term bursts (such > as web-browsing) which can quickly saturate a local- > bottleneck router or link, but also clear quickly, and > should recover quickly when the burst ends. > > B. We will need make some evaluation of fairness, but deciding > what is "fair" is a tough question and likely to be > partially subjective, but we should specify some of the > inputs needed in order to select among algorithms and > tunings presented as options. > > however, the document does not have a definition of the term "fair" or > "fairness". And while the document points us to terminology in another > draft (draft-ietf-rtcweb-overview-06.txt), this other draft doesn't even > mention "fair" or fairness". I think one nit is that the RMCAT > requirements draft needs its own terminology section instead of pointing to > another draft. > > And more importantly, I think we need to bite the bullet and decide what > is "fair" / "fairness". It just doesn't seem possible for us to say that > the algorithms *must* be fair, but then punt in defining what is (or > perhaps, what is not) fair. And I'm definitely not meaning to beat up on > the author, but rather ourselves. > > As a starting point, and in the context of real time apps, I don't think > we need to be fair to a continual series of parallel short transaction > flows. Rather, I would prefer to be fair, or focus our attention, to > longer transaction flows. > > thoughts? Have I missed something? > > -ken > > > > On Feb 27, 2013, at 1:37 PM, "Eggert, Lars" wrote: > > > On Feb 27, 2013, at 19:35, Matt Mathis wrote: > >> Did we perhaps address all of the hard problems in the charter process, > so > >> now there is nothing to controversial to chew on? > > > > I wish... > > > > Lars > > --bcaec54b48d083754e04d729f2c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Another concern for the requirement

There maybe sometimes UDP is blocked, and ICE may use TCP connection(see <= a href=3D"http://tools.ietf.org/html/rfc4571">http://tools.ietf.org/html/rf= c4571 for how to use rtp/rtcp on TCP), this is a practical user scenari= o, is there any consideration for this case? I'm not sure whether this = is in the scope of rmcat.

Thanks!

Jeromy


2013/2/28 ken carlberg = <carlberg@g11.org.uk>
well, perhaps I can get the ball rolling in = terms of a headache to chew on :-)

The second requirement in draft-jesup-rmcat-reqs-01.txt is...

=A0 2. =A0 The algorithm must be fair to other flows, both realtime flows =A0 =A0 =A0 =A0 (such as other instances of itself), and TCP flows, both lo= ng-
=A0 =A0 =A0 =A0 lived and bursts such as the traffic generated by a typical= web
=A0 =A0 =A0 =A0 browsing session. =A0Note that 'fair' is a rather h= ard-to-define
=A0 =A0 =A0 =A0 term.

=A0 =A0 =A0 =A0 A. =A0The algorithm must not overreact to short-term bursts= (such
=A0 =A0 =A0 =A0 =A0 =A0 as web-browsing) which can quickly saturate a local= -
=A0 =A0 =A0 =A0 =A0 =A0 bottleneck router or link, but also clear quickly, = and
=A0 =A0 =A0 =A0 =A0 =A0 should recover quickly when the burst ends.

=A0 =A0 =A0 =A0 B. =A0We will need make some evaluation of fairness, but de= ciding
=A0 =A0 =A0 =A0 =A0 =A0 what is "fair" is a tough question and li= kely to be
=A0 =A0 =A0 =A0 =A0 =A0 partially subjective, but we should specify some of= the
=A0 =A0 =A0 =A0 =A0 =A0 inputs needed in order to select among algorithms a= nd
=A0 =A0 =A0 =A0 =A0 =A0 tunings presented as options.

however, the document does not have a definition of the term "fair&quo= t; or "fairness". =A0And while the document points us to terminol= ogy in another draft (draft-ietf-rtcweb-overview-06.txt), this other draft = doesn't even mention "fair" or fairness". =A0I think one= nit is that the RMCAT requirements draft needs its own terminology section= instead of pointing to another draft.

And more importantly, I think we need to bite the bullet and decide what is= "fair" / "fairness". =A0It just doesn't seem possi= ble for us to say that the algorithms *must* be fair, but then punt in defi= ning what is (or perhaps, what is not) fair. =A0And I'm definitely not = meaning to beat up on the author, but rather ourselves.

As a starting point, and in the context of real time apps, I don't thin= k we need to be fair to a continual series of parallel short transaction fl= ows. =A0Rather, I would prefer to be fair, or focus our attention, to longe= r transaction flows.

thoughts? =A0Have I missed something?

-ken



On Feb 27, 2013, at 1:37 PM, "Eggert, Lars" <lars@netapp.com> wrote:

> On Feb 27, 2013, at 19:35, Matt Mathis <mattmathis@google.com> wrote:
>> Did we perhaps address all of the hard problems in the charter pro= cess, so
>> now there is nothing to controversial to chew on?
>
> I wish...
>
> Lars


--bcaec54b48d083754e04d729f2c2-- From zaheduzzaman.sarker@ericsson.com Tue Mar 5 05:13:25 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D461F21F8915 for ; Tue, 5 Mar 2013 05:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 CDLX9RFWPoIj for ; Tue, 5 Mar 2013 05:13:25 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 451FB21F8904 for ; Tue, 5 Mar 2013 05:13:24 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-4c-5135ef73f99f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 69.E0.19728.37FE5315; Tue, 5 Mar 2013 14:13:23 +0100 (CET) Received: from [150.132.141.113] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 5 Mar 2013 14:13:22 +0100 Message-ID: <5135EF72.3090007@ericsson.com> Date: Tue, 5 Mar 2013 14:13:22 +0100 From: Zaheduzzaman Sarker Organization: Ericsson AB User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rmcat@ietf.org, randell-ietf@jesup.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJJMWRmVeSWpSXmKPExsUyM+JvjW7xe9NAgyO35CzObsuyWH3zA5sD k8eSJT+ZPD4sX8cWwBTFZZOSmpNZllqkb5fAlXH4/2v2gr+KFfsb/rA0MPZJdzFyckgImEgc /z2BHcIWk7hwbz1bFyMXh5DASUaJrxtOsIAkhATWMEq82m0IYvMKaEs0T+4Ai7MIqEgsf/SI qYuRg4NNwEbi8WI/kDC/gKTEhobdzCC2qECUxPurTcwQrYISJ2c+AWsVEdCS2HpyJxuILSxg JrHo0W6wOLOArcSFOdehbHmJ5q2zmUHGCwnoSnS9jJvAyD8LyaRZSDpmIelYwMi8ipE9NzEz J73caBMjMLgObvmtuoPxzjmRQ4zSHCxK4rzhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBK NTAK/hcIFrq70CBgeXZiTWNet0FXSF4aM2/rLYbSlUKq0xe1Hc6feclqkfH8qPPnz/9LyPCW jF++6fU2T+39AswuD4/rzj29ed5VX26jWVLnNThO7ElP/PGx5iTrLiP2TVHcE/db2fT7cdWy To5Kv8ZS+fPlrqcFMSc+vuRKU+8oOvB9Q5WQzHwlluKMREMt5qLiRACbJ7qj/AEAAA== Subject: [rmcat] Initial comments on draft-jesup-rmcat-reqs-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: Tue, 05 Mar 2013 13:13:25 -0000 Hi, Thanks to the author for updating the doc. This version has clarified couple of issues but still I think there is lot left to do for the whole group. My thoughts/comments below- General : # I think it will be very good if the document includes some explanation text on why one particular requirement is listed. Those who are involved in the discussion from the very beginning perhaps understands the reasons but still I think it will be nice thing to add (to reduce latecomer effect :-)). # Now, we will have to decide on the "fairness" (everybody's favorite, right?). Yes, it is difficult and yes, we can spend huge amount of time discussing on it. However, IMHO the discussion should short and we should just pick one that is available or define something ( for example, something that Harald had mentioned in one of IAB CC workshop paper). # This draft should somewhere mentioned the circuit breaker draft. I would even say that it should be a requirement on the RMCAT Congestion Control (CC) algorithm that it works "within the envelope" of circuit breaker. # The applications that will use RMCAT solution for congestion control may need to have a way to configure certain behavior related to the service it provides. For example, the application may like to set the MIN and MAX bitrate rate, certain behavior if the MIN bitrate is not sustainable even if after adapting rate etc. How would we like to realize this? One way is to , set the MAX and MIN rate as configuration to the adaptation algorithm so that if it suggest , for example , bitrate to the application then it never goes above MAX and below MIN. Another way is to not set any limit to the CC algorithm and let it send feedback to the application on what will be the sustainable bitrate at a certain time and the application decides what to do with that feedback. The first one is perhaps the most commonly implemented approach while the second options gives lot of power to the application. Depending what we think is the right way to realize this, puts some requirements on the RMCAT CC algorithm. Requirement 1 touches upon it but it also created confusion in my mind and I think we can we a better job there. Requirement Specific: * Req 4: it says "Extra information could be added to the packets to provide more detailed information on actual send times (as opposed to sampling times), but should not be required." I think it can say something like this "Extra information could be added to the packets to provide more detailed information to improve the performance of the algorithm but the algorithm should justify the additional information added". Then an algorithm can use, for example, actual send times instead of sampling times or something else to improve its performance or use something else. * Req 7: this is an important requirements. Very ofter I find papers where they kind of forget about the congestion in feedback channel. * Req 8: This requirement focuses on long-lived TCP flows but I think it should focus on flows with known congestion control algorithm. in the fast phase, RMCAT will publish (hopefully) more than one experimental CC algorithms and I think it is important to look how one of the candidate is behaving when competing with other candidate. But if we want to focus on the behavior against competing TCP flows then the requirement should say "It should attempt to avoid bandwidth 'collapse' when facing a saturating TCP flow or flows but it should not starve TCP flow (should not grab more than necessary)" or something along this theme. And I would also like to get rid of the prefix terms "short-lived" and "Long-lived" TCP flow as I think from a congestion controller point of view it is hardly possible to distinguish between them unless we have some explicit information from the shared bottleneck. So far, this is what i think. BR -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies Laboratoriegränd 11 97128 Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ================================================== From michawe@ifi.uio.no Tue Mar 5 06:45:17 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 3E76621F8871 for ; Tue, 5 Mar 2013 06:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.199 X-Spam-Level: X-Spam-Status: No, score=-98.199 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_38=0.6, MANGLED_TOOL=2.3, 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 rBV4WkSdEXUL for ; Tue, 5 Mar 2013 06:45:15 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 89F3B21F87D2 for ; Tue, 5 Mar 2013 06:45:14 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UCt7B-0007dB-BK for rmcat@ietf.org; Tue, 05 Mar 2013 15:45:13 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UCt79-00027S-P8 for rmcat@ietf.org; Tue, 05 Mar 2013 15:45:13 +0100 From: Michael Welzl Content-Type: multipart/mixed; boundary="Apple-Mail=_25F391B5-E09C-487F-8FB1-424FA85B2320" Date: Tue, 5 Mar 2013 15:45:11 +0100 Message-Id: To: "rmcat@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 1 sum msgs/h 1 total rcpts 2510 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.552, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 72ADF401E50422CB838EE4FBA965A605C9F4B919 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -55 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1016 max/h 12 blacklist 0 greylist 0 ratelimit 0 Subject: [rmcat] preview of -01 update to draft-welzl-rmcat-coupled-cc X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 14:45:17 -0000 --Apple-Mail=_25F391B5-E09C-487F-8FB1-424FA85B2320 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, We (yes, now two authors) have made an update to the coupled-cc draft, = attached, in which we have improved the example algorithm a bit. If you have already given this document a high-level read, don't worry = about it. If you're planning to go through the algorithm step by step = and follow our example, it's better if you use this newer version. Thanks, cheers, Michael --Apple-Mail=_25F391B5-E09C-487F-8FB1-424FA85B2320 Content-Disposition: attachment; filename=draft-welzl-rmcat-coupled-cc-01.txt Content-Type: text/plain; x-unix-mode=0700; name="draft-welzl-rmcat-coupled-cc-01.txt" Content-Transfer-Encoding: quoted-printable RTP Media Congestion Avoidance M. Welzl Techniques (rmcat) S. Islam Internet-Draft University of Oslo Intended status: Experimental March 5, 2013 Expires: September 6, 2013 Coupled congestion control for RTP media draft-welzl-rmcat-coupled-cc-01 Abstract When multiple congestion controlled RTP sessions traverse the same network bottleneck, it can be beneficial to combine their controls such that the total on-the-wire behavior is improved. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Welzl & Islam Expires September 6, 2013 [Page 1] =0C Internet-Draft Coupled congestion control for RTP media March 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architectural overview . . . . . . . . . . . . . . . . . . . . 5 5. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. FSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3.1. Example algorithm . . . . . . . . . . . . . . . . . . 7 5.3.2. Example operation . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Changes from -00 to -01 . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Welzl & Islam Expires September 6, 2013 [Page 2] =0C Internet-Draft Coupled congestion control for RTP media March 2013 1. Introduction When there is enough data to send, a congestion controller must increase its sending rate until the path's capacity has been reached; depending on the controller, sometimes the rate is increased further, until packets are ECN-marked or dropped. This process inevitably creates undesirable queuing delay -- an effect that is amplified when multiple congestion controlled connections traverse the same network bottleneck. When such connections originate from the same host, it would therefore be ideal to use only one single sender-side congestion controller which determines the overall allowed sending rate, and then use a local scheduler to assign a proportion of this rate to each RTP session. This way, priorities could also be implemented quite easily, as a function of the scheduler; honoring user-specified priorities is, for example, required by rtcweb [rtcweb-usecases]. The Congestion Manager (CM) [RFC3124] provides a single congestion controller with a scheduling function just as described above. It is hard to implement because it requires an additional congestion controller and removes all per-connection congestion control functionality, which is quite a significant change to existing RTP based applications. This document presents a method that is easier to implement than the CM and also requires less significant changes to existing RTP based applications. It attempts to roughly approximate the CM behavior by sharing information between existing congestion controllers, akin to "Ensemble Sharing" in [RFC2140]. 2. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Available Bandwidth: The available bandwidth is the nominal link capacity minus the amount of traffic that traversed the link during a certain time interval, divided by that time interval. Bottleneck: The first link with the smallest available bandwidth along the path between a sender and receiver. Flow: A flow is the entity that congestion control is operating on. It could, for example, be a transport layer connection, an RTP session, or a subsession that is multiplexed onto a single RTP Welzl & Islam Expires September 6, 2013 [Page 3] =0C Internet-Draft Coupled congestion control for RTP media March 2013 session together with other subsessions. Flow Group Identifier (FGI): A unique identifier for each subset of flows that is limited by a common bottleneck. Flow State Exchange (FSE): The entity that maintains information that is exchanged between flows. Flow Group (FG): A group of flows having the same FGI. Shared Bottleneck Detection (SBD): The entity that determines which flows traverse the same bottleneck in the network, or the process of doing so. 3. Limitations Sender-side only: Coupled congestion control as described here only operates inside a single host on the sender side. This is because, irrespective of where the major decisions for congestion control are taken, the sender of a flow needs to eventually decide the transmission rate. Additionally, the necessary information about how much data an application can currently send on a flow is typically only available at the sender side, making the sender an obvious choice for placement of the elements and mechanisms described here. It is recognized that flows that have different senders but the same receiver, or different senders and different receivers can also share a bottleneck; such scenarios have been omitted for simplicity, and could be incorporated in future versions of this document. Note that limiting the flows on which coupled congestion control operates merely limits the benefits derived from the mechanism. Shared bottlenecks do not change quickly: As per the definition above, a bottleneck depends on cross traffic, and since such traffic can heavily fluctuate, bottlenecks can change at a high frequency (e.g., there can be oscillation between two or more links). This means that, when flows are partially routed along different paths, they may quickly change between sharing and not sharing a bottleneck. For simplicity, here it is assumed that a shared bottleneck is valid for a time interval that is significantly longer than the interval at which congestion controllers operate. Note that, Welzl & Islam Expires September 6, 2013 [Page 4] =0C Internet-Draft Coupled congestion control for RTP media March 2013 for the only SBD mechanism defined in this document (multiplexing on the same five-tuple), the notion of a shared bottleneck stays correct even in the presence of fast traffic fluctuations: since all flows that are assumed to share a bottleneck are routed in the same way, if the bottleneck changes, it will still be shared. 4. Architectural overview Figure 1 shows the elements of the architecture for coupled congestion control: the Flow State Exchange (FSE), Shared Bottleneck Detection (SBD) and Flows. The FSE is a storage element. It is passive in that it does not actively initiate communication with flows and the SBD; its only active role is internal state maintenance (e.g., an implementation could use soft state to remove a flow's data after long periods of inactivity). Every time a flow's congestion control mechanism would normally update its sending rate, the flow instead updates information in the FSE and performs a query on the FSE, leading to a sending rate that can be different from what the congestion controller originally determined. Using information about/from the currently active flows, SBD updates the FSE with the correct Flow State Identifiers (FSIs). ------- <--- Flow 1 | FSE | <--- Flow 2 .. ------- <--- .. Flow N ^ | | ------- | | SBD | <-------| ------- Figure 1: Coupled congestion control architecture Since everything shown in Figure 1 is assumed to operate on a single host (the sender) only, this document only describes aspects that have an influence on the resulting on-the-wire behavior. It does, for instance, not define how many bits must be used to represent FSIs, or in which way the entities communicate. Implementations can take various forms: for instance, all the elements in the figure could be implemented within a single application, thereby operating on flows generated by that application only. Another alternative could be to implement both the FSE and SBD together in a separate process which different applications communicate with via some form Welzl & Islam Expires September 6, 2013 [Page 5] =0C Internet-Draft Coupled congestion control for RTP media March 2013 of Inter-Process Communication (IPC). Such an implementation would extend the scope to flows generated by multiple applications. The FSE and SBD could also be included in the Operating System kernel. 5. Roles This section gives an overview of the roles of the elements of coupled congestion control, and provides an example of how coupled congestion control can operate. 5.1. SBD SBD uses knowledge about the flows to determine which flows belong in the same Flow Group (FG), and assigns FGIs accordingly. This knowledge can be derived from measurements, by considering correlations among measured delay and loss as an indication of a shared bottleneck, or it can be based on the simple assumption that packets sharing the same five-tuple (IP source and destination address, protocol, and transport layer port number pair) are typically routed in the same way. The latter method is the only one specified in this document: SBD MUST consider all flows that use the same five-tuple to belong to the same FG. This classification applies to certain tunnels, or RTP flows that are multiplexed over one transport (cf. [transport-multiplex]). In one way or another, such multiplexing will probably be recommended for use with rtcweb [rtcweb-rtp-usage]. 5.2. FSE The FSE contains a list of all flows that have registered with it. For each flow, it stores: o a unique flow number to identify the flow o the FGI of the FG that it belongs to (based on the definitions in this document, a flow has only one bottleneck, and can therefore be in only one FG) o a priority P, which here is assumed to be represented as a floating point number in the range from 0.1 (unimportant) to 1 (very important). A negative value is used to indicate that a flow has terminated. o The calculated rate CR, i.e. the rate that was most recently calculated by the flow's congestion controller. Welzl & Islam Expires September 6, 2013 [Page 6] =0C Internet-Draft Coupled congestion control for RTP media March 2013 o The desired rate DR. This can be smaller than the calculated rate if the application feeding into the flow has less data to send than the congestion controller would allow. In case of a greedy flow, DR must be set to CR. o S_CR, the sum of the calculated rates of all flows in the same FG (including the flow itself), as seen by the flow during its last rate update. The information listed here is enough to implement the sample flow algorithm given below. FSE implementations could easily be extended to store, e.g., a flow's current sending rate for statistics gathering or future potential optimizations. 5.3. Flows Flows register themselves with SBD and FSE when they start, deregister from the FSE when they stop, and carry out an UPDATE function call every time their congestion controller calculates a new sending rate. Via UPDATE, they provide the newly calculated rate and the desired rate (less than the calculated rate in case of non-greedy flows, the same otherwise). UPDATE returns a rate that should be used instead of the rate that the congestion controller has determined. Below, an example algorithm is described. While other algorithms could be used instead, the same algorithm must be applied to all flows. The way the algorithm is described here, the operations are carried out by the flows, but they are the same for all flows. This means that the algorithm could, for example, be implemented in a library that provides registration, deregistration functions and the UPDATE function. To minimize the number of changes to existing applications, one could, however, also embed this functionality in the FSE element. 5.3.1. Example algorithm (1) When a flow starts, it registers itself with SBD and the FSE. CR and DR are initialized with the congestion controller's initial rate. SBD will assign the correct FGI. When a flow is assigned an FGI, its S_CR is initialized to be the sum of the calculated rates of all the flows in its FG. (2) When a flow stops, it sets its DR to 0 and negates P. Welzl & Islam Expires September 6, 2013 [Page 7] =0C Internet-Draft Coupled congestion control for RTP media March 2013 (3) Every time the flow's congestion controller determines a new sending rate new_CR, assuming the flow's new desired rate new_DR to be "infinity" in case of a greedy flow with an unknown maximum rate, the flow calls UPDATE, which carries out the following tasks: (a) For all the flows in its FG (including itself), it calculates the sum of all the absolute values of all priorities, S_P, and the sum of all the calculated rates, new_S_CR. (b) DELTA =3D new_CR-CR. CR is updated if DELTA is negative, = or if new_S_CR is smaller or equal to the flow's stored S_CR value. This restriction on updating CR ensures that only one flow can make S_CR increase at a time. To further avoid increasing S_CR, a flow tries to "take" bandwidth from terminated flows when it increases its rate: if DELTA is positive, for all other flows i in its FG, it checks if P(i) is negative (i.e. the flow has terminated). It then reduces the CR(i) values of terminated flows such that these values do not become negative and the total amount of subtraction does not exceed DELTA. The entry of a flow i is removed from the FSE and S_P is updated if CR(i) =3D 0. (c) It updates new_S_CR using its own updated CR, and updates S_CR with new_S_CR. (d) It updates DR to min(new_DR, CR). (e) It initializes the total leftover rate TLO and its fair share of the total leftover rate TLO_FS to 0. If it is greedy (i.e. DR =3D CR), it then takes its fair share of = the leftover rate of non-greedy or terminated flows: for all non-greedy flows i in its FG (flows that have DR(i) < CR(i)), it adds the leftover rate abs(P(i))/S_P * S_CR - DR(i) to TLO. It calculates TLO_FS from TLO as P/S_P(G) * TLO, where S_P(G) is the sum of the priorities of all the greedy flows in the FG. (f) It calculates the new sending rate as min(new_DR, P/S_P * S_CR + TLO_FS). This applies an upper bound in case of an application-limited flow, gives the flow the correct share of the bandwidth based on its priority, and adds any potentially leftover bandwidth from non-greedy flows. The goals of the flow algorithm are to achieve prioritization, improve network utilization in the face of non-greedy flows, and impose limits on the increase behavior such that the negative impact Welzl & Islam Expires September 6, 2013 [Page 8] =0C Internet-Draft Coupled congestion control for RTP media March 2013 of multiple flows trying to increase their rate together is minimized. It does that by assigning a flow a sending rate that may not be what the flow's congestion controller expected. It therefore builds on the assumption that no significant inefficiencies arise from temporary non-greedy behavior or from quickly jumping to a rate that is higher than the congestion controller intended. How problematic these issues really are depends on the controllers in use and requires careful per-controller experimentation. The coupled congestion control mechanism described here also does not require all controllers to be equal; effects of heterogeneous controllers, or homogeneous controllers being in different states, are also subject to experimentation. There are more potential issues with the algorithm described here. Rule 3 b) leads to a conservative behavior: it ensures that only one flow at a time can increase the overall sending rate. This rule is probably appropriate for situations where minimizing delay is the major goal, but it may not fit for all purposes; it also does not incorporate the magnitude by which a flow can increase its rate. Notably, despite this limitation on the overall rate of all flows per FGI, immediate rate jumps of single flows could become problematic when the FSE is used in a highly asynchronous manner, e.g. when flows have very different RTTs. 5.3.2. Example operation In order to illustrate the operation of the coupled congestion control algorithm, this section presents a toy example of two flows that use it. Let us assume that both flows traverse a common 10 Mbit/s bottleneck and use a simplistic congestion controller that starts out with 1 Mbit/s, increases its rate by 1 Mbit/s in the absence of congestion and decreases it by 2 Mbit/s in the presence of congestion. For simplicity, flows are assumed to always operate in a round-robin fashion. Rate numbers below without units are assumed to be in Mbit/s. For illustration purposes, the actual sending rate is also shown for every flow in FSE diagrams even though it is not really stored in the FSE. Flow #1 begins. It is greedy and considers itself to have top priority. This is the FSE after the flow algorithm's step 1: --------------------------------------------- | # | FGI | P | CR | DR | S_CR | Rate | | | | | | | | | | 1 | 1 | 1 | 1 | 1 | 1 | 1 | --------------------------------------------- Welzl & Islam Expires September 6, 2013 [Page 9] =0C Internet-Draft Coupled congestion control for RTP media March 2013 Its congestion controller gradually increases its rate. Eventually, at some point, the FSE should look like this: --------------------------------------------- | # | FGI | P | CR | DR | S_CR | Rate | | | | | | | | | | 1 | 1 | 1 | 10 | 10 | 10 | 10 | --------------------------------------------- Now another flow joins. It is also greedy, and has a lower priority (0.5): ----------------------------------------------- | # | FGI | P | CR | DR | S_CR | Rate | | | | | | | | | | 1 | 1 | 1 | 10 | 10 | 10 | 10 | | 2 | 1 | 0.5 | 1 | 1 | 11 | 1 | ----------------------------------------------- Now assume that the first flow updates its rate to 8, because the total sending rate of 11 exceeds the total capacity. Let us take a closer look at what happens in step 3 of the flow algorithm. new_CR =3D 8. new_DR =3D infinity. 3 a) S_P =3D 1.5; new_S_CR =3D 11. 3 b) DELTA is negative, hence CR =3D 8. 3 c) new_S_CR =3D 9; S_CR =3D 9. 3 d) DR =3D CR =3D 8. 3 e) TLO =3D 0; there are no other flows with DR < CR. 3 f) new sending rate: min(infinity, 1/1.5 * 9 + 0) =3D 6. The resulting FSE looks as follows: ----------------------------------------------- | # | FGI | P | CR | DR | S_CR | Rate | | | | | | | | | | 1 | 1 | 1 | 8 | 8 | 9 | 6 | | 2 | 1 | 0.5 | 1 | 1 | 11 | 1 | ----------------------------------------------- The effect is that flow #1 is sending with 6 Mbit/s instead of the 8 Mbit/s that the congestion controller derived. Let us now assume that flow #2 updates its rate. Its congestion controller detects Welzl & Islam Expires September 6, 2013 [Page 10] =0C Internet-Draft Coupled congestion control for RTP media March 2013 that the network is not fully saturated (the actual total sending rate is 6+1=3D7) and increases its rate. new_CR=3D2. new_DR =3D infinity. 3 a) S_P =3D 1.5; new_S_CR =3D 9. 3 b) DELTA is positive but new_S_CR < S_CR, hence CR =3D 2. 3 c) new_S_CR =3D 10; S_CR =3D 10. 3 d) DR =3D CR =3D 2. 3 e) TLO =3D 0; there are no other flows with DR < CR. 3 f) new sending rate: min(infinity, 0.5/1.5 * 10 + 0) =3D 3.33. The resulting FSE looks as follows: ----------------------------------------------- | # | FGI | P | CR | DR | S_CR | Rate | | | | | | | | | | 1 | 1 | 1 | 8 | 8 | 9 | 6 | | 2 | 1 | 0.5 | 2 | 2 | 10 | 3.33 | ----------------------------------------------- The effect is that flow #2 is now sending with 3.33 Mbit/s, which is close to half of the rate of flow #1 and leads to a total utilization of 6(#1) + 3.33(#2) =3D 9.33 Mbit/s. Flow #2's congestion controller has increased its rate faster than the controller actually expected. Now, flow #1 updates its rate. Its congestion controller detects that the network is not fully saturated and increases its rate. Additionally, the application feeding into flow #1 limits the flow's sending rate to at most 2 Mbit/s. Welzl & Islam Expires September 6, 2013 [Page 11] =0C Internet-Draft Coupled congestion control for RTP media March 2013 new_CR=3D9. new_DR=3D2. 3 a) S_P =3D 1.5; new_S_CR =3D 10. 3 b) DELTA is positive and new_S_CR > S_CR, hence CR is not updated (since flow #2 has just increased S_CR, flow #1 cannot also increase it in this iteration). 3 c) new_S_CR =3D 10; S_CR =3D 10. 3 d) DR =3D 2. 3 e) TLO =3D 0; there are no other flows with DR < CR. 3 f) new sending rate: min(2, 1/1.5 * 10 + 0) =3D 2. Note that, without the 2 Mbit/s limitation from the application, the new sending rate for flow #1 would now be 6.66 Mbit/s, leading to perfect network saturation (6.66 + 3.33 =3D approx. 10). The resulting FSE looks as follows: ----------------------------------------------- | # | FGI | P | CR | DR | S_CR | Rate | | | | | | | | | | 1 | 1 | 1 | 8 | 2 | 10 | 2 | | 2 | 1 | 0.5 | 2 | 2 | 10 | 3.33 | ----------------------------------------------- Now, the total rate of the two flows is 2 + 3.33 =3D 5.33 Mbit/s, = i.e. the network is significantly underutilized due to the limitation of flow #1. Flow #2 updates its rate. Its congestion controller detects that the network is not fully saturated and increases its rate. new_CR=3D3. new_DR =3D infinity. 3 a) S_P =3D 1.5; new_S_CR =3D 10. 3 b) DELTA is positive but new_S_CR =3D S_CR, hence CR =3D 3. 3 c) new_S_CR =3D 11; S_CR =3D 11. 3 d) DR =3D 3. 3 e) TLO =3D 0; flow #1 has DR < CR, hence TLO +=3D 1/1.5 * 11 - 2 =3D 5.33, and TLO_FS =3D 0.5/0.5 * 5.33 =3D 5.33. 3 f) new sending rate: min(infinity, 0.5/1.5*11 + 5.33) =3D 9. The resulting FSE looks as follows: ----------------------------------------------- | # | FGI | P | CR | DR | S_CR | Rate | | | | | | | | | | 1 | 1 | 1 | 8 | 2 | 10 | 2 | | 2 | 1 | 0.5 | 3 | 3 | 11 | 9 | ----------------------------------------------- Now, the total rate of the two flows is 2 + 9 =3D 11 Mbit/s, = exceeding Welzl & Islam Expires September 6, 2013 [Page 12] =0C Internet-Draft Coupled congestion control for RTP media March 2013 the total capacity by the amount of 1 Mbit/s by which the congestion controller of flow #2 has increased its rate. Note that, had flow #1 been greedy, the same total rate would have resulted after this iteration. Finally, flow #1 terminates. It sets P to -1 and DR to 0. Let us assume that it terminated late enough for flow #2 to still experience the network in a congested state, i.e. flow #2 decreases its rate in the next iteration. new_CR =3D 1. new_DR =3D infinity. 3 a) S_P =3D 1.5; new_S_CR =3D 11. 3 b) DELTA is negative hence CR =3D 1. 3 c) new_S_CR =3D 9; S_CR =3D 9. 3 d) DR =3D 1. 3 e) TLO =3D 0; flow #1 has DR < CR, hence TLO +=3D 1/1.5 * 9 - 0 =3D = 6. TLO_FS=3D0.5/0.5 * 6 =3D 6. 3 f) new sending rate: min(infinity, 0.5/1.5 * 9 + 6) =3D 9. The resulting FSE looks as follows: ----------------------------------------------- | # | FGI | P | CR | DR | S_CR | Rate | | | | | | | | | | 1 | 1 | -1 | 8 | 0 | 10 | 2 | | 2 | 1 | 0.5 | 1 | 1 | 9 | 9 | ----------------------------------------------- Now, flow #2 increases its rate as the network is underutilized. The CR of the terminated flow is reduced so that the S_CR is adjusted. new_CR =3D 2. new_DR =3D infinity. 3 a) S_P =3D 1.5; new_S_CR =3D 9. 3 b) DELTA is positive but new_S_CR =3D S_CR, hence CR =3D 2. P(1) is negative, hence CR(1) =3D 8-1 =3D 7. 3 c) new_S_CR =3D 9; S_CR =3D 9. 3 d) DR =3D 2. 3 e) TLO =3D 0; flow #1 has DR < CR, hence TLO +=3D 1/1.5 * 9 - 0 =3D = 6. TLO_FS=3D0.5/0.5 * 6 =3D 6. 3 f) new sending rate: min(infinity, 0.5/1.5 * 9 + 6) =3D 9. The resulting FSE looks as follows: ----------------------------------------------- | # | FGI | P | CR | DR | S_CR | Rate | | | | | | | | | | 1 | 1 | -1 | 7 | 0 | 10 | 0 | | 2 | 1 | 0.5 | 2 | 2 | 9 | 9 | ----------------------------------------------- Welzl & Islam Expires September 6, 2013 [Page 13] =0C Internet-Draft Coupled congestion control for RTP media March 2013 Flow #2's congestion controller gradually increases its rate, and flow #1's CR is reduced to adjust the S_CR. Eventually, at some point, FSE should look like the following: ----------------------------------------------- | # | FGI | P | CR | DR | S_CR | Rate | | | | | | | | | | 1 | 1 | -1 | 1 | 0 | 10 | 0 | | 2 | 1 | 0.5 | 8 | 8 | 9 | 9 | ----------------------------------------------- and then, for flow #2: new_CR =3D 9. new_DR =3D infinity. 3 a) S_P =3D 1.5; new_S_CR =3D 9. 3 b) DELTA is positive but new_S_CR =3D S_CR, hence CR =3D 9. P(1) is negative, hence CR(1) =3D 1-1 =3D 0, and therefore the entry of flow #1 is deleted and S_P is updated to 0.5. 3 c) new_S_CR =3D 9; S_CR =3D 9. 3 d) DR =3D 9. 3 e) TLO =3D 0; there are no other flows. 3 f) new sending rate: min(infinity, 0.5/0.5 * 9 + 0) =3D 9. The resulting FSE looks as follows: ----------------------------------------------- | # | FGI | P | CR | DR | S_CR | Rate | | | | | | | | | | 2 | 1 | 0.5 | 9 | 9 | 9 | 9 | ----------------------------------------------- 6. Acknowledgements This document has benefitted from discussions with and feedback from Stein Gjessing, David Hayes, Andreas Petlund, and David Ros (who also gave the FSE its name). 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations In scenarios where the architecture described in this document is Welzl & Islam Expires September 6, 2013 [Page 14] =0C Internet-Draft Coupled congestion control for RTP media March 2013 applied across applications, various cheating possibilities arise: e.g., supporting wrong values for the calculated rate, the desired rate, or the priority of a flow. In the worst case, such cheating could either prevent other flows from sending or make them send at a rate that is unreasonably large. The end result would be unfair behavior at the network bottleneck, akin to what could be achieved with any UDP based application. Hence, since this is no worse than UDP in general, there seems to be no significant harm in using this in the absence of UDP rate limiters. In the case of a single-user system, it should also be in the interest of any application programmer to give the user the best possible experience by using reasonable flow priorities or even letting the user choose them. In a multi-user system, this interest may not be given, and one could imagine the worst case of an "arms race" situation, where applications end up setting their priorities to the maximum value. If all applications do this, the end result is a fair allocation in which the priority mechanism is implicitly eliminated, and no major harm is done. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997. [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001. 9.2. Informative References [rtcweb-rtp-usage] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", draft-ietf-rtcweb-rtp-usage-05.txt (work in progress), October 2012. [rtcweb-usecases] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use-cases and Requirements", draft-ietf-rtcweb-use-cases-and-requirements-10.txt (work in progress), December 2012. Welzl & Islam Expires September 6, 2013 [Page 15] =0C Internet-Draft Coupled congestion control for RTP media March 2013 [transport-multiplex] Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a Single Lower-Layer Transport", draft-westerlund-avtcore-transport-multiplexing-04.txt (work in progress), October 2012. Appendix A. Changes from -00 to -01 Updated the example algorithm and its operation to let flows fairly take the leftover rate from other non-greedy and/or terminated flows. Authors' Addresses Michael Welzl University of Oslo PO Box 1080 Blindern Oslo, N-0316 Norway Phone: +47 22 85 24 20 Email: michawe@ifi.uio.no Safiqul Islam University of Oslo PO Box 1080 Blindern Oslo, N-0316 Norway Phone: +47 22 84 08 37 Email: safiquli@ifi.uio.no Welzl & Islam Expires September 6, 2013 [Page 16] =0C --Apple-Mail=_25F391B5-E09C-487F-8FB1-424FA85B2320-- From carlberg@g11.org.uk Tue Mar 5 07:37:14 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 7263C21F88BF for ; Tue, 5 Mar 2013 07:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 bswWnpZoUv+B for ; Tue, 5 Mar 2013 07:37:13 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0CF21F889C for ; Tue, 5 Mar 2013 07:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=kEw/3TXDKC2Q/RSKA0fykNOODUPmUyRWc86JfYTq3Ss=; b=efUhaM6CsVHbTRqRnhRLWxaWTCiZKW16NRqg+W1KU8UIVfoFYNkWr+Ax2ad/fN7vFRjuB9XLg+N4mdwWiQr3iV/VoM1MT5GeCA/5qPrOJosr++l+ZkTsZUjBqkAHkpA+; Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:40015 helo=[10.0.1.20]) by portland.eukhosting.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UCtvQ-004KUG-6s; Tue, 05 Mar 2013 15:37:08 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: ken carlberg In-Reply-To: <5135EF72.3090007@ericsson.com> Date: Tue, 5 Mar 2013 10:37:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5135EF72.3090007@ericsson.com> To: Zaheduzzaman Sarker X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Get-Message-Sender-Via: portland.eukhosting.net: acl_c_relayhosts_text_entry: carlberg@g11.org.uk|g11.org.uk Cc: randell-ietf@jesup.org, rmcat@ietf.org Subject: Re: [rmcat] Initial comments on draft-jesup-rmcat-reqs-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: Tue, 05 Mar 2013 15:37:14 -0000 Hi Zahed, > * Req 8: This requirement focuses on long-lived TCP flows but I think = it should focus on flows with known congestion control algorithm. in the = fast phase, RMCAT will publish (hopefully) more than one experimental CC = algorithms and I think it is important to look how one of the candidate = is behaving when competing with other candidate. But if we want to = focus on the behavior against competing TCP flows then the requirement = should say "It should attempt to avoid bandwidth 'collapse' when facing = a saturating TCP flow or flows but it should not starve TCP flow (should = not grab more than necessary)" or something along this theme. And I = would also like to get rid of the prefix terms "short-lived" and = "Long-lived" TCP flow as I think from a congestion controller point of = view it is hardly possible to distinguish between them unless we have = some explicit information from the shared bottleneck. bringing up the terms "long-lived" and "short lived" triggered an = outside the box thought on the topic. Do you think its reasonable ro = feasable to use numbers associated with average call/flow duration as a = point of reference of what is considered a "typical real-time flow"? = Part of the reason that I bring this up is that I understand that one = (maybe more) popular VoIP applications starts with a rather aggressive = offered load, and then after some period of time (versus actual = feedback) the application backs off to some target measure that takes = into account accumulated path characteristics (eg, delay, loss). = Perhaps the time delay is to avoid oscilation. One can argue that the initial stage of such an approach is not fair, or = its excessively greedy (for lack of an alternative term), but that = perhaps over time, or an average call/flow duration, it is fair. I've = seen numbers that range from 1.8 minutes to 4 minutes in average call = duration, and so perhaps this could be a target reference point to gauge = how nice various algorithms work with each other. -ken From fuji246@gmail.com Wed Mar 6 05:12: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 880F921F8936 for ; Wed, 6 Mar 2013 05:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTjGZn2fTL5C for ; Wed, 6 Mar 2013 05:12:41 -0800 (PST) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id E79B421F8994 for ; Wed, 6 Mar 2013 05:12:34 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id ma3so5994849pbc.11 for ; Wed, 06 Mar 2013 05:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6EJ23LBfTOX+lX/LXNV9Po/8edLa9IS02wrQR6pHE2w=; b=gtY5KkJfzrkIV+z2vQdlXhqWOpqLuAnpWNgqbHCUqRn1qzoP+98zOA3Z/LuV6dX9Oc MDkxaICsZQkNs6Jxghas+sIlmKmo/KE5kXTQ6Hc9su4GkF2nw25v7jVW1xLtBGWGebhB gR1iWlLg8KFLY7zm5/3V0PHDSOJRnqwiC0o9i0kG708V/Hh+0cUvZd8SW6FTVEkz7gL2 OSn83V5DsnJw/kwJkZCNb07fXnJoXZtoTIslkgJjZw0EdgZ/ANgMCAaqijf1OsgM8XmI uDh3eeBJZAyjwqI7cdR3PYnvQurKKLAkiuky6eCaRn9r1ji+iWdDvT7qzvj44S0cVtjY G9ag== MIME-Version: 1.0 X-Received: by 10.68.211.225 with SMTP id nf1mr45907049pbc.104.1362575554543; Wed, 06 Mar 2013 05:12:34 -0800 (PST) Received: by 10.70.33.3 with HTTP; Wed, 6 Mar 2013 05:12:34 -0800 (PST) In-Reply-To: References: <20130119095614.17091.17595.idtracker@ietfa.amsl.com> Date: Wed, 6 Mar 2013 21:12:34 +0800 Message-ID: From: Fu Jiantao To: Michael Welzl Content-Type: multipart/alternative; boundary=e89a8ff1c090ea883204d741572e Cc: "rmcat@ietf.org WG" Subject: Re: [rmcat] Fwd: New Version Notification for draft-welzl-rmcat-coupled-cc-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:12:42 -0000 --e89a8ff1c090ea883204d741572e Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, Following are my comments: 1. multiplexing make the SBD simple, but it may take more effort for classification in QoS. delay and loss correlations works fine for UDP connection, but for having both TCP and UDP connections in police network(drop overlimit packets directly), it seems no easy way to do SDB. 2. the new_S_CR seems not updated with new_CR in step 3, from the examples, it should be the new_S_CR in the last round, and I guess new_S_CR is the common state variable sharing in each round, only so it can be used to avoid only make S_CR increase at once. 3. The example algorithm will only update flow(i)'s state when its cc changed the calculated rate, other flow's state is leave untouched. There are other algorithms, for example, updates all flow's state when flow(i)'s state changed. What's the reason to prefer the first one, and I think the second one is more reasonable and simple to implement. Thanks Jeromy 2013/1/19 Michael Welzl > Hi all, > > See below the announcement of a draft I just posted, to address the > milestone on "identifying and controlling groups of flows". > I'm curious to hear your thoughts! > > Cheers, > Michael > > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-welzl-rmcat-coupled-cc-00.txt > > Date: January 19, 2013 10:56:14 AM GMT+01:00 > > To: michawe@ifi.uio.no > > > > > > A new version of I-D, draft-welzl-rmcat-coupled-cc-00.txt > > has been successfully submitted by Michael Welzl and posted to the > > IETF repository. > > > > Filename: draft-welzl-rmcat-coupled-cc > > Revision: 00 > > Title: Coupled congestion control for RTP media > > Creation date: 2013-01-19 > > WG ID: Individual Submission > > Number of pages: 14 > > URL: > http://www.ietf.org/internet-drafts/draft-welzl-rmcat-coupled-cc-00.txt > > Status: > http://datatracker.ietf.org/doc/draft-welzl-rmcat-coupled-cc > > Htmlized: > http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-00 > > > > > > Abstract: > > When multiple congestion controlled RTP sessions traverse the same > > network bottleneck, it can be beneficial to combine their controls > > such that the total on-the-wire behavior is improved. This document > > describes such a method for flows that have the same sender, in a way > > that is as flexible and simple as possible while minimizing the > > amount of changes needed to existing RTP applications. > > > > > > > > > > The IETF Secretariat > > > > --e89a8ff1c090ea883204d741572e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael,

=A0=A0 Following are my comments:

=A0 1. multiplexing make t= he SBD simple, but it may take more effort for classification in QoS. delay= and loss correlations works fine for UDP connection, but for having both T= CP and UDP connections in police network(drop overlimit packets directly), = it seems no easy way to do SDB.

=A0 2. the new_S_CR seems not updated with new_CR in step 3, from= the examples, it should be the new_S_CR in the last round, and I guess new= _S_CR is the common state variable sharing in each round, only so it can be= used to avoid only make S_CR increase at once.

=A0 3. The example algorithm will only update flow(i)'s state= when its cc changed the calculated rate, other flow's state is leave u= ntouched. There are other algorithms, for example, updates all flow's s= tate when flow(i)'s state changed. What's the reason to prefer the = first one, and I think the second one is more reasonable and simple to impl= ement.

Thanks

Jeromy


2013/1/19 Michael Welzl <michawe@i= fi.uio.no>
Hi all,

See below the announcement of a draft I just posted, to address the milesto= ne on "identifying and controlling groups of flows".
I'm curious to hear your thoughts!

Cheers,
Michael


Begin forwarded message:

> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-welzl-rmcat-coupled-cc-00.= txt
> Date: January 19, 2013 10:56:14 AM GMT+01:00
> To: michawe@ifi.uio.no
>
>
> A new version of I-D, draft-welzl-rmcat-coupled-cc-00.txt
> has been successfully submitted by Michael Welzl and posted to the
> IETF repository.
>
> Filename: =A0 =A0 =A0draft-welzl-rmcat-coupled-cc
> Revision: =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Coupled congestion control for = RTP media
> Creation date: =A0 =A0 =A0 =A0 2013-01-19
> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 14
> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.iet= f.org/internet-drafts/draft-welzl-rmcat-coupled-cc-00.txt
> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org= /doc/draft-welzl-rmcat-coupled-cc
> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draf= t-welzl-rmcat-coupled-cc-00
>
>
> Abstract:
> =A0 When multiple congestion controlled RTP sessions traverse the same=
> =A0 network bottleneck, it can be beneficial to combine their controls=
> =A0 such that the total on-the-wire behavior is improved. =A0This docu= ment
> =A0 describes such a method for flows that have the same sender, in a = way
> =A0 that is as flexible and simple as possible while minimizing the > =A0 amount of changes needed to existing RTP applications.
>
>
>
>
> The IETF Secretariat
>


--e89a8ff1c090ea883204d741572e-- From michawe@ifi.uio.no Wed Mar 6 05:53:19 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C0B21F8887 for ; Wed, 6 Mar 2013 05:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.224 X-Spam-Level: X-Spam-Status: No, score=-101.224 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, 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 X25fOxKcDqqy for ; Wed, 6 Mar 2013 05:53:19 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 939CF21F8873 for ; Wed, 6 Mar 2013 05:53:18 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UDEmT-0007Lx-UH; Wed, 06 Mar 2013 14:53:17 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UDEmT-0003Vs-7j; Wed, 06 Mar 2013 14:53:17 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C0445B9E-F49E-4EB6-BDAF-BB1C34ACBD57" From: Michael Welzl In-Reply-To: Date: Wed, 6 Mar 2013 14:53:16 +0100 Message-Id: References: <20130119095614.17091.17595.idtracker@ietfa.amsl.com> To: Fu Jiantao X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 4 sum rcpts/h 18 sum msgs/h 7 total rcpts 2549 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.6, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.552, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EAED3AF45E5F1CB42FF8DDE4C1106A0803C4DAD7 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -55 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 1053 max/h 12 blacklist 0 greylist 0 ratelimit 0 Cc: "rmcat@ietf.org WG" Subject: Re: [rmcat] New Version Notification for draft-welzl-rmcat-coupled-cc-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:53:19 -0000 --Apple-Mail=_C0445B9E-F49E-4EB6-BDAF-BB1C34ACBD57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Jeromy, Thanks a whole lot for reading this and for your comments! More below - On 6. mars 2013, at 14:12, Fu Jiantao wrote: > Hi Michael, >=20 > Following are my comments: >=20 > 1. multiplexing make the SBD simple, but it may take more effort for = classification in QoS. delay and loss correlations works fine for UDP = connection, but for having both TCP and UDP connections in police = network(drop overlimit packets directly), it seems no easy way to do = SDB. As for delay and loss correlations: even that is not easy, but we're = working on something there. I agree that policers may make it impossible = to detect a SBD - but, for example, if flow 1 gets a lot of loss due to = a policer and flow 2 doesn't, losses of the two flows won't correlate. = Even if they share the same bottleneck, a correlation based scheme would = then judge the flows as not sharing a bottleneck, which is a false = negative and not a big problem: for all flows that are detected as not = sharing a bottleneck, you have the behavior of "today".... the FSE = scheme simply doesn't apply, you lose some extra benefit. > 2. the new_S_CR seems not updated with new_CR in step 3, from the = examples, it should be the new_S_CR in the last round, and I guess = new_S_CR is the common state variable sharing in each round, only so it = can be used to avoid only make S_CR increase at once. No, new_S_CR is really a temporary variable. Maybe we should have called = it tmp_S_CR... new_S_CR is the newly calculated sum, as a result of all the current CR = values in the FSE. S_CR however is a historical stored value per flow, = which is updated every time the flow enters step 3. Thus, if new_S_CR is = different from S_CR, some other flow Y has changed its CR since the last = time flow X has gone through step 3. > 3. The example algorithm will only update flow(i)'s state when its = cc changed the calculated rate, other flow's state is leave untouched. = There are other algorithms, for example, updates all flow's state when = flow(i)'s state changed. What's the reason to prefer the first one, and = I think the second one is more reasonable and simple to implement. I'm used to congestion controllers that update their rate all the time, = this guided my thinking. Maybe that's wrong for rmcat, where feedback is = minimized... I also thought that this is the simplest approach, but = maybe it's just fine to change a rate even when the controller doesn't = do anything to it. We'll have to consider that. Anyway, the main point = here is to come up with something simple and working. There are = something between 7000 and 9000 possible improvements to this, I guess = :-) Thanks again, cheers, Michael >=20 > Thanks >=20 > Jeromy >=20 >=20 > 2013/1/19 Michael Welzl > Hi all, >=20 > See below the announcement of a draft I just posted, to address the = milestone on "identifying and controlling groups of flows". > I'm curious to hear your thoughts! >=20 > Cheers, > Michael >=20 >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Subject: New Version Notification for = draft-welzl-rmcat-coupled-cc-00.txt > > Date: January 19, 2013 10:56:14 AM GMT+01:00 > > To: michawe@ifi.uio.no > > > > > > A new version of I-D, draft-welzl-rmcat-coupled-cc-00.txt > > has been successfully submitted by Michael Welzl and posted to the > > IETF repository. > > > > Filename: draft-welzl-rmcat-coupled-cc > > Revision: 00 > > Title: Coupled congestion control for RTP media > > Creation date: 2013-01-19 > > WG ID: Individual Submission > > Number of pages: 14 > > URL: = http://www.ietf.org/internet-drafts/draft-welzl-rmcat-coupled-cc-00.txt > > Status: = http://datatracker.ietf.org/doc/draft-welzl-rmcat-coupled-cc > > Htmlized: = http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-00 > > > > > > Abstract: > > When multiple congestion controlled RTP sessions traverse the same > > network bottleneck, it can be beneficial to combine their controls > > such that the total on-the-wire behavior is improved. This = document > > describes such a method for flows that have the same sender, in a = way > > that is as flexible and simple as possible while minimizing the > > amount of changes needed to existing RTP applications. > > > > > > > > > > The IETF Secretariat > > >=20 >=20 --Apple-Mail=_C0445B9E-F49E-4EB6-BDAF-BB1C34ACBD57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Jeromy,

Thanks a whole lot for reading this and for = your comments! More below -

On 6. = mars 2013, at 14:12, Fu Jiantao wrote:

Hi = Michael,

   Following are my = comments:

  1. multiplexing make the SBD simple, but = it may take more effort for classification in QoS. delay and loss = correlations works fine for UDP connection, but for having both TCP and = UDP connections in police network(drop overlimit packets directly), it = seems no easy way to do = SDB.

As for delay and loss correlations: even that is not easy, but we're = working on something there. I agree that policers may make it impossible = to detect a SBD - but, for example, if flow 1 gets a lot of loss due to = a policer and flow 2 doesn't, losses of the two flows won't correlate. = Even if they share the same bottleneck, a correlation based scheme = would then judge the flows as not sharing a bottleneck, which is a false = negative and not a big problem: for all flows that are detected as not = sharing a bottleneck, you have the behavior of "today".... the FSE = scheme simply doesn't apply, you lose some extra = benefit.


  2. the new_S_CR seems not updated = with new_CR in step 3, from the examples, it should be the new_S_CR in = the last round, and I guess new_S_CR is the common state variable = sharing in each round, only so it can be used to avoid only make S_CR = increase at = once.

No, = new_S_CR is really a temporary variable. Maybe we should have called it = tmp_S_CR...
new_S_CR is the newly calculated sum, as a result = of all the current CR values in the FSE. S_CR however is a historical = stored value per flow, which is updated every time the flow enters step = 3. Thus, if new_S_CR is different from S_CR, some other flow Y has = changed its CR since the last time flow X has gone through step = 3.


  3. The example algorithm will only = update flow(i)'s state when its cc changed the calculated rate, other = flow's state is leave untouched. There are other algorithms, for = example, updates all flow's state when flow(i)'s state changed. What's = the reason to prefer the first one, and I think the second one is more = reasonable and simple to = implement.

I'm= used to congestion controllers that update their rate all the time, = this guided my thinking. Maybe that's wrong for rmcat, where feedback is = minimized... I also thought that this is the simplest approach, but = maybe it's just fine to change a rate even when the controller doesn't = do anything to it. We'll have to consider that. Anyway, the main point = here is to come up with something simple and working. There are = something between 7000 and 9000 possible improvements to this, I guess =   :-)

Thanks = again,

cheers,
Michael



Thanks

Jeromy


2013/1/19 = Michael Welzl <michawe@ifi.uio.no>
Hi all,

See below the announcement of a draft I just posted, to address the = milestone on "identifying and controlling groups of flows".
I'm curious to hear your thoughts!

Cheers,
Michael


Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for = draft-welzl-rmcat-coupled-cc-00.txt
> Date: January 19, 2013 10:56:14 AM GMT+01:00
> To: michawe@ifi.uio.no
>
>
> A new version of I-D, draft-welzl-rmcat-coupled-cc-00.txt
> has been successfully submitted by Michael Welzl and posted to = the
> IETF repository.
>
> Filename:      draft-welzl-rmcat-coupled-cc
> Revision:      00
> Title:                 = Coupled congestion control for RTP media
> Creation date:         2013-01-19
> WG ID:                 = Individual Submission
> Number of pages: 14
> URL:             http://www.ietf.org/internet-drafts/draft-welzl-rmcat-co= upled-cc-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-welzl-rmcat-couple= d-cc
> Htmlized:        http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-= 00
>
>
> Abstract:
>   When multiple congestion controlled RTP sessions traverse = the same
>   network bottleneck, it can be beneficial to combine their = controls
>   such that the total on-the-wire behavior is improved. =  This document
>   describes such a method for flows that have the same sender, = in a way
>   that is as flexible and simple as possible while minimizing = the
>   amount of changes needed to existing RTP applications.
>
>
>
>
> The IETF Secretariat
>



= --Apple-Mail=_C0445B9E-F49E-4EB6-BDAF-BB1C34ACBD57-- From lars@netapp.com Thu Mar 7 06:21:18 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 1D2C421F850F for ; Thu, 7 Mar 2013 06:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.332 X-Spam-Level: X-Spam-Status: No, score=-10.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 V0N9ftb-jgve for ; Thu, 7 Mar 2013 06:21:17 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id A32E321F850C for ; Thu, 7 Mar 2013 06:21:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,803,1355126400"; d="scan'208";a="28849275" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 07 Mar 2013 06:21:14 -0800 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r27ELDET015047 for ; Thu, 7 Mar 2013 06:21:14 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Thu, 7 Mar 2013 06:21:13 -0800 From: "Eggert, Lars" To: rmcat WG Thread-Topic: slides, please! Thread-Index: AQHOGz8Fmh2YErWmpkKf/rIMHB/jCw== Date: Thu, 7 Mar 2013 14:21:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <339564BF91F480419F069F6B2900C715@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rmcat] slides, please! 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, 07 Mar 2013 14:21:18 -0000 Hi, since RMCAT is in the first slot on Monday morning, I will need the FINAL s= lides from all presenters by *** 6PM on Sunday *** (local time Orlando) to = upload them. Thanks, Lars= From zaheduzzaman.sarker@ericsson.com Thu Mar 7 09:30:26 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 60A5821F8C78 for ; Thu, 7 Mar 2013 09:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 O5aDbR92MvZy for ; Thu, 7 Mar 2013 09:30:25 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC0121F8C2C for ; Thu, 7 Mar 2013 09:30:16 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-75-5138cea7ab53 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 18.6C.10459.7AEC8315; Thu, 7 Mar 2013 18:30:15 +0100 (CET) Received: from [153.88.19.169] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Thu, 7 Mar 2013 18:30:14 +0100 Message-ID: <5138CEA6.1070807@ericsson.com> Date: Thu, 7 Mar 2013 18:30:14 +0100 From: Zaheduzzaman Sarker Organization: Ericsson AB User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: rmcat@ietf.org, varun@comnet.tkk.fi, jo@comnet.tkk.fi Content-Type: multipart/alternative; boundary="------------000507020005050805010206" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgluLIzCtJLcpLzFFi42KZGfG3Rnf5OYtAg3MnxS3a9i1ht1h98wOb xYwTHA7MHmeXTWXyWLLkJ1MAUxSXTUpqTmZZapG+XQJXxuf7/9gL5sxlquhvnc/YwPjiBmMX IyeHhICJROudGawQtpjEhXvr2boYuTiEBE4ySrzq/sQK4axilFh09DhYFa+AtkTb26fsIDaL gIpE36otzF2MHBxsAjYSjxf7gYT5BSQlNjTsBguLCkRJXNlnCdEpKHFy5hMWEFtEwFKi6dcl JhBbWMBOonlHK5jNLBAm8fh8BxtIq5CArkTXy7gJjHyzkHTPQlIFYdtKXJhzHSouL9G8dTYz hK0rceH/FLj49rdzmBcwsq1iZM9NzMxJLzfcxAgMzYNbfuvuYDx1TuQQozQHi5I4b5jrhQAh gfTEktTs1NSC1KL4otKc1OJDjEwcnFINjDEtj6XXvrvGkbvuot3iV4fuWD09yKtevWKh3LaW Xw7r/Ha5buCN01RRfaH+NcrAaunmTOMA8dOP221evfto7XXPear/z34/mSkcDYayN0/U7nL3 uvDjnc608rDfOh9Dj+fv1LdYWlzxwumJklA409/c/eLOf2fwPe/beuH8J9uGDMM01oLQMCWW 4oxEQy3mouJEANQRiQ0bAgAA Subject: [rmcat] Comments on eval draft (draft-singh-rmcat-cc-eval-02) 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, 07 Mar 2013 17:30:26 -0000 --------------000507020005050805010206 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Hi, Now that I have finished reading the evaluation draft, I think the recent version look much better than the previous one however I have several comments, reflections, questions related to different sections of the draft. Warning !!!!! long email ahead. Sorry, but I could not help it. Metrics: ·I understand that the RFC 5166 is referred for the description of the metrics mentioned in this draft. However, my take is that RFC 5166 was written to address a wider scope than what we are trying to do in RMCAT hence IMHO it is best to scope the definition and description down to the particular scope of RMCAT- interactive real-time media over RTP. This means this draft should actually include proper definition of the metrics, methodologies to realize them within this document (or in additional documents). ·Barely mentioning the metrics does not really help. We need to define proper methodologies to use them. Some of the metrics are easy to visualize but some of them are not (see more below). We need to describe/define a common understanding of all the metrics and how to use them in evaluation. ·Delay: this version excludes "Delay" as metric. Could you explain why? ·Minimum oscillation in encoding rate: This is related to QoE and minimizing oscillationis an wanted behavior. How do we measure oscillation? RFC 5166 gives some ref. but how well do they represent interactive real-time communication? We have variable bitrate encoder for video whose output will oscillate depending on scenes to encode. What do we do there? We perhaps will need to measure the oscillation in the target bitrate set bythe Congestion Control (CC) algorithm but very often there will be mismatch between the target rate and actual encoding rate. ·Reactivity to transient events: We canreact to transient event only if we know that it is a transient event. In testbeds, perhaps we can do this by setting up particular test for a particular transient event and very soon we will find that there is no "silver bullet" to dodge all favorite transient events. What can we do then? one way to handle this could be to setup a sequence tests of transient events and weight them to evaluate the reactivity to the transient events. Please let me know if I am missing something here. ·Packet loss and discard rate: We have three categories here- 1) loss at transport layer (TL), 2) loss due to late arrival (LL) and 3) residual loss (RL = TL+LL). RL will also have effects of application depended techniques used for countering the packet loss (for example, FEC, RTP retransmission). Where TL perhaps a good metric for network, RL is perhaps what the application care about most. We will need to define a relation here. Also this metric is not about how the CC algorithms calculate the packet loss rate (-- different algorithm may calculate loss event/rate differently- per RTCP Send Report/Receiver Report, fractional loss over a time period, per RTT etc. etc.) but about how we want to measure the loss, right? then, lets define it concretely. ·Bandwidth utilization: This is a metric I have hard time to grasp. Whatdo we actuallywant to achieve/measure with this metric? I perhaps understand it if I have a fixed capacity link but in real-time communication the input data itself can starve*//*,resulting inless utilization of the available bandwidth. And for cellular networks where the users have different capacity view even within a cell depending on their radio condition, speed, distance etc. etc. ; even in a aggregate level (per cell measurement) will depend on what is going on other cells. Moreover, the view of available bandwidth changes all the time, I don't see how we can visualize the available bandwidth utilization. I am not aware of any model that actually does it. Please let me know if I have missed something here. The thing is if we can't really measure a metric in a proper/straight forward way then there is not point of including it. ·Convergence time: I would like add this metric in the preferred metric list. This is also related to fairness metric as it gives a view about how fast the algorithm can reach a stable bitrate when competing with flows with same CC algorithm. Guideline: ·4.3 : It seems that it is necessary to have some reference cases to verify against. ·4.4 : Is this the plan to test against all possible access types? ·4.7 : any idea on how to "highlight the bottleneck capacity share of each RTP flow" for wireless/cellular networks? ·This also says "However, long-lived TCP flows may starve out the RTP flow depending on router queue length. In the latter case the proposed congestion control for RTP should be as aggressive as standard TCP"- how realistic is this? at some point (if there are buffer-bloats) the RMCAT will have to give up as it has certain delay budget to meet. ·missing guidelines ·Congested feedback channel : the CC algorithm should be evaluated against congested feedback channel. Could be included as separate guideline or a part of 4.5. ·Different start up values: as the requirement draft mentioned several options for start-up values, the algorithms should be tested. One can argue that different CC algorithm will have different strategies but then it should be judged against fairness and convergence time. ·Fairness to other RMCAT proposed algorithms: as part of fairness guideline. Eval scenarios: ·This section should really list a "must be" evaluated test scenarios not example scenarios. Those "must be" evaluated scenarios should take the guides lines into account and includetherelatedmetrics so that people have a common view on how to evaluate their algorithms. Any kind of effort to write down example scenarios should be waste of time and energy. Of course, there could be optional test cases and people can go an add their scenarios and if some scenarios become very useful then include those in the "must-be" evaluated sets. ·Video starting rate is 128 kbps. Feels like the default behavior is slow start, why? ·Yes, I would like to get a value(s) for queue length when AQM is used along with the AQM behavior. ·I have hard time fitting a radio scenario into dumbbell topology with the current definition in the draft. BR -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies Laboratoriegränd 11 97128 Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ================================================== --------------000507020005050805010206 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

Hi,

Now that I have finished reading the evaluation draft, I think the recent version look much better than the previous one however I have several comments, reflections, questions related to different sections of the draft.

Warning !!!!! long email ahead. Sorry, but I could not help it.

Metrics:

·   I understand that the RFC 5166 is referred for the description of the metrics mentioned in this draft. However, my take is that RFC 5166 was written to address a wider scope than what we are trying to do in RMCAT hence IMHO it is best to scope the definition and description down to the particular scope of RMCAT- interactive real-time media over RTP. This means this draft should actually include proper definition of the metrics, methodologies to realize them within this document (or in additional documents).

·   Barely mentioning the metrics does not really help. We need to define proper methodologies to use them. Some of the metrics are easy to visualize but some of them are not (see more below). We need to describe/define a common understanding of all the metrics and how to use them in evaluation.

·   Delay: this version excludes "Delay" as metric. Could you explain why?

·   Minimum oscillation in encoding rate: This is related to QoE and minimizing oscillation is an wanted behavior. How do we measure oscillation? RFC 5166 gives some ref. but how well do they represent interactive real-time communication?  We have variable bitrate encoder for video whose output will oscillate depending on scenes to encode. What do we do there? We perhaps will need to measure the oscillation in the target bitrate set by  the Congestion Control (CC) algorithm but very often there will be mismatch between the target rate and actual encoding rate.      

·   Reactivity to transient events: We can react to transient event only if we know that it is a transient event. In testbeds, perhaps we can do this by setting up particular test for a particular transient event and very soon we will find that there is no "silver bullet" to dodge all favorite transient events. What can we do then? one way to handle this could be to setup a sequence tests of transient events and weight them to evaluate the reactivity to the transient events.  Please let me know if I am missing something here.

·   Packet loss and discard rate: We have three categories here- 1) loss at transport layer (TL), 2) loss due to late arrival (LL) and 3) residual loss  (RL = TL+LL).  RL will also have effects of application depended techniques used for countering the packet loss (for example, FEC, RTP retransmission). Where TL perhaps a good metric for network, RL is perhaps what the application care about most. We will need to define a relation here. Also this metric is not about how the CC algorithms calculate the packet loss rate (--  different algorithm may calculate loss event/rate differently- per RTCP Send Report/Receiver Report, fractional loss over a time period, per RTT etc. etc.) but about how we want to measure the loss, right? then, lets define it concretely.

·   Bandwidth utilization: This is a metric I have hard time to grasp. What do we actually want to achieve/measure with this metric? I perhaps understand it if I have a fixed capacity link but in real-time communication the input data itself can starve,  resulting  in less utilization of the available bandwidth. And for cellular networks where the users have different capacity view even within a cell depending on their radio condition, speed, distance etc. etc. ; even in a aggregate level (per cell measurement) will depend on what is going on other cells. Moreover, the view of available bandwidth changes all the time, I don't see how we can visualize the available bandwidth utilization. I am not aware of any model that actually does it. Please let me know if I have missed something here. The thing is if we can't really measure a metric in a proper/straight forward way then there is not point of including it.

·   Convergence time: I would like add this metric in the preferred metric list. This is also related to fairness metric as it gives a view about how fast the algorithm can reach a stable bitrate when competing with flows with same CC algorithm.

Guideline:

·         4.3 : It seems that it is necessary to have some reference cases to verify against.

·         4.4 : Is this the plan to test against all possible access types ?

·         4.7 : any idea on how to "highlight the bottleneck capacity share of each RTP flow" for wireless/cellular networks?

·   This also says "However, long-lived TCP flows may starve out the RTP flow depending on router queue length. In the latter case the proposed congestion control for RTP should be as aggressive as standard TCP"- how realistic is this? at some point (if there are buffer-bloats) the RMCAT will have to give up as it has certain delay budget to meet.

·         missing guidelines

·   Congested feedback channel : the CC algorithm should be evaluated against congested feedback channel. Could be included as separate guideline or a part of 4.5.

·   Different start up values: as the requirement draft mentioned several options for start-up values, the algorithms should be tested. One can argue that different CC algorithm will have different strategies but then it should be judged against fairness and convergence time.

·   Fairness to other RMCAT proposed algorithms: as part of fairness guideline.

Eval scenarios:

·   This section should really list a "must be" evaluated test scenarios not example scenarios. Those "must be" evaluated scenarios should take the guides lines into account and include the related metrics so that people have a common view on how to evaluate their algorithms. Any kind of effort to write down example scenarios should be waste of time and energy. Of course, there could be optional test cases and people can go an add their scenarios and if some scenarios become very useful then include those in the "must-be" evaluated sets.

·   Video starting rate is 128 kbps. Feels like the default behavior is slow start, why?

·   Yes, I would like to get a value(s) for queue length when AQM is used along with the AQM behavior.

·   I have hard time fitting a radio scenario into dumbbell topology with the current definition in the draft.  

BR

-- 

Zahed

==================================================
ANM ZAHEDUZZAMAN SARKER 


Ericsson AB
Multimedia Technologies
Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43
zaheduzzaman.sarker@ericsson.com
www.ericsson.com

==================================================
--------------000507020005050805010206-- From zaheduzzaman.sarker@ericsson.com Fri Mar 8 22:38:09 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C5021F84AB for ; Fri, 8 Mar 2013 22:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 U-YO82U0ZXUF for ; Fri, 8 Mar 2013 22:38:08 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0149621F84A9 for ; Fri, 8 Mar 2013 22:38:07 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-d5-513ad8ce61a3 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9E.9D.32353.EC8DA315; Sat, 9 Mar 2013 07:38:06 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.54]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.004; Sat, 9 Mar 2013 07:38:06 +0100 From: Zaheduzzaman Sarker To: "rmcat@ietf.org" Thread-Topic: [ipr-announce] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-alvestrand-rtcweb-congestion-03 Thread-Index: AQHOE1zjG0EDYTXaQEux+r47wknUapic9Nmw Date: Sat, 9 Mar 2013 06:38:05 +0000 Message-ID: References: <20130222162118.25681.88313.idtracker@ietfa.amsl.com> In-Reply-To: <20130222162118.25681.88313.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje65G1aBBk3nLS1W3/zA5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGfP/7MV7OCs+DOzhaWBsYWji5GDQ0LARGLrGqYuRk4gU0zi wr31bF2MXBxCAocYJZpPzGKFcBYxSrQdPMMC0sAmYCPxeLEfSIOIgKrElv4/YA3CArMZJT5t mssC4ogIzGGUuL37KwtElZHEiVOXwFawCKhIrD91FizOK+AtsWD3e7C4kICjxP4nv1hBFnAK OEk8/F0OEmYEuuj7KYjrmAXEJW49mQ91qYDEkj3nmSFsUYmXj/+xQtiKEu1PGxgh6nWAxn9i g7C1JZYtfM0MsVZQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcXInpuYmZNebr6JERj2B7f8 NtjBuOm+2CFGaQ4WJXHecNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY9V0d74WvcPjy pFd6/U1DDa12V/2g9uWbTirvP3RA7FV51qrflrMzui5EnzikaVFvtkro5Qm+35dnzBZ93CR3 5JT44qy/wge2lKT8nb/ULFrA9Madace3Fq+bvLJbvvnL/jlcVTpVOlMse/8aZ30/v8RQz449 iv3aSnX5uZunXa3cOO1p/d2bvEosxRmJhlrMRcWJAJtQPqhJAgAA Subject: [rmcat] FW: [ipr-announce] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-alvestrand-rtcweb-congestion-03 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 06:38:09 -0000 Hi all, FYI .. BR Zahed -----Original Message----- From: ipr-announce-bounces@ietf.org [mailto:ipr-announce-bounces@ietf.org] = On Behalf Of IETF Secretariat Sent: den 22 februari 2013 17:21 To: holmer@google.com; harald@alvestrand.no Cc: ipr-announce@ietf.org Subject: [ipr-announce] IPR Disclosure: Telefonaktiebolaget LM Ericsson (pu= bl)'s Statement about IPR related to draft-alvestrand-rtcweb-congestion-03 Dear Stefan Holmer, Harald T. Alvestrand: An IPR disclosure that pertains to your Internet-Draft entitled "A Google = Congestion Control Algorithm for Real-Time Communication on the World Wide = Web" (draft-alvestrand-rtcweb-congestion) was submitted to the IETF Secretariat = on 2013-02-22 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1972/). The title of t= he IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement ab= out IPR related to draft-alvestrand-rtcweb-congestion-03.""); The IETF Secretariat _______________________________________________ ipr-announce mailing list ipr-announce@ietf.org https://www.ietf.org/mailman/listinfo/ipr-announce From randell-ietf@jesup.org Sun Mar 10 06:08:10 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 1DE5521F8782 for ; Sun, 10 Mar 2013 06:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 ea6FSgoFy5Jm for ; Sun, 10 Mar 2013 06:08:09 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 87B8D21F874B for ; Sun, 10 Mar 2013 06:08:09 -0700 (PDT) Received: from [216.53.157.5] (port=55277 helo=[10.96.3.64]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UEfyy-000EdC-L7 for rmcat@ietf.org; Sun, 10 Mar 2013 08:08:08 -0500 Message-ID: <513C85B8.2090004@jesup.org> Date: Sun, 10 Mar 2013 09:08:08 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <5135EF72.3090007@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org Subject: Re: [rmcat] Initial comments on draft-jesup-rmcat-reqs-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: Sun, 10 Mar 2013 13:08:10 -0000 On 3/5/2013 10:37 AM, ken carlberg wrote: > bringing up the terms "long-lived" and "short lived" triggered an outside the box thought on the topic. Do you think its reasonable ro feasable to use numbers associated with average call/flow duration as a point of reference of what is considered a "typical real-time flow"? Part of the reason that I bring this up is that I understand that one (maybe more) popular VoIP applications starts with a rather aggressive offered load, and then after some period of time (versus actual feedback) the application backs off to some target measure that takes into account accumulated path characteristics (eg, delay, loss). Perhaps the time delay is to avoid oscilation. > > One can argue that the initial stage of such an approach is not fair, or its excessively greedy (for lack of an alternative term), but that perhaps over time, or an average call/flow duration, it is fair. I've seen numbers that range from 1.8 minutes to 4 minutes in average call duration, and so perhaps this could be a target reference point to gauge how nice various algorithms work with each other. An initial burst at a higher rate may help in some cases (force existing TCP flows into backoff), but can only do so by generating enough delay right at the start of a connection to fill the bottleneck and force loss. So it won't do that - but it will allow a call to function "well" from the start if there is unused (typically local) bandwidth, whereas a classic slow-start may lead to a poor start-of-call experience. In the past, I used bandwidth availability history (and user settings) to select an initial bandwidth I believed was below the likely available, since I wanted good startup quality with minimal chance of getting behind-the-ball. A balance; as usual there's no "right" solution. -- Randell Jesup randell-ietf@jesup.org From lars@netapp.com Mon Mar 11 05:19:37 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 393EF21F866E for ; Mon, 11 Mar 2013 05:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.306 X-Spam-Level: X-Spam-Status: No, score=-10.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 K+G4WLThPSnj for ; Mon, 11 Mar 2013 05:19:35 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id EA60221F8501 for ; Mon, 11 Mar 2013 05:19:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,822,1355126400"; d="scan'208";a="29763082" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 11 Mar 2013 05:19:35 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2BCJZd1004817 for ; Mon, 11 Mar 2013 05:19:35 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Mon, 11 Mar 2013 05:19:35 -0700 From: "Eggert, Lars" To: "rmcat@ietf.org" Thread-Topic: minute taker? Thread-Index: AQHOHlKxsm9tu5BavESB1q/7DcNRJw== Date: Mon, 11 Mar 2013 12:19:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: text/plain; charset="us-ascii" Content-ID: <4DF0D4D1E0B11647ACABBD997AB9E494@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rmcat] minute taker? 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, 11 Mar 2013 12:19:37 -0000 Hi, in the interest of avoiding that awkward pause at the beginning of the meet= ing, where we chairs ask for a minute taker and you all stare at the floor,= if anyone would be willing to take minutes, please drop me a note. Thanks, Lars= From randell-ietf@jesup.org Mon Mar 11 08:02:18 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 5D30511E810F for ; Mon, 11 Mar 2013 08:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcwCCHUbogHr for ; Mon, 11 Mar 2013 08:02:17 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 948D511E8108 for ; Mon, 11 Mar 2013 08:02:17 -0700 (PDT) Received: from dhcp-1229.meeting.ietf.org ([130.129.18.41]:51917) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UF4Ey-000B3i-QL for rmcat@ietf.org; Mon, 11 Mar 2013 10:02:16 -0500 Message-ID: <513DF1FA.4040703@jesup.org> Date: Mon, 11 Mar 2013 11:02:18 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: rmcat@ietf.org 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 Subject: [rmcat] Evaluation criteria - network parameters 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, 11 Mar 2013 15:02:18 -0000 Network Parameters: For each node we have the following possibilities: * LAN (very low delay < 10ms) * Low delay (<40ms ms one-way-delay) <--- Chosen arbitrarily * High delay (>100(?)ms OWD) * Extreme delay (>300ms OWD) (Satellite links, etc) Unspecified is the link capacity (and if it's asymmetric) and description of cross traffic. * WiFi ** fast ** slow/poor signal <----- Need to choose parameters for WiFi ** low-power ** loss rate * 3G/LTE/etc WiFi for edge nodes is a critical usecase. For an entire network, we typically will have mixtures except in the simplest (same LAN/etc) cases. In most cases, the most important parameter will be where the bottleneck is. In some cases, the bottleneck will move from one node to another due to either varying cross traffic, or do due to varying link capacity (WiFi, 3G, etc). Bottlenecks in each direction may be in different nodes. (Frequently with asymmetric links) We should describe what sort of blocks we want to use in the eval scenarios, and then try to define specific sets of network params to measure each scenario. Each scenario will need to be measured with multiple network configurations, though there are too many combinations to test them all (or even close). Things we need to do: Define example characteristics for each type of node we want to use. Define which sets of nodes we want to measure for each topology. Related decision: defining cross-traffic for each topology. -- Randell Jesup randell-ietf@jesup.org From wes@mti-systems.com Mon Mar 11 10:05:01 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 5068A11E8167 for ; Mon, 11 Mar 2013 10:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkjJzuEI4lzg for ; Mon, 11 Mar 2013 10:05:00 -0700 (PDT) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F88321F89E2 for ; Mon, 11 Mar 2013 10:05:00 -0700 (PDT) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r2BH4xK7019332 for ; Mon, 11 Mar 2013 13:04:59 -0400 Received: (qmail 4146 invoked by uid 0); 11 Mar 2013 17:04:59 -0000 Received: from unknown (HELO ?10.11.0.30?) (wes@mti-systems.com@95.211.92.237) by 0 with ESMTPA; 11 Mar 2013 17:04:59 -0000 Message-ID: <513E0EAC.30305@mti-systems.com> Date: Mon, 11 Mar 2013 13:04:44 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , Lars Eggert , Varun Singh Subject: [rmcat] room reserved for side-meeting X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:05:01 -0000 Varun is in charge, but I reserved the IESG Breakout Room (Boca 3) for Tuesday and Thursday mornings from 8 to 9 AM for the "design team" Lars suggested in the meeting today to have a place to talk. I know there was some discussion about potentially meeting outdoors as well, so Varun should let you know where to meet; I'm just letting you know that the room is reserved as a possibility. I should fit 15ish without issue, and might have an easel/notepad to doodle on (but no projector). -- Wes Eddy MTI Systems From vsingh.ietf@gmail.com Mon Mar 11 11:36: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 7FDBE21F8E22 for ; Mon, 11 Mar 2013 11:36: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 QouZzRhi24Rk for ; Mon, 11 Mar 2013 11:36:57 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 303D921F8E21 for ; Mon, 11 Mar 2013 11:36:57 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id k14so5225539iea.27 for ; Mon, 11 Mar 2013 11:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5l0NWM2FBq+BXrWDxI7lVYdyZM7XYS1qW4L0TFAxpBg=; b=Ywr+AWJLeeZ64U4j8bmM0uW61KTsgC7AAPU1GCi0XDD3B2tE1gaIitA+h3QPzr5IOu kMA7P5KEEZUE9e1SFqxkvHnwaFExxxXPBIYLbeYdjepNT70GdiMPyKbTJDO9d6AfsHfP qx9SvrgGw2PK81RXavTFYMgDw/kutHSocX+xcpiGT5DyWQuww6H6tDXYmT2VUQfDqFzz Bjb478Z8w4ltkERV2cpN16NDLzjpFSqB0kpndyW9RRPP0sN6oMFa2lDer1l9iF+ILQOG LFk5NhFa5Ky5F/LA+RfBBtwpo37dnRGdJX2Rnvg4vWPlSxc0cBZDP1TEch12cjPr5D0W j6/A== X-Received: by 10.50.217.167 with SMTP id oz7mr8414163igc.26.1363027016801; Mon, 11 Mar 2013 11:36:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.152.7 with HTTP; Mon, 11 Mar 2013 11:36:36 -0700 (PDT) In-Reply-To: <513E0EAC.30305@mti-systems.com> References: <513E0EAC.30305@mti-systems.com> From: Varun Singh Date: Mon, 11 Mar 2013 14:36:36 -0400 Message-ID: To: rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Cc: Wesley Eddy , Lars Eggert , Martin Stiemerling Subject: Re: [rmcat] room reserved for side-meeting X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:36:58 -0000 Hi all, We will meet in the IESG Breakout Room and if the weather permits, we can move out into the sun. Varun On Mon, Mar 11, 2013 at 1:04 PM, Wesley Eddy wrote: > Varun is in charge, but I reserved the IESG Breakout Room > (Boca 3) for Tuesday and Thursday mornings from 8 to 9 AM > for the "design team" Lars suggested in the meeting today > to have a place to talk. > > I know there was some discussion about potentially meeting > outdoors as well, so Varun should let you know where to meet; > I'm just letting you know that the room is reserved as a > possibility. I should fit 15ish without issue, and might > have an easel/notepad to doodle on (but no projector). > > -- > Wes Eddy > MTI Systems -- http://www.netlab.tkk.fi/~varun/ From lars@netapp.com Mon Mar 11 13:04:01 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 3B5E121F8E06 for ; Mon, 11 Mar 2013 13:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.348 X-Spam-Level: X-Spam-Status: No, score=-10.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 ytoGlnD9OSgT for ; Mon, 11 Mar 2013 13:04:00 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id ABDAC21F8DD5 for ; Mon, 11 Mar 2013 13:04:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,825,1355126400"; d="scan'208";a="29876189" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 11 Mar 2013 13:04:00 -0700 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2BK40MA006951 for ; Mon, 11 Mar 2013 13:04:00 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Mon, 11 Mar 2013 13:03:59 -0700 From: "Eggert, Lars" To: "rmcat@ietf.org" Thread-Topic: confirmation of WG adoption calls Thread-Index: AQHOHpORdnYZFalzFEmheSb69M4zjg== Date: Mon, 11 Mar 2013 20:03:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <7958885C3D195A49BA96C0BC44CF4A18@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rmcat] confirmation of WG adoption calls 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, 11 Mar 2013 20:04:01 -0000 Hi, during the meeting today, I asked for consensus calls to adopt (1) draft-jesup-rmcat-reqs as a starting point for our cc-requirements work= item (2) draft-singh-rmcat-cc-eval as a starting point for our eval-criteria wor= k item For (1), the room as 20-0 in favor of adoption. I'd call this strong consen= sus and would as the author to submit the next revision as a WG item. Pleas= e speak up if you disagree with this notion. For (2), the room was more split, with about 10-5 in favor. I'd like to und= erstand the reservations that kept some people from supporting the consensu= s call. Please send a brief email to the list (or to the chairs personally)= and let us know if you have fundamental objections or would simply see the= document develop a bit further before being able to support it, or any oth= er concerns you may have. We don't have any alternative documents targeting our eval-criteria milesto= ne, and I'm thus at the moment leaning to call a weak consensus for adoptio= n. But I want to make sure we understand the concerns first. Thanks, Lars PS: I'm saying "I" a lot in this email, because I haven't had a chance to s= ync up with Mirja on this yet. From spencer@wonderhamster.org Mon Mar 11 21:18: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 54D7221F87D7 for ; Mon, 11 Mar 2013 21:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 Y11oynMYf-NY for ; Mon, 11 Mar 2013 21:18:21 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 72B2C21F87D6 for ; Mon, 11 Mar 2013 21:18:20 -0700 (PDT) Received: from [130.129.131.159] ([130.129.131.159]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MaJHc-1UUj9F3KfY-00Jxcb; Tue, 12 Mar 2013 00:18:19 -0400 Message-ID: <513EAC88.8080107@wonderhamster.org> Date: Mon, 11 Mar 2013 23:18:16 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: RMCAT Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:Xjz60Kkkw3B2Pt8pyIriWDgbmfufTcXIu6z3t/J8cc7 bcNNeL508y0QDwqjQ4suCPRlN/faqmIPlIptZoH8RWAqCo+Vyf R7y4m1o8nNt3kBwL3rJYnw/3mSbXmBkc8DgJsjTFKm9mXll4Vw ivoico1A/nxszU/7KRQmBMPLZZyPoKkRnwbxWqQKhNau1Pe9Dy zE9C154IKinoJx8jilITxSz5Q6DSgvhvaupK4ZE1qVPYyQiQIR GzBSE0prg0SUVvBfz0+Ck/rqc1wlqbiOGI42dvDOfnLAIqMu+3 nG2bQVS28DeItsB1TRtz5tfspE3zCkfNT5dbRBCV3ZRHA9Tw7v M1VYIMoRfroM9jTuFHiZ+qzlFi6OFJHXdxQFsJk2z Subject: [rmcat] My notes from today's RMCAT session X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 04:18:22 -0000 Lars asked me to take notes at today's session; I'm sending my notes to the list so when I've horribly misunderstood or misquoted you, you can clue me in ... Thanks, Spencer 2013-03 IETF 86 - RMCAT Lars is chairing this meeting solo ... Note Well - thank you, Ericsson for disclosing IPR on a Google draft == Chair Intro We're running late on Requirements, we have one draft to choose from We're running late on Evaluation Criteria and group-cc We aren't sure we need to do rtcp-requirements and application interactions milestones We're going to talk with AD about milestones - proposing 1 year slip for submission to IESG milestones Nothing happened on the mailing list over winter holidays, picking up a little speed now No agenda bashing == Requirements - Randall Jesup Draft was discussed in Atlanta, revised as -01 Reviewing issues we're discussing and haven't closed on Definition of "fair" - we don't have one, and there's not a single definition - doesn't have to be 1x TCP - matters more against longer flows - matters most against other low-delay flows - can't collapse, can't take too long for a new flow to become usable - needs to be bounded if we can't define it - needs to cover both local fairness and aggregate fairness at nodes deeper in the net Other issues - "minimum bandwidth" can be application-defined. - need to think about oscillation and possible "mode-switching" between "fair" and "aggressive" Q and A - anything we can do to bound the problem will help - we know what UNfairness is. Can we define tests for unfairness? - can we describe principles for identifying unfairness? - Lars: this is the biggest issue facing the group, need to make progress this week - can we agree on a list of priorities? - how self-friendly is existing non-real time traffic? - how self-friendly can we be with no other traffic, dedicated nets? - need to think about what else we're competing against -RTCWeb data channels - Matt: one definition is impossible, think about what matters - Lars: we need to form a design team this week - is friendliness part of fairness? - can we come up with a test plan to check for fairness? - Lars: remember that bad congestion control makes it bad for everyone - Colin: decide whether competing with TCP is a short-term goal - Randall: especially competing against short-term TCP flows - Pat: need to notice the effect of fairness constraints on other characteristics Lars: this may be one of the hard problems in computer science, but we're going to solve it before Berlin :-) == Evaluating Congestion Control - Varuna Singh Now at -02 - Open issue: two metrics under discussion, other metrics seem ok - ideally, we do a distribution and then think about what "discard rate" is - needs to be more than one number - we can do things during evaluation we can't do in deployments We've identified 8 evaluation guidelines - do we need a minimum set? - are the identified guidelines sufficient? Have proposed 3 more - Lars: if you are proposing a solution you need to look at proposal - have included a proposal for various evaluation scenario parameters - also want to limit combinatorial explosion of test scenarios - do we use media packet generators or real video streams? - video ends up trying to keep quality consistent, not bit rate - Randall: have to know where the edges are - not one parameter set - Harald: need to be able to show we aren't ruining video experience - Gorry: what happens if your delay exceeds 300ms? Need to separate out the transport aspects and focus on them - we need to start someplace - pick scenarios, parameters - need to use simple and consistent traffic stream - would like to see continuity from requirements draft to this draft - need to characterize requirements for various media types - need to look at multiple network types - wired, WiFi, cellular ... - Magnus: video is so changeable - that's why it's important to look at various media sources Evaluation Scenarios - fixed link capacity, variable link capacity, self-awareness - do all scenarios use the same parameters? - Matt: assuming single queue or multiple? Need to make that explicit - Lars: want some scenarios that do it each way == Working Group Hums Adopt requirements draft? 20 hands yes, no nos Adopt evaluation draft? 10 hands yes, 4 nos What do people want to see in the document to be "yes"? No comments from the mikes == Coupled Congestion Control - Michael Wetzl Controlling groups of flows has been tried in the past - why didn't these see deployment? - hard to identify flows, hard to implement Flow State Exchange (FSE) - Flows register with FSE when they start, stop, change rates - could use various algorithms, but competing flows all use the same one - not priorities, but proportional share - Magnus: need to think about RTCWeb control channels, HTTP, etc - need to figure out shared bottleneck detection, still working on this - browser could use flow table to self-regulate - Dale: if everyone builds the same state table, we can understand more - this would have security implications - current algorithm has two problems: flow told to use rate that's not what congestion manager determined, highly asynchronous flows - can this be sender-side only? Can do better management if receiver is involved (Missed question here) == On the use of RTCP feedback for congestion control - Colin Perkins Thinking about how existing feedback channel works (with AVPF) - Per-packet feedback would be great, but RTCP feedback is much less frequent, and no mechanism to piggyback information - per-video frame? 30 fps gives you 0.033 second RTCP control interval - assuming compound RTCP, but not cross-reporting - per-RTT? Longer than inter-frame interval - Hannes: can't adjust sending rates arbitrarily with most codecs, and frequent quality changes cause problems with user experience anyway - conclusion - RTCP suitable for per-frame, per-RTT, not per-packet - Colin's presentation assumes no RTCP extensions - remember you can lose feedback packets, too. Just need stable control system - don't adjust what we do in RMCAT based on existing codec limitations - may need to accommodate massive sending rate changes - can we ignore the fact that this is audio/video? Video streams are likely to drive congestion, audio is small and you can end up sending more feedback than audio - packet rate in wireless networks more significant than bandwidth, need piggybacking to reduce that - what about sampling? Could give you enough feedback - two issues - how often do you sample, latency for feedback to sender - do we have any minimum requirements that cover feedback? - this isn't easy stuff (and wasn't easy with TCP, either) Colin wrote the draft to generate discussion, not planning to progress == NADA - a unified congestion control scheme for real-time media - Rong Pan Design goals: limit self-inflicted delay, leverage a suite of network feedback mechanisms (loss-based, delay-based, ECN, PCN) Sender does linear prediction to accommodate feedback latency Simulation of NADA with ECN shows improvement in avoiding queue build PCN allows zero standing queue Q and A - PCN? Standards are out but haven't been deployed yet - Rate-shaping buffer on frame basis? Different frame types - I-frames can span packets, and buffering them can degrade predictive calculations for receiving codec - Do you see problems with self-interference after congestion happens? Depends on traffic and where you stabilize - 3-5 percent loss rates in your simulations are very bad for video traffic - If we have a high loss rate, we need FEC or other recovery mechanisms that come with overhead - Have you looked at CoDeL? Not yet ... - How does this compete with TCP? We're looking at that - We don't know if ECN has benefits when you're already doing delay-based mechanisms - Should evaluation criteria look at both loss and delay? Probably not, we're evaluating the results of the algorithms - but we need to look at latency and loss as part of the results - If you cause other people 5 percent loss, that's worse than causing yourself 5 percent loss that you can recover from From dan@marketsoup.com Tue Mar 12 06:51: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 229D321F8AB2 for ; Tue, 12 Mar 2013 06:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 3GTVKc8iJv9A for ; Tue, 12 Mar 2013 06:51:40 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4A15721F8ABC for ; Tue, 12 Mar 2013 06:51:40 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id k13so6326650iea.35 for ; Tue, 12 Mar 2013 06:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type; bh=U5/sGYKD6U7B7r6Tb+YD7oIS1LDNAvi2tYba3n0OVXg=; b=ItPBMYFI+jl2wU/d0WlyowGscLvJsLfADYNe+9BXaJZ3HT6FsNwZ1ONZLwD3aARGqJ 7rKx+or4xIbgqrkVQNSGWbmUsIXCYGdkWZ+56qy5jwhze5+ZiLQPeAl1hNm+mdUxdh6L 30ypzY2mqhcb3qyw8X5Ltt1n4yNliZQ/R/Y10= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=U5/sGYKD6U7B7r6Tb+YD7oIS1LDNAvi2tYba3n0OVXg=; b=jrmPNEtukID8ZgQlF7Qqr/D9KEwiEoz3ueHPo8No4A5/lulolXf0sfbLXqf7XlEDuR l07MW8FeGWxtzgYSsV1WduKZULTdc3wR+Oz1b6ifDle+9qpWw9lMGzDSO5XgA1kwv3k0 VPxAzu542LviVw0jjXiJMA6YPul1gzR3PtftTVS1sTuc7PzStBAb73nVG07tBfOWsp9d ueH5xAqhtgCOf68ZM7ZxjKwDp5qwjWpt/bkFcKLntsbt7ek20cx1Mocbyl/OdQkPBXVe Zu9YTJIk2dCEb1YKKodAVkaQ1Rjw3bLUTCz/H7GeOxPBd5IEObm01zPZf8Rvp1YYbtSy iw6Q== MIME-Version: 1.0 X-Received: by 10.42.155.136 with SMTP id u8mr12513675icw.26.1363096299822; Tue, 12 Mar 2013 06:51:39 -0700 (PDT) Received: by 10.43.118.73 with HTTP; Tue, 12 Mar 2013 06:51:39 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:241d:96e8:9ea3:9b4] Date: Tue, 12 Mar 2013 07:51:39 -0600 Message-ID: From: Dan Weber To: rmcat@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e817abf199d04d7ba9605 X-Gm-Message-State: ALoCoQkbrfDeUAKTP7DndclYENr5Z7hLtAepjmIFDO4L3I3yERstg1QIpNU76h+d7gJfN2WfE5Ba Subject: [rmcat] ICCRG White Paper on Managing Network Uncertainty X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 13:51:42 -0000 --90e6ba6e817abf199d04d7ba9605 Content-Type: text/plain; charset=UTF-8 Hi everyone, Varun suggested this paper: End-to-End Transmission Control by Modeling Uncertainty about the Network State ( http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final100.pdf) This is worth a look when discussing our evaluation criteria. Thanks, Dan --90e6ba6e817abf199d04d7ba9605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi everyone,

Varun suggested this paper:=C2=A0End-to-End= Transmission Control by Modeling Uncertainty about the Network State (http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final100.= pdf)

This is worth a look when discussing our evaluation cri= teria.

Thanks,
Dan

--90e6ba6e817abf199d04d7ba9605-- From vsingh.ietf@gmail.com Tue Mar 12 07:00:00 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 D3A8A21F8ABA for ; Tue, 12 Mar 2013 07:00:00 -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 H3JraN4cgVsk for ; Tue, 12 Mar 2013 07:00:00 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEB421F8AAD for ; Tue, 12 Mar 2013 06:59:59 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id c13so6274875ieb.23 for ; Tue, 12 Mar 2013 06:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=JOthuyiF5jPlB35JBx4EbancQ+LLVHFwnYEuSYDgvuc=; b=Au4jrIyN1ImMJe9TaWopgDswB0aKys5owTIUsCDoeATcB9fueELlugG7bg5Frsmb9U u8ZEk58PLi666Pkp5TlVrMe7xmhvIYSS/kIfhgGPkwCNfLpnAKSj66xvN2/bfvViJcnH zYQPcfJTOXIXy3Wvg4J1L0U33oVazqYxATEbt+/Nfgfv35XMNK3EV4BHiUfZLSV6kkQg yXR4F7WvhjRq28budf2MCyLYXcKqoW2OWGGpRyAa8ernCW2SuqtNZQuiLcJL+jwY5Uun 0T1JoexLkeJrGq3eWQdn6WfnAcUUHvyGJ++Zrso+NIasDNJVWv6CINnBUitdSbHUfN5z qYxA== X-Received: by 10.50.103.33 with SMTP id ft1mr11605702igb.26.1363096799042; Tue, 12 Mar 2013 06:59:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.152.7 with HTTP; Tue, 12 Mar 2013 06:59:38 -0700 (PDT) From: Varun Singh Date: Tue, 12 Mar 2013 09:59:38 -0400 Message-ID: To: rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [rmcat] Design Meeting 1 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:00:00 -0000 Hi all, The discussion yielded the following application scenarios (network scenarios/link characteristics will be discussed separately): 0. Single Flow (no fairness) 1. Competing with the same/homogeneous flows (i.e., all flows are interactive multimedia) 2. Competing with long-lived TCP 3. Competing with bursty TCP 4. Competing with bitorrent/LEDBAT. 5. Competing with unresponsive interactive multimedia (i.e., not only CBR) --- 6. Competing with data-channel (probably covered by bursty/long-lived tcp flows?) These are an initial list of application scenarios, if anyone has additional scenarios, send them to the list before the next design meeting session on Thursday (see below). So that we consider it for the fairness discussion. If you missed the session today and are interested to contribute, you are welcome to join the next session on Thursday (see below) Thursday Agenda (14 March): Location: (8-9am, Room: Boca III) Recap (5mins) Network scenarios Flow scenarios History of Fairness (15mins, Bob Briscoe volunteered to present) Principles of Fairness If required, we will have an additional session on Thursday/Friday. Attendees today (tuesday): Kevin Gross Bob Briscoe Michael Ramalho Zahed Sarker Colin Perkins Randell Jesup Dan Weber Varun Singh Wes Eddy -Varun -- http://www.netlab.tkk.fi/~varun/ From zaheduzzaman.sarker@ericsson.com Tue Mar 12 07:23:17 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 E4ABB21F8B4C for ; Tue, 12 Mar 2013 07:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 fAE2YsXWrVVt for ; Tue, 12 Mar 2013 07:23:16 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 777D121F899E for ; Tue, 12 Mar 2013 07:23:14 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-ba-513f3a517f59 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AA.1A.10459.15A3F315; Tue, 12 Mar 2013 15:23:13 +0100 (CET) Received: from [153.88.47.35] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 12 Mar 2013 15:23:12 +0100 Message-ID: <513F3A4D.4040509@ericsson.com> Date: Tue, 12 Mar 2013 15:23:09 +0100 From: Zaheduzzaman Sarker Organization: Ericsson AB User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Varun Singh References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42KZGfG3RjfQyj7QYMFxDYvVNz+wWext8ndg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4MvbumcBWcF+w4tPibvYGxm6+LkZODgkBE4k7 L96yQthiEhfurWfrYuTiEBI4ySixvfkPM4SzilFiwZduJpAqXgFtiUfrm1hAbBYBVYk/044C dXNwsAnYSDxe7AcS5heQlNjQsJsZJCwqECVxZZ8lRKegxMmZT1hAwiIC6hIHb/iAhJkFZCWu v93JBmILAw2cfWopG0iJkECAxJxFmiBhToFAiR8/17NBlNtKXJhznQXClpdo3jqbGaJcV6Lr ZdwERqFZSHbNQtIxC0nHAkbmVYzsuYmZOenlhpsYgQF6cMtv3R2Mp86JHGKU5mBREucNc70Q ICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoEx0fvCyobJtQt5r//h8DO+KdtyPmQGX+KOO9JZ 708clHNudzzOsW1yzsnC1rcnDq0IPn3Bc4tEjr7Mqah1vazK72O/h3/vkUiS/rFqgoO10JLN BkL/lun+cJziPe+f878fJ48L/DlTHlIs+N3wJ/fUO92JP45mBP8MMSnKuXEtoO2b/NGH4p7B SizFGYmGWsxFxYkAkYtaoB4CAAA= Cc: rmcat WG Subject: Re: [rmcat] Design Meeting 1 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:23:17 -0000 Hi, it is important to note that the scenarios discussed in the design team meeting are those where we think "fairness" matters. These are not complete set of evaluation scenarios. Our focus was "fairness" and we started with identifying set of scenarios where we want to see the "fairness". The idea is to come up with principles that will help achieving fairness in those scenarios. BR Zahed On 2013-03-12 14:59, Varun Singh wrote: > Hi all, > > The discussion yielded the following application scenarios > (network scenarios/link characteristics will be discussed > separately): > > 0. Single Flow (no fairness) > 1. Competing with the same/homogeneous flows > (i.e., all flows are interactive multimedia) > 2. Competing with long-lived TCP > 3. Competing with bursty TCP > 4. Competing with bitorrent/LEDBAT. > 5. Competing with unresponsive interactive multimedia > (i.e., not only CBR) > --- > 6. Competing with data-channel > (probably covered by bursty/long-lived tcp flows?) > > These are an initial list of application scenarios, if anyone has > additional scenarios, send them to the list before the next design > meeting session on Thursday (see below). So > that we consider it for the fairness discussion. > > If you missed the session today and are interested to contribute, > you are welcome to join the next session on Thursday (see below) > > Thursday Agenda (14 March): > Location: (8-9am, Room: Boca III) > > Recap (5mins) > Network scenarios > Flow scenarios > History of Fairness (15mins, Bob Briscoe volunteered to present) > Principles of Fairness > > If required, we will have an additional session on Thursday/Friday. > > Attendees today (tuesday): > Kevin Gross > Bob Briscoe > Michael Ramalho > Zahed Sarker > Colin Perkins > Randell Jesup > Dan Weber > Varun Singh > Wes Eddy > > -Varun > > > -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies Laboratoriegränd 11 97128 Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ================================================== From csp@csperkins.org Tue Mar 12 19:47:12 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 5817821F8596 for ; Tue, 12 Mar 2013 19:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4, 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 8TT5Ie65UmwN for ; Tue, 12 Mar 2013 19:47:11 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9328611E80F9 for ; Tue, 12 Mar 2013 19:47:10 -0700 (PDT) Received: from [130.129.70.145] (port=52667 helo=dhcp-4691.meeting.ietf.org) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UFbid-0007Fv-Sr; Wed, 13 Mar 2013 02:47:09 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_33C6ED5A-B80A-4AD3-9A5F-8C3FED4C6ACF" From: Colin Perkins In-Reply-To: Date: Tue, 12 Mar 2013 22:47:05 -0400 Message-Id: <23969000-A71B-4A37-93B9-F9D67206B346@csperkins.org> References: <20130218232842.19535.91395.idtracker@ietfa.amsl.com> <8471CA16-DC31-4AFD-ABEF-558ABB79AE31@csperkins.org> To: Fu Jiantao X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rmcat@ietf.org Subject: Re: [rmcat] I-D Action: draft-perkins-rmcat-rtp-cc-feedback-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 02:47:12 -0000 --Apple-Mail=_33C6ED5A-B80A-4AD3-9A5F-8C3FED4C6ACF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 4 Mar 2013, at 23:41, Fu Jiantao wrote: > Hi Colin, >=20 > I've got the following comments: >=20 > 1."there is little point in providing feedback more often than the = codec can adapt", i think there is no need to send those overlimits data = onto the network if we've got feedback that the network is congested, so = i think it make sense if there is traffic shaper on the sender side, = those overlimit packets can buffered and dropped at the sender side, = rather than sending them to the network which affects other traffics. This draft isn't proposing a congestion control algorithm, it's = exploring the space of possible feedback using RTCP as defined. It might = make sense to send feedback as you suggest.=20 > 2. How about ack in a given interval, this can be treat as variant = of per-frame ack(several frames per ack). This is another kind which has = less load than per-frame ack. Sure. > 3. There can be adaptive feedback which feedback when there is need = to do so, for example, when the given interval is not enough for the = adaption(the queuing delay goes large very fast), the feedback can be = accelerated in this case. I agree that this is an option. > 4. The feedback strategy has some relationship with = sender-based/receiver-based, is this in the scope of this draft? I'm not intending to progress this draft, but it's certainly an issue to = consider when designing a congestion control algorithm. Colin > Thanks >=20 > Jeromy >=20 >=20 > 2013/2/26 Colin Perkins > I submitted the following draft that talks about the types of = congestion control feedback that can be sent using RTCP as is currently = specified, and their suitability for implementing congestion control for = unicast multimedia applications. In particular, it talks about the rate = of congestion feedback that can be supported. >=20 > Comments are welcome. I'm also happy to present this in Orlando, if = the chairs think it useful. >=20 > Colin >=20 >=20 >=20 >=20 > Begin forwarded message: > > From: internet-drafts@ietf.org > > Subject: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-00.txt > > Date: 18 February 2013 23:28:42 GMT > > To: i-d-announce@ietf.org > > Reply-To: internet-drafts@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > > > > > Title : On the Use of RTP Control Protocol (RTCP) = Feedback for Unicast Multimedia Congestion Control > > Author(s) : Colin Perkins > > Filename : draft-perkins-rmcat-rtp-cc-feedback-00.txt > > Pages : 8 > > Date : 2013-02-18 > > > > Abstract: > > This memo discusses the types of congestion control feedback that it > > is possible to send using the RTP Control Protocol (RTCP), and their > > suitability of use in implementing congestion control for unicast > > multimedia applications. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-perkins-rmcat-rtp-cc-feedback > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-perkins-rmcat-rtp-cc-feedback-00 >=20 >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 >=20 --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_33C6ED5A-B80A-4AD3-9A5F-8C3FED4C6ACF Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 4 Mar 2013, at 23:41, Fu Jiantao wrote:
Hi Colin,

   I've got the following comments:

  1."there is little point in providing feedback more often than the codec can adapt", i think there is no need to send those overlimits data onto the network if we've got feedback that the network is congested, so i think it make sense if there is traffic shaper on the sender side, those overlimit packets can buffered and dropped at the sender side, rather than sending them to the network which affects other traffics.

This draft isn't proposing a congestion control algorithm, it's exploring the space of possible feedback using RTCP as defined. It might make sense to send feedback as you suggest. 

  2. How about ack in a given interval, this can be treat as variant of per-frame ack(several frames per ack). This is another kind which has less load than per-frame ack.

Sure.

  3. There can be adaptive feedback which feedback when there is need to do so, for example, when the given interval is not enough for the adaption(the queuing delay goes large very fast), the feedback can be accelerated in this case.

I agree that this is an option.

  4. The feedback strategy has some relationship with sender-based/receiver-based, is this in the scope of this draft?

I'm not intending to progress this draft, but it's certainly an issue to consider when designing a congestion control algorithm.

Colin




Thanks

Jeromy


2013/2/26 Colin Perkins <csp@csperkins.org>
I submitted the following draft that talks about the types of congestion control feedback that can be sent using RTCP as is currently specified, and their suitability for implementing congestion control for unicast multimedia applications. In particular, it talks about the rate of congestion feedback that can be supported.

Comments are welcome. I'm also happy to present this in Orlando, if the chairs think it useful.

Colin




Begin forwarded message:
> From: internet-drafts@ietf.org
> Subject: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-00.txt
> Date: 18 February 2013 23:28:42 GMT
> To: i-d-announce@ietf.org
> Reply-To: internet-drafts@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>       Title           : On the Use of RTP Control Protocol (RTCP) Feedback for Unicast Multimedia Congestion Control
>       Author(s)       : Colin Perkins
>       Filename        : draft-perkins-rmcat-rtp-cc-feedback-00.txt
>       Pages           : 8
>       Date            : 2013-02-18
>
> Abstract:
> This memo discusses the types of congestion control feedback that it
> is possible to send using the RTP Control Protocol (RTCP), and their
> suitability of use in implementing congestion control for unicast
> multimedia applications.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-perkins-rmcat-rtp-cc-feedback
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-perkins-rmcat-rtp-cc-feedback-00


--
Colin Perkins
http://csperkins.org/







-- 
Colin Perkins



--Apple-Mail=_33C6ED5A-B80A-4AD3-9A5F-8C3FED4C6ACF-- From dan@marketsoup.com Wed Mar 13 20:57:51 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 DD87C11E80A3 for ; Wed, 13 Mar 2013 20:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.339 X-Spam-Level: X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaEq+tar1fT3 for ; Wed, 13 Mar 2013 20:57:51 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBAF11E809C for ; Wed, 13 Mar 2013 20:57:50 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id 9so2476146iec.32 for ; Wed, 13 Mar 2013 20:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type; bh=25UcQAuGBKRY5SMmT0zU2yj1cFSEUj90P5NzLGbbLOY=; b=RUQsoRjgEHYhyfpXWNS/SgXE7c0OCPWxRLSidwN7+PNwPoTqXi6Ug2upMTarGWLyMr sxwGb1N4UL8rW7Yt5nR9QtUXOvqTjgJLlaAiHwhLSDlvNW1VH0Xof6/WGyl3obKL3+cp NV3fwl4kbwey3lKOTKMZBErCYtmQ51e4Zlgpw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=25UcQAuGBKRY5SMmT0zU2yj1cFSEUj90P5NzLGbbLOY=; b=BSB1BMEBFZMmDzRDaTuy5/UiPovfIMfSHx3Yfq4F9GhNInyoA53uq6yZzktvQdbQHn x8zjp0gTnuSPAj1i8W4JR0/vH6u6fKpNwg85WR738ouvS/ALWUNaM7MSXkfzKq5NFOlN UJjAxUu0Rgv887UZ93brZVSB1JOWdTgTbsq0mgT33hKL+L/8iq77WTW/GLAntfPF8fGT uXZrBVuJGeAybikPmRo6TBWC1GyigrfhDuHhR7q/KfSW8rrsMH8d//vMv7LoE4p9qv/M M0aluDIviwz9JbeM9uUZwKG2wqfUcExwJ8rKH66LZ0ZpKfP4XX3CYtkhNNhIp7OvvXmA MIhw== MIME-Version: 1.0 X-Received: by 10.43.62.12 with SMTP id wy12mr770533icb.19.1363233469409; Wed, 13 Mar 2013 20:57:49 -0700 (PDT) Received: by 10.42.55.209 with HTTP; Wed, 13 Mar 2013 20:57:49 -0700 (PDT) X-Originating-IP: [174.51.153.161] Date: Wed, 13 Mar 2013 21:57:49 -0600 Message-ID: From: Dan Weber To: rmcat@ietf.org Content-Type: multipart/alternative; boundary=bcaec51d2980b1aac104d7da86f0 X-Gm-Message-State: ALoCoQlZs9jw02p8XYcUucgNNAd8TOc7z0SWoqTMEuV6fewrSR/DO975+vDod7zuqm1k1Hh29Q7Z Subject: [rmcat] RMCAT Evaluation Ideas 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, 14 Mar 2013 03:57:52 -0000 --bcaec51d2980b1aac104d7da86f0 Content-Type: text/plain; charset=UTF-8 Hi everyone, While I sat on the airplane today, it became clear to me that there is a reasonable way to do some evaluation of congestion control algorithms that can be both indicative of real use cases (e.g. live streaming video) while also being easy to test (e.g. fixed rate packet generators). Three ideas here: 1. Test cases We will never agree on what a definition of fairness is, and I think it is a lost cause. However, we can definitely reach consensus on expected behavior given various test cases. Behavioral driven design gives us a great method for defining these. It follows the form (given the facts (concrete verifiable constants), when action or event occurs, then I expect it to do XYZ.). I will start a separate thread kicking this off. 2. Packet Generator Model After re-reading Varun's draft and speaking with him on the evaluation scenarios, I think it makes enough sense to build a packet generator to implement what he suggests. The time involved isn't substantial, and it can help us get a unified starting point for testing even if we decide to change it later. It's worth at least this much. My proposed implementation of this will be able to simulate real video traffic as well as fixed packet generator traffic. For the real video traffic, it can be fed a CSV file filled with frame sizes and RTP timestamps. For the fixed generator traffic, ladder steps can be used. I'm thinking I'll start a project on Google Code, and make any interested participant a developer. 3. Evaluation Metrics We need an initial set of metrics for testing any congestion control algorithm. To evaluate any congestion control algorithm, we'll want enough data to build our favorite line charts. For simplicity, all metrics should be sampled per second (maybe per millisecond?). This also allows us to work with real test environments easily. Here is my initial and non-exhaustive list of metrics (based off of the draft): [Received] In Kbit/s [Sent] Out Kbit/s Packets sent/second, Packets received/second, Packets lost/second [Determined by using standard RTP packet loss calculations] RTT/s Discards per second [ use a range of buffer calculations, 20ms 40ms, 100ms, 200ms, 500ms] These metrics should be built into an RTP stack that we standardize for testing. My two preferences are jrtplib (C++) and libjitsi (Java). At least with both of these, we can contact the authors and get any bugs fixed if we need them relatively easily. Thanks, Dan --bcaec51d2980b1aac104d7da86f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi everyone,

While I sat on the airplane today, it becam= e clear to me that there is a reasonable way to do some evaluation of conge= stion control algorithms that can be both indicative of real use cases (e.g= . live streaming video) while also being easy to test (e.g. fixed rate pack= et generators).

Three ideas here:

1. Test case= s
We will never agree on what a definition of fairness is, and I = think it is a lost cause. =C2=A0However, we can definitely reach consensus = on expected behavior given various test cases.

Behavioral driven design gives us a great method for de= fining these. =C2=A0It follows the form (given the facts (concrete verifiab= le constants), when action or event occurs, then I expect it to do =C2=A0XY= Z.). =C2=A0I will start a separate thread kicking this off.


2. Packet Generator Model
Afte= r re-reading Varun's draft and speaking with him on the evaluation scen= arios, I think it makes enough sense to build a packet generator to impleme= nt what he suggests. =C2=A0The time involved isn't substantial, and it = can help us get a unified starting point for testing even if we decide to c= hange it later. =C2=A0It's worth at least this much.

My proposed implementation of this will be able to simu= late real video traffic as well as fixed packet generator traffic. =C2=A0Fo= r the real video traffic, it can be fed a CSV file filled with frame sizes = and RTP timestamps. =C2=A0For the fixed generator traffic, ladder steps can= be used. =C2=A0I'm thinking I'll start a project on Google Code, a= nd make any interested participant a developer.


3. Evaluation Metrics

We need an initial set of metrics for testing any congestion control= algorithm. =C2=A0To evaluate any congestion control algorithm, we'll w= ant enough data to build our favorite line charts. =C2=A0For simplicity, al= l metrics should be sampled per second (maybe per millisecond?). =C2=A0This= also allows us to work with real test environments easily.

Here is my initial and non-exhaustive list of metrics (= based off of the draft):

[Received] In Kbit/s
[Sent] Out Kbit/s
Packets sent/second,
Packets re= ceived/second,=C2=A0
Packets lost/second [Determined by using standard RTP packet loss calc= ulations]
RTT/s
Discards per second [ use a range of bu= ffer calculations, 20ms 40ms, 100ms, 200ms, 500ms]


These metrics should be built into an RTP stack that we= standardize for testing. =C2=A0My two preferences are jrtplib (C++) and li= bjitsi (Java). =C2=A0At least with both of these, we can contact the author= s and get any bugs fixed if we need them relatively easily.

Thanks,
Dan

--bcaec51d2980b1aac104d7da86f0-- From dan@marketsoup.com Wed Mar 13 21:20:50 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 36C2A11E80A3 for ; Wed, 13 Mar 2013 21:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.134 X-Spam-Level: X-Spam-Status: No, score=-0.134 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaUd0eXsmc4g for ; Wed, 13 Mar 2013 21:20:49 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2CD11E80EF for ; Wed, 13 Mar 2013 21:20:48 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id y26so285280iab.23 for ; Wed, 13 Mar 2013 21:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type; bh=MmU4Tb3x0NGiySh45YhUN/rjqU+Q5RLv6Ww7f63Lufk=; b=ITtXbgehsgj+ipP8dGJtc9jKYs8NgRBvvG+f3TsvPF6MrmL+MJzVx8ks4KzQ0H+SIA EsBkjwl4skEYgCfKDeJBo3qrG1TexJXbPRPNep2pc+BoVFP7EiWBjvgqdeuT3gN7LSEI 9AivNBtO/9sgZTXj03Kew/uniIh9ZT7Rrk/ZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=MmU4Tb3x0NGiySh45YhUN/rjqU+Q5RLv6Ww7f63Lufk=; b=gAwbpZ7mKs53b+T2jkPWg7TSnRUHNdHQZnzMHz7w2WgG+k/9ez6HCksvEOR8UI4PNS JZAhlbgQB8lyNL2X90o0J7nuVMjj/VL3VXEGSpl9BhVX26iVx9/4AVyBHT1+9Scd1lJ9 XEC7QZI0SR6/mi2uaOBscwucOAbJ8g1eBAA4vscyM+vmb64MtV5P4XSN+3Jfv4YugECW voxD9dLFV/ApzmPvvvjQAGMHaw9QCQ+VFLln8NirJZkskj0k9fGPx9DZ7UW8yDzOPUYc /Wr8jy+pS4qt4SNS4c7ZOFpEX2GpetXYG3p1AB9NyDIa+btVkcH29sBeg1pbnGbipg8F /ApA== MIME-Version: 1.0 X-Received: by 10.50.192.138 with SMTP id hg10mr18264328igc.95.1363234846946; Wed, 13 Mar 2013 21:20:46 -0700 (PDT) Received: by 10.42.55.209 with HTTP; Wed, 13 Mar 2013 21:20:46 -0700 (PDT) X-Originating-IP: [174.51.153.161] Date: Wed, 13 Mar 2013 22:20:46 -0600 Message-ID: From: Dan Weber To: rmcat@ietf.org Content-Type: multipart/alternative; boundary=14dae9340717cc4dab04d7dad8c0 X-Gm-Message-State: ALoCoQlrV95Z7R0XagJWvBEGrnhYyGDIu5y4feJn6v9iB5hKf1d0Pm7sGBxCGo9GoSNjKSPIRKVA Subject: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 04:20:50 -0000 --14dae9340717cc4dab04d7dad8c0 Content-Type: text/plain; charset=UTF-8 Hi there, This is the first and example behavior test case based on the concept I proposed in "RMCAT Evaluation Ideas". Please add your own following the same format. I seek to aggregate all of these test cases onto a wiki and establish categories for them. Given: A video media stream sends at 512kbit/s on a link with an upstream capacity of 512 kbit/s When: an FTP Transfer of 1GB file begins uploading Then: Packet loss occurs. Throughput should be diminished. RTPCC should notify application of developments. Given: A link with capacity limited at 512 kbit/s When: A video conference call starts sending Mulaw audio (ptime=20, 81.92kbit/s) and Video @ max kbitrate of 384 kbit/s Then: All packets should be received. ... This may need more work, but it can get us going in the right direction. Thanks, Dan --14dae9340717cc4dab04d7dad8c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi there,

This is the =C2=A0first and example behavior t= est case based on the concept I proposed in "RMCAT Evaluation Ideas&qu= ot;. =C2=A0Please add your own following the same format. =C2=A0I seek to a= ggregate all of these test cases onto a wiki and establish categories for t= hem.


Given: A video media stream sends at 512= kbit/s on a link with an upstream capacity of 512 kbit/s=C2=A0
Wh= en: an FTP Transfer of 1GB file begins uploading
Then: Packet los= s occurs. =C2=A0Throughput should be diminished. =C2=A0RTPCC should notify = application of developments.

Given: A link with capacity limited at 512 kbit/s
=
When: A video conference call starts sending Mulaw audio (ptime=3D20, = 81.92kbit/s) and Video @ max kbitrate of 384 kbit/s
Then: =C2=A0A= ll packets should be received.

...

This may need more work, b= ut it can get us going in the right direction.

Tha= nks,
Dan
--14dae9340717cc4dab04d7dad8c0-- From sergio.garcia.murillo@gmail.com Thu Mar 14 02:04:31 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA5F21F8F15 for ; Thu, 14 Mar 2013 02:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.143 X-Spam-Level: X-Spam-Status: No, score=-0.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebx2JSHd3Na6 for ; Thu, 14 Mar 2013 02:04:30 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6E99821F8EEC for ; Thu, 14 Mar 2013 02:04:30 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id s43so1829024wey.7 for ; Thu, 14 Mar 2013 02:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3oNYWwF6IKydhwCgmAYJ5uYzGjYk4r+yHUm8ITdKPk0=; b=hL/tKh01TrYjN3IHJw5WaOcUIa7dpArfpE54YM3Eeqv07j13bIHAxi26aUquGOEFGf pb1X7JhA86+lNqJIcsVcLDf2lioywgP6pnd4Y1MMoT/Qp5eeQAP3JuUoy66xI4FhDhVo kHbs3bHwXB9k/s3xGGt1PnJI9q2d82KiymZhGeZWbIvao98zJhFAxrR266sWcO7tB5Jv AZ/y0M0xpLmd+sPoSwcGAFe3YHQF1O6ySOnuoPHdp38Fe+nSrmQGwxYWDMAanZI/XwYW V5Ps9+/v3dtcg4YtnTcOErw/73aNx/guhlMnDT39QgZf9Gpdj0oZnvLgUnLyjV/6mYTh vamg== X-Received: by 10.194.133.198 with SMTP id pe6mr2440641wjb.9.1363251869613; Thu, 14 Mar 2013 02:04:29 -0700 (PDT) Received: from [192.168.1.45] ([90.168.194.177]) by mx.google.com with ESMTPS id ek4sm7606397wib.11.2013.03.14.02.04.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 02:04:28 -0700 (PDT) Message-ID: <5141929A.6040500@gmail.com> Date: Thu, 14 Mar 2013 10:04:26 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: rmcat@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rmcat] RMCAT Evaluation Ideas 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, 14 Mar 2013 09:04:31 -0000 Hi Dan, I made a testing tool to test my rate adaptation algorithm implementation in my MCU. You can find the source code here: http://sourceforge.net/p/mcumediaserver/code/745/tree/trunk/cca/ It consist on a random packet generator (which can be parametrized to emulate certain video behaviors, like different sizes for I/P frames) and a receiever. I implementes a full RTP/RTCP stack with preliminary support for NACK and FEC (which I think it is essential for evaluating the behavior of the algorithm). The current algorithm implemented is based on google's congestion control algorithm, but it could be also interesting to create a comon interface so we could test different algorithms and compare between them. Best regards Sergio El 14/03/2013 4:57, Dan Weber escribió: > Hi everyone, > > While I sat on the airplane today, it became clear to me that there is > a reasonable way to do some evaluation of congestion control > algorithms that can be both indicative of real use cases (e.g. live > streaming video) while also being easy to test (e.g. fixed rate packet > generators). > > Three ideas here: > > 1. Test cases > We will never agree on what a definition of fairness is, and I think > it is a lost cause. However, we can definitely reach consensus on > expected behavior given various test cases. > > Behavioral driven design gives us a great method for defining these. > It follows the form (given the facts (concrete verifiable constants), > when action or event occurs, then I expect it to do XYZ.). I will > start a separate thread kicking this off. > > > 2. Packet Generator Model > After re-reading Varun's draft and speaking with him on the evaluation > scenarios, I think it makes enough sense to build a packet generator > to implement what he suggests. The time involved isn't substantial, > and it can help us get a unified starting point for testing even if we > decide to change it later. It's worth at least this much. > > My proposed implementation of this will be able to simulate real video > traffic as well as fixed packet generator traffic. For the real video > traffic, it can be fed a CSV file filled with frame sizes and RTP > timestamps. For the fixed generator traffic, ladder steps can be > used. I'm thinking I'll start a project on Google Code, and make any > interested participant a developer. > > > 3. Evaluation Metrics > > We need an initial set of metrics for testing any congestion control > algorithm. To evaluate any congestion control algorithm, we'll want > enough data to build our favorite line charts. For simplicity, all > metrics should be sampled per second (maybe per millisecond?). This > also allows us to work with real test environments easily. > > Here is my initial and non-exhaustive list of metrics (based off of > the draft): > > [Received] In Kbit/s > [Sent] Out Kbit/s > Packets sent/second, > Packets received/second, > Packets lost/second [Determined by using standard RTP packet loss > calculations] > RTT/s > Discards per second [ use a range of buffer calculations, 20ms 40ms, > 100ms, 200ms, 500ms] > > > These metrics should be built into an RTP stack that we standardize > for testing. My two preferences are jrtplib (C++) and libjitsi > (Java). At least with both of these, we can contact the authors and > get any bugs fixed if we need them relatively easily. > > Thanks, > Dan From holmer@google.com Thu Mar 14 02:32:25 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA3021F8E77 for ; Thu, 14 Mar 2013 02:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 KwIzQqjjFbUf for ; Thu, 14 Mar 2013 02:32:21 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 86F4221F8E75 for ; Thu, 14 Mar 2013 02:32:20 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hm14so3543508wib.15 for ; Thu, 14 Mar 2013 02:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=foJW2btU8Pddwtz3C4hHLM5f/9hIPtmnY/EJxQwoZdA=; b=YZQBFth77kTq+uDCegiLUPMV7Dsds6dj2TUKRFgknpxyFC8bTxurZP7XDyY1k+vziZ v05pSROVWkv3QXTivxR3JuPuaUX7C8+ZnAnt1tj07GrBIkPDBXJ/pLd8+RT1D3lNQndg 8BRSJt9rGSxd7y5lKtix0V4oeUrDh1/Kirp3q/9aTFKqTRXv962bmZxWuZR0ET/MZ/2k PW+zBIfVmMg8LjuuOqFQd+NQHCwnAij//+17NNEDuxHjm63yTycyAM68Sr7va0IFNk6n etDhls3+WtJxK8YlMPJMtWy7ZX5qL58hHfUP8HVCeICja7HkyoMPHXDRm5C0pZLE+LdV ntwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=foJW2btU8Pddwtz3C4hHLM5f/9hIPtmnY/EJxQwoZdA=; b=R+unyiAXmjD5CbmsgVl2VMGvSXWhvdO8ymK90lVNrHjQXiuB7xLLrZ2+wAKeoAKg2r IROM6d71LY4XXodnXhOrBx2N64a91IyNDVcdqMGW60SrIWjwb/APto+pwaXegi9A8mcz B+mb78f2jAq/OpVAFMbHYLFa8MJIsC/b+BZhhVcFwhDQ+CixnVAfMruUlgbiMzOhLy4A 9A6KzCgNzXvPUFRlMBbROFcR8XVuIiqxj0bPEvJeeRSHua7+jlGY8mEYNKYz3B0V9gtH Td3fynsne54x/EHXp9wCgCrHdSiiS9yaohsmHoipyng1e91grflFtBQkQH9o1n2WyF+C 7w3w== MIME-Version: 1.0 X-Received: by 10.194.21.233 with SMTP id y9mr2474526wje.47.1363253539450; Thu, 14 Mar 2013 02:32:19 -0700 (PDT) Sender: holmer@google.com Received: by 10.194.172.3 with HTTP; Thu, 14 Mar 2013 02:32:19 -0700 (PDT) In-Reply-To: <5141929A.6040500@gmail.com> References: <5141929A.6040500@gmail.com> Date: Thu, 14 Mar 2013 10:32:19 +0100 X-Google-Sender-Auth: jlHf0HN4Y1KFxVkGSU2tK1PuZ8s Message-ID: From: Stefan Holmer To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=047d7b5d2774f5516a04d7df32d1 X-Gm-Message-State: ALoCoQnY2JQABOYHE76V2kvrgQM753ltOAxKbXUFa52CBFNqlHiAoCoYTVDrm8SVlLAWiAOvxFRdfqgG/okkcjenn+raGxGNsiV+OtAzwDNY6cKEVWrZprRCydCr/rXNxqrzqsFMuNwqiakmdZR/123DI1MYT3pnu959QF6zWJXdKsnx6KCbPr/XjBcaBMJIa6wQf7fdocP8 Cc: rmcat WG Subject: Re: [rmcat] RMCAT Evaluation Ideas 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, 14 Mar 2013 09:32:26 -0000 --047d7b5d2774f5516a04d7df32d1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Another option could be to develop something based on the RTP stack on http://webrtc.googlecode.com. We have some legacy code which contains, among other things, various load generators, but it hasn't been used for quite some time, so I think it would need a bit of work to get back to a working state. /Stefan On Thu, Mar 14, 2013 at 10:04 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Hi Dan, > > I made a testing tool to test my rate adaptation algorithm implementation > in my MCU. You can find the source code here: > > http://sourceforge.net/p/**mcumediaserver/code/745/tree/**trunk/cca/ > > It consist on a random packet generator (which can be parametrized to > emulate certain video behaviors, like different sizes for I/P frames) and= a > receiever. I implementes a full RTP/RTCP stack with preliminary support f= or > NACK and FEC (which I think it is essential for evaluating the behavior o= f > the algorithm). > > The current algorithm implemented is based on google's congestion control > algorithm, but it could be also interesting to create a comon interface s= o > we could test different algorithms and compare between them. > > Best regards > Sergio > > El 14/03/2013 4:57, Dan Weber escribi=F3: > > Hi everyone, >> >> While I sat on the airplane today, it became clear to me that there is a >> reasonable way to do some evaluation of congestion control algorithms th= at >> can be both indicative of real use cases (e.g. live streaming video) whi= le >> also being easy to test (e.g. fixed rate packet generators). >> >> Three ideas here: >> >> 1. Test cases >> We will never agree on what a definition of fairness is, and I think it >> is a lost cause. However, we can definitely reach consensus on expected >> behavior given various test cases. >> >> Behavioral driven design gives us a great method for defining these. It >> follows the form (given the facts (concrete verifiable constants), when >> action or event occurs, then I expect it to do XYZ.). I will start a >> separate thread kicking this off. >> >> >> 2. Packet Generator Model >> After re-reading Varun's draft and speaking with him on the evaluation >> scenarios, I think it makes enough sense to build a packet generator to >> implement what he suggests. The time involved isn't substantial, and it >> can help us get a unified starting point for testing even if we decide t= o >> change it later. It's worth at least this much. >> >> My proposed implementation of this will be able to simulate real video >> traffic as well as fixed packet generator traffic. For the real video >> traffic, it can be fed a CSV file filled with frame sizes and RTP >> timestamps. For the fixed generator traffic, ladder steps can be used. >> I'm thinking I'll start a project on Google Code, and make any interest= ed >> participant a developer. >> >> >> 3. Evaluation Metrics >> >> We need an initial set of metrics for testing any congestion control >> algorithm. To evaluate any congestion control algorithm, we'll want eno= ugh >> data to build our favorite line charts. For simplicity, all metrics sho= uld >> be sampled per second (maybe per millisecond?). This also allows us to >> work with real test environments easily. >> >> Here is my initial and non-exhaustive list of metrics (based off of the >> draft): >> >> [Received] In Kbit/s >> [Sent] Out Kbit/s >> Packets sent/second, >> Packets received/second, >> Packets lost/second [Determined by using standard RTP packet loss >> calculations] >> RTT/s >> Discards per second [ use a range of buffer calculations, 20ms 40ms, >> 100ms, 200ms, 500ms] >> >> >> These metrics should be built into an RTP stack that we standardize for >> testing. My two preferences are jrtplib (C++) and libjitsi (Java). At >> least with both of these, we can contact the authors and get any bugs fi= xed >> if we need them relatively easily. >> >> Thanks, >> Dan >> > > --047d7b5d2774f5516a04d7df32d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Another option could be to develop something based on the = RTP stack on http= ://webrtc.googlecode.com. We have some legacy code=A0which contains, among = other things, various load generators, but it hasn't been used for quit= e some time, so I think it would need a bit of work to get back to a workin= g state.

/Stefan


=
On Thu, Mar 14, 2013 at 10:04 AM, Sergio Garcia = Murillo <sergio.garcia.murillo@gmail.com> wrot= e:
Hi Dan,

I made a testing tool to test my rate adaptation algorithm implementation i= n my MCU. You can find the source code here:

http://sourceforge.net/p/mcumediaserver/code/745= /tree/trunk/cca/

It consist on a random packet generator (which can be parametrized to emula= te certain video behaviors, like different sizes for I/P frames) and a rece= iever. I implementes a full RTP/RTCP stack with preliminary support for NAC= K and FEC (which I think it is essential for evaluating the behavior of the= algorithm).

The current algorithm implemented is based on google's congestion contr= ol algorithm, but it could be also interesting to create a comon interface = so we could test different algorithms and compare between them.

Best regards
Sergio

El 14/03/2013 4:57, Dan Weber escribi=F3:

Hi everyone,

While I sat on the airplane today, it became clear to me that there is a re= asonable way to do some evaluation of congestion control algorithms that ca= n be both indicative of real use cases (e.g. live streaming video) while al= so being easy to test (e.g. fixed rate packet generators).

Three ideas here:

1. Test cases
We will never agree on what a definition of fairness is, and I think it is = a lost cause. =A0However, we can definitely reach consensus on expected beh= avior given various test cases.

Behavioral driven design gives us a great method for defining these. =A0It = follows the form (given the facts (concrete verifiable constants), when act= ion or event occurs, then I expect it to do =A0XYZ.). =A0I will start a sep= arate thread kicking this off.


2. Packet Generator Model
After re-reading Varun's draft and speaking with him on the evaluation = scenarios, I think it makes enough sense to build a packet generator to imp= lement what he suggests. =A0The time involved isn't substantial, and it= can help us get a unified starting point for testing even if we decide to = change it later. =A0It's worth at least this much.

My proposed implementation of this will be able to simulate real video traf= fic as well as fixed packet generator traffic. =A0For the real video traffi= c, it can be fed a CSV file filled with frame sizes and RTP timestamps. =A0= For the fixed generator traffic, ladder steps can be used. =A0I'm think= ing I'll start a project on Google Code, and make any interested partic= ipant a developer.


3. Evaluation Metrics

We need an initial set of metrics for testing any congestion control algori= thm. =A0To evaluate any congestion control algorithm, we'll want enough= data to build our favorite line charts. =A0For simplicity, all metrics sho= uld be sampled per second (maybe per millisecond?). =A0This also allows us = to work with real test environments easily.

Here is my initial and non-exhaustive list of metrics (based off of the dra= ft):

[Received] In Kbit/s
[Sent] Out Kbit/s
Packets sent/second,
Packets received/second,
Packets lost/second [Determined by using standard RTP packet loss calculati= ons]
RTT/s
Discards per second [ use a range of buffer calculations, 20ms 40ms, 100ms,= 200ms, 500ms]


These metrics should be built into an RTP stack that we standardize for tes= ting. =A0My two preferences are jrtplib (C++) and libjitsi (Java). =A0At le= ast with both of these, we can contact the authors and get any bugs fixed i= f we need them relatively easily.

Thanks,
Dan


--047d7b5d2774f5516a04d7df32d1-- From lars@netapp.com Thu Mar 14 04:34:17 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 5949721F8FC6 for ; Thu, 14 Mar 2013 04:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 sUuNqqCaooqh for ; Thu, 14 Mar 2013 04:34:16 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4B56A11E809C for ; Thu, 14 Mar 2013 04:34:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,844,1355126400"; d="scan'208";a="30732260" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 14 Mar 2013 04:34:13 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2EBYCtV005222; Thu, 14 Mar 2013 04:34:13 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 04:34:12 -0700 From: "Eggert, Lars" To: Dan Weber Thread-Topic: [rmcat] Congestion Control Behavior Suggestion Thread Thread-Index: AQHOIGtWgEUKQwH3cECqMQTKMwzdzJilhDaA Date: Thu, 14 Mar 2013 11:34:11 +0000 Message-ID: <6BD4BD5D-9689-4AF4-A970-0AAB9E816977@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 11:34:17 -0000 Hi, On Mar 14, 2013, at 0:20, Dan Weber wrote: > This may need more work, but it can get us going in the right direction. thanks for starting this! Yes, there needs to be more detail. In case folks= haven't see it yet, we tried to specify such scenarios for doing performan= ce measurements for TCP extensions a few years ago: http://eggert.org/paper= s/2008-pfldnet.pdf The intent with that paper, and I guess the intent now, would be to nail do= wn all constants sufficiently and describe the parameterization of each tes= t sufficiently so that someone could set up a simulation or experiment base= d only on the text. (For the TCP scenarios described in the paper, someone = - from NEC? - actually did provide an ns2 script.) Lars= From vsingh.ietf@gmail.com Thu Mar 14 06:23:36 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 4B42921F909E for ; Thu, 14 Mar 2013 06:23:36 -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 eit5dManBZGy for ; Thu, 14 Mar 2013 06:23:31 -0700 (PDT) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 76E4521F8D57 for ; Thu, 14 Mar 2013 06:23:22 -0700 (PDT) Received: by mail-ia0-f170.google.com with SMTP id h8so2065050iaa.1 for ; Thu, 14 Mar 2013 06:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=zne4z57cHrLKv8f1K3mHSv6evQ6LvOVqfrh1YSASaNY=; b=F6C4rMfhO9ueu5UdAFdyegk9FRfY5S0iPcLyxygzgT1FhloWtzkRx33BFMiPRKi2OF UeYKdWnTcXaTno8XDKIc2kuVLrIc/T7vIiLo2lII++lHwkE0ApONF8VeewPFgdC+4eSA uBSmkL7WyFtsULRu3HZn7yUQVUazvyp5a9pZe9BK+AwAsgf5ljamYYfqPtiaq/+Z/Y/e CzODyFEiLW6RX0YvPvpQEqxE6w/2csD8bgfC71p6hqaKE2jMZcyfv8XoCiS2NWqbbiIf lBBdaq5gZyjPw82tojT+ewjIqq+GvIBzPYtJ2BXCUB0zs8WYNFfz1prNzqB7niBAI5sR KR8g== X-Received: by 10.50.191.133 with SMTP id gy5mr20886959igc.50.1363267402262; Thu, 14 Mar 2013 06:23:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.152.7 with HTTP; Thu, 14 Mar 2013 06:23:02 -0700 (PDT) From: Varun Singh Date: Thu, 14 Mar 2013 09:23:02 -0400 Message-ID: To: rmcat WG , Wesley Eddy Content-Type: text/plain; charset=ISO-8859-1 Subject: [rmcat] Design Meeting 2 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, 14 Mar 2013 13:23:36 -0000 HI all, We did a quick recap of the earlier meeting and Bob Briscoe discussed "History of Fairness" and discussion centered around measuring congestion, fairness and trade-off of throughput, delay and discards. We will meet again tomorrow (15.03) at 8am (if Boca 3 is available, we'll continue the meeting there). Bob will send a reading list of RFCs and papers. Attendees: Randell Jesup Zahed Sarker Michael Ramalho Mo Zanaty Kevin Gross Gory Fairhurst Bob Briscoe Varun Singh -- http://www.netlab.tkk.fi/~varun/ From vsingh.ietf@gmail.com Thu Mar 14 06:35:09 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56621F0D0D for ; Thu, 14 Mar 2013 06:35:09 -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 o9BxsDNAJfK3 for ; Thu, 14 Mar 2013 06:35:04 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD381F0D09 for ; Thu, 14 Mar 2013 06:35:04 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id k13so2934596iea.7 for ; Thu, 14 Mar 2013 06:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=a7Uixw2XGntJ43mFhCbnSzcSWSR9nWx4Fm7WB0+mxiY=; b=QMv4oFaQyP1D0PZhwytNwXW60MfdnGGa40bxd0TZqYviCKxJ4/Ae40dzZp0yBco+FX jPkw2m73KrSgMiLMmkKz2B2QbhEWNb0NYEcTxKc3V5bTy1tlHsDqsfB43ajLg3sfSqgz qq7MeR11TJ62ZNR6MfzItB9on3LW3nC7X+jb1GbatX2k3LEX+lFdd5cyGJzc8zyHx/2n RCLGOo8BNxRNPlhuAPZ5Y/jNxXL8a0gXZyfHJva/LlY8TRPknONPA3k0cidndP6WJsSo DqKSnR9Axx9jFcnwgKr9P8QhDqSyQXhAvKqr6JJJSzxWTMPWpF09PFsvAL45el5roBj/ D9sw== X-Received: by 10.50.47.168 with SMTP id e8mr2325706ign.50.1363268104224; Thu, 14 Mar 2013 06:35:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.152.7 with HTTP; Thu, 14 Mar 2013 06:34:44 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Thu, 14 Mar 2013 09:34:44 -0400 Message-ID: To: Dan Weber Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat@ietf.org Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 13:35:10 -0000 Hi Dan, On Thu, Mar 14, 2013 at 12:20 AM, Dan Weber wrote: > Hi there, > > This is the first and example behavior test case based on the concept I > proposed in "RMCAT Evaluation Ideas". Please add your own following the > same format. I seek to aggregate all of these test cases onto a wiki and > establish categories for them. > > > Given: A video media stream sends at 512kbit/s on a link with an upstream > capacity of 512 kbit/s > When: an FTP Transfer of 1GB file begins uploading > Then: Packet loss occurs. Throughput should be diminished. RTPCC should > notify application of developments. > > Given: A link with capacity limited at 512 kbit/s > When: A video conference call starts sending Mulaw audio (ptime=20, > 81.92kbit/s) and Video @ max kbitrate of 384 kbit/s > Then: All packets should be received. > The "Then" part may depend also on what other network characteristics may be applied (path loss and/or delay). > ... > > This may need more work, but it can get us going in the right direction. > > Thanks, > Dan -- http://www.netlab.tkk.fi/~varun/ From zaheduzzaman.sarker@ericsson.com Thu Mar 14 07:07:47 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 E93AC11E8164 for ; Thu, 14 Mar 2013 07:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 vxwZ+rf2WjTM for ; Thu, 14 Mar 2013 07:07:45 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4E811E815B for ; Thu, 14 Mar 2013 07:07:41 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-a9-5141d9ab07d0 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 88.53.32353.BA9D1415; Thu, 14 Mar 2013 15:07:40 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.54]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 15:07:39 +0100 From: Zaheduzzaman Sarker To: Dan Weber , "rmcat@ietf.org" Thread-Topic: [rmcat] RMCAT Evaluation Ideas Thread-Index: AQHOIGgbyBj5jrlTUEaPBhTBxr93JpilM4hA Date: Thu, 14 Mar 2013 14:07:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_E0F7A68B07B53F4FBD12DABD61CBA90E098B03ESESSMB307ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6am46BBktP8FvMXmBusfrmBzYH Jo8lS34yecy/sZ41gCmKyyYlNSezLLVI3y6BK2P5vPesBd+8K/b37WFpYHzh2cXIySEhYCIx 4e1TRghbTOLCvfVsXYxcHEIChxgl/t96wALhLGaUmP5nJXMXIwcHm4CNxOPFfiANIgKuEi3f XrOC2MIC2hIXv65lhYjrSFy608MOYRtJ7NrSDbaARUBVYvvORiYQm1fAW2Lfm/dgNUICARIz F05jA7E5BQIl5h7bD1bDCHTQ91NrwGxmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sELaSxI8N l1gg6vMljv2axgyxS1Di5MwnLBMYRWYhGTULSdksJGWzgL5kFtCUWL9LH6JEUWJK90N2CFtD onXOXHZk8QWM7KsY2XMTM3PSy803MQLj5uCW3wY7GDfdFzvEKM3BoiTOG+56IUBIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QDo4RzV8L3Tfpnop+277onJfxZYK+Ni/6MI+e+XD0ufyvo1asH TCoHxN2X9+tKyTwNmtvZ6His1/A876fFrv/kiqV4483/9ncu5l70Ll6TVcd9wVuLw09+G0gE dK4/e4xz6d+zy4T2n3YRMWjzz14/42pYVf2hsoIfkjq8gXd4JnRli9o+/C+SqcRSnJFoqMVc VJwIAJFFrwdpAgAA Subject: Re: [rmcat] RMCAT Evaluation Ideas 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, 14 Mar 2013 14:07:47 -0000 --_000_E0F7A68B07B53F4FBD12DABD61CBA90E098B03ESESSMB307ericsso_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCjIuIFBhY2tldCBHZW5lcmF0b3IgTW9kZWwNCkFmdGVyIHJlLXJlYWRpbmcgVmFydW4ncyBk cmFmdCBhbmQgc3BlYWtpbmcgd2l0aCBoaW0gb24gdGhlIGV2YWx1YXRpb24gc2NlbmFyaW9zLCBJ IHRoaW5rIGl0IG1ha2VzIGVub3VnaCBzZW5zZSB0byBidWlsZCBhIHBhY2tldCBnZW5lcmF0b3Ig dG8gaW1wbGVtZW50IHdoYXQgaGUgc3VnZ2VzdHMuICBUaGUgdGltZSBpbnZvbHZlZCBpc24ndCBz dWJzdGFudGlhbCwgYW5kIGl0IGNhbiBoZWxwIHVzIGdldCBhIHVuaWZpZWQgc3RhcnRpbmcgcG9p bnQgZm9yIHRlc3RpbmcgZXZlbiBpZiB3ZSBkZWNpZGUgdG8gY2hhbmdlIGl0IGxhdGVyLiAgSXQn cyB3b3J0aCBhdCBsZWFzdCB0aGlzIG11Y2guDQoNCk15IHByb3Bvc2VkIGltcGxlbWVudGF0aW9u IG9mIHRoaXMgd2lsbCBiZSBhYmxlIHRvIHNpbXVsYXRlIHJlYWwgdmlkZW8gdHJhZmZpYyBhcyB3 ZWxsIGFzIGZpeGVkIHBhY2tldCBnZW5lcmF0b3IgdHJhZmZpYy4gIEZvciB0aGUgcmVhbCB2aWRl byB0cmFmZmljLCBpdCBjYW4gYmUgZmVkIGEgQ1NWIGZpbGUgZmlsbGVkIHdpdGggZnJhbWUgc2l6 ZXMgYW5kIFJUUCB0aW1lc3RhbXBzLg0KW1phaGVkdXp6YW1hbiBTYXJrZXJdIHdlIGFscmVhZHkg dXNlIHNvbWUgc29ydCBvZiBwYWNrZXQgZ2VuZXJhdG9yIGluIG91ciBzaW11bGF0aW9ucywgcmln aHQ/IEFuZCBpdCBtaWdodCBiZSBhbHNvIG5vdCB0aGF0IGhhcmQgdG8gY29tZSB1cCB3aXRoIGEg cGFja2V0IGdlbmVyYXRvci4gSG93ZXZlciwgdGhlIGhhcmQgcGFydCBpcyB0byByZWFsaXplIGhv dyByZXByZXNlbnRhdGl2ZSB0aG9zZSBwYWNrZXQgZ2VuZXJhdG9yIGFyZSBmb3Igb3VyIHVzZWNh c2VzIGF0IGhhbmQ/IElNSE8sIHdlIHdpbGwgbmVlZCB0byB2ZXJpZnkgdGhlIGdlbmVyYXRlIHBh Y2tldCB0cmFjZSBhIHdpdGggc29tZSByZWZlcmVuY2UgdHJhY2UuIEFsc28gcmVtZW1iZXIgd2Ug bWlnaHQgaGF2ZSBRb0UgYXMgZXZhbHVhdGlvbiAgbWV0cmljIHRvbyBhbmQgSSBoZWFyIHBlb3Bs ZSBhcmUgYWxzbyB0YWxraW5nIGFib3V0IHN1YmplY3RpdmUgcXVhbGl0eSByZWxhdGVkIHRvIGZh aXJuZXNzLiBJdCB3aWxsIGJlIGhhcmQgdG8gYWNoaWV2ZSB0aGF0IHdpdGgganVzdCBzaW1wbGUg cGFja2V0IGdlbmVyYXRvcnMuDQogRm9yIHRoZSBmaXhlZCBnZW5lcmF0b3IgdHJhZmZpYywgbGFk ZGVyIHN0ZXBzIGNhbiBiZSB1c2VkLiAgSSdtIHRoaW5raW5nIEknbGwgc3RhcnQgYSBwcm9qZWN0 IG9uIEdvb2dsZSBDb2RlLCBhbmQgbWFrZSBhbnkgaW50ZXJlc3RlZCBwYXJ0aWNpcGFudCBhIGRl dmVsb3Blcg0KDQoNCg0KQlINCg0KWmFoZWQNCg== --_000_E0F7A68B07B53F4FBD12DABD61CBA90E098B03ESESSMB307ericsso_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4y LiBQYWNrZXQgR2VuZXJhdG9yIE1vZGVsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BZnRlciByZS1yZWFkaW5nIFZhcnVuJ3MgZHJhZnQgYW5kIHNw ZWFraW5nIHdpdGggaGltIG9uIHRoZSBldmFsdWF0aW9uIHNjZW5hcmlvcywgSSB0aGluayBpdCBt YWtlcyBlbm91Z2ggc2Vuc2UgdG8gYnVpbGQgYSBwYWNrZXQgZ2VuZXJhdG9yIHRvIGltcGxlbWVu dCB3aGF0IGhlIHN1Z2dlc3RzLiAmbmJzcDtUaGUgdGltZSBpbnZvbHZlZCBpc24ndCBzdWJzdGFu dGlhbCwgYW5kIGl0IGNhbiBoZWxwIHVzIGdldCBhIHVuaWZpZWQNCiBzdGFydGluZyBwb2ludCBm b3IgdGVzdGluZyBldmVuIGlmIHdlIGRlY2lkZSB0byBjaGFuZ2UgaXQgbGF0ZXIuICZuYnNwO0l0 J3Mgd29ydGggYXQgbGVhc3QgdGhpcyBtdWNoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBwcm9wb3NlZCBpbXBsZW1lbnRhdGlvbiBvZiB0 aGlzIHdpbGwgYmUgYWJsZSB0byBzaW11bGF0ZSByZWFsIHZpZGVvIHRyYWZmaWMgYXMgd2VsbCBh cyBmaXhlZCBwYWNrZXQgZ2VuZXJhdG9yIHRyYWZmaWMuICZuYnNwO0ZvciB0aGUgcmVhbCB2aWRl byB0cmFmZmljLCBpdCBjYW4gYmUgZmVkIGEgQ1NWIGZpbGUgZmlsbGVkIHdpdGggZnJhbWUgc2l6 ZXMgYW5kIFJUUCB0aW1lc3RhbXBzLg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bWmFoZWR1enphbWFuIFNhcmtlcl0gd2Ug YWxyZWFkeSB1c2Ugc29tZSBzb3J0IG9mIHBhY2tldCBnZW5lcmF0b3IgaW4gb3VyIHNpbXVsYXRp b25zLCByaWdodD8gQW5kIGl0IG1pZ2h0IGJlIGFsc28gbm90IHRoYXQgaGFyZCB0byBjb21lIHVw IHdpdGggYSBwYWNrZXQNCiBnZW5lcmF0b3IuIEhvd2V2ZXIsIHRoZSBoYXJkIHBhcnQgaXMgdG8g cmVhbGl6ZSBob3cgcmVwcmVzZW50YXRpdmUgdGhvc2UgcGFja2V0IGdlbmVyYXRvciBhcmUgZm9y IG91ciB1c2VjYXNlcyBhdCBoYW5kPyBJTUhPLCB3ZSB3aWxsIG5lZWQgdG8gdmVyaWZ5IHRoZSBn ZW5lcmF0ZSBwYWNrZXQgdHJhY2UgYSB3aXRoIHNvbWUgcmVmZXJlbmNlIHRyYWNlLiBBbHNvIHJl bWVtYmVyIHdlIG1pZ2h0IGhhdmUgUW9FIGFzIGV2YWx1YXRpb24gJm5ic3A7bWV0cmljDQogdG9v IGFuZCBJIGhlYXIgcGVvcGxlIGFyZSBhbHNvIHRhbGtpbmcgYWJvdXQgc3ViamVjdGl2ZSBxdWFs aXR5IHJlbGF0ZWQgdG8gZmFpcm5lc3MuIEl0IHdpbGwgYmUgaGFyZCB0byBhY2hpZXZlIHRoYXQg d2l0aCBqdXN0IHNpbXBsZSBwYWNrZXQgZ2VuZXJhdG9ycy4gJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtGb3IgdGhlIGZpeGVk IGdlbmVyYXRvciB0cmFmZmljLCBsYWRkZXIgc3RlcHMgY2FuIGJlIHVzZWQuICZuYnNwO0knbSB0 aGlua2luZyBJJ2xsIHN0YXJ0IGEgcHJvamVjdCBvbiBHb29nbGUgQ29kZSwgYW5kIG1ha2UgYW55 IGludGVyZXN0ZWQgcGFydGljaXBhbnQgYSBkZXZlbG9wZXI8c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+WmFoZWQ8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E0F7A68B07B53F4FBD12DABD61CBA90E098B03ESESSMB307ericsso_-- From vsingh.ietf@gmail.com Thu Mar 14 07:09: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 2928011E8140 for ; Thu, 14 Mar 2013 07:09:46 -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 a8RI5WEONxub for ; Thu, 14 Mar 2013 07:09:41 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 15C9911E8164 for ; Thu, 14 Mar 2013 07:09:41 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id c12so2989911ieb.20 for ; Thu, 14 Mar 2013 07:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=459YrcR3Jn5NGqBRHm5fxi+WyPl0d+FY2zBZtvXWCjw=; b=vHQGgjwTKDmX0pi9h3frOjw0GxJFl/ppF5RsjTIchirUdcjTgAQpttJgWFPa/DGMU9 DbKaufJf1wXSAtj1gXZo5ZwHKEkh6HhWbyb/aoTd5J+tPQOvqJoDaFMMfu7iAVp/EHvR XEIdrXbt35kz/dkaqSyx/ARe0KZgzF+0XG5YboiVyPFd4eVflLpHLyGrCxyNfVHBzN4Q z6ZNx2WXmRPs7wVV7/qbOQW1obgkBy75on0+3EwotNcMZpTKsQUxNPq03L1W7gZNjjoG NpzDz9C+8KBFBXgdscXRuxvdCnrHcVViR04P1N58rc0tmM8qDFjrIbgK7sQYU8j7sFk2 Cr0A== X-Received: by 10.50.47.168 with SMTP id e8mr2433630ign.50.1363270180681; Thu, 14 Mar 2013 07:09:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.152.7 with HTTP; Thu, 14 Mar 2013 07:09:20 -0700 (PDT) In-Reply-To: References: <5141929A.6040500@gmail.com> From: Varun Singh Date: Thu, 14 Mar 2013 10:09:20 -0400 Message-ID: To: Stefan Holmer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG , Sergio Garcia Murillo Subject: Re: [rmcat] RMCAT Evaluation Ideas 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, 14 Mar 2013 14:09:46 -0000 Hi Stefan, Sergio, Is it possible for either of you to characterize the behaviour of the packet generator? I am mainly looking for plots related to the different video parameters. Thanks, Varun On Thu, Mar 14, 2013 at 5:32 AM, Stefan Holmer wrote: > Another option could be to develop something based on the RTP stack on > http://webrtc.googlecode.com. We have some legacy code which contains, am= ong > other things, various load generators, but it hasn't been used for quite > some time, so I think it would need a bit of work to get back to a workin= g > state. > > /Stefan > > > On Thu, Mar 14, 2013 at 10:04 AM, Sergio Garcia Murillo > wrote: >> >> Hi Dan, >> >> I made a testing tool to test my rate adaptation algorithm implementatio= n >> in my MCU. You can find the source code here: >> >> http://sourceforge.net/p/mcumediaserver/code/745/tree/trunk/cca/ >> >> It consist on a random packet generator (which can be parametrized to >> emulate certain video behaviors, like different sizes for I/P frames) an= d a >> receiever. I implementes a full RTP/RTCP stack with preliminary support = for >> NACK and FEC (which I think it is essential for evaluating the behavior = of >> the algorithm). >> >> The current algorithm implemented is based on google's congestion contro= l >> algorithm, but it could be also interesting to create a comon interface = so >> we could test different algorithms and compare between them. >> >> Best regards >> Sergio >> >> El 14/03/2013 4:57, Dan Weber escribi=F3: >> >>> Hi everyone, >>> >>> While I sat on the airplane today, it became clear to me that there is = a >>> reasonable way to do some evaluation of congestion control algorithms t= hat >>> can be both indicative of real use cases (e.g. live streaming video) wh= ile >>> also being easy to test (e.g. fixed rate packet generators). >>> >>> Three ideas here: >>> >>> 1. Test cases >>> We will never agree on what a definition of fairness is, and I think it >>> is a lost cause. However, we can definitely reach consensus on expecte= d >>> behavior given various test cases. >>> >>> Behavioral driven design gives us a great method for defining these. I= t >>> follows the form (given the facts (concrete verifiable constants), when >>> action or event occurs, then I expect it to do XYZ.). I will start a >>> separate thread kicking this off. >>> >>> >>> 2. Packet Generator Model >>> After re-reading Varun's draft and speaking with him on the evaluation >>> scenarios, I think it makes enough sense to build a packet generator to >>> implement what he suggests. The time involved isn't substantial, and i= t can >>> help us get a unified starting point for testing even if we decide to c= hange >>> it later. It's worth at least this much. >>> >>> My proposed implementation of this will be able to simulate real video >>> traffic as well as fixed packet generator traffic. For the real video >>> traffic, it can be fed a CSV file filled with frame sizes and RTP >>> timestamps. For the fixed generator traffic, ladder steps can be used.= I'm >>> thinking I'll start a project on Google Code, and make any interested >>> participant a developer. >>> >>> >>> 3. Evaluation Metrics >>> >>> We need an initial set of metrics for testing any congestion control >>> algorithm. To evaluate any congestion control algorithm, we'll want en= ough >>> data to build our favorite line charts. For simplicity, all metrics sh= ould >>> be sampled per second (maybe per millisecond?). This also allows us to= work >>> with real test environments easily. >>> >>> Here is my initial and non-exhaustive list of metrics (based off of the >>> draft): >>> >>> [Received] In Kbit/s >>> [Sent] Out Kbit/s >>> Packets sent/second, >>> Packets received/second, >>> Packets lost/second [Determined by using standard RTP packet loss >>> calculations] >>> RTT/s >>> Discards per second [ use a range of buffer calculations, 20ms 40ms, >>> 100ms, 200ms, 500ms] >>> >>> >>> These metrics should be built into an RTP stack that we standardize for >>> testing. My two preferences are jrtplib (C++) and libjitsi (Java). At >>> least with both of these, we can contact the authors and get any bugs f= ixed >>> if we need them relatively easily. >>> >>> Thanks, >>> Dan >> >> > --=20 http://www.netlab.tkk.fi/~varun/ From lars@netapp.com Thu Mar 14 07:14:05 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 D0D6F1F0D12 for ; Thu, 14 Mar 2013 07:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 NXllEloKkbnn for ; Thu, 14 Mar 2013 07:14:05 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3BC1F0D08 for ; Thu, 14 Mar 2013 07:13:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,845,1355126400"; d="scan'208";a="14878691" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 14 Mar 2013 07:13:52 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2EEDqar027501; Thu, 14 Mar 2013 07:13:52 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 07:13:51 -0700 From: "Eggert, Lars" To: Zaheduzzaman Sarker Thread-Topic: [rmcat] RMCAT Evaluation Ideas Thread-Index: AQHOIGgtfEjz1F7pqkGqKpq50ELmrZilrxkAgAABv4A= Date: Thu, 14 Mar 2013 14:13:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: text/plain; charset="us-ascii" Content-ID: <9643A5E7C670CE49BE34881F5228934C@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dan Weber , "rmcat@ietf.org" Subject: Re: [rmcat] RMCAT Evaluation Ideas 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, 14 Mar 2013 14:14:06 -0000 On Mar 14, 2013, at 10:07, Zaheduzzaman Sarker wrote: > For the fixed generator traffic, ladder steps can be used. I'm thinking = I'll start a project on Google Code, and make any interested participant a = developer Suggestion: take a look at if an existing generator can be extended, rather= than starting from scratch? E.g. flowgrind Lars= From versteb@cisco.com Thu Mar 14 07:21:26 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 650EA11E8158 for ; Thu, 14 Mar 2013 07:21:26 -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 sDUh6QRuK7nZ for ; Thu, 14 Mar 2013 07:21:11 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3250B11E814E for ; Thu, 14 Mar 2013 07:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=800; q=dns/txt; s=iport; t=1363270871; x=1364480471; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=w9RIn3Env6/STkUGEHaRtx4ehuwW0ES7hQeyoXcJ2Ps=; b=QSgSuOBhyP4IZuErJRi2Ywk0TrCR11a9iW7QD0t6adpou17vgdr7pA3E XlRg0CZyyGMP74uKYqV5t7XHZbKX/WYUZ4pqk6M4KvBlFBVteCwB5+jgW nuxdgt1fjGAw1wHP2zxi+/N6WPvymHMKchR6n5NU5cDJfMQ+DNXSjkljM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAKTcQVGtJV2d/2dsb2JhbABDh2O9FYFiFnSCKgEBAQMBOj8FCwIBCBgeEDIlAgQOBYgOBsEvjl0zB4JfYQOWWJECgwo X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="187482171" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 14 Mar 2013 14:21:04 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2EEL4Z8015503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 14:21:04 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 09:21:04 -0500 From: "Bill Ver Steeg (versteb)" To: "Eggert, Lars" Thread-Topic: [rmcat] RMCAT Evaluation Ideas Thread-Index: AQHOIGgbBKKR+F3VWUiUahIhn0uqLpiljZIAgAABvAD//64xtQ== Date: Thu, 14 Mar 2013 14:21:02 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dan Weber , Zaheduzzaman Sarker , "rmcat@ietf.org" Subject: Re: [rmcat] RMCAT Evaluation Ideas 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, 14 Mar 2013 14:21:26 -0000 Iperf can also generate a wide variety of traffic. I have also recently mod= ified it to track one-way delay, and can help with changing the code to se= nd data patterns and track delay.=20 I will try to make tomorrow's 8am meeting, and we can compare notes on what= tools are available.=20 Bill VerSteeg On Mar 14, 2013, at 10:15 AM, "Eggert, Lars" wrote: > On Mar 14, 2013, at 10:07, Zaheduzzaman Sarker wrote: >> For the fixed generator traffic, ladder steps can be used. I'm thinking= I'll start a project on Google Code, and make any interested participant a= developer >=20 > Suggestion: take a look at if an existing generator can be extended, rath= er than starting from scratch? E.g. flowgrind >=20 > Lars From bob.briscoe@bt.com Thu Mar 14 08:08:10 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 56CDC11E8244 for ; Thu, 14 Mar 2013 08:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ1--y03biN6 for ; Thu, 14 Mar 2013 08:08:08 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCE011E8256 for ; Thu, 14 Mar 2013 08:08:07 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 14 Mar 2013 15:08:05 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 14 Mar 2013 15:08:05 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Thu, 14 Mar 2013 15:08:02 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.109.132]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r2EF7wZx032240 for ; Thu, 14 Mar 2013 15:07:59 GMT Message-ID: <201303141507.r2EF7wZx032240@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 Mar 2013 15:07:59 +0000 To: RMCAT IETF list From: Bob Briscoe MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_440193949==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Subject: [rmcat] History of Fairness Discussions in the IETF 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, 14 Mar 2013 15:08:10 -0000 --=====================_440193949==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed RMCAT-ers, At the fairness design team mtg this morning, I promised to send this list of RFCs & docs to the list. If you want to cut to the chase, jump over the pre-history and read from RFC5033 onwards. RFCs that specify best current practice, guidelines and principles for designers of congestion control: - the `Gateway Congestion Control Survey' [RFC1254], - recommendations on AQM [RFC2309], - `Congestion Control Principles' [RFC2914], - `General Architectural and Policy Considerations' [RFC3426] - IAB Concerns Regarding Congestion Control for Voice Traffic [RFC3714]; RFCs that recommend how new transport protocols should interact with existing ones: - recommendations on AQM [RFC2309], - Criteria for Evaluating Reliable Multicast Transports [RFC2357], - `Congestion Control Principles' [RFC2914] and - Guidelines for new RTP profiles [RFC3550] ________________ VVV _____skip to here if in a hurry _____ VVV ______ - Specifying New Congestion Control Algorithms [RFC5033] Individual contributions (that led to RFC5033) - Flow Rate Fairness: Dismantling a Religion [draft-briscoe-tsvarea-fair-02.pdf] - Problem Statement: Transport Protocols Don't Have To Do Fairness [draft-briscoe-tsvwg-relax-fairness] - Comments on the Usefulness of Simple Best-Effort Traffic [RFC5290] Fairness Metrics - ConEx Concepts & Use Cases [RFC6789] Manifests of RFCs relevant to Fairness & Congestion Control: - http://tools.ietf.org/html/draft-briscoe-tsvarea-fair-02#section-9 - Congestion Control in the RFC Series [RFC5783] Bob ________________________________________________________________ Bob Briscoe, BT --=====================_440193949==.ALT Content-Type: text/html; charset="us-ascii" RMCAT-ers,

At the fairness design team mtg this morning, I promised to send this list of RFCs & docs to the list. If you want to cut to the chase, jump over the pre-history and read from RFC5033 onwards.

RFCs that specify best current practice, guidelines and principles for designers of congestion control:
- the `Gateway Congestion Control Survey' [RFC1254],
- recommendations on AQM [RFC2309],
- `Congestion Control Principles' [RFC2914],
- `General Architectural and Policy Considerations' [RFC3426]
- IAB Concerns Regarding Congestion Control for Voice Traffic [RFC3714];

RFCs that recommend how new transport protocols should interact with existing ones:
- recommendations on AQM [RFC2309],
- Criteria for Evaluating Reliable Multicast Transports [RFC2357],
- `Congestion Control Principles' [RFC2914] and
- Guidelines for new RTP profiles [RFC3550]
________________ VVV _____skip to here if in a hurry _____ VVV ______
- Specifying New Congestion Control Algorithms [RFC5033]

Individual contributions (that led to RFC5033)
- Flow Rate Fairness: Dismantling a Religion [ draft-briscoe-tsvarea-fair-02.pdf]
- Problem Statement: Transport Protocols Don't Have To Do Fairness [ draft-briscoe-tsvwg-relax-fairness]
- Comments on the Usefulness of Simple Best-Effort Traffic [RFC5290]

Fairness Metrics
- ConEx Concepts & Use Cases [RFC6789]

Manifests of RFCs relevant to Fairness & Congestion Control:
- http://tools.ietf.org/html/draft-briscoe-tsvarea-fair-02#section-9
- Congestion Control in the RFC Series [RFC5783]


Bob

________________________________________________________________
Bob Briscoe,                                                  BT --=====================_440193949==.ALT-- From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Mar 14 08:22:23 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5A811E823C for ; Thu, 14 Mar 2013 08:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 HuKByUV+Nty5 for ; Thu, 14 Mar 2013 08:22:19 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id A218821F8D52 for ; Thu, 14 Mar 2013 08:22:19 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id BF09B6018D for ; Thu, 14 Mar 2013 16:12:02 +0100 (CET) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id B98B660166 for ; Thu, 14 Mar 2013 16:12:02 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: rmcat@ietf.org Date: Thu, 14 Mar 2013 16:12:02 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201303141612.02292.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [rmcat] RMCAT Evaluation Ideas 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, 14 Mar 2013 15:22:24 -0000 Hi, just to name one more option: we have a Java-based, event-driven simulation framework which we recently=20 extended to integrate a virtual machine (using QEMU). That means we can use= =20 traffic generated by a real operating system in simulations. Currently we=20 only have a small relay program running in the virtual machine that can be= =20 controlled by the simulation program to send chunks of data. Thus a specifi= c=20 generator could be implemented in simulation program. The relay program sen= ds=20 only TCP traffic at the moment. Moreover, we can also run a real applicatio= n=20 in the virtual machine. At the moment we are still working on the framework= =2E=20 Before we will publish the code, we need to find some more bug fixes. But t= he=20 simulations are working and we are using this for all our current TCP=20 simulations. Mirja On Thursday 14 March 2013 15:07:38 Zaheduzzaman Sarker wrote: > 2. Packet Generator Model > After re-reading Varun's draft and speaking with him on the evaluation > scenarios, I think it makes enough sense to build a packet generator to > implement what he suggests. The time involved isn't substantial, and it > can help us get a unified starting point for testing even if we decide to > change it later. It's worth at least this much. > > My proposed implementation of this will be able to simulate real video > traffic as well as fixed packet generator traffic. For the real video > traffic, it can be fed a CSV file filled with frame sizes and RTP > timestamps. [Zaheduzzaman Sarker] we already use some sort of packet > generator in our simulations, right? And it might be also not that hard to > come up with a packet generator. However, the hard part is to realize how > representative those packet generator are for our usecases at hand? IMHO, > we will need to verify the generate packet trace a with some reference > trace. Also remember we might have QoE as evaluation metric too and I he= ar > people are also talking about subjective quality related to fairness. It > will be hard to achieve that with just simple packet generators. For the > fixed generator traffic, ladder steps can be used. I'm thinking I'll sta= rt > a project on Google Code, and make any interested participant a developer > > > > BR > > Zahed =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From xiaoqzhu@cisco.com Thu Mar 14 08:42:03 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 A7FF311E819A for ; Thu, 14 Mar 2013 08:42:03 -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 KvSGRzzRykRJ for ; Thu, 14 Mar 2013 08:41:59 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 93B2111E8192 for ; Thu, 14 Mar 2013 08:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3716; q=dns/txt; s=iport; t=1363275719; x=1364485319; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WqN2CNBtTc8fkkAtHLwcer5iNUUe/UGmryhStY7IKNU=; b=ds3W3SZaclY1QklC9kgDSQtqy1uq+rk4UC6F4vySfCtPtWAXL9Hhkq74 7SyCJ19XEAPJZL4bXYUC0kWttuSix2g4BLw0w9h7tP6MLYAUa04m4ETk2 1Ml7IouoTlqzICJaxC1R9HTzcsQ0ucneVbPiNwFzRPd2jSdPjXYqAAaf1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMGAHzuQVGtJV2c/2dsb2JhbABDhD29MoMJgWIWdIIqAQEBAwFJMAULAgEIGAokMiUCBA4FCIgGBgHBSY1PgQ4CMQeCX2EDiD6fHIMKgXM1 X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="187522617" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 14 Mar 2013 15:41:59 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2EFfxRu012591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 15:41:59 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 10:41:58 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: Mirja Kuehlewind Thread-Topic: [rmcat] RMCAT Evaluation Ideas Thread-Index: AQHOIGgbVfACc/+bx0WmM7wwLKE+1JiljZIAgAAR/gCAAAhcgA== Date: Thu, 14 Mar 2013 15:41:58 +0000 Message-ID: References: <201303141612.02292.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201303141612.02292.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.127.73] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rmcat] RMCAT Evaluation Ideas 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, 14 Mar 2013 15:42:03 -0000 Hi,=20 Great idea on the packet generator model. We will also be happy to contribu= te on this piece as well.=20 In the past we have put together some some ns-2 code for via in two approac= hes:=20 - trace-driven: where the packet sizes and intervals are taken from h.264 = encoding result of video sequences. one could also switch between different= rate versions of the same video content at GOP boundaries.=20 - statistical modeling: where the encoder rate control behavior is modeled = statistically, with tunable parameters on burstiness, range of deviation fr= om target rate, and lag in reaction (i.e., how long it takes the encoder to= react to a change in target rate).=20 Thanks, Xiaoqing On Mar 14, 2013, at 10:12 AM, Mirja Kuehlewind wrote: > Hi, >=20 > just to name one more option: >=20 > we have a Java-based, event-driven simulation framework which we recently= =20 > extended to integrate a virtual machine (using QEMU). That means we can u= se=20 > traffic generated by a real operating system in simulations. Currently we= =20 > only have a small relay program running in the virtual machine that can b= e=20 > controlled by the simulation program to send chunks of data. Thus a speci= fic=20 > generator could be implemented in simulation program. The relay program s= ends=20 > only TCP traffic at the moment. Moreover, we can also run a real applicat= ion=20 > in the virtual machine. At the moment we are still working on the framewo= rk.=20 > Before we will publish the code, we need to find some more bug fixes. But= the=20 > simulations are working and we are using this for all our current TCP=20 > simulations. >=20 > Mirja >=20 >=20 > On Thursday 14 March 2013 15:07:38 Zaheduzzaman Sarker wrote: >> 2. Packet Generator Model >> After re-reading Varun's draft and speaking with him on the evaluation >> scenarios, I think it makes enough sense to build a packet generator to >> implement what he suggests. The time involved isn't substantial, and it >> can help us get a unified starting point for testing even if we decide t= o >> change it later. It's worth at least this much. >>=20 >> My proposed implementation of this will be able to simulate real video >> traffic as well as fixed packet generator traffic. For the real video >> traffic, it can be fed a CSV file filled with frame sizes and RTP >> timestamps. [Zaheduzzaman Sarker] we already use some sort of packet >> generator in our simulations, right? And it might be also not that hard = to >> come up with a packet generator. However, the hard part is to realize ho= w >> representative those packet generator are for our usecases at hand? IMHO= , >> we will need to verify the generate packet trace a with some reference >> trace. Also remember we might have QoE as evaluation metric too and I h= ear >> people are also talking about subjective quality related to fairness. It >> will be hard to achieve that with just simple packet generators. For the >> fixed generator traffic, ladder steps can be used. I'm thinking I'll st= art >> a project on Google Code, and make any interested participant a develope= r >>=20 >>=20 >>=20 >> BR >>=20 >> Zahed >=20 >=20 >=20 > --=20 > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- From xiaoqzhu@cisco.com Thu Mar 14 08:57:09 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D60C11E81A0 for ; Thu, 14 Mar 2013 08:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnJr1Wpn7KmS for ; Thu, 14 Mar 2013 08:57:05 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFD611E8184 for ; Thu, 14 Mar 2013 08:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8983; q=dns/txt; s=iport; t=1363276625; x=1364486225; h=from:to:subject:date:message-id:references:mime-version; bh=VrJaeb1f1B9QtykAXTIDPHNGPE4Bk5M5+81ZjfvlR5E=; b=lGYFEMX2yWj+oZT3KjHjXYk5rlHHvhRFMUPASL1IN4G6crw2iv7U6L52 IP8RnDcoGgFD81d8oPX/b2OWsZtrYNTBPDtpdu7u4faHunw/05q37oVCQ 5V6U7vomdVMpfiaKAnKcpg0zNSilaooefsZrd7tiag1dWM1Cd2me9H9iK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQHAOXyQVGtJV2Z/2dsb2JhbABDhD2BE4U4qB2JKgGGW4FNgWIWdIIqAQEBBHcSAgEZAQIBAgsdBzIUAwQCCAIEEwgBiAsBBgXBUo1PgRAgBhEHgllhA5d3j2OBMYFZgXM1 X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208,217";a="187473004" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 14 Mar 2013 15:57:04 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2EFv4YX016100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Mar 2013 15:57:04 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 10:57:04 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: rmcat WG Thread-Topic: New Version Notification for draft-zhu-rmcat-nada-01.txt Thread-Index: AQHOH1Lt4rvdatbNeEqBG1ft4k1VZw== Date: Thu, 14 Mar 2013 15:57:03 +0000 Message-ID: References: <20130312185342.17732.31996.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.127.73] Content-Type: multipart/alternative; boundary="_000_E7175A8E3DC14048A7D3020E0338C1FA1238B58Exmbalnx13ciscoc_" MIME-Version: 1.0 Subject: [rmcat] Fwd: New Version Notification for draft-zhu-rmcat-nada-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: Thu, 14 Mar 2013 15:57:09 -0000 --_000_E7175A8E3DC14048A7D3020E0338C1FA1238B58Exmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We submitted the updated version of the NADA scheme, as presented by Rong o= n Monday. The major change from the last version is that all forms of congestion sign= als from the network (loss/delay/ECN/PCN) are now integrated into a composi= te signal (which we call "equivalent delay"), so that the sender can react = in exactly the same manner. No more mode switching between ECN-enabled and = ECN-disabled at the sender, as in draft-00 and criticized by Michael in pre= vious email discussions. We also much appreciate all the feedback and discussions on the scheme duri= ng the WG meeting on Monday, as summarized in Spencer's notes. Will try to = address these issues, clarify some of the doubts, and improve our design ac= cordingly. Thanks, Xiaoqing Begin forwarded message: From: > Date: March 12, 2013 1:53:42 PM CDT To: > Cc: > Subject: New Version Notification for draft-zhu-rmcat-nada-01.txt A new version of I-D, draft-zhu-rmcat-nada-01.txt has been successfully submitted by Xiaoqing Zhu and posted to the IETF repository. Filename: draft-zhu-rmcat-nada Revision: 01 Title: NADA: A Unified Congestion Control Scheme for Real-Time Media Creation date: 2013-03-12 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-0= 1.txt Status: http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-zhu-rmcat-nada-01 Abstract: This document describes a scheme named network-assisted dynamic adaptation (NADA), a novel congestion control approach for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from explicit congestion notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays and packet losses instead. We present here the overall system architecture, recommended behaviors at the sender and the receiver, as well as expected network node operations. Results from extensive simulation studies of the proposed scheme are available upon request. The IETF Secretariat --_000_E7175A8E3DC14048A7D3020E0338C1FA1238B58Exmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <0BAE7F3FB3D6514088C07D398264CABC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi, 


We submitted the updated version of the NADA scheme, as presented by R= ong on Monday.  

The major change from the last version is that all forms of congestion= signals from the network (loss/delay/ECN/PCN) are now integrated into a co= mposite signal (which we call "equivalent delay"), so that the se= nder can react in exactly the same manner. No more mode switching between ECN-enabled and ECN-disabled at the sender,= as in draft-00 and criticized by Michael in previous email discussions.&nb= sp;

We also much appreciate all the feedback and discussions on the scheme= during the WG meeting on Monday, as summarized in Spencer's notes. Will tr= y to address these issues, clarify some of the doubts, and improve our desi= gn accordingly. 

Thanks,
Xiaoqing


Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Date: March= 12, 2013 1:53:42 PM CDT
To: <<= a href=3D"mailto:xiaoqzhu@cisco.com">xiaoqzhu@cisco.com>
Cc: <<= a href=3D"mailto:ropan@cisco.com">ropan@cisco.com>
Subject: Ne= w Version Notification for draft-zhu-rmcat-nada-01.txt


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

Filename: d= raft-zhu-rmcat-nada
Revision: 0= 1
Title: NADA: A Unified= Congestion Control Scheme for Real-Time Media
Creation date: 2013-03-12
Group: Individual Subm= ission
Number of pages: 11
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-01.txt
Status:          http://datatracker.ietf= .org/doc/draft-zhu-rmcat-nada
Htmlized:        http://tools.ietf.org/html/draft-zh= u-rmcat-nada-01
Diff:            http://= www.ietf.org/rfcdiff?url2=3Ddraft-zhu-rmcat-nada-01

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

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




The IETF Secretariat


--_000_E7175A8E3DC14048A7D3020E0338C1FA1238B58Exmbalnx13ciscoc_-- From dan@marketsoup.com Thu Mar 14 10:27:12 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 6450F21F910D for ; Thu, 14 Mar 2013 10:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSgW9ToRytkE for ; Thu, 14 Mar 2013 10:27:11 -0700 (PDT) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 97BE921F910C for ; Thu, 14 Mar 2013 10:27:11 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id y26so64985iab.34 for ; Thu, 14 Mar 2013 10:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type; bh=UiNF4e9L8AyuFzPXQcImz9bGxxdVsNNMNve1BE6HWaM=; b=bVrzPOpgBxA/vzrvZTdDDR0zNztijoySnQKj4kD9StKV7WT21/UVJQfpysBIyy5N4N gO7CiiZ9q1eqnSnlNFbPFkMUO22AHswJ5F1ucgZO4DZPN/og/gzYEkT4JdtqoYFS2g1i PGkbL8rVY/tCYMcdHEeI0FiOcQNlaAtRHdeSI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=UiNF4e9L8AyuFzPXQcImz9bGxxdVsNNMNve1BE6HWaM=; b=KKMYNVBV2NurW2eVzKs2vo+u/hp4cDZ54fIVIaeKEiM6qCSvWC24Bd0fIAKs+I5Bdb Ls4cVeXM8JsFaFYVRidDYEnY4w4VTInDQpkBq4qBA2SnY6rarra94RTHIm/ENxeKUii5 VKmRSQBJVaTCOHjOVMTqkqwbDdbolBbhvvfC+IgUNzhjEl6yHJm+rTSO4wMr4BP1IUYd NGKrTdMCvFxC2nNib2EJftHjak21dJ+PRFGTe5MPUiYeLWzYw0mT2Ktp1hJdUkg6ftU5 zBlXWHNbY+TbczYgNWnLsG13J0eJiOe2I80ZKD4zIyWwNJBpzbjwLl437s7QBjK4xnqU EHWA== MIME-Version: 1.0 X-Received: by 10.50.47.170 with SMTP id e10mr21439186ign.84.1363282031192; Thu, 14 Mar 2013 10:27:11 -0700 (PDT) Received: by 10.42.55.209 with HTTP; Thu, 14 Mar 2013 10:27:11 -0700 (PDT) X-Originating-IP: [174.51.153.161] Date: Thu, 14 Mar 2013 11:27:11 -0600 Message-ID: From: Dan Weber To: rmcat@ietf.org Content-Type: multipart/alternative; boundary=14dae9340e3b32c47604d7e5d59b X-Gm-Message-State: ALoCoQm2jEXJT1/0ocKe3G0P/tQXdS1qjXKMaAYi+J1EAG34EF2jOlEicqNH0sLXFofso/h3YTSN Subject: [rmcat] Packet Generator Requirements 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, 14 Mar 2013 17:27:12 -0000 --14dae9340e3b32c47604d7e5d59b Content-Type: text/plain; charset=UTF-8 Hi everyone, After looking at the technology suggestions and responses to the last thread (RMCAT Evaluation Ideas), I think it would make sense if we defined some basic criteria for what makes an effective testing tool. My intent is to utilize a tool in which we can get true apples to apples comparisons while being inclusive of as many people as possible. Likewise, it should also be reasonably comparable to a real world implementation. Here are some questions that come to mind: 1) Does the testing tool (packet generator) implement or use an existing RTP stack implementation? 2) Is the tool or suggested application portable? e.g. Can we run this on windows, linux, and mac os x? 3) Is the application framework extensible to support new flows? e.g. What difficulty is presented if someone wants to send an actual video stream versus just generated packets? 4) Is it possible to implement congestion control algorithms on top of it or its output? 5) What are all of the metrics it supports? Does it support outputting these metrics in common units such as seconds, packets, etc.? 6) Does it output data in a human readable or easily parseable format such as CSV or text? 7) Does the data it outputs support the generation of line charts? Feel free to add any questions you think may fit. If you have an implementation that you think is worth standardizing on, please answer these questions with your submission. Thanks! Dan --14dae9340e3b32c47604d7e5d59b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi everyone,

After looking at the technology suggestions and respons= es to the last thread (RMCAT Evaluation Ideas), I think it would make sense= if we defined some basic criteria for what makes an effective testing tool= .

My intent is to utilize a tool in which we can get true apples to apple= s comparisons while being inclusive of as many people as possible.=C2=A0 Li= kewise, it should also be reasonably comparable to a real world implementat= ion.

Here are some questions that come to mind:

1) Does the testing t= ool (packet generator) implement or use an existing RTP stack implementatio= n?
2) Is the tool or suggested application portable? e.g. Can we run thi= s on windows, linux, and mac os x?
3) Is the application framework extensible to support new flows?=C2=A0 e.g.= What difficulty is presented if someone wants to send an actual video stre= am versus just generated packets?
4) Is it possible to implement congest= ion control algorithms on top of it or its output?
5) What are all of the metrics it supports?=C2=A0 Does it support outputtin= g these metrics in common units such as seconds, packets, etc.?
6) Does = it output data in a human readable or easily parseable format such as CSV o= r text?
7) Does the data it outputs support the generation of line charts?

F= eel free to add any questions you think may fit.

If you have an impl= ementation that you think is worth standardizing on, please answer these qu= estions with your submission.

Thanks!
Dan
--14dae9340e3b32c47604d7e5d59b-- From dan@marketsoup.com Thu Mar 14 10:35: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 7170F11E819A for ; Thu, 14 Mar 2013 10:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rz0DdyMVSBO4 for ; Thu, 14 Mar 2013 10:35:45 -0700 (PDT) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1F15911E8197 for ; Thu, 14 Mar 2013 10:35:45 -0700 (PDT) Received: by mail-ia0-f182.google.com with SMTP id b35so2330474iac.13 for ; Thu, 14 Mar 2013 10:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6l/JI+jfndsjfT49QVfXaQW4GJ7kDDXKH2xP0jAadh0=; b=FxPkvUAL53bqGgw5dZJ5lhdITKfu+60O5AIck4X0KR34Z5eq0wjKvoeJFj6sX+lool 2a6zoglgB+Q1DFOLkfDwmIa2NaNX/QN0Eh33xkddUCQAwNOd6hxXhqs87itIjlcOvgOY Hik5338+a8QQn4kcrfiu/lfWjJWT/Kzw5/VH0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6l/JI+jfndsjfT49QVfXaQW4GJ7kDDXKH2xP0jAadh0=; b=CXV27NsZU/b+Eru9DuzcI/51+Vtyq54dw8z9sMlxpH7NYo89nAyt7CBU9RJQIcwU/0 ZEIIoFH9bCnuN4zQLyoJitimwOejI8R/NB4edyJnBebQMl4ldIkSWOsQZcEJbyO/S7am EW7kaWwonjR4Bo7Z42kTFeLQi1RDXBZS92keS4xRyvbLnrEQrJixb1nn5ynJG7wUdlF2 yO6BkhHiTREJjpaOdVFHL1g9OpicM2pPu523WU32bf0XH/0BIQjZmVQvGl1ChR/EejhF t1bRX9nkdY8GE1IhzPMTzs+Sjs6/f7L0NWhx6qQcMPznixPp4rxtxxSR7RJ1ubDNAzdS KxLw== MIME-Version: 1.0 X-Received: by 10.50.34.231 with SMTP id c7mr2885961igj.95.1363282543587; Thu, 14 Mar 2013 10:35:43 -0700 (PDT) Received: by 10.42.55.209 with HTTP; Thu, 14 Mar 2013 10:35:43 -0700 (PDT) X-Originating-IP: [174.51.153.161] In-Reply-To: References: Date: Thu, 14 Mar 2013 11:35:43 -0600 Message-ID: From: Dan Weber To: Varun Singh Content-Type: multipart/alternative; boundary=14dae9340eebbd92b204d7e5f38d X-Gm-Message-State: ALoCoQnnf6/OZDbCQU7MilMwZJsV9zWjs3X9SN4H7HF8k/0FcHDOI+XgLBjGN7wnT3wqY4VdylDS Cc: rmcat@ietf.org Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 17:35:49 -0000 --14dae9340eebbd92b204d7e5f38d Content-Type: text/plain; charset=UTF-8 Hi Varun, On Thu, Mar 14, 2013 at 7:34 AM, Varun Singh wrote: > Hi Dan, > > On Thu, Mar 14, 2013 at 12:20 AM, Dan Weber wrote: > > > > Given: A video media stream sends at 512kbit/s on a link with an upstream > > capacity of 512 kbit/s > > When: an FTP Transfer of 1GB file begins uploading > > Then: Packet loss occurs. Throughput should be diminished. RTPCC should > > notify application of developments. > > > > Given: A link with capacity limited at 512 kbit/s > > When: A video conference call starts sending Mulaw audio (ptime=20, > > 81.92kbit/s) and Video @ max kbitrate of 384 kbit/s > > Then: All packets should be received. > > > > The "Then" part may depend also on what other network characteristics > may be applied (path loss and/or delay). > > > I concur. Even putting together these surprisingly simple behavior cases is difficult. Every single one of these cases needs to be tangible and easily implementable. Your specific note carries relevance. How do you define the network environment? Linux's Network Emulation (netem, http://www.linuxfoundation.org/collaborate/workgroups/networking/netem) provides a very valuable toolset for this sort of thing. Do you think it would make sense to use its capabilities for defining our 'given' case? I'm looking forward to reading Lars's paper to see if it may provide some more insight into this matter. Thanks, Dan --14dae9340eebbd92b204d7e5f38d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Varun,

On Thu, Mar 14, 2013 at 7:34 AM= , Varun Singh <vsingh.ietf@gmail.com> wrote:
Hi Dan,

On Thu, Mar 14, 2013 at 12:20 AM, Dan Weber <dan@marketsoup.com> wrote:
>
> Given: A video media stream sends at 512kbit/s on a link with an upstr= eam
> capacity of 512 kbit/s
> When: an FTP Transfer of 1GB file begins uploading
> Then: Packet loss occurs. =C2=A0Throughput should be diminished. =C2= =A0RTPCC should
> notify application of developments.
>
> Given: A link with capacity limited at 512 kbit/s
> When: A video conference call starts sending Mulaw audio (ptime=3D20,<= br> > 81.92kbit/s) and Video @ max kbitrate of 384 kbit/s
> Then: =C2=A0All packets should be received.
>

The "Then" part may depend also on what other network chara= cteristics
may be applied (path loss and/or delay).


I concur.=C2=A0 Even putting together the= se surprisingly simple behavior cases is difficult.=C2=A0 Every single one = of these cases needs to be tangible and easily implementable.=C2=A0
Your specific note carries relevance.=C2=A0 How do you define the network = environment?=C2=A0 Linux's Network Emulation (netem, http://www= .linuxfoundation.org/collaborate/workgroups/networking/netem) provides = a very valuable toolset for this sort of thing.=C2=A0

Do you think it would make sense to use its capabilities for defining o= ur 'given' case?

I'm looking forward to reading Lars= 9;s paper to see if it may provide some more insight into this matter.

Thanks,
Dan

--14dae9340eebbd92b204d7e5f38d-- From vsingh.ietf@gmail.com Thu Mar 14 11:00:35 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 17B6411E8129 for ; Thu, 14 Mar 2013 11:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rUynUDI-DcN1 for ; Thu, 14 Mar 2013 11:00:34 -0700 (PDT) Received: from mail-ia0-x230.google.com (mail-ia0-x230.google.com [IPv6:2607:f8b0:4001:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id D489311E8162 for ; Thu, 14 Mar 2013 11:00:33 -0700 (PDT) Received: by mail-ia0-f176.google.com with SMTP id i18so2322717iac.7 for ; Thu, 14 Mar 2013 11:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type; bh=qoylPOyo/eF2x3YahMbUzLODwoeNvBpasKraEuggBzI=; b=jQFsaCukJBZULfWt2dMmfkwuimiYAKL7bBXxCwXNT0fx6dgdpS11W9OGYkhlmfDRht 0Vr2rsspp3CBH9cyaMdNj4tebHv+hY2+4OEuNR+1s6uBook69oXi3NZuNeF3Onz33jK9 BXCLJSUTPsOKNoMHI5dVgaiB0gIBg9a9sVGBavPkBTPi/DKL7z1I0zhiK4pK7L2jVQu9 vK02UziT3PSyDxzkU2pKg3Pc1TEzok8esnIDtdkuj1yEkfNu2ZQ1NzcrcMBdeICxrW62 K/G2i75ZU8NiXtBu1GJ4/r+3qeuOmWC4oaspiPM4r9iVjeSmBGrtDNyZcAOnG8qOCAid Zl7g== X-Received: by 10.50.217.167 with SMTP id oz7mr20999411igc.26.1363284033457; Thu, 14 Mar 2013 11:00:33 -0700 (PDT) References: From: Varun Singh Mime-Version: 1.0 (1.0) In-Reply-To: Date: Thu, 14 Mar 2013 14:00:30 -0400 Message-ID: <8599976746477508614@unknownmsgid> To: Dan Weber Content-Type: multipart/alternative; boundary=14dae93403918ad7c204d7e64c4b Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 18:00:35 -0000 --14dae93403918ad7c204d7e64c4b Content-Type: text/plain; charset=ISO-8859-1 On 14.3.2013, at 13.35, Dan Weber wrote: Hi Varun, On Thu, Mar 14, 2013 at 7:34 AM, Varun Singh wrote: > Hi Dan, > > On Thu, Mar 14, 2013 at 12:20 AM, Dan Weber wrote: > > > > Given: A video media stream sends at 512kbit/s on a link with an upstream > > capacity of 512 kbit/s > > When: an FTP Transfer of 1GB file begins uploading > > Then: Packet loss occurs. Throughput should be diminished. RTPCC should > > notify application of developments. > > > > Given: A link with capacity limited at 512 kbit/s > > When: A video conference call starts sending Mulaw audio (ptime=20, > > 81.92kbit/s) and Video @ max kbitrate of 384 kbit/s > > Then: All packets should be received. > > > > The "Then" part may depend also on what other network characteristics > may be applied (path loss and/or delay). > > > I concur. Even putting together these surprisingly simple behavior cases is difficult. Every single one of these cases needs to be tangible and easily implementable. My take for the cc-eval was to define some of these characteristics as variables. Then the implementer can pick values for a variable from a set. This will create a combinatorial explosion of tests for each scenario, but I hope we can attempt to constrain the number of variables in each scenario. Your specific note carries relevance. How do you define the network environment? Linux's Network Emulation (netem, http://www.linuxfoundation.org/collaborate/workgroups/networking/netem) provides a very valuable toolset for this sort of thing. I have used both netem, and dummynet. However there is netkit, AutoNetkit. Both of these have been recommended but I haven't used either for RTP. Do you think it would make sense to use its capabilities for defining our 'given' case? Typically the tools allow setting delay, throughput, packet loss rate, queue length. (The list may be longer). However, packet loss rate is random, which doesn't work well for some of our tests. For dummynet, I have a wrapper written up for changing some of these params. See https://github.com/vr000m/Research-Scripts/tree/master/dummynet I'm looking forward to reading Lars's paper to see if it may provide some more insight into this matter. Thanks, Dan --14dae93403918ad7c204d7e64c4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 14.3.2013, at 13= .35, Dan Weber <dan@marketsoup.com= > wrote:

Hi Varun,

On Thu, Mar 14, 2013 at 7:34 AM, Varun Singh &l= t;vsingh.ietf@gm= ail.com> wrote:
Hi Dan,

On Thu, Mar 14, 2013 at 12:20 AM, Dan Weber <dan@marketsoup.com> wrote:
>
> Given: A video media stream sends at 512kbit/s on a link with an upstr= eam
> capacity of 512 kbit/s
> When: an FTP Transfer of 1GB file begins uploading
> Then: Packet loss occurs. =A0Throughput should be diminished. =A0RTPCC= should
> notify application of developments.
>
> Given: A link with capacity limited at 512 kbit/s
> When: A video conference call starts sending Mulaw audio (ptime=3D20,<= br> > 81.92kbit/s) and Video @ max kbitrate of 384 kbit/s
> Then: =A0All packets should be received.
>

The "Then" part may depend also on what other network chara= cteristics
may be applied (path loss and/or delay).


I concur.=A0 Even putting together these = surprisingly simple behavior cases is difficult.=A0 Every single one of the= se cases needs to be tangible and easily implementable.=A0


My take for the cc-eval was to defin= e some of these characteristics as variables. Then the implementer can pick= values for a variable from a set.=A0

This will cr= eate a combinatorial explosion of tests for each scenario, but I hope we ca= n attempt to constrain the number of variables in each scenario.=A0

Your spe= cific note carries relevance.=A0 How do you define the network environment?= =A0 Linux's Network Emulation (netem, http://www.linuxfoundatio= n.org/collaborate/workgroups/networking/netem) provides a very valuable= toolset for this sort of thing.=A0


I have used both net= em, and dummynet.=A0

However there is netkit, Auto= Netkit. Both of these have been recommended =A0but I haven't used eithe= r for RTP.=A0

Do you think it would make sense to use its capabilities for defining ou= r 'given' case?



Typically the tools allow setting delay, throughput, packet = loss rate, queue length. (The list may be longer).=A0

Ho= wever, packet loss rate is random, which doesn't work well for some of = our tests.=A0

For dummynet, I have a wrapper written up for changing = some of these params.=A0
See=A0


I'm looking forward to reading Lars's paper to see = if it may provide some more insight into this matter.

Thanks,<= br>Dan

--14dae93403918ad7c204d7e64c4b-- From versteb@cisco.com Thu Mar 14 11:04:40 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 C555811E8110 for ; Thu, 14 Mar 2013 11:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj8v4Z+Mawzx for ; Thu, 14 Mar 2013 11:04:39 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id ABB3511E8162 for ; Thu, 14 Mar 2013 11:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7800; q=dns/txt; s=iport; t=1363284277; x=1364493877; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gF9cpwVGaevrR4kZrQ9NR1aw0JOornMacoA9ANefdz8=; b=LIRjMVIf584/p9fT4VVv26bfiZE6o4lOeqCOV2y8zwbY4tDjAJrscFkJ hihD5e7C8NnHvLCrW4iZj/93qwwXzGan9iGP4ycWe/v2YQGv0TxqXheVh 95tTCqkYP8kbGhhKDSQl66sNWFdVVTYJXG0XrXG1I2VdIA+ARJb6rdboh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFoQQlGtJXG8/2dsb2JhbABDxQKBZRZ0gisBAQEEZwEREAIBCBgnByERFBECBAoEBQmHeQMPDLghDYlbjEyBE4E3B4JfYQOTE4FlgWCLaIUagwqBag X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208,217";a="187339462" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 14 Mar 2013 18:04:33 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2EI4XZT032011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 18:04:33 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 13:04:33 -0500 From: "Bill Ver Steeg (versteb)" To: Dan Weber Thread-Topic: [rmcat] Congestion Control Behavior Suggestion Thread Thread-Index: AQHOIGtXxJthuk91K06P9e0++zMsapilhFsAgABDVID//7Q97w== Date: Thu, 14 Mar 2013 18:04:33 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DE646A448F77411AB4A41740961A590Eciscocom_" MIME-Version: 1.0 Cc: "rmcat@ietf.org" , Varun Singh Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 18:04:40 -0000 --_000_DE646A448F77411AB4A41740961A590Eciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable netem is a very good emulation tool, and we often use it to get close to th= e right answer. However, I will caution that there is a wide variety of pac= ket schedulers in use in the wild. Not all of them the exhibit flat, determ= inistic scheduling that netem defaults to. One (of many) example of such a packet scheduling/limiting algorithm was de= scribed in yesterday's congestion control research group. HFC CPE (cable mo= dems) use a leaky bucket algorithm that provides a weighted average to enfo= rce an SLA, and this can interact with higher level control loops. In other= words, if a sender is slightly under the provisioned link rate for a while= , it can then can send at slightly over the link rate for a while. If you a= re not careful, a variable bitrate sender can infer an incorrect SLA rate b= ased on such scheduler behavior. I do not imply that this is the definitive= case, just that there can be interactions. Flow control algorithms that wo= rk very well for a given scheduler can have unexpected entanglements with a= nother (chain of) schedulers. Fortunately, there are ways to introduce these behaviors in test rigs. So, if we define a reference test environment, we either need to have a few= scheduler variations or recognize that the test rig is only a first-order = approximation and live testing on a variety of network topologies is requir= ed. Short version- I agree that netem is a very good tool, but you need to be = careful how you use it. Bvs On Mar 14, 2013, at 1:35 PM, "Dan Weber" > wrote: Hi Varun, On Thu, Mar 14, 2013 at 7:34 AM, Varun Singh > wrote: Hi Dan, On Thu, Mar 14, 2013 at 12:20 AM, Dan Weber > wrote: > > Given: A video media stream sends at 512kbit/s on a link with an upstream > capacity of 512 kbit/s > When: an FTP Transfer of 1GB file begins uploading > Then: Packet loss occurs. Throughput should be diminished. RTPCC should > notify application of developments. > > Given: A link with capacity limited at 512 kbit/s > When: A video conference call starts sending Mulaw audio (ptime=3D20, > 81.92kbit/s) and Video @ max kbitrate of 384 kbit/s > Then: All packets should be received. > The "Then" part may depend also on what other network characteristics may be applied (path loss and/or delay). I concur. Even putting together these surprisingly simple behavior cases i= s difficult. Every single one of these cases needs to be tangible and easi= ly implementable. Your specific note carries relevance. How do you define the network enviro= nment? Linux's Network Emulation (netem, http://www.linuxfoundation.org/co= llaborate/workgroups/networking/netem) provides a very valuable toolset for= this sort of thing. Do you think it would make sense to use its capabilities for defining our '= given' case? I'm looking forward to reading Lars's paper to see if it may provide some m= ore insight into this matter. Thanks, Dan --_000_DE646A448F77411AB4A41740961A590Eciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
netem is a very good emulation tool, and we often use it to get close = to the right answer. However, I will caution that there is a wide variety o= f packet schedulers in use in the wild. Not all of them the exhibit flat, d= eterministic scheduling that netem defaults to. 

One (of many) example of such a packet scheduling/limiting algorithm w= as described in yesterday's congestion control research group. HFC CPE (cab= le modems) use a leaky bucket algorithm that provides a weighted average to= enforce an SLA, and this can interact with higher level control loops. In other words, if a sender is slightly u= nder the provisioned link rate for a while, it can then can send at slightl= y over the link rate for a while. If you are not careful, a variable bitrat= e sender can infer an incorrect SLA rate based on such scheduler behavior. I do not imply that this is the= definitive case, just that there can be interactions. Flow control algorit= hms that work very well for a given scheduler can have unexpected entanglem= ents with another (chain of) schedulers. 

Fortunately, there are ways to introduce these behaviors in test rigs.=  

So, if we define a reference test environment, we either need to have = a few scheduler variations or recognize that the test rig is only a first-o= rder approximation and live testing on a variety of network topologies is r= equired. 

Short version-  I agree that netem is a very good tool, but you n= eed to be careful how you use it. 

Bvs


On Mar 14, 2013, at 1:35 PM, "Dan Weber" <dan@marketsoup.com> wrote:

Hi Varun,

On Thu, Mar 14, 2013 at 7:34 AM, Varun Singh <vsingh.ietf@= gmail.com> wrote:
Hi Dan,

On Thu, Mar 14, 2013 at 12:20 AM, Dan Weber <dan@marketsoup.com> wrote:
>
> Given: A video media stream sends at 512kbit/s on a link with an upstr= eam
> capacity of 512 kbit/s
> When: an FTP Transfer of 1GB file begins uploading
> Then: Packet loss occurs.  Throughput should be diminished.  = ;RTPCC should
> notify application of developments.
>
> Given: A link with capacity limited at 512 kbit/s
> When: A video conference call starts sending Mulaw audio (ptime=3D20,<= br> > 81.92kbit/s) and Video @ max kbitrate of 384 kbit/s
> Then:  All packets should be received.
>

The "Then" part may depend also on what other network characteris= tics
may be applied (path loss and/or delay).


I concur.  Even putting together these surprisingly simple behavi= or cases is difficult.  Every single one of these cases needs to be ta= ngible and easily implementable. 

Your specific note carries relevance.  How do you define the network e= nvironment?  Linux's Network Emulation (netem, http://www.linuxfoundation.org/collaborate/workgroups/networking/netem)= provides a very valuable toolset for this sort of thing. 

Do you think it would make sense to use its capabilities for defining our '= given' case?

I'm looking forward to reading Lars's paper to see if it may provide some m= ore insight into this matter.

Thanks,
Dan

--_000_DE646A448F77411AB4A41740961A590Eciscocom_-- From dan@marketsoup.com Thu Mar 14 11:15:32 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 2836511E81BD for ; Thu, 14 Mar 2013 11:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFG93aakl8k9 for ; Thu, 14 Mar 2013 11:15:31 -0700 (PDT) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 585AF11E80E9 for ; Thu, 14 Mar 2013 11:15:31 -0700 (PDT) Received: by mail-ia0-f170.google.com with SMTP id h8so2423983iaa.29 for ; Thu, 14 Mar 2013 11:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Z2o9HunuDDSZVAhLOcEJMhynDCNIecUl5G/kg/CWNdo=; b=GqmVqUbyN3I3lwWZdLNtxD+cLP6nWZPMzLj9EvJl+OMgHkAJnOFVXTXiyq+sgpLwiq U18sS38iG6aYjkQcFUN4qbqesLw3y+HNJ20Ate8PMbRLiErIHBThAMn0N9j8kuW6VYYf n45F3+h7IDQ7pRfo4zWNDt1RkAf6tpuNfI+1Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Z2o9HunuDDSZVAhLOcEJMhynDCNIecUl5G/kg/CWNdo=; b=ilsgHRlNvhRCljkWc3mLp2iW9pTPWstzKv7jE5KMlXmRY67a17Mh5LCCLs7SYeecny Q0bXYyA+ov4nDPNBKylCqwnrw4ZLdKpQU1g5vy+kpDKNJAKN4t8Zc59JuekGaYMp/ki5 nYLVSa8sZInV22MpWUzQgtNNbDIASjC7D/KGprTA81wTrQIF5ck65Hr8ybeNZ1669mcA EYUDqbIJl+8HV27y95RkBFWd/OxLtRAAdLdSMOdraa+m+1OPR9skQ/CkVz7+gjOKjhdm AZytaF6HcHM4RseH2+VCprfGXeDz36Q8fwGv3Szust0TpmkZ8qZP4yZ1PpkBa68sbARO 7dtQ== MIME-Version: 1.0 X-Received: by 10.50.34.231 with SMTP id c7mr3013025igj.95.1363284930792; Thu, 14 Mar 2013 11:15:30 -0700 (PDT) Received: by 10.42.55.209 with HTTP; Thu, 14 Mar 2013 11:15:30 -0700 (PDT) X-Originating-IP: [174.51.153.161] In-Reply-To: References: Date: Thu, 14 Mar 2013 12:15:30 -0600 Message-ID: From: Dan Weber To: "Bill Ver Steeg (versteb)" Content-Type: multipart/alternative; boundary=14dae9340eeb072df904d7e68267 X-Gm-Message-State: ALoCoQl190skej1Vk/5Ye7DB/rrOvZDzSkX8Zjq7yV6QRenTwjsArIdA15suqbBUNa5ugbWsTtqS Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 18:15:32 -0000 --14dae9340eeb072df904d7e68267 Content-Type: text/plain; charset=UTF-8 Hi Bill, I understand your concerns about netem. It's no panacea. I'm shooting to define a table of configurable parameters to go with each test case. E.g. Ploss 1% Correlation (90%) Delay 80ms Jitter 50ms Bandwidth 2mbit/s etc. It seems to me that this is required regardless of the tools we use. If we can standardize on which parameters are adjustable, we can include them in every test case and use a variety of tools. As for defining a reference test environment, does anyone have access to some systems we could open up for the purpose of this testing? I may be able to call around and see if we can get one provided for us if no one else has resources available. Thanks, Dan On Thu, Mar 14, 2013 at 12:04 PM, Bill Ver Steeg (versteb) < versteb@cisco.com> wrote: > netem is a very good emulation tool, and we often use it to get close to > the right answer. However, I will caution that there is a wide variety of > packet schedulers in use in the wild. Not all of them the exhibit flat, > deterministic scheduling that netem defaults to. > > One (of many) example of such a packet scheduling/limiting algorithm was > described in yesterday's congestion control research group. HFC CPE (cable > modems) use a leaky bucket algorithm that provides a weighted average to > enforce an SLA, and this can interact with higher level control loops. In > other words, if a sender is slightly under the provisioned link rate for a > while, it can then can send at slightly over the link rate for a while. If > you are not careful, a variable bitrate sender can infer an incorrect SLA > rate based on such scheduler behavior. I do not imply that this is the > definitive case, just that there can be interactions. Flow control > algorithms that work very well for a given scheduler can have unexpected > entanglements with another (chain of) schedulers. > > Fortunately, there are ways to introduce these behaviors in test rigs. > > So, if we define a reference test environment, we either need to have a > few scheduler variations or recognize that the test rig is only a > first-order approximation and live testing on a variety of network > topologies is required. > > Short version- I agree that netem is a very good tool, but you need to > be careful how you use it. > > Bvs > > --14dae9340eeb072df904d7e68267 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bill,

I understand your concerns about netem.=C2=A0 It's no p= anacea.

I'm shooting to define a table of configurable parameter= s to go with each test case.

E.g.
Ploss 1% Correlation (90%)
D= elay 80ms Jitter 50ms
Bandwidth 2mbit/s
etc.

It seems to me that this is required regar= dless of the tools we use.=C2=A0 If we can standardize on which parameters = are adjustable, we can include them in every test case and use a variety of= tools.=C2=A0 As for defining a reference test environment, does anyone hav= e access to some systems we could open up for the purpose of this testing?= =C2=A0 I may be able to call around and see if we can get one provided for = us if no one else has resources available.

Thanks,
Dan

On Thu, Mar 14, 2013 a= t 12:04 PM, Bill Ver Steeg (versteb) <versteb@cisco.com> wro= te:
netem is a very good emulation tool, and we often use it to get close = to the right answer. However, I will caution that there is a wide variety o= f packet schedulers in use in the wild. Not all of them the exhibit flat, d= eterministic scheduling that netem defaults to.=C2=A0

One (of many) example of such a packet scheduling/limiting algorithm w= as described in yesterday's congestion control research group. HFC CPE = (cable modems) use a leaky bucket algorithm that provides a weighted averag= e to enforce an SLA, and this can interact with higher level control loops. In other words, if a sender is slightly u= nder the provisioned link rate for a while, it can then can send at slightl= y over the link rate for a while. If you are not careful, a variable bitrat= e sender can infer an incorrect SLA rate based on such scheduler behavior. I do not imply that this is the= definitive case, just that there can be interactions. Flow control algorit= hms that work very well for a given scheduler can have unexpected entanglem= ents with another (chain of) schedulers.=C2=A0

Fortunately, there are ways to introduce these behaviors in test rigs.= =C2=A0

So, if we define a reference test environment, we either need to have = a few scheduler variations or recognize that the test rig is only a first-o= rder approximation and live testing on a variety of network topologies is r= equired.=C2=A0

Short version- =C2=A0I agree that netem is a very good tool, but you n= eed to be careful how you use it.=C2=A0

Bvs

--14dae9340eeb072df904d7e68267-- From lars@netapp.com Thu Mar 14 11:21:38 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 E270011E81F0 for ; Thu, 14 Mar 2013 11:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.493 X-Spam-Level: X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 aqr-7jQslzBY for ; Thu, 14 Mar 2013 11:21:38 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 775DB11E81E9 for ; Thu, 14 Mar 2013 11:21:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,846,1355126400"; d="scan'208";a="30842200" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 14 Mar 2013 11:21:37 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2EILbnk027422; Thu, 14 Mar 2013 11:21:37 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 11:21:36 -0700 From: "Eggert, Lars" To: "Bill Ver Steeg (versteb)" Thread-Topic: [rmcat] Congestion Control Behavior Suggestion Thread Thread-Index: AQHOIGtWgEUKQwH3cECqMQTKMwzdzJilpeIAgABDVICAAAgOgIAABMYA Date: Thu, 14 Mar 2013 18:21:36 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <854963C47950994DA87277129A2C4ECB@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dan Weber , Varun Singh , "rmcat@ietf.org" Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 18:21:39 -0000 Hi, one thing to keep in mind is that we don't have to describe a fully exhaust= ive list of tests in eval-criteria, esp. initially. If we describe a few and the folks pushing solution candidates ran these, t= hat'd be great. They should also run other tests, and some of them in turn = should make it into a future revision of eval-criteria. I do (again) want to encourage the folks that are proposing one solution ca= ndidate to also try to compare theirs against the others directly in one me= asurement setup, instead of everyone only bringing their set of measurement= s and then we all trust that the setups were really fully comparable. Esp. = great would be if folks actually implemented each other's candidates instea= d of just running the other's code. This way, we'd have way ore confidence = that the respective specs were complete and correct. Lars= From dan@marketsoup.com Thu Mar 14 11:24:28 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 E6E1E21F8E71 for ; Thu, 14 Mar 2013 11:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJ1Lz9-UA+46 for ; Thu, 14 Mar 2013 11:24:28 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 122CB21F8E57 for ; Thu, 14 Mar 2013 11:24:27 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id c12so3359622ieb.6 for ; Thu, 14 Mar 2013 11:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=alus4RM07Id6HkvWwrzKbEt6bDjuSZtElNGvf825APo=; b=bWD4zQNyagTz/snaMJ2Bss1tc+vcd75ba6lZMstZvkmBTedZBnzS7LVTSDehX7Kv7B AB9A/zEcYlvUe0wx6Zi7AgK5Tk2TAN31cxQQwN3eM4svoZZtALCz4o3rFvHrkiaSPub0 PFlZP5NRlMqYLrMyqeRF2J861jig/4yaYsD+I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=alus4RM07Id6HkvWwrzKbEt6bDjuSZtElNGvf825APo=; b=V8kAwutp+ELd2lpNyAT13MJXBAwiZ8VlNSLmiiUgPZPXYVBF6jZIhIrjYe5gaZlk3r 7PbOoR6a7254q+CwhyC3MmpXyQrw6nrGtRrpEgQPWSNEDYeCXYw9XJs3iCH2bMh+APw4 jSibTyuCJCIALhe7Hg3NB8+iGzSYJc/oe9gMUoYz4OotvsMLrf1oJNFO1Vp3bmM5vZ8e z7XO2/1tdyFRsuYK+NeE2xOphw6QPIMBKQLel6+rBxb2rGh3lIqBUwWq0JWa6rVaaG9K PUtdKj7o3wkRylKUs5RrbDry1EX3XeVceIht2asQpMCYOVwZlZ/PX3v+jCGn+T+iWyqM c+9w== MIME-Version: 1.0 X-Received: by 10.50.189.170 with SMTP id gj10mr3403154igc.1.1363285467392; Thu, 14 Mar 2013 11:24:27 -0700 (PDT) Received: by 10.42.55.209 with HTTP; Thu, 14 Mar 2013 11:24:27 -0700 (PDT) X-Originating-IP: [174.51.153.161] In-Reply-To: <8599976746477508614@unknownmsgid> References: <8599976746477508614@unknownmsgid> Date: Thu, 14 Mar 2013 12:24:27 -0600 Message-ID: From: Dan Weber To: Varun Singh Content-Type: multipart/alternative; boundary=14dae934037b0310b404d7e6a25f X-Gm-Message-State: ALoCoQl2fytN3MFGcVFvOLSRRQU1hfwrLa5gsayL1ADlOelJ9nD6zI4wOjjlgUS+w1/cBLVRkwDt Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 18:24:29 -0000 --14dae934037b0310b404d7e6a25f Content-Type: text/plain; charset=UTF-8 Hi Varun, On Thu, Mar 14, 2013 at 12:00 PM, Varun Singh wrote: > > On 14.3.2013, at 13.35, Dan Weber wrote: > > Hi Varun, > > On Thu, Mar 14, 2013 at 7:34 AM, Varun Singh wrote: > >> Hi Dan, >> >> On Thu, Mar 14, 2013 at 12:20 AM, Dan Weber wrote: >> > >> > Given: A video media stream sends at 512kbit/s on a link with an >> upstream >> > capacity of 512 kbit/s >> > When: an FTP Transfer of 1GB file begins uploading >> > Then: Packet loss occurs. Throughput should be diminished. RTPCC >> should >> > notify application of developments. >> > >> > Given: A link with capacity limited at 512 kbit/s >> > When: A video conference call starts sending Mulaw audio (ptime=20, >> > 81.92kbit/s) and Video @ max kbitrate of 384 kbit/s >> > Then: All packets should be received. >> > >> >> The "Then" part may depend also on what other network characteristics >> may be applied (path loss and/or delay). >> >> >> I concur. Even putting together these surprisingly simple behavior cases > is difficult. Every single one of these cases needs to be tangible and > easily implementable. > > > My take for the cc-eval was to define some of these characteristics as > variables. Then the implementer can pick values for a variable from a set. > > This will create a combinatorial explosion of tests for each scenario, but > I hope we can attempt to constrain the number of variables in each > scenario. > I'm not sure I understand exactly what you mean by this. I do understand how a combinatorial explosion can occur with countless parameters. However, this problem mirrors ones used in other fields. I'm not sure if you're familiar with Genichi Taguchi but he defined the methods that are the backbone of most popular total quality management systems. His solution to this particular problem is the use of an orthogonal array. You might enjoy reading his article on their use: "Robust Quality" http://offermaxima.com/pdfs/RobustQuality.pdf > > Your specific note carries relevance. How do you define the network > environment? Linux's Network Emulation (netem, > http://www.linuxfoundation.org/collaborate/workgroups/networking/netem) > provides a very valuable toolset for this sort of thing. > > > I have used both netem, and dummynet. > > However there is netkit, AutoNetkit. Both of these have been recommended > but I haven't used either for RTP. > > I have not used dummynet, netkit, or autonetkit, but I'm always interested in trying new things. Is there a basic set of parameters that apply to all of them? > Do you think it would make sense to use its capabilities for defining our > 'given' case? > > > > Typically the tools allow setting delay, throughput, packet loss rate, > queue length. (The list may be longer). > > However, packet loss rate is random, which doesn't work well for some of > our tests. > Netem does allow for packet loss with correlation so that you can generate burst packet loss, although the distribution is still primarily random. However, that may be reasonably good enough if we get the rest of the packet loss from actually limiting the link capacity. > > For dummynet, I have a wrapper written up for changing some of these > params. > See > https://github.com/vr000m/Research-Scripts/tree/master/dummynet > > > I'll check this out when I get a chance. Thanks, Dan --14dae934037b0310b404d7e6a25f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Varun,

On Thu, Mar 14, 2013 at 12:00 P= M, Varun Singh <vsingh.ietf@gmail.com> wrote:

On 14.3.2013, at 13= .35, Dan Weber <= dan@marketsoup.com> wrote:

Hi Varun,

On Thu, Mar 14, 2013 at 7:34 AM, Varun Singh &l= t;vsingh.ietf@gm= ail.com> wrote:
Hi Dan,

On Thu, Mar 14, 2013 at 12:20 AM, Dan Weber <dan@marketsoup.com> wrote:
>
> Given: A video media stream sends at 512kbit/s on a link with an upstr= eam
> capacity of 512 kbit/s
> When: an FTP Transfer of 1GB file begins uploading
> Then: Packet loss occurs. =C2=A0Throughput should be diminished. =C2= =A0RTPCC should
> notify application of developments.
>
> Given: A link with capacity limited at 512 kbit/s
> When: A video conference call starts sending Mulaw audio (ptime=3D20,<= br> > 81.92kbit/s) and Video @ max kbitrate of 384 kbit/s
> Then: =C2=A0All packets should be received.
>

The "Then" part may depend also on what other network chara= cteristics
may be applied (path loss and/or delay).


I concur.=C2=A0 Even putting together the= se surprisingly simple behavior cases is difficult.=C2=A0 Every single one = of these cases needs to be tangible and easily implementable.=C2=A0

My take for the cc-eval was to= define some of these characteristics as variables. Then the implementer ca= n pick values for a variable from a set.=C2=A0

Thi= s will create a combinatorial explosion of tests for each scenario, but I h= ope we can attempt to constrain the number of variables in each scenario.= =C2=A0

I'm not sure I understand exactly what you = mean by this.=C2=A0 I do understand how a combinatorial explosion can occur= with countless parameters.=C2=A0 However, this problem mirrors ones used i= n other fields.=C2=A0 I'm not sure if you're familiar with Genichi = Taguchi but he defined the methods that are the backbone of most popular to= tal quality management systems.=C2=A0 His solution to this particular probl= em is the use of an orthogonal array.=C2=A0 You might enjoy reading his art= icle on their use: "Robust Quality" http://offermaxima.com/pdfs/RobustQuality.pdf<= /a>




I have used bo= th netem, and dummynet.=C2=A0

However there is net= kit, AutoNetkit. Both of these have been recommended =C2=A0but I haven'= t used either for RTP.=C2=A0

I have not used dummynet, netk= it, or autonetkit, but I'm always interested in trying new things.=C2= =A0 Is there a basic set of parameters that apply to all of them?
Do you think it would make sense to use = its capabilities for defining our 'given' case?



Typically the tools allow setting delay, throughput, p= acket loss rate, queue length. (The list may be longer).=C2=A0

However, packet loss rate is random, which doesn't work well for= some of our tests.=C2=A0
Netem does allow for packet loss with correlation s= o that you can generate burst packet loss, although the distribution is sti= ll primarily random.=C2=A0 However, that may be reasonably good enough if w= e get the rest of the packet loss from actually limiting the link capacity.=

For dummynet, I have a wrapper written up for changing = some of these params.=C2=A0
See=C2=A0


I'll check this out when I get a chance.

Thanks,Dan
--14dae934037b0310b404d7e6a25f-- From versteb@cisco.com Thu Mar 14 11:30:40 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 6DB1211E8200 for ; Thu, 14 Mar 2013 11:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi1xuMTnzQzm for ; Thu, 14 Mar 2013 11:30:39 -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 70C5C11E81FE for ; Thu, 14 Mar 2013 11:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7816; q=dns/txt; s=iport; t=1363285839; x=1364495439; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1e4Oa4qD2YR8uouH/EYbHKfcx8Q2RZRbZQ78gl/BZig=; b=h+Rm1f8ryx0c4LSAXrcnsMDOk0Uh6LB1YhBRf1JrNc34PWay9kNWlCs1 tPqrHk5AP7GIj74Udbe/fMRQN8vkmMUZBYpmiWaFmAxBc4/IszWOsyz+Q RkpG+TS6YfwO8T/xZ0mnu4fjqjanCaJf6npR68b0E1djEPZDJ6k0LG8ug 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE8VQlGtJXHA/2dsb2JhbABDxQKBZRZ0giwBAQR5EAIBCD8HMhQRAgQOBYgUwgqPFgeCX2EDkxODRZECgwo X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208,217";a="187560807" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 14 Mar 2013 18:30:39 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2EIUcHV023302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 18:30:38 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 13:30:38 -0500 From: "Bill Ver Steeg (versteb)" To: Dan Weber Thread-Topic: [rmcat] Congestion Control Behavior Suggestion Thread Thread-Index: AQHOIGtXxJthuk91K06P9e0++zMsapilhFsAgABDVID//7Q974AAVuEA//+wZzc= Date: Thu, 14 Mar 2013 18:30:37 +0000 Message-ID: <9257B4B4-6284-4E73-AA1C-EED18901424E@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9257B4B462844E73AA1CEED18901424Eciscocom_" MIME-Version: 1.0 Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 18:30:40 -0000 --_000_9257B4B462844E73AA1CEED18901424Eciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In an ns2 environment, having a physical test rig is mute. Quite a bit of p= rogress can be made in this domain. A simple tar file of the complete ns2 t= est rig would make for results that can be verified, tweaked and retested. Once we move to a real device, it seems that Linux sources and sinks with n= etem-like impairments would work. I used to have a pretty good test rig, bu= t I loaned it to GaTech last year....... I do think that a well defined test rig would help in this effort, and also= in the broader congestion work underway at IETF. Getting gear is easier th= an staff to run it. If I can get a coop student this summer, maybe I can co= bble some gear together and stand up a test rig somewhere that is publicly = accessible. Bvs On Mar 14, 2013, at 2:15 PM, "Dan Weber" > wrote: Hi Bill, I understand your concerns about netem. It's no panacea. I'm shooting to define a table of configurable parameters to go with each t= est case. E.g. Ploss 1% Correlation (90%) Delay 80ms Jitter 50ms Bandwidth 2mbit/s etc. It seems to me that this is required regardless of the tools we use. If we= can standardize on which parameters are adjustable, we can include them in= every test case and use a variety of tools. As for defining a reference t= est environment, does anyone have access to some systems we could open up f= or the purpose of this testing? I may be able to call around and see if we= can get one provided for us if no one else has resources available. Thanks, Dan On Thu, Mar 14, 2013 at 12:04 PM, Bill Ver Steeg (versteb) > wrote: netem is a very good emulation tool, and we often use it to get close to th= e right answer. However, I will caution that there is a wide variety of pac= ket schedulers in use in the wild. Not all of them the exhibit flat, determ= inistic scheduling that netem defaults to. One (of many) example of such a packet scheduling/limiting algorithm was de= scribed in yesterday's congestion control research group. HFC CPE (cable mo= dems) use a leaky bucket algorithm that provides a weighted average to enfo= rce an SLA, and this can interact with higher level control loops. In other= words, if a sender is slightly under the provisioned link rate for a while= , it can then can send at slightly over the link rate for a while. If you a= re not careful, a variable bitrate sender can infer an incorrect SLA rate b= ased on such scheduler behavior. I do not imply that this is the definitive= case, just that there can be interactions. Flow control algorithms that wo= rk very well for a given scheduler can have unexpected entanglements with a= nother (chain of) schedulers. Fortunately, there are ways to introduce these behaviors in test rigs. So, if we define a reference test environment, we either need to have a few= scheduler variations or recognize that the test rig is only a first-order = approximation and live testing on a variety of network topologies is requir= ed. Short version- I agree that netem is a very good tool, but you need to be = careful how you use it. Bvs --_000_9257B4B462844E73AA1CEED18901424Eciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In an ns2 environment, having a physical test rig is mute. Quite a bit= of progress can be made in this domain. A simple tar file of the complete = ns2 test rig would make for results that can be verified, tweaked and retes= ted. 

Once we move to a real device, it seems that Linux sources and sinks w= ith netem-like impairments would work. I used to have a pretty good test ri= g, but I loaned it to GaTech last year....... 

I do think that a well defined test rig would help in this effort, and= also in the broader congestion work underway at IETF. Getting gear is easi= er than staff to run it. If I can get a coop student this summer, maybe I c= an cobble some gear together and stand up a test rig somewhere that is publicly accessible. 


Bvs 

On Mar 14, 2013, at 2:15 PM, "Dan Weber" <dan@marketsoup.com> wrote:

Hi Bill,

I understand your concerns about netem.  It's no panacea.

I'm shooting to define a table of configurable parameters to go with each t= est case.

E.g.
Ploss 1% Correlation (90%)
Delay 80ms Jitter 50ms
Bandwidth 2mbit/s
etc.

It seems to me that this is required regardless of the tools we use.  = If we can standardize on which parameters are adjustable, we can include th= em in every test case and use a variety of tools.  As for defining a r= eference test environment, does anyone have access to some systems we could open up for the purpose of this testing?&n= bsp; I may be able to call around and see if we can get one provided for us= if no one else has resources available.

Thanks,
Dan

On Thu, Mar 14, 2013 at 12:04 PM, Bill Ver Steeg= (versteb) <versteb@cisco.com> wrote:
netem is a very good emulation tool, and we often use it to get close = to the right answer. However, I will caution that there is a wide variety o= f packet schedulers in use in the wild. Not all of them the exhibit flat, d= eterministic scheduling that netem defaults to. 

One (of many) example of such a packet scheduling/limiting algorithm w= as described in yesterday's congestion control research group. HFC CPE (cab= le modems) use a leaky bucket algorithm that provides a weighted average to= enforce an SLA, and this can interact with higher level control loops. In other words, if a sender is slightly u= nder the provisioned link rate for a while, it can then can send at slightl= y over the link rate for a while. If you are not careful, a variable bitrat= e sender can infer an incorrect SLA rate based on such scheduler behavior. I do not imply that this is the= definitive case, just that there can be interactions. Flow control algorit= hms that work very well for a given scheduler can have unexpected entanglem= ents with another (chain of) schedulers. 

Fortunately, there are ways to introduce these behaviors in test rigs.=  

So, if we define a reference test environment, we either need to have = a few scheduler variations or recognize that the test rig is only a first-o= rder approximation and live testing on a variety of network topologies is r= equired. 

Short version-  I agree that netem is a very good tool, but you n= eed to be careful how you use it. 

Bvs

--_000_9257B4B462844E73AA1CEED18901424Eciscocom_-- From dan@marketsoup.com Thu Mar 14 11:38:55 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 9644911E8144 for ; Thu, 14 Mar 2013 11:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJgFbJz4jK6t for ; Thu, 14 Mar 2013 11:38:54 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 89DA411E80F2 for ; Thu, 14 Mar 2013 11:38:54 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id j5so2445265iaf.28 for ; Thu, 14 Mar 2013 11:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=1blop42siToJ+SnY1u4cIdijrc6AdLCqCkmpgKVBaZk=; b=GeyOJa0h+zU5WsGTYYe03sztZoxfYERXPPs607esY46LJS++RQlkSnjPQeGCM0+0aI 0vf5yRavP6D3ggmwYBCOyZgIENslbY7t0mc6F9BxGhdzczC5PSqdp5r1ECDH35vFQ4wi WD6ykGufMV8qDk8LZLAJ2RJBnYgy445MBGqLA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=1blop42siToJ+SnY1u4cIdijrc6AdLCqCkmpgKVBaZk=; b=QvEuXkfkuLG7RyhpTt0rw8hKBQtOIRb6PSTvdgStsAkMTEXk2y7k3kscc8bwqwWkGJ H12AhaHb9UQcqeCh11l5gKsXSwpA5hIO3Fanh19sxpR7+ReLAQgP//+hFGIISFjpovU+ 4InnDljVTw4aHOgwqXjaQNlG8LENNy+ofupUfL0bTu9TU1SUgrle757HpSyb7RBgnWRY duoPbiZ9KOw7cTU+VyWRzXExX4+eUcoB0tEZ8g+6IXuJK3Xhh52tF/CgFqLwtMci8kac oeZyWhDxEeYOMajQtYV3VPf2c0P7ZnMUXvDT1Qo0JzpM/8BC49X9wdI1P/sU5TyyqsdM LRrQ== MIME-Version: 1.0 X-Received: by 10.50.216.231 with SMTP id ot7mr3275139igc.84.1363286334120; Thu, 14 Mar 2013 11:38:54 -0700 (PDT) Received: by 10.42.55.209 with HTTP; Thu, 14 Mar 2013 11:38:53 -0700 (PDT) X-Originating-IP: [174.51.153.161] In-Reply-To: <9257B4B4-6284-4E73-AA1C-EED18901424E@cisco.com> References: <9257B4B4-6284-4E73-AA1C-EED18901424E@cisco.com> Date: Thu, 14 Mar 2013 12:38:53 -0600 Message-ID: From: Dan Weber To: "Bill Ver Steeg (versteb)" Content-Type: multipart/alternative; boundary=14dae93406cdac446c04d7e6d5ec X-Gm-Message-State: ALoCoQkDKSoQ6ASV+ZWSBBjZjrxAmvWDDvRru9F8yFAIj1JxhF1Tz862VBuY8eUW+qOt4zrBaJhm Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 18:38:55 -0000 --14dae93406cdac446c04d7e6d5ec Content-Type: text/plain; charset=UTF-8 Hey Bill, I'm not familiar with ns2, but I am in favor of having a complete test rig that everyone can download. Does it work with existing applications? Thanks, Dan On Thu, Mar 14, 2013 at 12:30 PM, Bill Ver Steeg (versteb) < versteb@cisco.com> wrote: > In an ns2 environment, having a physical test rig is mute. Quite a bit > of progress can be made in this domain. A simple tar file of the complete > ns2 test rig would make for results that can be verified, tweaked and > retested. > > Once we move to a real device, it seems that Linux sources and sinks > with netem-like impairments would work. I used to have a pretty good test > rig, but I loaned it to GaTech last year....... > > I do think that a well defined test rig would help in this effort, and > also in the broader congestion work underway at IETF. Getting gear is > easier than staff to run it. If I can get a coop student this summer, maybe > I can cobble some gear together and stand up a test rig somewhere that is > publicly accessible. > > > Bvs > > On Mar 14, 2013, at 2:15 PM, "Dan Weber" wrote: > > Hi Bill, > > I understand your concerns about netem. It's no panacea. > > I'm shooting to define a table of configurable parameters to go with each > test case. > > E.g. > Ploss 1% Correlation (90%) > Delay 80ms Jitter 50ms > Bandwidth 2mbit/s > etc. > > It seems to me that this is required regardless of the tools we use. If > we can standardize on which parameters are adjustable, we can include them > in every test case and use a variety of tools. As for defining a reference > test environment, does anyone have access to some systems we could open up > for the purpose of this testing? I may be able to call around and see if > we can get one provided for us if no one else has resources available. > > Thanks, > Dan > > On Thu, Mar 14, 2013 at 12:04 PM, Bill Ver Steeg (versteb) < > versteb@cisco.com> wrote: > >> netem is a very good emulation tool, and we often use it to get close >> to the right answer. However, I will caution that there is a wide variety >> of packet schedulers in use in the wild. Not all of them the exhibit flat, >> deterministic scheduling that netem defaults to. >> >> One (of many) example of such a packet scheduling/limiting algorithm >> was described in yesterday's congestion control research group. HFC CPE >> (cable modems) use a leaky bucket algorithm that provides a weighted >> average to enforce an SLA, and this can interact with higher level control >> loops. In other words, if a sender is slightly under the provisioned link >> rate for a while, it can then can send at slightly over the link rate for a >> while. If you are not careful, a variable bitrate sender can infer an >> incorrect SLA rate based on such scheduler behavior. I do not imply that >> this is the definitive case, just that there can be interactions. Flow >> control algorithms that work very well for a given scheduler can have >> unexpected entanglements with another (chain of) schedulers. >> >> Fortunately, there are ways to introduce these behaviors in test rigs. >> >> So, if we define a reference test environment, we either need to have a >> few scheduler variations or recognize that the test rig is only a >> first-order approximation and live testing on a variety of network >> topologies is required. >> >> Short version- I agree that netem is a very good tool, but you need to >> be careful how you use it. >> >> Bvs >> >> --14dae93406cdac446c04d7e6d5ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Bill,

I'm not familiar with ns2, but I am in favor of having= a complete test rig that everyone can download.

Does it work with e= xisting applications?

Thanks,
Dan



On Thu, Mar 14, 2013 at 12:30 PM, Bill Ver Steeg (versteb) <versteb@cisco.= com> wrote:
In an ns2 environment, having a physical test rig is mute. Quite a bit= of progress can be made in this domain. A simple tar file of the complete = ns2 test rig would make for results that can be verified, tweaked and retes= ted.=C2=A0

Once we move to a real device, it seems that Linux sources and sinks w= ith netem-like impairments would work. I used to have a pretty good test ri= g, but I loaned it to GaTech last year.......=C2=A0

I do think that a well defined test rig would help in this effort, and= also in the broader congestion work underway at IETF. Getting gear is easi= er than staff to run it. If I can get a coop student this summer, maybe I c= an cobble some gear together and stand up a test rig somewhere that is publicly accessible.=C2=A0


Bvs=C2=A0

On Mar 14, 2013, at 2:15 PM, "Dan Weber" <dan@marketsoup.com> wrote:

Hi Bill,

I understand your concerns about netem.=C2=A0 It's no panacea.

I'm shooting to define a table of configurable parameters to go with ea= ch test case.

E.g.
Ploss 1% Correlation (90%)
Delay 80ms Jitter 50ms
Bandwidth 2mbit/s
etc.

It seems to me that this is required regardless of the tools we use.=C2=A0 = If we can standardize on which parameters are adjustable, we can include th= em in every test case and use a variety of tools.=C2=A0 As for defining a r= eference test environment, does anyone have access to some systems we could open up for the purpose of this testing?= =C2=A0 I may be able to call around and see if we can get one provided for = us if no one else has resources available.

Thanks,
Dan

On Thu, Mar 14, 2013 at 12:04 PM, Bill Ver Steeg= (versteb) <versteb@cisco.com> wrote:
netem is a very good emulation tool, and we often use it to get close = to the right answer. However, I will caution that there is a wide variety o= f packet schedulers in use in the wild. Not all of them the exhibit flat, d= eterministic scheduling that netem defaults to.=C2=A0

One (of many) example of such a packet scheduling/limiting algorithm w= as described in yesterday's congestion control research group. HFC CPE = (cable modems) use a leaky bucket algorithm that provides a weighted averag= e to enforce an SLA, and this can interact with higher level control loops. In other words, if a sender is slightly u= nder the provisioned link rate for a while, it can then can send at slightl= y over the link rate for a while. If you are not careful, a variable bitrat= e sender can infer an incorrect SLA rate based on such scheduler behavior. I do not imply that this is the= definitive case, just that there can be interactions. Flow control algorit= hms that work very well for a given scheduler can have unexpected entanglem= ents with another (chain of) schedulers.=C2=A0

Fortunately, there are ways to introduce these behaviors in test rigs.= =C2=A0

So, if we define a reference test environment, we either need to have = a few scheduler variations or recognize that the test rig is only a first-o= rder approximation and live testing on a variety of network topologies is r= equired.=C2=A0

Short version- =C2=A0I agree that netem is a very good tool, but you n= eed to be careful how you use it.=C2=A0

Bvs


--14dae93406cdac446c04d7e6d5ec-- From dan@marketsoup.com Thu Mar 14 11:43:15 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 4D4EB11E81F4 for ; Thu, 14 Mar 2013 11:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsO-r9kY3jGt for ; Thu, 14 Mar 2013 11:43:14 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFEB11E81AF for ; Thu, 14 Mar 2013 11:43:14 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id c11so3464551ieb.15 for ; Thu, 14 Mar 2013 11:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TyGNvQl9y8sTRnLV7/TLqa0iB72vs2NODJhI5ISS2Xg=; b=dOuMycQqqSz/rHcjnb0RHsgMwA2gFIjJDup4NHU+xm64vxBTRDGYh75nmxCWbq3WCC ZvIEEl+sqigu8R+zPza7TWoYNaZww1DSaIOFEOS8tPnCAFCjDSbVuMiAD6kteNHDaiJ/ uYNSQrQFXRJMlNiwuVGtgxptRqX6A5KMBj1N0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=TyGNvQl9y8sTRnLV7/TLqa0iB72vs2NODJhI5ISS2Xg=; b=m1eAhm6iIDpPwkjiNUhQWzwG1OUaZCS26JoWWn1+LkQtF+fYZBTzBt6TWEoisYnZ0k dRhG8uBLRDwyra5Ek+g9dFXfG5GA0r+ns3Aytxj9nNtOMbQA3goD5NGJFJ6Bg4DpGlLL 8GZaT8CcjEiTbJCNEROvF5aDq4l//f1cKAIFSF1IjjNovZuV+/eSoD08nSDSF96E69V/ oOE0xhICVPpCI2QmwOJqpqMRF3q5LiCiuQcAmhsOp5mfW+mjuu6GenJCngkyA2dtj+EQ gr7WIzlBBrSzvjyc7duE8X+B9z99bIvicHSXGTuBtZGt6IyBvJhzrSqorpBYyQhMl8ta KzAA== MIME-Version: 1.0 X-Received: by 10.50.150.167 with SMTP id uj7mr21993434igb.1.1363286594224; Thu, 14 Mar 2013 11:43:14 -0700 (PDT) Received: by 10.42.55.209 with HTTP; Thu, 14 Mar 2013 11:43:14 -0700 (PDT) X-Originating-IP: [174.51.153.161] In-Reply-To: <6BD4BD5D-9689-4AF4-A970-0AAB9E816977@netapp.com> References: <6BD4BD5D-9689-4AF4-A970-0AAB9E816977@netapp.com> Date: Thu, 14 Mar 2013 12:43:14 -0600 Message-ID: From: Dan Weber To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=f46d04339d402d1a5504d7e6e584 X-Gm-Message-State: ALoCoQlix4I4h+In5HX38UWjgfQYEzb/GOVVNR/HV4ghB+4RJHfqSGofvuYmeWhCI1RtOJ05QFQE Cc: "" Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 18:43:15 -0000 --f46d04339d402d1a5504d7e6e584 Content-Type: text/plain; charset=UTF-8 This paper is excellent. Thanks for sharing. Do you have a copy of the NS2 script we could use for inspiration? Thanks, Dan On Thu, Mar 14, 2013 at 5:34 AM, Eggert, Lars wrote: > Hi, > > On Mar 14, 2013, at 0:20, Dan Weber wrote: > > This may need more work, but it can get us going in the right direction. > > thanks for starting this! Yes, there needs to be more detail. In case > folks haven't see it yet, we tried to specify such scenarios for doing > performance measurements for TCP extensions a few years ago: > http://eggert.org/papers/2008-pfldnet.pdf > > The intent with that paper, and I guess the intent now, would be to nail > down all constants sufficiently and describe the parameterization of each > test sufficiently so that someone could set up a simulation or experiment > based only on the text. (For the TCP scenarios described in the paper, > someone - from NEC? - actually did provide an ns2 script.) > > Lars --f46d04339d402d1a5504d7e6e584 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This paper is excellent.=C2=A0 Thanks for sharing.

Do you have a cop= y of the NS2 script we could use for inspiration?

Thanks,
Dan
=
On Thu, Mar 14, 2013 at 5:34 AM, Eggert, Lar= s <lars@netapp.com> wrote:
Hi,

On Mar 14, 2013, at 0:20, Dan Weber <dan@marketsoup.com> wrote:
> This may need more work, but it can get us going in the right directio= n.

thanks for starting this! Yes, there needs to be more detail. In case= folks haven't see it yet, we tried to specify such scenarios for doing= performance measurements for TCP extensions a few years ago: http://eggert.or= g/papers/2008-pfldnet.pdf

The intent with that paper, and I guess the intent now, would be to nail do= wn all constants sufficiently and describe the parameterization of each tes= t sufficiently so that someone could set up a simulation or experiment base= d only on the text. (For the TCP scenarios described in the paper, someone = - from NEC? - actually did provide an ns2 script.)

Lars

--f46d04339d402d1a5504d7e6e584-- From lars@netapp.com Thu Mar 14 11:46:52 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 E204A11E811B for ; Thu, 14 Mar 2013 11:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 vRtEPGcMKdhz for ; Thu, 14 Mar 2013 11:46:52 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 395AF11E816E for ; Thu, 14 Mar 2013 11:46:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,846,1355126400"; d="scan'208";a="246878581" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 14 Mar 2013 11:46:37 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2EIkb4j001989; Thu, 14 Mar 2013 11:46:37 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 11:46:36 -0700 From: "Eggert, Lars" To: Dan Weber Thread-Topic: [rmcat] Congestion Control Behavior Suggestion Thread Thread-Index: AQHOIGtWgEUKQwH3cECqMQTKMwzdzJilhDaAgAB33QCAAADzAA== Date: Thu, 14 Mar 2013 18:46:36 +0000 Message-ID: <562191AE-0BD7-4BC1-8298-12289D74EE71@netapp.com> References: <6BD4BD5D-9689-4AF4-A970-0AAB9E816977@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <7719D69E6F3898458E8F7D2795EE6701@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 14 Mar 2013 18:46:53 -0000 On Mar 14, 2013, at 14:43, Dan Weber wrote: > This paper is excellent. Thanks for sharing. >=20 > Do you have a copy of the NS2 script we could use for inspiration? http://sourceforge.net/projects/tcpeval/ Lars From gettysjim@gmail.com Thu Mar 14 17:08:37 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 DA13B21F8D1C for ; Thu, 14 Mar 2013 17:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ohySXSLG6UFt for ; Thu, 14 Mar 2013 17:08:36 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id C585121F8D19 for ; Thu, 14 Mar 2013 17:08:36 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id j6so2908273oag.36 for ; Thu, 14 Mar 2013 17:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vj+fLaKF1LLYJvUjBfoVxryt4mYmOTrm8ThSgXF97Hg=; b=bHUzykqW9u8oNSblaEE1xFCGNRRJn1eoQ2DX42VcltWwBx48ephmvcpJUCSSGw1xAC 0nYF1J037DGx3b4gibKG8ccsCAFG8M7jMfLOlAaZDnF7JtDx55/7Tjm8sb//7sdDclVR iMuzyvT4kK4/Ku4S5w8D2Ilg22PULA905oo0CnCaeoXhmbRsclF5OTsgoh24l8JsVYff Q47I3YuYgrvvSNTTwdWDRhXKOR8IvPpmWAfiQTf7RK8Tvt0x+Auo5TClAm7Rr4dUpr4z xkjkswznB6eFvQ5KAQg0kyhCoF7Kk4QyeOqa7PU+3l6fic6dsEMam6NwX8FmKq5CkxZI 9azg== MIME-Version: 1.0 X-Received: by 10.60.3.71 with SMTP id a7mr2137984oea.35.1363306116294; Thu, 14 Mar 2013 17:08:36 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.22.193 with HTTP; Thu, 14 Mar 2013 17:08:36 -0700 (PDT) Received: by 10.76.22.193 with HTTP; Thu, 14 Mar 2013 17:08:36 -0700 (PDT) In-Reply-To: <9257B4B4-6284-4E73-AA1C-EED18901424E@cisco.com> References: <9257B4B4-6284-4E73-AA1C-EED18901424E@cisco.com> Date: Thu, 14 Mar 2013 20:08:36 -0400 X-Google-Sender-Auth: UfGldzUGGguOwhj6uRXk5FhXgZ4 Message-ID: From: Jim Gettys To: "Bill Ver Steeg (versteb)" Content-Type: multipart/alternative; boundary=e89a8f839d51c82edc04d7eb7046 Cc: Dan Weber , "rmcat@ietf.org" Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 15 Mar 2013 00:08:38 -0000 --e89a8f839d51c82edc04d7eb7046 Content-Type: text/plain; charset=ISO-8859-1 And note that netem needs to be run on a separate system. Jim On Mar 14, 2013 2:30 PM, "Bill Ver Steeg (versteb)" wrote: > In an ns2 environment, having a physical test rig is mute. Quite a bit > of progress can be made in this domain. A simple tar file of the complete > ns2 test rig would make for results that can be verified, tweaked and > retested. > > Once we move to a real device, it seems that Linux sources and sinks > with netem-like impairments would work. I used to have a pretty good test > rig, but I loaned it to GaTech last year....... > > I do think that a well defined test rig would help in this effort, and > also in the broader congestion work underway at IETF. Getting gear is > easier than staff to run it. If I can get a coop student this summer, maybe > I can cobble some gear together and stand up a test rig somewhere that is > publicly accessible. > > > Bvs > > On Mar 14, 2013, at 2:15 PM, "Dan Weber" wrote: > > Hi Bill, > > I understand your concerns about netem. It's no panacea. > > I'm shooting to define a table of configurable parameters to go with each > test case. > > E.g. > Ploss 1% Correlation (90%) > Delay 80ms Jitter 50ms > Bandwidth 2mbit/s > etc. > > It seems to me that this is required regardless of the tools we use. If > we can standardize on which parameters are adjustable, we can include them > in every test case and use a variety of tools. As for defining a reference > test environment, does anyone have access to some systems we could open up > for the purpose of this testing? I may be able to call around and see if > we can get one provided for us if no one else has resources available. > > Thanks, > Dan > > On Thu, Mar 14, 2013 at 12:04 PM, Bill Ver Steeg (versteb) < > versteb@cisco.com> wrote: > >> netem is a very good emulation tool, and we often use it to get close >> to the right answer. However, I will caution that there is a wide variety >> of packet schedulers in use in the wild. Not all of them the exhibit flat, >> deterministic scheduling that netem defaults to. >> >> One (of many) example of such a packet scheduling/limiting algorithm >> was described in yesterday's congestion control research group. HFC CPE >> (cable modems) use a leaky bucket algorithm that provides a weighted >> average to enforce an SLA, and this can interact with higher level control >> loops. In other words, if a sender is slightly under the provisioned link >> rate for a while, it can then can send at slightly over the link rate for a >> while. If you are not careful, a variable bitrate sender can infer an >> incorrect SLA rate based on such scheduler behavior. I do not imply that >> this is the definitive case, just that there can be interactions. Flow >> control algorithms that work very well for a given scheduler can have >> unexpected entanglements with another (chain of) schedulers. >> >> Fortunately, there are ways to introduce these behaviors in test rigs. >> >> So, if we define a reference test environment, we either need to have a >> few scheduler variations or recognize that the test rig is only a >> first-order approximation and live testing on a variety of network >> topologies is required. >> >> Short version- I agree that netem is a very good tool, but you need to >> be careful how you use it. >> >> Bvs >> >> --e89a8f839d51c82edc04d7eb7046 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

And note that netem needs to be run on a separate system.

Jim

On Mar 14, 2013 2:30 PM, "Bill Ver Steeg (v= ersteb)" <versteb@cisco.com> wrote:
In an ns2 environment, having a physical test rig is mute. Quite a bit= of progress can be made in this domain. A simple tar file of the complete = ns2 test rig would make for results that can be verified, tweaked and retes= ted.=A0

Once we move to a real device, it seems that Linux sources and sinks w= ith netem-like impairments would work. I used to have a pretty good test ri= g, but I loaned it to GaTech last year.......=A0

I do think that a well defined test rig would help in this effort, and= also in the broader congestion work underway at IETF. Getting gear is easi= er than staff to run it. If I can get a coop student this summer, maybe I c= an cobble some gear together and stand up a test rig somewhere that is publicly accessible.=A0


Bvs=A0
Hi Bill,

I understand your concerns about netem.=A0 It's no panacea.

I'm shooting to define a table of configurable parameters to go with ea= ch test case.

E.g.
Ploss 1% Correlation (90%)
Delay 80ms Jitter 50ms
Bandwidth 2mbit/s
etc.

It seems to me that this is required regardless of the tools we use.=A0 If = we can standardize on which parameters are adjustable, we can include them = in every test case and use a variety of tools.=A0 As for defining a referen= ce test environment, does anyone have access to some systems we could open up for the purpose of this testing?= =A0 I may be able to call around and see if we can get one provided for us = if no one else has resources available.

Thanks,
Dan

On Thu, Mar 14, 2013 at 12:04 PM, Bill Ver Steeg= (versteb) <versteb@cisco.com> wrote:
netem is a very good emulation tool, and we often use it to get close = to the right answer. However, I will caution that there is a wide variety o= f packet schedulers in use in the wild. Not all of them the exhibit flat, d= eterministic scheduling that netem defaults to.=A0

One (of many) example of such a packet scheduling/limiting algorithm w= as described in yesterday's congestion control research group. HFC CPE = (cable modems) use a leaky bucket algorithm that provides a weighted averag= e to enforce an SLA, and this can interact with higher level control loops. In other words, if a sender is slightly u= nder the provisioned link rate for a while, it can then can send at slightl= y over the link rate for a while. If you are not careful, a variable bitrat= e sender can infer an incorrect SLA rate based on such scheduler behavior. I do not imply that this is the= definitive case, just that there can be interactions. Flow control algorit= hms that work very well for a given scheduler can have unexpected entanglem= ents with another (chain of) schedulers.=A0

Fortunately, there are ways to introduce these behaviors in test rigs.= =A0

So, if we define a reference test environment, we either need to have = a few scheduler variations or recognize that the test rig is only a first-o= rder approximation and live testing on a variety of network topologies is r= equired.=A0

Short version- =A0I agree that netem is a very good tool, but you need= to be careful how you use it.=A0

Bvs

--e89a8f839d51c82edc04d7eb7046-- From fuji246@gmail.com Fri Mar 15 00:14:18 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 7EDE721F8A0B for ; Fri, 15 Mar 2013 00:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPhVBvBVHjGZ for ; Fri, 15 Mar 2013 00:14:17 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1255321F87AA for ; Fri, 15 Mar 2013 00:14:16 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id gf7so2559392lbb.18 for ; Fri, 15 Mar 2013 00:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=SwcBF8lFt5YuaRSWomn9cw8wjjWVox+rFfwahNnvDYs=; b=kOAWlBr7+T7QiVYyBSd2HTPk2tJX9EY4HU65ft/6nE82HE7N9wxEo2CJIKXiMX1X6q gmejA3InzyTioXAw1Qr+wsjMQp/luOnhdxM7Zr99hlLA94BXr+lr9XdEb0JQ+FPpyWHy +KZ/ePMQ8b2fK0T/E403HcdA0koxCCIYnENfzm1Rr8J0MDO+s1+ttMuH1kSLd4175CzZ /KC+cP+MRSuOw12fyz/2JCLuwk1DqzCJXMawDRJSOfRe8yo5owphQH+S2tZUw9ftWDEI Qnu/o+LpCVYM8A7hLpZb8hjzvhkiiYfnbvncGjOKvyK3/AMBYNKHuHefMA7b++Xduet1 fyuA== MIME-Version: 1.0 X-Received: by 10.152.110.6 with SMTP id hw6mr4757734lab.43.1363331655660; Fri, 15 Mar 2013 00:14:15 -0700 (PDT) Received: by 10.114.25.231 with HTTP; Fri, 15 Mar 2013 00:14:15 -0700 (PDT) In-Reply-To: References: <9257B4B4-6284-4E73-AA1C-EED18901424E@cisco.com> Date: Fri, 15 Mar 2013 15:14:15 +0800 Message-ID: From: Fu Jiantao To: "rmcat@ietf.org" Content-Type: multipart/alternative; boundary=bcaec54b48d00bfc8604d7f163cd Subject: Re: [rmcat] Congestion Control Behavior Suggestion Thread 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, 15 Mar 2013 07:14:18 -0000 --bcaec54b48d00bfc8604d7f163cd Content-Type: text/plain; charset=ISO-8859-1 We use tc extensively in our test, I think this may be helpful, see here: http://www.slideshare.net/fuji246/network-emulator --bcaec54b48d00bfc8604d7f163cd Content-Type: text/html; charset=ISO-8859-1
We use tc extensively in our test, I think this may be helpful, see here: http://www.slideshare.net/fuji246/network-emulator
--bcaec54b48d00bfc8604d7f163cd-- From fuji246@gmail.com Fri Mar 15 02:59:27 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559FC21F91E1 for ; Fri, 15 Mar 2013 02:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, 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 iGWSo6bACpPv for ; Fri, 15 Mar 2013 02:59:26 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2506F21F91A0 for ; Fri, 15 Mar 2013 02:59:25 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eb20so3558265lab.3 for ; Fri, 15 Mar 2013 02:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=+oLKjRv/A7TysKHRofeHVP278CXnMz5vtrZGzr+nm90=; b=RLvk05s45FTqn7Mz7P4Wufesfaw2L90Y2H93piWUa6LhpFVuxsBXFDEMEUFKfqcTtI k+ozUknSNQVXI0GjFc/4ECNSyx743zDOEK1F2LdpswJQG4U9FF3l69KPrQRq67eU2i6J 6t6EroSy/JpCk1shzHpINGhKAohY12jjY4IVm+GQJpT54srjJnuZwE6vCnBaVGtubnhI wwcdmt0O0AwjC5kSgvOJDuzTQSULN83c1e1hQHa2EmLgW769qMgmqTEqKtE4S5jwXTrK YLxhhPJTwOhKB/RweagnCeW1jRjP/H44pr1dfF+cA5YTS9eZgs0OnLYdYjx86+Twi0u6 KjCA== MIME-Version: 1.0 X-Received: by 10.152.112.138 with SMTP id iq10mr5083412lab.55.1363341564878; Fri, 15 Mar 2013 02:59:24 -0700 (PDT) Received: by 10.114.25.231 with HTTP; Fri, 15 Mar 2013 02:59:24 -0700 (PDT) In-Reply-To: References: <201303141612.02292.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Fri, 15 Mar 2013 17:59:24 +0800 Message-ID: From: Fu Jiantao To: rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [rmcat] RMCAT Evaluation Ideas 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, 15 Mar 2013 09:59:27 -0000 Testcase can be the following combinations - typical network(bw, rtt, qdelay, loss, token_burst) - with/without cross traffic(CBR, TCP/UDP etc) - avail-bw change(capcity change or cross traffic change) - inherit loss network - route change Jeromy 2013/3/14 Xiaoqing Zhu (xiaoqzhu) : > Hi, > > Great idea on the packet generator model. We will also be happy to contri= bute on this piece as well. > > In the past we have put together some some ns-2 code for via in two appro= aches: > > - trace-driven: where the packet sizes and intervals are taken from h.26= 4 encoding result of video sequences. one could also switch between differe= nt rate versions of the same video content at GOP boundaries. > > - statistical modeling: where the encoder rate control behavior is modele= d statistically, with tunable parameters on burstiness, range of deviation = from target rate, and lag in reaction (i.e., how long it takes the encoder = to react to a change in target rate). > > Thanks, > Xiaoqing > > > > > > On Mar 14, 2013, at 10:12 AM, Mirja Kuehlewind wrote: > >> Hi, >> >> just to name one more option: >> >> we have a Java-based, event-driven simulation framework which we recentl= y >> extended to integrate a virtual machine (using QEMU). That means we can = use >> traffic generated by a real operating system in simulations. Currently w= e >> only have a small relay program running in the virtual machine that can = be >> controlled by the simulation program to send chunks of data. Thus a spec= ific >> generator could be implemented in simulation program. The relay program = sends >> only TCP traffic at the moment. Moreover, we can also run a real applica= tion >> in the virtual machine. At the moment we are still working on the framew= ork. >> Before we will publish the code, we need to find some more bug fixes. Bu= t the >> simulations are working and we are using this for all our current TCP >> simulations. >> >> Mirja >> >> >> On Thursday 14 March 2013 15:07:38 Zaheduzzaman Sarker wrote: >>> 2. Packet Generator Model >>> After re-reading Varun's draft and speaking with him on the evaluation >>> scenarios, I think it makes enough sense to build a packet generator to >>> implement what he suggests. The time involved isn't substantial, and i= t >>> can help us get a unified starting point for testing even if we decide = to >>> change it later. It's worth at least this much. >>> >>> My proposed implementation of this will be able to simulate real video >>> traffic as well as fixed packet generator traffic. For the real video >>> traffic, it can be fed a CSV file filled with frame sizes and RTP >>> timestamps. [Zaheduzzaman Sarker] we already use some sort of packet >>> generator in our simulations, right? And it might be also not that hard= to >>> come up with a packet generator. However, the hard part is to realize h= ow >>> representative those packet generator are for our usecases at hand? IMH= O, >>> we will need to verify the generate packet trace a with some reference >>> trace. Also remember we might have QoE as evaluation metric too and I = hear >>> people are also talking about subjective quality related to fairness. I= t >>> will be hard to achieve that with just simple packet generators. For th= e >>> fixed generator traffic, ladder steps can be used. I'm thinking I'll s= tart >>> a project on Google Code, and make any interested participant a develop= er >>> >>> >>> >>> BR >>> >>> Zahed >> >> >> >> -- >> ------------------------------------------------------------------- >> Dipl.-Ing. Mirja K=FChlewind >> Institute of Communication Networks and Computer Engineering (IKR) >> University of Stuttgart, Germany >> Pfaffenwaldring 47, D-70569 Stuttgart >> >> tel: +49(0)711/685-67973 >> email: mirja.kuehlewind@ikr.uni-stuttgart.de >> web: www.ikr.uni-stuttgart.de >> ------------------------------------------------------------------- > From lars@netapp.com Sat Mar 16 11:07: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 AC72521F85D4 for ; Sat, 16 Mar 2013 11:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.919 X-Spam-Level: X-Spam-Status: No, score=-9.919 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 fi5G2blHaA8g for ; Sat, 16 Mar 2013 11:07:58 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2D97821F8528 for ; Sat, 16 Mar 2013 11:07:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,857,1355126400"; d="scan'208";a="31348523" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 16 Mar 2013 11:07:48 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2GI7lIQ014892 for ; Sat, 16 Mar 2013 11:07:48 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Sat, 16 Mar 2013 11:07:47 -0700 From: "Eggert, Lars" To: "" Thread-Topic: RMCAT raw minutes Thread-Index: AQHOInEqUwteIUoNxEiHtk0Yrd3s5Q== Date: Sat, 16 Mar 2013 18:07:47 +0000 Message-ID: <9E252A6C-1BB9-46E6-A8D7-374ED2FFFE5E@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: text/plain; charset="Windows-1252" Content-ID: <69A474BD646BF74DBB9DB7B062809FE1@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rmcat] RMCAT raw 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: Sat, 16 Mar 2013 18:07:59 -0000 Hi, below are the raw notes from our minute taker (thanks, Michael!) If you spoke on the mike, please make sure your points were sufficiently we= ll captured and send corrections/additions by mail. Lars RTP Media Congestion Avoidance Techniques (RMCAT) at IETF 86, Orlando Monday March 11 2013, 9:00 Presentation: Lars Eggert (LE), Administrativa & WG Status Harald Alvestrand (HA): You said "add a year to milestones". I would hope t= hat we could get adoption done within the first year. LE: Yes, this was meant for finishing the documents, not adopting them. Presentation: Randell Jesup (RJ), Congestion Control Requirements For RMCAT draft-jesup-rmcat-reqs-01 (milestone cc-requirements)=20 Michael Ramalho (MR): I would challenge us to come up with a metric of fair= ness in terms of self-fairness and types of traffic that they're competing = against, and have it independent of whether you're in the core or access ne= twork. HA: I think we know how to detect blatant unfairness. We should say "here's= the tests. if something fails one of these tests, it's not fair". I'm happ= y with a definition of fairness that says "we can't tell whether you're fai= r or not, but we can tell whether you passed these tests or not" RJ: Agreed. Still comes down to a subjective evaluation, to check if on the= whole . LE: This list could get very long. It would be nice if we could find some p= rinciples up front. e.g., "you shouldn't start a new flow persistently". Th= en define cases for checking against those. The people who have solution ca= ndidates must have thought about this, so these people should make proposal= s. If we don't solve it now in the meeting we should see if we can make som= e progress later in ths meeting. Toerless Eckert (TE): Let's agree on a priority list. It seems to be clear = that total blatant unfairness is on the top of the list. Second, how self-f= riendly or unfriendly is existing real-time traffic already, just as a comp= arison metric. I would love to see what we can achieve not only over an Int= ernet path with other traffic, but also if there was no other traffic (self= -fairness). LE: It's not only us competing against TCP. rtcweb has a data channel. Matt Mathis: TCP fairness is a very deep rathole, guaranteed not to converg= e. I would suggest making a list of fairness criteria, evaluate based on si= mple principles. Preventing starvation, for instance, would be very importa= nt, and that is something you could define rigorously. LE: We should start a design team on this. Faisan Hasan (FH): Shall we go down to "friendliness" instead of fairness? Dan Weber (DW): MOS scores as in audio quality or something like that might= be good enough. RJ: Problematic to evaluate. LE: It's a bit harder, if you produce poor audio quality that's only your o= wn problem, but a bad congestion controller harms everyone. Colin Perkins (CP): "Compete reasonably with" - TCP. But we could decide in= itially that that's not a goal and only compete fairly with ourselves. RJ: When competing with TCP, at some point you have to transition to loss b= ased mode. So therefore it=20 CP: Decision, what do we want to give up? RJ: In the short term, we definitely want to compete with TCP. Longer term,= either give up or transition. ??: One has to judge the importance of fairness over other characteristics.= Reaction time, throughput loss, might be more problematic. Don't want to l= ose throughput because of fairness constraints. LE: At some point we have to make a decision. If you want to actively help = work on this stay here, we will try to form a design team. Presentation: Varun Singh (VS), Evaluating Congestion Control for Interactive Real-time M= edia draft-singh-rmcat-cc-eval-02 (milestone eval-criteria)=20 RJ: Discard rate =3D maximum beyond which we shouldn't resume and =85 if yo= u achieved a low average delay =85 my real question is: is this relative to= shortest delay or is it an absolute value? VS: Absolute value. MR: Should have some user related metric. like =85 find out where the tail= is, wait a reasonable amount of time for a packet to come in. What's a rea= sonable amount of time? VS: Playout delay when you receive packets. MR: small jitter buffer will consider well it's audio or video. Small jitte= r buffer doesn't use a number. Zaheduzzaman Sarker (ZS): get rid of delay metric. 300 ms =85 There will = be some queuing in the bottlenecks. You have to look into this delay figure= and compare with RTT etc =85 CDF of queuing delay: you get an idea of va= lues =85 I think we shouldn't have delay. VS: Discard rate to check if trade-off make sense or not. ZS: But then it shouldn't be a fixed value. DW: You can have buffering somewhere, e.g. on the video card, so how does t= his fit in? VS: The way I use it is that you get a feedback value from the receiver to = calculate. It's only for evaluation case, not for deploying it. ZS: We need a minimum set of guidelines, just those you really care about f= or real-time interactive communication. VS: So is this list sufficient? ZS: We have to discuss. On the mailing list I had 3 more suggestions to thi= s one. MR: when you say video frame rate etc., are you creating something artifici= al or are you using real video sources? VS: That's an open question. Do we use a packet generation or actual video = streams? MR: Suggest to simplify to something we can characterize. DW: Video is highly inconsistent. Using any form of constant bitrate create= s serious issues in terms of evaluation. I-frame can blast 100kbytes / seco= nd. VS: Should we remove this and say each app starts with different values? DW: Pick five, use the same streams for all tests. We need to compress it b= efore we even test this. Then we can focus on network related constraints. VS: But with congestion control you change the rates on the fly. It's not a= fixed stream. Depends on the encoder. RJ: We'll have to add cases to this as we go along. But must have some unde= rstanding of edge cases. Single set of parameters will not help us determin= e those. Another issue, I would suggest to keep the number of variables dow= n to something reasonable. Suggest: encoder can use all bits it has availab= le, starts with a given rate. When congestion control gives feedback, contr= oller changes rate (and sticks with it), with some defined delay based on t= he frame rate. Trying to characterize all the encoder behaviors will make t= oo many problems. I-Frames etc. should be avoided anyway, I would not try t= o model that. Simple packet generator would be better. HA: Not try to use real video streams for the tests we do when we develop t= hings. But we need test scenario that can show that cc. is not ruining the = video experience. Gorry Fairhurst (GF): Maximum end-to-end delay of 300ms stands out, what is= it? Application expectation? Network requirement? Is RMCAT going to break = the circuit beyond 300ms? VS: No it's not a circuit breaker. The packet would not be fed into the dec= oder, would be discarded among arrival. GF: RMCAT might be used for various things=85 let's be clear to separate au= dio / video / transport part of it. ZS: We're talking about the wrong things here now. We should focus on test = scenarios, not values. Evaluation draft should take this approach, to test = if guidelines have been followed, but fixed parameters won't work. MR: I agree, we have to take out some uncertainty. Packet generator that sh= ould follow some rule of the cc. you want to test. TCP tracks bits in fligh= t which is a round trip measure. It worked long, so our algorithm is more l= ikely if it has a measure of capacity, measure of bits in flight. We need t= o have a mechanism that's stable, behaves well=85 let's not worry about vid= eo MOS score yet. Not start with a real video source, but packet generator = fit to test a cc. mechanism. Mo Zanaty (MZ): we're looking at it from different perspectives. Applicatio= n perspective vs. network perspective. Now we're mixing all those, not good= . In the requirements and evaluation, let's have a section for application-= level objective metrics. Need to start putting down, what are the real need= s of video applications - start rate, loss tolerance, =85 then network-cent= ric flow behavior. RJ: Good to separate network parameters, video parameters, application para= meters. What are the parameters of the networks that connect the nodes for = evaluation? Critical for determining the results of the algorithm. e.g. low= -delay network, WiFi network =85 not a single set of points, a multi-dimens= ional surface of results. Magnus Westerlund (MW1): Important to evaluate that algorithms are stable. = Minimum path delay is important. Video is dynamic, this is the challenge he= re. For evaluation, let's get as many bits across as possible is also a pos= sible evaluation for these cases. Slide Evaluation Scenarios 1/3 MR: is this delay the propagation delay or the queuing delay? Queuing delay= is rather important (buffer bloat). Slide Evaluation Scenarios 2/3 ZS: each user will have different capacity. Where is the bottleneck? Capaci= ty changes. MM: single queue assumption or using different classes? VS: single MM: it should be stated for cases where throughput maximizing and delay-bas= ed mechanisms competing are guaranteed to fail. MR: We could design a topology such that we're only competing against ourse= lves and stay in a delay-based mode. But maybe I'm wrong, I thought this gr= oup was about competing against other traffic too. LE: assumption is correct. I think we want to have a set of isolated scenar= ios but also cover running on the Internet with other traffic. MM: Have to ask: when you have to compete, and when you have separate queue= s, and when mode switching works. LE: 20 hands for adopting. 0 hands against. We can call that rough consensu= s. Evaluation criteria draft: 10 hands for adopting. 4 or 5 hands against. So = not clear consensus. Presentation: Michael Welzl (MW2), Coupled congestion control for RTP media draft-welzl-rmcat-coupled-cc-00 (milestone group-cc)=20 *** FROM ANNA LE: Fairness is not priorities (slide 5) MW2: Proportional share MW: How do you handle mix of RTP, SCTP flows etc. Can you handle all these = cases. MW2: Current version can handle 5-tuples, beyond that need shared bottlenec= k detection, false negatives will not be a problem. Integrating rate-based = and window-based is a challenge. Could have multiple FSEs. MW: what we have in rtcweb is priorities=20 LE: assume kernel impl will not change on short time-scale, application cou= ld do more quick adaptation. DW: Would it make sense to broadcast state table on local LAN so everyone c= an see what goes on? MW2: Interesting research topic, but raises too many issues for rmcat. ZS: Do the flows using the FSE run the same cong control algorithm? Could c= over more scenarios than rmcat MW2: in my tests yes, but we could use different ones. LE: Are more working on coupled cong control. No. Presentation: Colin Perkins (CP), On the Use of RTP Control Protocol (RTCP) Feedback for = Unicast Multimedia Congestion Control draft-perkins-rmcat-rtp-cc-feedback (related to milestone rtcp-requirements= )=20 MZ: I always assumed that we would do RSize extension. CP: I was picking pessimistic assumption. MZ: I think it's even doable in the per-packet case. CP: Depends on the bandwidth. But there's maybe not even a point. Hannes Tschofenig (HT): Sending feedback quickly has its origin in cc. for = traffic that is very quickly adaptable. In this case, there are reasons why= you can't change it so fast anyway. And you may not want to do it anyway b= ecause of the user experience. CP: Agreed. But you do need enough feedback so you can tell when problems a= re happening, to look at change in queuing delay for example. Frame feedbac= k seems like a reasonable compromise, with also sending feedback faster whe= n problems are developing. HT: Agreed. I think RTCP is in fact a suitable mechanism for cc. feedback. MR: Draft is very well written, thank you. Per-frame or per-packet feedback= is a sampling problem. Ideally you do every single packet because backchan= nel is unreliable. Feedback has to be often enough for the control system t= o work. The fact that video encoders are limited in how fast they can chang= e the rate is somehow irrelevant for the question of convergence, stability= etc. of the controller. CP: Agreed, this is a balancing act. We need to figure out what is appropri= ate. If something roughly in the order of an RTT is enough I think we can d= o that with RTCP very well. MR: My point is that it's a control theory problem wrt. what types of feedb= ack we want in the system. RJ: Agreed. But these are just worst case scenarios, best case scenarios ar= e much better. You may need to change rates dramatically in certain situati= ons, to recover appropriately and deal with bursty situations. TE: Is there anything video specific here? Can we ignore that it's video? P= eople talk about VBR audio codecs that can change arbitrarily. Is the feedb= ack for a video codec not totally decorrelated from congestion feedback? CP: With audio, you may quickly run into situations where you send as much = RTCP feedback as data. RJ: RTCP-fair feedback will work doesn't mean that an algorithm should use = RTCP feedback. This feedback is important and needed for certain cases. Pig= gybacking may be a useful technique in conjunction with RTCP. CP: Point is, RTCP is a valid player in the space, potentially the right so= rt of feedback. MZ: Agree. Even if RTCP feedback could do it, from an efficiency point of v= iew the packet rate often matters more than the total bandwidth consumption= , especially in wireless networks. Especially piggybacking could help. CP: Not sending any RTCP packets that you wouldn't send anyway. MR: Feedback could be very low in terms of bandwidth, but it needs to come = often enough, but perhaps not more often than necessary. I see it as a samp= ling problem. Kevin Gross (KG): How often do you sample, how often do you get that data? = You can cause control system instability by having too much latency in feed= back. CP: People developing CC. algorithms must answer that for their algorithm. = I'm trying to show that for reasonable amounts of feedback, RTCP can work. = Don't discard it because of the assumption it's too slow. ZS: Do we know what the minimum desired amount of feedback is? It depends o= n how we design our controller, that is not answered anywhere yet. MR: TCP does it via clocking. You have to take the RTT into consideration. = I want to make that point really clear, in order to get the control loop ri= ght, you have to think about that. LE: What is the intended goal of the draft? CP: Create awareness, raise discussion. I consider this as success. Not pro= posing to progress it any further. LE: I could see the material in an appendix of a mechanism, to explain desi= gn choices that were made. Presentation: Rong Pan (RP), NADA: A Unified Congestion Control Scheme for Real-Time Medi= a draft-zhu-rmcat-nada=20 ZS: PCN based signaling is something new that you want to design, it's not = there, right? LE: PCN standards are out. ZS: Yes, but not used yet. We're going with things for the current Internet= . LE: We do a mechanism for the current Internet, but good if it works better= in the future Internet. ZS: I have similar results, and shown in the CC. workshop. Second thing: yo= u have a rate-shaping buffer at the sender. Does it relate to video frames?= It's per packet, right? RP: Video frames are there, buffer basically smooths into the network. ZS: Packet shaper on the packet level that delays packets may affect the su= bjective quality, e.g. when doing it with I-frame. Importance of packet is = missing. RJ: Queue is a fair number of packets beyond a certain window in your simul= ation. Once you're overloaded, do you end up with delay even when competing= with itself? RP: Depends on where your settle, on how heavily congested things are. RJ: Loss rates on one slide were in the 3-5% range. That's a pretty high lo= ss rate for video. RP: If that's the way the network gives the feedback then that's how it is.= But algorithm could be tuned to be more sensitive to delay. RJ: Latency is a critical parameter. Throughput includes any recovery or FE= C or whatever is needed to make for a high loss rate. Must be factored in. = FEC has delay issues. KR: Have you looked at Codel? RP: We should evaluate that. KR: Codel works without ECN or PCN. RP: But it does drop packets. KR: But the way it drops packets based on delay measurements. Jim Gettys (JG): Codel is happy to do ECN. RP: Have to look at it. If it's ECN that's fine. Algorithm can be adopted h= ere. As a result you'll have less losses. KR: How does it compete with TCP? RP: Good question. Here we look at self-fairness. If TCP is the concern, we= have a similar design where, we can respond with sqrt(p) when competing wi= th loss based. HA: Next time you update the draft, please include a reference for PCN. TE: Agree with ZS, bringing in more codec knowledge might be used to optimi= ze the behavior. ZS: Encoder would have to know that this packet has been delayed or lost. TE: Showed that it is fair =85 test should take into account whether ECN ha= s some benefit over delay variation, especially when there is other traffic= . Do we have clear evidence that we could ask network operators to enable i= t? That's still the open question now. MZ: In Nada, losses are translated into delays, in Dflow, delays are transl= ated into losses, in Google yet different=85 what is the right way to mix t= he signals? LE: Evaluation criteria are more about objective quality measures of the re= sult. Up to the mechanism to decide what's best. MZ: There should be objective criteria on how to mix the signals - e.g. thi= s combination of delay and loss is better than that combination of delay an= d loss. LE: agreed. RJ: If you take in more loss you effectively reduce your bit rate because y= ou have to add FEC. Subjective quality is more important in the end. ZS: Different algorithms handle delay and loss rates in different ways. Let= 's define how many % loss rate are okay. Google's mechanism says 10% is oka= y. LE: It's not so easy. In a shared bottleneck you're not going to be the one= who sees all the losses. From vsingh.ietf@gmail.com Mon Mar 18 08:23: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 DC29921F8D77 for ; Mon, 18 Mar 2013 08:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.245, 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 wzaQoRN+veoj for ; Mon, 18 Mar 2013 08:23:52 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7891E21F8D62 for ; Mon, 18 Mar 2013 08:23:49 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id 16so7104132iea.22 for ; Mon, 18 Mar 2013 08:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=0FOymMeDOYYuN3ZAevZiB/8nzT/URCWfw/flew7HtQU=; b=y4CHpwj3H1cN47vCUiDK/n9EkOzq/39Wghi62D+YbnE3UikFymYwPJhi1PFurM1vMs 95ux9OTPpnpGqIKUcVJptuA9D2/gVR8xa3XCbJ99zZQjarS3HtPdsQjoPd2vcQF7EKto AgdwuD54UeJgXuv+4U8w/vCQmy6htPMvF36kbTpkt90NpIaj10uxAO60dga886ATw3An iOXvX3FI3dCTbQqhZE92imyFWcfAREAW4SEd5tMlrOzWcpvlzqaU81bov7vBxvQ7YovC AISmnogJqeQdNIc1QUzQy1wanoUaN6brUPpWuKA9/e6MC2lndHYtT+jUGd/hpUrfKDJw WzUw== X-Received: by 10.50.217.167 with SMTP id oz7mr6162651igc.26.1363620228966; Mon, 18 Mar 2013 08:23:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.152.7 with HTTP; Mon, 18 Mar 2013 08:23:27 -0700 (PDT) From: Varun Singh Date: Mon, 18 Mar 2013 17:23:27 +0200 Message-ID: To: rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [rmcat] Virtual Design Meetings 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, 18 Mar 2013 15:23:54 -0000 Hi all, To continue making progress on the fairness principles, we will have virtual design meetings every few weeks. At the last design meeting, we discussed possible meeting times (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed like a good fit for most people). However, I am open to expanding the list of available times. Drop me a note and I will add it to the doodle choice list. Here's a doodle poll for the next one: http://www.doodle.com/2uci3a27nw37qwk4 Mo Zanaty and Michael Romalho offered to host this via webex (with recording). Cheers, Varun -- http://www.netlab.tkk.fi/~varun/ From kevin.gross@avanw.com Mon Mar 18 10:04:27 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10C221F8634 for ; Mon, 18 Mar 2013 10:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.444 X-Spam-Level: * X-Spam-Status: No, score=1.444 tagged_above=-999 required=5 tests=[AWL=3.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 PWBb0qvdT44u for ; Mon, 18 Mar 2013 10:04:19 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 51F0221F9051 for ; Mon, 18 Mar 2013 10:03:11 -0700 (PDT) Received: (qmail 22038 invoked by uid 0); 18 Mar 2013 17:02:46 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy7.bluehost.com with SMTP; 18 Mar 2013 17:02:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=UhI8Nz+qDZuivWOAkAxwdt9pdk/L9btItclfQ1a/TlM=; b=BbUiHy8IOAhi15oVKYC5fcZJdU3V+lRuwYzzMXUddblZXBe3g908DLc+5nDZRQ1TrrxDPKuC5ctLMfTcwxEeGFTpo+PX4wGNBPUrXvIpMgA9NBYVJe553ews8SNGS1uA; Received: from [209.85.223.173] (port=51133 helo=mail-ie0-f173.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1UHdSP-0002xe-Vy for rmcat@ietf.org; Mon, 18 Mar 2013 11:02:46 -0600 Received: by mail-ie0-f173.google.com with SMTP id 9so7298085iec.18 for ; Mon, 18 Mar 2013 10:02:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.37.212 with SMTP id a20mr6513464igk.88.1363626165084; Mon, 18 Mar 2013 10:02:45 -0700 (PDT) Received: by 10.50.183.163 with HTTP; Mon, 18 Mar 2013 10:02:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Mar 2013 11:02:44 -0600 Message-ID: From: Kevin Gross To: Varun Singh Content-Type: multipart/alternative; boundary=f46d04446b212d985504d835f537 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.223.173 authed with kevin.gross@avanw.com} Cc: rmcat WG Subject: Re: [rmcat] Virtual Design Meetings 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, 18 Mar 2013 17:04:27 -0000 --f46d04446b212d985504d835f537 Content-Type: text/plain; charset=ISO-8859-1 Is there a plan for digesting what we accomplished in the IETF86 design meetings? Right now we just have raw notes. At a minimum, I would expect revision to one of our existing drafts. I am willing to help but I need to start by reading those drafts :) Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Mon, Mar 18, 2013 at 9:23 AM, Varun Singh wrote: > Hi all, > > To continue making progress on the fairness principles, > we will have virtual design meetings every few weeks. > > At the last design meeting, we discussed possible meeting times > (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed > like a good fit for most people). However, I am open to expanding the > list of available times. Drop me a note and I will add it to the > doodle choice list. > > Here's a doodle poll for the next one: > http://www.doodle.com/2uci3a27nw37qwk4 > > Mo Zanaty and Michael Romalho offered to host this via webex (with > recording). > > Cheers, > Varun > > -- > http://www.netlab.tkk.fi/~varun/ > --f46d04446b212d985504d835f537 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is there a plan for digesting what we accomplished in the IETF86 design mee= tings? Right now we just have raw notes. At a minimum, I would expect revis= ion to one of our existing drafts. I am willing to help but I need to start= by reading those drafts :)

Kevin Gross
Media Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


On Mon, Mar 18, 2013 at 9:23 AM, Varun S= ingh <vsingh.ietf@gmail.com> wrote:
Hi all,

To continue making progress on the fairness principles,
we will have virtual design meetings every few weeks.

At the last design meeting, we discussed possible meeting times
(1hr timeslot: 1100-noon, noon-1300 eastern US time seemed
like a good fit for most people). However, I am open to expanding the
list of available times. Drop me a note and I will add it to the
doodle choice list.

Here's a doodle poll for the next one: http://www.doodle.com/2uci3a27nw37qwk4=

Mo Zanaty and Michael Romalho offered to host this via webex (with recordin= g).

Cheers,
Varun

--
http://www.n= etlab.tkk.fi/~varun/

--f46d04446b212d985504d835f537-- From vsingh.ietf@gmail.com Fri Mar 22 02:48:23 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B574B21F90CC for ; Fri, 22 Mar 2013 02:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.350, 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 sifff2XkP1rM for ; Fri, 22 Mar 2013 02:48:22 -0700 (PDT) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 635C421F8E74 for ; Fri, 22 Mar 2013 02:48:19 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id l29so3379501iag.3 for ; Fri, 22 Mar 2013 02:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=IORBXbtiuo8wqQYqRRu8JVfZQ2iHGObq7oOGgduVmTA=; b=C9YzVQYGWyGE/+Mso70oiUYCIcUyyGW8pDAS6bo7eNmxFvFJ+qYAiZ4kVwko+10QcU G6R0GpvXxtSzTMWZk/MrWnuiVNWmUO25vTVZLUYf1spJ03VVcDQ9KNdjuJ/t9HpS0KGc ZXDq20TwST9WWeYfsidOdNqi44oiv3QPyE+rKkstS2uQvLhbFwJVJ9MiRPeyV5WB/k1E RCsf9tXxSC3IuuxZLCH3QwJ0HBMa/hEt7aodVgfmsEcS7n79OUbptX7/AhwSww0Tvppp j8aSvC8J5QnapKmzwBEB9FVT1pa+zNmTSfuYHmWICV7ICohMWzOutYhCVZ+zAsfzdDuK WQjg== X-Received: by 10.42.64.135 with SMTP id g7mr572657ici.37.1363945698939; Fri, 22 Mar 2013 02:48:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.170.106 with HTTP; Fri, 22 Mar 2013 02:47:58 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Fri, 22 Mar 2013 11:47:58 +0200 Message-ID: To: Kevin Gross Content-Type: text/plain; charset=ISO-8859-1 Cc: rmcat WG Subject: Re: [rmcat] Virtual Design Meetings 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, 22 Mar 2013 09:48:23 -0000 Hi Kevin, I was under the impression there was inclination to have a virtual meeting before Easter? and then every 3 weeks. >From the doodle poll, I am leaning towards timeslots on Wednesday/Thursday. I'll leave the poll open until Saturday and inform the chosen time. -Varun On Mon, Mar 18, 2013 at 7:02 PM, Kevin Gross wrote: > Is there a plan for digesting what we accomplished in the IETF86 design > meetings? Right now we just have raw notes. At a minimum, I would expect > revision to one of our existing drafts. I am willing to help but I need to > start by reading those drafts :) > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com, www.X192.org > > > On Mon, Mar 18, 2013 at 9:23 AM, Varun Singh wrote: >> >> Hi all, >> >> To continue making progress on the fairness principles, >> we will have virtual design meetings every few weeks. >> >> At the last design meeting, we discussed possible meeting times >> (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed >> like a good fit for most people). However, I am open to expanding the >> list of available times. Drop me a note and I will add it to the >> doodle choice list. >> >> Here's a doodle poll for the next one: >> http://www.doodle.com/2uci3a27nw37qwk4 >> >> Mo Zanaty and Michael Romalho offered to host this via webex (with >> recording). >> >> Cheers, >> Varun >> >> -- >> http://www.netlab.tkk.fi/~varun/ > > -- http://www.netlab.tkk.fi/~varun/ From zaheduzzaman.sarker@ericsson.com Fri Mar 22 04:31:05 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 0402F21F90BB for ; Fri, 22 Mar 2013 04:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 S5CP5rBCXpBn for ; Fri, 22 Mar 2013 04:31:02 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2C00D21F89CB for ; Fri, 22 Mar 2013 04:31:02 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-a2-514c40f56fcf Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 42.7B.19728.5F04C415; Fri, 22 Mar 2013 12:31:01 +0100 (CET) Received: from [150.132.141.108] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 22 Mar 2013 12:31:00 +0100 Message-ID: <514C40F4.9030605@ericsson.com> Date: Fri, 22 Mar 2013 12:31:00 +0100 From: Zaheduzzaman Sarker Organization: Ericsson AB User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Varun Singh References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Rverg0+gwe9/Iharb35gs9jb5O/A 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZcyf9JOxoJ+z4vOj64wNjPPZuxg5OSQETCSu 3z4HZYtJXLi3nq2LkYtDSOAko8SmK/cYIZy1jBLXvuxiAqniFdCW2DB3KVgHi4CqxJwfX4Hi HBxsAjYSjxf7gYT5BSQlNjTsZgaxRQWiJPZuuMwM0SoocXLmExaQchEBdYmDN3xAwswCshLX 3+5kA7GFBXQk5jw8xghiCwkESPw9uwIszikQKLHmzH9WiHpbiQtzrrNA2PISzVtnM4OMFBLQ leh6GTeBUWgWkmWzkHTMQtKxgJF5FSN7bmJmTnq50SZGYJAe3PJbdQfjnXMihxilOViUxHnD XS8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBcL82l6OvlFzAlYp6xU5P2lR0/55wuMTKu rpJ/nbAg3bKtWluLLXziht1PZ38y42mv0X7gyRW5M+TSim+mV3hzjpvtndWlcyV67cnQJ1Uh dvFd20I3q330bHh4J0/+K2P8ptLvfVNMH+9R6d5fkrP0QsjyqefSnCbY14QITW39WCbcF7aI PVeJpTgj0VCLuag4EQAh3H+mIAIAAA== Cc: rmcat WG Subject: Re: [rmcat] Virtual Design Meetings 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, 22 Mar 2013 11:31:05 -0000 Hi Varun, Was there any meeting on 15th March on site? Could you also share the updated meeting notes from on site meeting? BR Zahed On 2013-03-18 16:23, Varun Singh wrote: > Hi all, > > To continue making progress on the fairness principles, > we will have virtual design meetings every few weeks. > > At the last design meeting, we discussed possible meeting times > (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed > like a good fit for most people). However, I am open to expanding the > list of available times. Drop me a note and I will add it to the > doodle choice list. > > Here's a doodle poll for the next one: http://www.doodle.com/2uci3a27nw37qwk4 > > Mo Zanaty and Michael Romalho offered to host this via webex (with recording). > > Cheers, > Varun > -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies Laboratoriegränd 11 97128 Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ================================================== From mzanaty@cisco.com Fri Mar 22 11:14:01 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 A8F7D21F8FB0 for ; Fri, 22 Mar 2013 11:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.666 X-Spam-Level: X-Spam-Status: No, score=-9.666 tagged_above=-999 required=5 tests=[AWL=0.933, 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 G3b2T1cfOfAN for ; Fri, 22 Mar 2013 11:14:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE0921F8F2F for ; Fri, 22 Mar 2013 11:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2566; q=dns/txt; s=iport; t=1363976040; x=1365185640; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6yYZlMlPZvnAx2qdrew6eNTvuNc0RIVgSf4BiMCD18U=; b=MN2V9LIE8p1Qq8h+keUe/0HxcQwM7ZI0rlG+9Hyld2MtuImvVyDn3Cx6 CfNdwXhsgrUkjfih7PSa5Hd58jbJikukTD5/bRpwR28Y18sG5vqCFHiSs XRxv3PMxLE9BznnO27B2+gssD824vdGmwkwPbZbLW0kTTBzSrOfHWC5Rp k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFABafTFGtJXG//2dsb2JhbABAAxbFPoFlFnSCJAEBAQQ6DzAMBAIBCA4DBAEBAQoUCQchERQJCAIEAQ0FCId6Aw8MuDQNiVuMSIIZIQ8BBwYLgk5hA5UEjUkDhRiDCoIo X-IronPort-AV: E=Sophos;i="4.84,893,1355097600"; d="scan'208";a="190491263" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 22 Mar 2013 18:13:59 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2MIDxik022699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 18:13:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 13:13:59 -0500 From: "Mo Zanaty (mzanaty)" To: Varun Singh , Kevin Gross Thread-Topic: [rmcat] Virtual Design Meetings Thread-Index: AQHOJuJp+CLEMXclL0uR0yNA7LTVkpix+1rQ Date: Fri, 22 Mar 2013 18:13:58 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F695EB5@xmb-rcd-x14.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.30.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rmcat WG Subject: Re: [rmcat] Virtual Design Meetings 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, 22 Mar 2013 18:14:01 -0000 Warning: Doodle appears to have a timezone bug. In the timezone selection b= ox, it thinks the US is still on standard/winter time, but we already switc= hed to daylight/summer time. After selecting a timezone, for example EST (G= MT-5), the times it shows as EST (GMT-5) are incorrect and are actually EDT= (GMT-4). I assume the meeting timeslots are GMT 15:00-16:00 and 16:00-17:00. That wo= uld be EDT (GMT-4) 11:00-12:00 and 12:00-13:00. But Doodle shows EST (GMT-5= ) 11:00-1200 and 12:00-13:00. So if you believed its timezone label and man= ually added an hour to get daylight/summer time, you get the wrong meeting = times. If you ignore the timezone label and just look at the meeting times,= you get the right times. Mo -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of V= arun Singh Sent: Friday, March 22, 2013 5:48 AM To: Kevin Gross Cc: rmcat WG Subject: Re: [rmcat] Virtual Design Meetings Hi Kevin, I was under the impression there was inclination to have a virtual meeting before Easter? and then every 3 weeks. >From the doodle poll, I am leaning towards timeslots on Wednesday/Thursday. I'll leave the poll open until Saturday and inform the chosen time. -Varun On Mon, Mar 18, 2013 at 7:02 PM, Kevin Gross wrote: > Is there a plan for digesting what we accomplished in the IETF86 design > meetings? Right now we just have raw notes. At a minimum, I would expect > revision to one of our existing drafts. I am willing to help but I need t= o > start by reading those drafts :) > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com, www.X192.org > > > On Mon, Mar 18, 2013 at 9:23 AM, Varun Singh wrot= e: >> >> Hi all, >> >> To continue making progress on the fairness principles, >> we will have virtual design meetings every few weeks. >> >> At the last design meeting, we discussed possible meeting times >> (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed >> like a good fit for most people). However, I am open to expanding the >> list of available times. Drop me a note and I will add it to the >> doodle choice list. >> >> Here's a doodle poll for the next one: >> http://www.doodle.com/2uci3a27nw37qwk4 >> >> Mo Zanaty and Michael Romalho offered to host this via webex (with >> recording). >> >> Cheers, >> Varun >> >> -- >> http://www.netlab.tkk.fi/~varun/ > > --=20 http://www.netlab.tkk.fi/~varun/ From vsingh.ietf@gmail.com Fri Mar 22 11:52:38 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 71B7121F8C71 for ; Fri, 22 Mar 2013 11:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.306, 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 IkxvLL0Ow9ig for ; Fri, 22 Mar 2013 11:52:37 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BD4AB21F859D for ; Fri, 22 Mar 2013 11:52:37 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id c12so5167739ieb.20 for ; Fri, 22 Mar 2013 11:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=VxhuI2dBwjE8xri9UXZ3A2vvZ5wsm+Jkki50Qx+bD/g=; b=KlIY2gO/MUg4FjaOlIahN8DgbIDmVHF6X2UsGN1NHXQWLkRIIyognLOZaN8SsHQQ5e XwS1eFlkMeE8WPQNfEvbRaMfaGQDAFtp421podThHa2oaKCy3h9zZdFSAIvt4HSKSecS MRPE7jDc5A+VS0web+b/CWol9hVC4DqIv8oBD+M0H1GTibb61Y6EeAwNLYVP5qHsQnhF wWa/tBu0HGrsUzkv3We04iQU7LvLOQGRDs4+A7JZ+3teQkPj/6S6U2646NYuzFT5jsk5 DSO9TOzEKOtCfJB8oy5wcaelq8vxi2NKi7QT50hSTEU3LejxHN4dL3HA2ZZSEVGgyQad uhlg== X-Received: by 10.43.8.200 with SMTP id ot8mr1672652icb.11.1363978357402; Fri, 22 Mar 2013 11:52:37 -0700 (PDT) References: <3879D71E758A7E4AA99A35DD8D41D3D90F695EB5@xmb-rcd-x14.cisco.com> From: Varun Singh Mime-Version: 1.0 (1.0) In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F695EB5@xmb-rcd-x14.cisco.com> Date: Fri, 22 Mar 2013 20:52:23 +0200 Message-ID: <-7903924745427374961@unknownmsgid> To: "Mo Zanaty (mzanaty)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG , Kevin Gross Subject: Re: [rmcat] Virtual Design Meetings 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, 22 Mar 2013 18:52:38 -0000 Maybe there are more timezone bugs because I didn't take into account Europe moving into DST this coming weekend. Without taking DST into account, the GMT times were correct. Regards, Varun ---- http://www.netlab.tkk.fi/~varun On 22.3.2013, at 20.14, "Mo Zanaty (mzanaty)" wrote: > Warning: Doodle appears to have a timezone bug. In the timezone selection= box, it thinks the US is still on standard/winter time, but we already swi= tched to daylight/summer time. After selecting a timezone, for example EST = (GMT-5), the times it shows as EST (GMT-5) are incorrect and are actually E= DT (GMT-4). > > I assume the meeting timeslots are GMT 15:00-16:00 and 16:00-17:00. That = would be EDT (GMT-4) 11:00-12:00 and 12:00-13:00. But Doodle shows EST (GMT= -5) 11:00-1200 and 12:00-13:00. So if you believed its timezone label and m= anually added an hour to get daylight/summer time, you get the wrong meetin= g times. If you ignore the timezone label and just look at the meeting time= s, you get the right times. > > Mo > > -----Original Message----- > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of= Varun Singh > Sent: Friday, March 22, 2013 5:48 AM > To: Kevin Gross > Cc: rmcat WG > Subject: Re: [rmcat] Virtual Design Meetings > > Hi Kevin, > > I was under the impression there was inclination to have a virtual meetin= g > before Easter? and then every 3 weeks. > > From the doodle poll, I am leaning towards timeslots on Wednesday/Thursda= y. > I'll leave the poll open until Saturday and inform the chosen time. > > -Varun > > On Mon, Mar 18, 2013 at 7:02 PM, Kevin Gross wrot= e: >> Is there a plan for digesting what we accomplished in the IETF86 design >> meetings? Right now we just have raw notes. At a minimum, I would expect >> revision to one of our existing drafts. I am willing to help but I need = to >> start by reading those drafts :) >> >> Kevin Gross >> +1-303-447-0517 >> Media Network Consultant >> AVA Networks - www.AVAnw.com, www.X192.org >> >> >> On Mon, Mar 18, 2013 at 9:23 AM, Varun Singh wro= te: >>> >>> Hi all, >>> >>> To continue making progress on the fairness principles, >>> we will have virtual design meetings every few weeks. >>> >>> At the last design meeting, we discussed possible meeting times >>> (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed >>> like a good fit for most people). However, I am open to expanding the >>> list of available times. Drop me a note and I will add it to the >>> doodle choice list. >>> >>> Here's a doodle poll for the next one: >>> http://www.doodle.com/2uci3a27nw37qwk4 >>> >>> Mo Zanaty and Michael Romalho offered to host this via webex (with >>> recording). >>> >>> Cheers, >>> Varun >>> >>> -- >>> http://www.netlab.tkk.fi/~varun/ >> >> > > > > -- > http://www.netlab.tkk.fi/~varun/ From vsingh.ietf@gmail.com Mon Mar 25 08:55: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 1AB1321E8055 for ; Mon, 25 Mar 2013 08:55:53 -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 1Rk1oMudai4i for ; Mon, 25 Mar 2013 08:55:52 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E893321E8053 for ; Mon, 25 Mar 2013 08:55:48 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id bn7so5101676ieb.37 for ; Mon, 25 Mar 2013 08:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=3gPpquVYjS8vVN9aNyHKFHDADAxlguJQQWOqY3h1uk8=; b=fo9H92Plg9hxPhFnk7E8RVO6h0KMcnyNFK0XGG6XzLI2lIp4XtH5qtOy72fkdKovNP frkq7BEzw3ftTQ+Zh97Wo6zxA9pTD02+Xjhxf8EkJlC3BjW98lViL9Ig8wu/SjpVcfny EWDgkhHbOvl1UNTTQeK6BD8pBVPX6KW9yPvm+7uQYFDyro2eQVb0z81m7OSA26TOxo+K 9nllxcUxML24nJj7QZk/NWyiJzDAk2mxNm7/7G6OfqZlvthdqIIL663px9dYNlMIAKTW WC2X/Y/+0gSfhFPwJVApFL569efc3LcpsE0SM9PawX0GHUVXcusSnd0K8TFtAnWxdXmQ 4vvA== X-Received: by 10.50.191.133 with SMTP id gy5mr12092299igc.50.1364226948438; Mon, 25 Mar 2013 08:55:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.170.106 with HTTP; Mon, 25 Mar 2013 08:55:28 -0700 (PDT) In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F695EB5@xmb-rcd-x14.cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D90F695EB5@xmb-rcd-x14.cisco.com> From: Varun Singh Date: Mon, 25 Mar 2013 17:55:28 +0200 Message-ID: To: "Mo Zanaty (mzanaty)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rmcat WG , Kevin Gross Subject: Re: [rmcat] Virtual Design Meetings 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, 25 Mar 2013 15:55:53 -0000 Hi all, I chose the second of the two sessions on Thursday, it had the best participation. Of the tentatives: I will make it, Mirja what about you? Cheers, Varun On Fri, Mar 22, 2013 at 8:13 PM, Mo Zanaty (mzanaty) wr= ote: > Warning: Doodle appears to have a timezone bug. In the timezone selection= box, it thinks the US is still on standard/winter time, but we already swi= tched to daylight/summer time. After selecting a timezone, for example EST = (GMT-5), the times it shows as EST (GMT-5) are incorrect and are actually E= DT (GMT-4). > > I assume the meeting timeslots are GMT 15:00-16:00 and 16:00-17:00. That = would be EDT (GMT-4) 11:00-12:00 and 12:00-13:00. But Doodle shows EST (GMT= -5) 11:00-1200 and 12:00-13:00. So if you believed its timezone label and m= anually added an hour to get daylight/summer time, you get the wrong meetin= g times. If you ignore the timezone label and just look at the meeting time= s, you get the right times. > > Mo > > -----Original Message----- > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of= Varun Singh > Sent: Friday, March 22, 2013 5:48 AM > To: Kevin Gross > Cc: rmcat WG > Subject: Re: [rmcat] Virtual Design Meetings > > Hi Kevin, > > I was under the impression there was inclination to have a virtual meetin= g > before Easter? and then every 3 weeks. > > From the doodle poll, I am leaning towards timeslots on Wednesday/Thursda= y. > I'll leave the poll open until Saturday and inform the chosen time. > > -Varun > > On Mon, Mar 18, 2013 at 7:02 PM, Kevin Gross wrot= e: >> Is there a plan for digesting what we accomplished in the IETF86 design >> meetings? Right now we just have raw notes. At a minimum, I would expect >> revision to one of our existing drafts. I am willing to help but I need = to >> start by reading those drafts :) >> >> Kevin Gross >> +1-303-447-0517 >> Media Network Consultant >> AVA Networks - www.AVAnw.com, www.X192.org >> >> >> On Mon, Mar 18, 2013 at 9:23 AM, Varun Singh wro= te: >>> >>> Hi all, >>> >>> To continue making progress on the fairness principles, >>> we will have virtual design meetings every few weeks. >>> >>> At the last design meeting, we discussed possible meeting times >>> (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed >>> like a good fit for most people). However, I am open to expanding the >>> list of available times. Drop me a note and I will add it to the >>> doodle choice list. >>> >>> Here's a doodle poll for the next one: >>> http://www.doodle.com/2uci3a27nw37qwk4 >>> >>> Mo Zanaty and Michael Romalho offered to host this via webex (with >>> recording). >>> >>> Cheers, >>> Varun >>> >>> -- >>> http://www.netlab.tkk.fi/~varun/ >> >> > > > > -- > http://www.netlab.tkk.fi/~varun/ --=20 http://www.netlab.tkk.fi/~varun/ From dan@marketsoup.com Mon Mar 25 08:58: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 BA09021F8FFB for ; Mon, 25 Mar 2013 08:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifd6zPxQD0aV for ; Mon, 25 Mar 2013 08:58:20 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD7321E804B for ; Mon, 25 Mar 2013 08:58:20 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id b35so5659151iac.33 for ; Mon, 25 Mar 2013 08:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=1wSxOxMdwAFUVjQo14W89zGDEKdjsJIIre2lTELRBbA=; b=Jg4Q8ToWEQpS6RePhbp0pwoH07rXVdR6xpvyTRUERLm4OUrktsfa0QXMzer6HzaniL 8Y1P8gyJyNOIvYWKmEFaV80JKxd9nY0srIpIBajDFmpxm+bKN9a9GvKwxKIpmd4Hy1ON BC5t9BNzJc9xqPg7P3Dr8fAyFwb69r8vVbiCg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=1wSxOxMdwAFUVjQo14W89zGDEKdjsJIIre2lTELRBbA=; b=Af1DeHJPnW+Jqux75gsgn8yUzjFcbgytOOR0wqnnQU5JDn8r05alsgaFuIB/9Wsb3b eglwK65UJUeZj+RtRLzSn16DJv4LZ4MnIKUIra1073DrvmrJeSjJEDQBVP21VU05ySiv aA0Y5r1AkFqkJZRSvBiiNS2r4M9aoGKgBChiHSzhaf0EggjwJzWl8d4sk2DlNmETGvc5 iz4CwbPiWUv0MWArT0/qSArR6Xfhf/FkO9wGsIw63DFNbEcHWygR2VTX0/w+AY8T+6H1 0AIyKMx0lERTDLWqOeqHX9Zdr25zMuotZH+9xe5xMDmoaqjXcs7mnH8N9ILXqIVlqi/n sCvA== MIME-Version: 1.0 X-Received: by 10.50.57.166 with SMTP id j6mr8393818igq.21.1364227100021; Mon, 25 Mar 2013 08:58:20 -0700 (PDT) Received: by 10.43.7.134 with HTTP; Mon, 25 Mar 2013 08:58:19 -0700 (PDT) X-Originating-IP: [174.51.153.161] In-Reply-To: References: <3879D71E758A7E4AA99A35DD8D41D3D90F695EB5@xmb-rcd-x14.cisco.com> Date: Mon, 25 Mar 2013 09:58:19 -0600 Message-ID: From: Dan Weber To: Varun Singh Content-Type: multipart/alternative; boundary=14dae934036fb0aaea04d8c1dff9 X-Gm-Message-State: ALoCoQmVsMtH06iSFmmgHX06Ox+imWIyIbRD2Xn+2uqTCg66Vblg9TZSdIibeHkwRvkonTx+/StG Cc: rmcat WG , "Mo Zanaty \(mzanaty\)" , Kevin Gross Subject: Re: [rmcat] Virtual Design Meetings 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, 25 Mar 2013 15:58:21 -0000 --14dae934036fb0aaea04d8c1dff9 Content-Type: text/plain; charset=UTF-8 Can you send out a meeting invite for the time that is selected? Thanks, Dan On Mon, Mar 25, 2013 at 9:55 AM, Varun Singh wrote: > Hi all, > > I chose the second of the two sessions on Thursday, > it had the best participation. > Of the tentatives: I will make it, Mirja what about you? > > > Cheers, > Varun > > On Fri, Mar 22, 2013 at 8:13 PM, Mo Zanaty (mzanaty) > wrote: > > Warning: Doodle appears to have a timezone bug. In the timezone > selection box, it thinks the US is still on standard/winter time, but we > already switched to daylight/summer time. After selecting a timezone, for > example EST (GMT-5), the times it shows as EST (GMT-5) are incorrect and > are actually EDT (GMT-4). > > > > I assume the meeting timeslots are GMT 15:00-16:00 and 16:00-17:00. That > would be EDT (GMT-4) 11:00-12:00 and 12:00-13:00. But Doodle shows EST > (GMT-5) 11:00-1200 and 12:00-13:00. So if you believed its timezone label > and manually added an hour to get daylight/summer time, you get the wrong > meeting times. If you ignore the timezone label and just look at the > meeting times, you get the right times. > > > > Mo > > > > -----Original Message----- > > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf > Of Varun Singh > > Sent: Friday, March 22, 2013 5:48 AM > > To: Kevin Gross > > Cc: rmcat WG > > Subject: Re: [rmcat] Virtual Design Meetings > > > > Hi Kevin, > > > > I was under the impression there was inclination to have a virtual > meeting > > before Easter? and then every 3 weeks. > > > > From the doodle poll, I am leaning towards timeslots on > Wednesday/Thursday. > > I'll leave the poll open until Saturday and inform the chosen time. > > > > -Varun > > > > On Mon, Mar 18, 2013 at 7:02 PM, Kevin Gross > wrote: > >> Is there a plan for digesting what we accomplished in the IETF86 design > >> meetings? Right now we just have raw notes. At a minimum, I would expect > >> revision to one of our existing drafts. I am willing to help but I need > to > >> start by reading those drafts :) > >> > >> Kevin Gross > >> +1-303-447-0517 > >> Media Network Consultant > >> AVA Networks - www.AVAnw.com, www.X192.org > >> > >> > >> On Mon, Mar 18, 2013 at 9:23 AM, Varun Singh > wrote: > >>> > >>> Hi all, > >>> > >>> To continue making progress on the fairness principles, > >>> we will have virtual design meetings every few weeks. > >>> > >>> At the last design meeting, we discussed possible meeting times > >>> (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed > >>> like a good fit for most people). However, I am open to expanding the > >>> list of available times. Drop me a note and I will add it to the > >>> doodle choice list. > >>> > >>> Here's a doodle poll for the next one: > >>> http://www.doodle.com/2uci3a27nw37qwk4 > >>> > >>> Mo Zanaty and Michael Romalho offered to host this via webex (with > >>> recording). > >>> > >>> Cheers, > >>> Varun > >>> > >>> -- > >>> http://www.netlab.tkk.fi/~varun/ > >> > >> > > > > > > > > -- > > http://www.netlab.tkk.fi/~varun/ > > > > -- > http://www.netlab.tkk.fi/~varun/ > --14dae934036fb0aaea04d8c1dff9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can you send out a meeting invite for the time that is selected?

Thanks,
Dan

On Mon, Ma= r 25, 2013 at 9:55 AM, Varun Singh <vsingh.ietf@gmail.com> wrote:
Hi all,

I chose the second of the two sessions on Thursday,
it had the best participation.
Of the tentatives: I will make it, Mirja what about you?


Cheers,
Varun

On Fri, Mar 22, 2013 at 8:13 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:
> Warning: Doodle appears to have a timezone bug. In the timezone select= ion box, it thinks the US is still on standard/winter time, but we already = switched to daylight/summer time. After selecting a timezone, for example E= ST (GMT-5), the times it shows as EST (GMT-5) are incorrect and are actuall= y EDT (GMT-4).
>
> I assume the meeting timeslots are GMT 15:00-16:00 and 16:00-17:00. Th= at would be EDT (GMT-4) 11:00-12:00 and 12:00-13:00. But Doodle shows EST (= GMT-5) 11:00-1200 and 12:00-13:00. So if you believed its timezone label an= d manually added an hour to get daylight/summer time, you get the wrong mee= ting times. If you ignore the timezone label and just look at the meeting t= imes, you get the right times.
>
> Mo
>
> -----Original Message-----
> From: rmcat-bounces@ietf.org= [mailto:rmcat-bounces@ietf.o= rg] On Behalf Of Varun Singh
> Sent: Friday, March 22, 2013 5:48 AM
> To: Kevin Gross
> Cc: rmcat WG
> Subject: Re: [rmcat] Virtual Design Meetings
>
> Hi Kevin,
>
> I was under the impression there was inclination to have a virtual mee= ting
> before Easter? and then every 3 weeks.
>
> From the doodle poll, I am leaning towards timeslots on Wednesday/Thur= sday.
> I'll leave the poll open until Saturday and inform the chosen time= .
>
> -Varun
>
> On Mon, Mar 18, 2013 at 7:02 PM, Kevin Gross <kevin.gross@avanw.com> wrote:
>> Is there a plan for digesting what we accomplished in the IETF86 d= esign
>> meetings? Right now we just have raw notes. At a minimum, I would = expect
>> revision to one of our existing drafts. I am willing to help but I= need to
>> start by reading those drafts :)
>>
>> Kevin Gross
>> +1-303-44= 7-0517
>> Media Network Consultant
>> AVA Networks - = www.AVAnw.com, www.X1= 92.org
>>
>>
>> On Mon, Mar 18, 2013 at 9:23 AM, Varun Singh <vsingh.ietf@gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> To continue making progress on the fairness principles,
>>> we will have virtual design meetings every few weeks.
>>>
>>> At the last design meeting, we discussed possible meeting time= s
>>> (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed
>>> like a good fit for most people). However, I am open to expand= ing the
>>> list of available times. Drop me a note and I will add it to t= he
>>> doodle choice list.
>>>
>>> Here's a doodle poll for the next one:
>>> http://www.doodle.com/2uci3a27nw37qwk4
>>>
>>> Mo Zanaty and Michael Romalho offered to host this via webex (= with
>>> recording).
>>>
>>> Cheers,
>>> Varun
>>>
>>> --
>>> http://www.netlab.tkk.fi/~varun/
>>
>>
>
>
>
> --
> http://= www.netlab.tkk.fi/~varun/



--
http://www.n= etlab.tkk.fi/~varun/

--14dae934036fb0aaea04d8c1dff9-- From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Mar 25 10:58:09 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DD021F8EEA for ; Mon, 25 Mar 2013 10:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 2b3UlcnOxSzk for ; Mon, 25 Mar 2013 10:58:08 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 586FD21F8DDD for ; Mon, 25 Mar 2013 10:58:01 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id D16B76026C; Mon, 25 Mar 2013 18:57:59 +0100 (CET) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 965886026B; Mon, 25 Mar 2013 18:57:59 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: rmcat@ietf.org Date: Mon, 25 Mar 2013 18:57:59 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <3879D71E758A7E4AA99A35DD8D41D3D90F695EB5@xmb-rcd-x14.cisco.com> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201303251857.59379.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: Varun Singh Subject: Re: [rmcat] Virtual Design Meetings 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, 25 Mar 2013 17:58:09 -0000 That's GMT 16:00 - 17:00 on Thursday? That would actually be fine for me... Mirja On Monday 25 March 2013 16:55:28 Varun Singh wrote: > Hi all, > > I chose the second of the two sessions on Thursday, > it had the best participation. > Of the tentatives: I will make it, Mirja what about you? > > > Cheers, > Varun > > On Fri, Mar 22, 2013 at 8:13 PM, Mo Zanaty (mzanaty) = =20 wrote: > > Warning: Doodle appears to have a timezone bug. In the timezone selecti= on > > box, it thinks the US is still on standard/winter time, but we already > > switched to daylight/summer time. After selecting a timezone, for examp= le > > EST (GMT-5), the times it shows as EST (GMT-5) are incorrect and are > > actually EDT (GMT-4). > > > > I assume the meeting timeslots are GMT 15:00-16:00 and 16:00-17:00. That > > would be EDT (GMT-4) 11:00-12:00 and 12:00-13:00. But Doodle shows EST > > (GMT-5) 11:00-1200 and 12:00-13:00. So if you believed its timezone lab= el > > and manually added an hour to get daylight/summer time, you get the wro= ng > > meeting times. If you ignore the timezone label and just look at the > > meeting times, you get the right times. > > > > Mo > > > > -----Original Message----- > > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf = Of > > Varun Singh Sent: Friday, March 22, 2013 5:48 AM > > To: Kevin Gross > > Cc: rmcat WG > > Subject: Re: [rmcat] Virtual Design Meetings > > > > Hi Kevin, > > > > I was under the impression there was inclination to have a virtual > > meeting before Easter? and then every 3 weeks. > > > > From the doodle poll, I am leaning towards timeslots on > > Wednesday/Thursday. I'll leave the poll open until Saturday and inform > > the chosen time. > > > > -Varun > > > > On Mon, Mar 18, 2013 at 7:02 PM, Kevin Gross =20 wrote: > >> Is there a plan for digesting what we accomplished in the IETF86 design > >> meetings? Right now we just have raw notes. At a minimum, I would expe= ct > >> revision to one of our existing drafts. I am willing to help but I need > >> to start by reading those drafts :) > >> > >> Kevin Gross > >> +1-303-447-0517 > >> Media Network Consultant > >> AVA Networks - www.AVAnw.com, www.X192.org > >> > >> On Mon, Mar 18, 2013 at 9:23 AM, Varun Singh =20 wrote: > >>> Hi all, > >>> > >>> To continue making progress on the fairness principles, > >>> we will have virtual design meetings every few weeks. > >>> > >>> At the last design meeting, we discussed possible meeting times > >>> (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed > >>> like a good fit for most people). However, I am open to expanding the > >>> list of available times. Drop me a note and I will add it to the > >>> doodle choice list. > >>> > >>> Here's a doodle poll for the next one: > >>> http://www.doodle.com/2uci3a27nw37qwk4 > >>> > >>> Mo Zanaty and Michael Romalho offered to host this via webex (with > >>> recording). > >>> > >>> Cheers, > >>> Varun > >>> > >>> -- > >>> http://www.netlab.tkk.fi/~varun/ > > > > -- > > http://www.netlab.tkk.fi/~varun/ =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From vsingh.ietf@gmail.com Mon Mar 25 10:58:09 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B80121F8DDD for ; Mon, 25 Mar 2013 10:58:09 -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 zNqrmlkE35Zv for ; Mon, 25 Mar 2013 10:58:08 -0700 (PDT) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7B67521F8E66 for ; Mon, 25 Mar 2013 10:58:08 -0700 (PDT) Received: by mail-ia0-f177.google.com with SMTP id w33so2550959iag.8 for ; Mon, 25 Mar 2013 10:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=W7UtcjdrEVuQV+iAtTOszdXRB6wZpDTjKLA/bpAq0nM=; b=V5HuLqxnT+TWnvlieXuDVli0v/Q9jdq1GWBeyUxWEk4GyjtNucAsutDyXTHtoD0iY6 KHAYPgtyn5QQ4ftsJPZu1FJH0d/ar1ybbayVbPMC9Ih9Inw10X+VWTSOlDSg42CH5cD+ sAu18dIQdY4ve3DckpcjjfmizfecPPr1b8Aqobw4Q7yKc0dK8i9Wwj+xeRVL25FSrSV3 BpTxI1MlLVAFjrJlG4Vdy7yqq3+y7eWJt81cPdnEKUDEEXsobK0wgWNZJsy7MTc8WBk/ aLnd4vr3WcCWVwUB+S92Ys+EUthqn2sviWPKBAteqWnrdxPSDe1h4lQ790nD19WI/64Z WaMg== X-Received: by 10.43.8.200 with SMTP id ot8mr7318189icb.11.1364234283289; Mon, 25 Mar 2013 10:58:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.170.106 with HTTP; Mon, 25 Mar 2013 10:57:43 -0700 (PDT) In-Reply-To: References: <3879D71E758A7E4AA99A35DD8D41D3D90F695EB5@xmb-rcd-x14.cisco.com> From: Varun Singh Date: Mon, 25 Mar 2013 19:57:43 +0200 Message-ID: To: Dan Weber , rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Cc: "Mo Zanaty \(mzanaty\)" Subject: Re: [rmcat] Virtual Design Meetings 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, 25 Mar 2013 17:58:09 -0000 Hi Dan, You can export it from doodle: http://www.doodle.com/export/ics?optionIndex=9&locale=en&timeZone=Europe%2FHelsinki&adminKey=&pollId=2uci3a27nw37qwk4&participantKey= Additionally, Mo Zanaty may send and invite and instructions to access the meeting via Webex. Cheers, Varun On Mon, Mar 25, 2013 at 5:58 PM, Dan Weber wrote: > Can you send out a meeting invite for the time that is selected? > > Thanks, > Dan > > > On Mon, Mar 25, 2013 at 9:55 AM, Varun Singh wrote: >> >> Hi all, >> >> I chose the second of the two sessions on Thursday, >> it had the best participation. >> Of the tentatives: I will make it, Mirja what about you? >> >> >> Cheers, >> Varun >> >> On Fri, Mar 22, 2013 at 8:13 PM, Mo Zanaty (mzanaty) >> wrote: >> > Warning: Doodle appears to have a timezone bug. In the timezone >> > selection box, it thinks the US is still on standard/winter time, but we >> > already switched to daylight/summer time. After selecting a timezone, for >> > example EST (GMT-5), the times it shows as EST (GMT-5) are incorrect and are >> > actually EDT (GMT-4). >> > >> > I assume the meeting timeslots are GMT 15:00-16:00 and 16:00-17:00. That >> > would be EDT (GMT-4) 11:00-12:00 and 12:00-13:00. But Doodle shows EST >> > (GMT-5) 11:00-1200 and 12:00-13:00. So if you believed its timezone label >> > and manually added an hour to get daylight/summer time, you get the wrong >> > meeting times. If you ignore the timezone label and just look at the meeting >> > times, you get the right times. >> > >> > Mo >> > >> > -----Original Message----- >> > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf >> > Of Varun Singh >> > Sent: Friday, March 22, 2013 5:48 AM >> > To: Kevin Gross >> > Cc: rmcat WG >> > Subject: Re: [rmcat] Virtual Design Meetings >> > >> > Hi Kevin, >> > >> > I was under the impression there was inclination to have a virtual >> > meeting >> > before Easter? and then every 3 weeks. >> > >> > From the doodle poll, I am leaning towards timeslots on >> > Wednesday/Thursday. >> > I'll leave the poll open until Saturday and inform the chosen time. >> > >> > -Varun >> > >> > On Mon, Mar 18, 2013 at 7:02 PM, Kevin Gross >> > wrote: >> >> Is there a plan for digesting what we accomplished in the IETF86 design >> >> meetings? Right now we just have raw notes. At a minimum, I would >> >> expect >> >> revision to one of our existing drafts. I am willing to help but I need >> >> to >> >> start by reading those drafts :) >> >> >> >> Kevin Gross >> >> +1-303-447-0517 >> >> Media Network Consultant >> >> AVA Networks - www.AVAnw.com, www.X192.org >> >> >> >> >> >> On Mon, Mar 18, 2013 at 9:23 AM, Varun Singh >> >> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> To continue making progress on the fairness principles, >> >>> we will have virtual design meetings every few weeks. >> >>> >> >>> At the last design meeting, we discussed possible meeting times >> >>> (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed >> >>> like a good fit for most people). However, I am open to expanding the >> >>> list of available times. Drop me a note and I will add it to the >> >>> doodle choice list. >> >>> >> >>> Here's a doodle poll for the next one: >> >>> http://www.doodle.com/2uci3a27nw37qwk4 >> >>> >> >>> Mo Zanaty and Michael Romalho offered to host this via webex (with >> >>> recording). >> >>> >> >>> Cheers, >> >>> Varun >> >>> >> >>> -- >> >>> http://www.netlab.tkk.fi/~varun/ >> >> >> >> >> > >> > >> > >> > -- >> > http://www.netlab.tkk.fi/~varun/ >> >> >> >> -- >> http://www.netlab.tkk.fi/~varun/ > > -- http://www.netlab.tkk.fi/~varun/ From mzanaty@cisco.com Tue Mar 26 12:24: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 6BCD821F8D90 for ; Tue, 26 Mar 2013 12:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, 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 lXUr28H9XQ72 for ; Tue, 26 Mar 2013 12:24:45 -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 DE80621F8D8F for ; Tue, 26 Mar 2013 12:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9386; q=dns/txt; s=iport; t=1364325885; x=1365535485; h=from:to:subject:date:message-id:mime-version; bh=sdizBfu+zRxiljHrUXLzg+wDAHdbBJpbDU0S7oqMb2E=; b=UMALShKOVXZwsJ+sG7Ox9VOhtydE+Jb41mkZP/UFnGrSnmC7wCjGchDq DFOgdC7VoqNsrZZrKULM5m8nNUhi1CY9jERbPp3lWnymr8YKryDD9y1qg CB/xHe79/+4HKArBXUymydKLVu8btA2FFsUxo18mY9c07fAM4JbCFJXlX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0nAMn0UVGtJXG//2dsb2JhbAApFwOBbwYBTXeDHr0/DXkWbT2CIQECAiMKOQIjAQwQDgoEDAYCBDAkAgEBAxuIDAwun2eOVYJAgVGOII1SDg10FgoBDBwHghUyYQOIQJ8ugjpRgXM1 X-IronPort-AV: E=Sophos;i="4.84,913,1355097600"; d="scan'208,217";a="191757798" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 26 Mar 2013 19:24:44 +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 r2QJOilv016638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Mar 2013 19:24:44 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 26 Mar 2013 14:24:44 -0500 From: "Mo Zanaty (mzanaty)" To: "rmcat@ietf.org" Thread-Topic: RMCAT Eval Design Team 28 MAR GMT 16:00 Thread-Index: Ac4qVDz3X2s3AgBtQe+YDw3VCnf6LQAAzs/g Date: Tue, 26 Mar 2013 19:24:43 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F697259@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.87] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D90F697259xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: [rmcat] RMCAT Eval Design Team 28 MAR GMT 16:00 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 19:24:46 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D90F697259xmbrcdx14ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable https://cisco.webex.com/ciscosales/j.php?ED=3D221585972&UID=3D484666302&PW= =3DNNmNhZTJjYTI1&RT=3DMiMyMQ%3D%3D Topic: RMCAT Eval Design Team Date: Thursday, March 28, 2013 Time: 4:00 pm, GMT Time (London, GMT) Meeting Number: 203 451 310 Password: rmcat Host Key: 412564 (use this to reclaim host privileges) ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D221585972&UID=3D4846= 66302&PW=3DNNmNhZTJjYTI1&RT=3DMiMyMQ%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: rmcat 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Global call-in numbers: https://cisco.webex.com/ciscosales/globalcallin.php= ?serviceType=3DMC&ED=3D221585972&tollFree=3D1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:203 451 310 CCP:+14085256800x203451310# --_000_3879D71E758A7E4AA99A35DD8D41D3D90F697259xmbrcdx14ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Topic= : RMCAT Eval Design Team
Date: Thursday, March 28, 2013
Time: 4:00 pm, GMT Time (London, GMT)
Meeting Number: 203 451 310
Password: rmcat
Host = Key: 412564 (use this to reclaim host privileges)

-------------------------------------------------------
To join the meeting online(Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D221585972&= ;UID=3D484666302&PW=3DNNmNhZTJjYTI1&RT=3DMiMyMQ%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: rmcat
4. Click "Join".
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen.

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code.
Call-in toll-free number (US/Canada): +1-866-432-9903
Call-in toll number (US/Canada): +1-408-525-6800
Global call-in numbers: https://cisco.webex.com/ciscosales/globalcallin.php?serviceT= ype=3DMC&ED=3D221585972&tollFree=3D1
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfr= ee_restrictions.pdf
Access code:203 451 310
CCP:+14085256800x203451310#
 
 --_000_3879D71E758A7E4AA99A35DD8D41D3D90F697259xmbrcdx14ciscoc_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpFYXN0ZXJu IFN0YW5kYXJkIFRpbWUNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0K VFpPRkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJ TlRFUlZBTD0xO0JZREFZPTFTVTtCWU1PTlRIPTExDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRBWUxJ R0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNF VFRPOi0wNDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPTJTVTtCWU1PTlRI PTMNCkVORDpEQVlMSUdIVA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpPUkdBTklaRVI7 Q049TW8gWmFuYXR5IChtemFuYXR5KTpNQUlMVE86bXphbmF0eUBjaXNjby5jb20NCkFUVEVOREVF O1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049 cm1jYXRAaWV0Zg0KIC5vcmc6TUFJTFRPOnJtY2F0QGlldGYub3JnDQpERVNDUklQVElPTjtMQU5H VUFHRT1lbi1VUzpodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP0VEPTIy MTUNCiA4NTk3MiZVSUQ9NDg0NjY2MzAyJlBXPU5ObU5oWlRKallUSTEmUlQ9TWlNeU1RJTNEJTNE XG5cblRvcGljOiBSTUNBVCBFdmFsIA0KIERlc2lnbiBUZWFtXG5EYXRlOiBUaHVyc2RheVwsIE1h cmNoIDI4XCwgMjAxM1xuVGltZTogNDowMCBwbVwsIEdNVCBUaW1lIChMDQogb25kb25cLCBHTVQp XG5NZWV0aW5nIE51bWJlcjogMjAzIDQ1MSAzMTBcblBhc3N3b3JkOiBybWNhdFxuSG9zdCBLZXk6 IDQxMjUNCiA2NCAodXNlIHRoaXMgdG8gcmVjbGFpbSBob3N0IHByaXZpbGVnZXMpXG5cbi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1cblRv IGpvaW4gdGhlIG1lZXRpbmcgb25saW5lKE5vdyBmcm9tIG1vYmlsZSBkZXZpDQogY2VzISlcbi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1cbjEu IEdvIHRvIGgNCiB0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvai5waHA/RUQ9MjIx NTg1OTcyJlVJRD00ODQ2NjYzMDImUFc9Tk5tTg0KIGhaVEpqWVRJMSZSVD1NaU15TVElM0QlM0Rc bjIuIElmIHJlcXVlc3RlZFwsIGVudGVyIHlvdXIgbmFtZSBhbmQgZW1haWwgYWRkDQogcmVzcy5c bjMuIElmIGEgcGFzc3dvcmQgaXMgcmVxdWlyZWRcLCBlbnRlciB0aGUgbWVldGluZyBwYXNzd29y ZDogcm1jYXRcbjQNCiAuIENsaWNrICJKb2luIi5cbjUuIElmIHRoZSBtZWV0aW5nIGluY2x1ZGVz IGEgdGVsZWNvbmZlcmVuY2VcLCBmb2xsb3cgdGhlIA0KIGluc3RydWN0aW9ucyB0aGF0IGFwcGVh ciBvbiB5b3VyIHNjcmVlbi5cblxuLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLVxuVG8gam9pbiB0aGUgYXVkaW8gY29uZmVyZW5jZSBvbmx5 XG4tLS0tLS0tLS0tLS0NCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tXG5UbyByZWNlaXZlIGEgY2FsbCBiYWNrXCwgcHJvdg0KIGlkZSB5b3VyIHBob25lIG51bWJl ciB3aGVuIHlvdSBqb2luIHRoZSBtZWV0aW5nXCwgb3IgY2FsbCB0aGUgbnVtYmVyIGJlbG93DQog IGFuZCBlbnRlciB0aGUgYWNjZXNzIGNvZGUuXG5DYWxsLWluIHRvbGwtZnJlZSBudW1iZXIgKFVT L0NhbmFkYSk6ICsxLTg2Ni0NCiA0MzItOTkwM1xuQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2Fu YWRhKTogKzEtNDA4LTUyNS02ODAwXG5HbG9iYWwgY2FsbC1pbg0KICBudW1iZXJzOiBodHRwczov L2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2dsb2JhbGNhbGxpbi5waHA/c2VydmljZVR5cGU9 DQogTUMmRUQ9MjIxNTg1OTcyJnRvbGxGcmVlPTFcblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0 aW9uczogaHR0cDovL3d3dy53ZWINCiBleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5w ZGZcbkFjY2VzcyBjb2RlOjIwMyA0NTEgMzEwXG5DQ1A6KzE0MDg1Mg0KIDU2ODAweDIwMzQ1MTMx MCNcblxuXG4NClNVTU1BUlk7TEFOR1VBR0U9ZW4tVVM6Uk1DQVQgRXZhbCBEZXNpZ24gVGVhbSAy OCBNQVIgR01UIDE2OjAwDQpEVFNUQVJUO1RaSUQ9RWFzdGVybiBTdGFuZGFyZCBUaW1lOjIwMTMw MzI4VDEyMDAwMA0KRFRFTkQ7VFpJRD1FYXN0ZXJuIFN0YW5kYXJkIFRpbWU6MjAxMzAzMjhUMTMw MDAwDQpVSUQ6MDQwMDAwMDA4MjAwRTAwMDc0QzVCNzEwMUE4MkUwMDgwMDAwMDAwMDkwMDA3OTBG MzMyQUNFMDEwMDAwMDAwMDAwMDAwMDANCiAwMTAwMDAwMDA5RTQxRkI0RERFNUY1MTREQkQ4OTMx Mjk0M0JCQUE0Rg0KQ0xBU1M6UFVCTElDDQpQUklPUklUWTo1DQpEVFNUQU1QOjIwMTMwMzI2VDE5 MjQwMFoNClRSQU5TUDpPUEFRVUUNClNUQVRVUzpDT05GSVJNRUQNClNFUVVFTkNFOjANCkxPQ0FU SU9OO0xBTkdVQUdFPWVuLVVTOmh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvai5w aHA/RUQ9MjIxNTg1OQ0KIDcyJlVJRD00ODQ2NjYzMDImUFc9Tk5tTmhaVEpqWVRJMSZSVD1NaU15 TVElM0QlM0QNClgtTUlDUk9TT0ZULUNETy1BUFBULVNFUVVFTkNFOjANClgtTUlDUk9TT0ZULUNE Ty1PV05FUkFQUFRJRDotMTAxMzMwMzMzMQ0KWC1NSUNST1NPRlQtQ0RPLUJVU1lTVEFUVVM6VEVO VEFUSVZFDQpYLU1JQ1JPU09GVC1DRE8tSU5URU5ERURTVEFUVVM6QlVTWQ0KWC1NSUNST1NPRlQt Q0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1JQ1JPU09GVC1DRE8tSU1QT1JUQU5DRToxDQpYLU1J Q1JPU09GVC1DRE8tSU5TVFRZUEU6MA0KWC1NSUNST1NPRlQtRElTQUxMT1ctQ09VTlRFUjpGQUxT RQ0KQkVHSU46VkFMQVJNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJUFRJT046UkVNSU5ERVINClRS SUdHRVI7UkVMQVRFRD1TVEFSVDotUFQxNU0NCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpW Q0FMRU5EQVINCg== --_000_3879D71E758A7E4AA99A35DD8D41D3D90F697259xmbrcdx14ciscoc_-- From mzanaty@cisco.com Tue Mar 26 13:41:23 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7179821F8DEF for ; Tue, 26 Mar 2013 13:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxdMXuB840A7 for ; Tue, 26 Mar 2013 13:41:20 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id F136F21F8DC9 for ; Tue, 26 Mar 2013 13:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21409; q=dns/txt; s=iport; t=1364330480; x=1365540080; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Lav5yGbAyxGo3Gg9pioPXIv1B22zaDc4ECLu69801EQ=; b=RltqzmNawCarKyZ7Wzq652/jBado5mVRogZtJybJYz1MYQROMEWLiX1T e+CpjEnlrC+RFA290Cn0WuPiqLeZWWPDFfiwujQLz1ejbQlqx5wRX/UHU FmVBXPJBm7lIwkBI3QmVt6G0b4lJCULGJZqzFC+yJx8fS8ea81r9ESscw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4HAJsGUlGtJXG+/2dsb2JhbAApFwMWgi13wF+BBxaBKoIfAQEBAwEtHDUHBAIBCA4DBAEBCx0HIREUCQgCBAESCId6AwkGDC6wfYYNDYlbiQSDQ4IaASAMAwgGC4JOYQOVB41MA4UYgwuCKA X-IronPort-AV: E=Sophos;i="4.84,913,1355097600"; d="scan'208,217";a="191746092" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 26 Mar 2013 20:41:19 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2QKfIBF008858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Mar 2013 20:41:18 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 26 Mar 2013 15:41:18 -0500 From: "Mo Zanaty (mzanaty)" To: Varun Singh , Dan Weber , "rmcat WG" Thread-Topic: [rmcat] Virtual Design Meetings Thread-Index: AQHOKYI/+CLEMXclL0uR0yNA7LTVkpi4bOxQ Date: Tue, 26 Mar 2013 20:41:17 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F69733C@xmb-rcd-x14.cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D90F695EB5@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.87] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D90F69733Cxmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [rmcat] Virtual Design Meetings X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 20:41:23 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D90F69733Cxmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I sent a calendar invite for this Thursday at GMT 16:00 using this webex: https://cisco.webex.com/ciscosales/j.php?ED=3D221585972&UID=3D484666302&PW= =3DNNmNhZTJjYTI1&RT=3DMiMyMQ%3D%3D The webex is actually recurring every Thursday if we want to reuse the link= for any future meetings (if the timeslot works again for enough folks). It= will be recorded (if everyone agrees), and the link to the recording will = be sent to the list shortly after the meeting. (It will be a different link= than above.) I assume Varun will run the agenda, since it's his draft we're "designing". Mo -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of V= arun Singh Sent: Monday, March 25, 2013 1:58 PM To: Dan Weber; rmcat WG Cc: Mo Zanaty (mzanaty) Subject: Re: [rmcat] Virtual Design Meetings Hi Dan, You can export it from doodle: http://www.doodle.com/export/ics?optionIndex=3D9&locale=3Den&timeZone=3DEur= ope%2FHelsinki&adminKey=3D&pollId=3D2uci3a27nw37qwk4&participantKey=3D Additionally, Mo Zanaty may send and invite and instructions to access the meeting via Webex. Cheers, Varun On Mon, Mar 25, 2013 at 5:58 PM, Dan Weber > wrote: > Can you send out a meeting invite for the time that is selected? > > Thanks, > Dan > > > On Mon, Mar 25, 2013 at 9:55 AM, Varun Singh > wrote: >> >> Hi all, >> >> I chose the second of the two sessions on Thursday, >> it had the best participation. >> Of the tentatives: I will make it, Mirja what about you? >> >> >> Cheers, >> Varun >> >> On Fri, Mar 22, 2013 at 8:13 PM, Mo Zanaty (mzanaty) > >> wrote: >> > Warning: Doodle appears to have a timezone bug. In the timezone >> > selection box, it thinks the US is still on standard/winter time, but = we >> > already switched to daylight/summer time. After selecting a timezone, = for >> > example EST (GMT-5), the times it shows as EST (GMT-5) are incorrect a= nd are >> > actually EDT (GMT-4). >> > >> > I assume the meeting timeslots are GMT 15:00-16:00 and 16:00-17:00. Th= at >> > would be EDT (GMT-4) 11:00-12:00 and 12:00-13:00. But Doodle shows EST >> > (GMT-5) 11:00-1200 and 12:00-13:00. So if you believed its timezone la= bel >> > and manually added an hour to get daylight/summer time, you get the wr= ong >> > meeting times. If you ignore the timezone label and just look at the m= eeting >> > times, you get the right times. >> > >> > Mo >> > >> > -----Original Message----- >> > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf >> > Of Varun Singh >> > Sent: Friday, March 22, 2013 5:48 AM >> > To: Kevin Gross >> > Cc: rmcat WG >> > Subject: Re: [rmcat] Virtual Design Meetings >> > >> > Hi Kevin, >> > >> > I was under the impression there was inclination to have a virtual >> > meeting >> > before Easter? and then every 3 weeks. >> > >> > From the doodle poll, I am leaning towards timeslots on >> > Wednesday/Thursday. >> > I'll leave the poll open until Saturday and inform the chosen time. >> > >> > -Varun >> > >> > On Mon, Mar 18, 2013 at 7:02 PM, Kevin Gross > >> > wrote: >> >> Is there a plan for digesting what we accomplished in the IETF86 desi= gn >> >> meetings? Right now we just have raw notes. At a minimum, I would >> >> expect >> >> revision to one of our existing drafts. I am willing to help but I ne= ed >> >> to >> >> start by reading those drafts :) >> >> >> >> Kevin Gross >> >> +1-303-447-0517 >> >> Media Network Consultant >> >> AVA Networks - www.AVAnw.com, www.X192.org >> >> >> >> >> >> On Mon, Mar 18, 2013 at 9:23 AM, Varun Singh > >> >> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> To continue making progress on the fairness principles, >> >>> we will have virtual design meetings every few weeks. >> >>> >> >>> At the last design meeting, we discussed possible meeting times >> >>> (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed >> >>> like a good fit for most people). However, I am open to expanding th= e >> >>> list of available times. Drop me a note and I will add it to the >> >>> doodle choice list. >> >>> >> >>> Here's a doodle poll for the next one: >> >>> http://www.doodle.com/2uci3a27nw37qwk4 >> >>> >> >>> Mo Zanaty and Michael Romalho offered to host this via webex (with >> >>> recording). >> >>> >> >>> Cheers, >> >>> Varun >> >>> >> >>> -- >> >>> http://www.netlab.tkk.fi/~varun/ >> >> >> >> >> > >> > >> > >> > -- >> > http://www.netlab.tkk.fi/~varun/ >> >> >> >> -- >> http://www.netlab.tkk.fi/~varun/ > > -- http://www.netlab.tkk.fi/~varun/ --_000_3879D71E758A7E4AA99A35DD8D41D3D90F69733Cxmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I sent a calendar invite for this Thursday at GMT= 16:00 using this webex:

https://cisco.webex.com/ciscosales/j.php?ED=3D221585972&UID=3D= 484666302&PW=3DNNmNhZTJjYTI1&RT=3DMiMyMQ%3D%3D

 

The webex is actually recurring every Thursday if= we want to reuse the link for any future meetings (if the timeslot works a= gain for enough folks). It will be recorded (if everyone agrees), and the l= ink to the recording will be sent to the list shortly after the meeting. (It will be a different link than a= bove.)

 

I assume Varun will run the agenda, since it̵= 7;s his draft we’re “designing”.

 

Mo

 

-----Original Message-----
From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of V= arun Singh
Sent: Monday, March 25, 2013 1:58 PM
To: Dan Weber; rmcat WG
Cc: Mo Zanaty (mzanaty)
Subject: Re: [rmcat] Virtual Design Meetings

 

Hi Dan,

 

You can export it from doodle:

http://www.doodle.com/export/ics?optionIndex= =3D9&locale=3Den&timeZone=3DEurope%2FHelsinki&adminKey=3D&p= ollId=3D2uci3a27nw37qwk4&participantKey=3D

 

Additionally, Mo Zanaty may send and invite and i= nstructions to access

the meeting via Webex.

 

Cheers,

Varun

 

On Mon, Mar 25, 2013 at 5:58 PM, Dan Weber <dan@marketsoup.com> wrote:

> Can you send out a meeting invite for the ti= me that is selected?

> 

> Thanks,

> Dan

> 

> 

> On Mon, Mar 25, 2013 at 9:55 AM, Varun Singh= <vsingh.ietf@gmail.com> wrote:

>> 

>> Hi all,

>> 

>> I chose the second of the two sessions o= n Thursday,

>> it had the best participation.

>> Of the tentatives: I will make it, Mirja= what about you?

>> 

>> 

>> Cheers,

>> Varun

>> 

>> On Fri, Mar 22, 2013 at 8:13 PM, Mo Zana= ty (mzanaty) <mzanaty@cisco.com>

>> wrote:

>> > Warning: Doodle appears to have a t= imezone bug. In the timezone

>> > selection box, it thinks the US is = still on standard/winter time, but we

>> > already switched to daylight/summer= time. After selecting a timezone, for

>> > example EST (GMT-5), the times it s= hows as EST (GMT-5) are incorrect and are

>> > actually EDT (GMT-4).

>> >

>> > I assume the meeting timeslots are = GMT 15:00-16:00 and 16:00-17:00. That

>> > would be EDT (GMT-4) 11:00-12:00 an= d 12:00-13:00. But Doodle shows EST

>> > (GMT-5) 11:00-1200 and 12:00-13:00.= So if you believed its timezone label

>> > and manually added an hour to get d= aylight/summer time, you get the wrong

>> > meeting times. If you ignore the ti= mezone label and just look at the meeting

>> > times, you get the right times.

>> >

>> > Mo

>> >

>> > -----Original Message-----

>> > From: rmcat-bounces@ietf.org [mailt= o:rmcat-bounces@ietf.org] On Behalf

>> > Of Varun Singh

>> > Sent: Friday, March 22, 2013 5:48 A= M

>> > To: Kevin Gross

>> > Cc: rmcat WG

>> > Subject: Re: [rmcat] Virtual Design= Meetings

>> >

>> > Hi Kevin,

>> >

>> > I was under the impression there wa= s inclination to have a virtual

>> > meeting

>> > before Easter? and then every 3 wee= ks.

>> >

>> > From the doodle poll, I am leaning = towards timeslots on

>> > Wednesday/Thursday.

>> > I'll leave the poll open until Satu= rday and inform the chosen time.

>> >

>> > -Varun

>> >

>> > On Mon, Mar 18, 2013 at 7:02 PM, Ke= vin Gross <kevin.gross@avanw.com>=

>> > wrote:

>> >> Is there a plan for digesting w= hat we accomplished in the IETF86 design

>> >> meetings? Right now we just hav= e raw notes. At a minimum, I would

>> >> expect

>> >> revision to one of our existing= drafts. I am willing to help but I need

>> >> to

>> >> start by reading those drafts := )

>> >>

>> >> Kevin Gross

>> >> +1-303-447-0517<= /p>

>> >> Media Network Consultant

>> >> AVA Networks - www.= AVAnw.com, www.X192.org

>> >>

>> >>

>> >> On Mon, Mar 18, 2013 at 9:23 AM= , Varun Singh <vsingh.ietf@gmail.com><= o:p>

>> >> wrote:

>> >>>

>> >>> Hi all,

>> >>>

>> >>> To continue making progress= on the fairness principles,

>> >>> we will have virtual design= meetings every few weeks.

>> >>>

>> >>> At the last design meeting,= we discussed possible meeting times

>> >>> (1hr timeslot: 1100-noon, n= oon-1300 eastern US time seemed

>> >>> like a good fit for most pe= ople). However, I am open to expanding the

>> >>> list of available times. Dr= op me a note and I will add it to the

>> >>> doodle choice list.

>> >>>

>> >>> Here's a doodle poll for th= e next one:

>> >>> http://www.doodle.com/2uci3a27nw37qwk4

>> >>>

>> >>> Mo Zanaty and Michael Romal= ho offered to host this via webex (with

>> >>> recording).

>> >>>

>> >>> Cheers,

>> >>> Varun

>> >>>

>> >>> --

>> >>> htt= p://www.netlab.tkk.fi/~varun/

>> >>

>> >>

>> >

>> >

>> >

>> > --

>> > http://www.= netlab.tkk.fi/~varun/

>> 

>> 

>> 

>> --

>> http://www.netla= b.tkk.fi/~varun/

> 

> 

 

 

 

--

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

--_000_3879D71E758A7E4AA99A35DD8D41D3D90F69733Cxmbrcdx14ciscoc_-- From lars@netapp.com Wed Mar 27 03:50:25 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4277721F9061 for ; Wed, 27 Mar 2013 03:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.2 X-Spam-Level: X-Spam-Status: No, score=-10.2 tagged_above=-999 required=5 tests=[AWL=0.399, 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 BVSnkVtk3RGG for ; Wed, 27 Mar 2013 03:50:24 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 4B67921F905B for ; Wed, 27 Mar 2013 03:50:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,917,1355126400"; d="scan'208";a="249103018" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 27 Mar 2013 03:50:24 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2RAoNZd001127; Wed, 27 Mar 2013 03:50:23 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Wed, 27 Mar 2013 03:50:23 -0700 From: "Eggert, Lars" To: Spencer Dawkins Thread-Topic: [rmcat] My notes from today's RMCAT session Thread-Index: AQHOHtjBZzXXPJdWkkOvDuGjSgLYDpi56WaA Date: Wed, 27 Mar 2013 10:50:22 +0000 Message-ID: References: <513EAC88.8080107@wonderhamster.org> In-Reply-To: <513EAC88.8080107@wonderhamster.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5EB5E93345B7AD44A1A9FAA3035AB629@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: RMCAT Mailing List Subject: Re: [rmcat] My notes from today's RMCAT session X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 10:50:25 -0000 Hi, THANK YOU! Note that I've also gotten two more sets of notes. While this is awesome, m= erging them is a pain. In the future, could I ask that any additional minut= e takers sync up with the main stuckee to e.g. collaboratively minute in et= herpad, so we end up with one set of complete notes instead of three sets o= f rough ones? Lars On Mar 12, 2013, at 5:18, Spencer Dawkins wrote= : > Lars asked me to take notes at today's session; I'm sending my notes to t= he list so when I've horribly misunderstood or misquoted you, you can clue = me in ... >=20 > Thanks, >=20 > Spencer >=20 > 2013-03 IETF 86 - RMCAT > Lars is chairing this meeting solo ... > Note Well - thank you, Ericsson for disclosing IPR on a Google draft >=20 > =3D=3D Chair Intro > We're running late on Requirements, we have one draft to choose from > We're running late on Evaluation Criteria and group-cc > We aren't sure we need to do rtcp-requirements and application interactio= ns milestones > We're going to talk with AD about milestones - proposing 1 year slip for = submission to IESG milestones > Nothing happened on the mailing list over winter holidays, picking up a l= ittle speed now >=20 > No agenda bashing >=20 > =3D=3D Requirements - Randall Jesup > Draft was discussed in Atlanta, revised as -01 > Reviewing issues we're discussing and haven't closed on > Definition of "fair" > - we don't have one, and there's not a single definition > - doesn't have to be 1x TCP > - matters more against longer flows > - matters most against other low-delay flows > - can't collapse, can't take too long for a new flow to become usable > - needs to be bounded if we can't define it > - needs to cover both local fairness and aggregate fairness at nodes deep= er in the net >=20 > Other issues > - "minimum bandwidth" can be application-defined. > - need to think about oscillation and possible "mode-switching" between "= fair" and "aggressive" >=20 > Q and A > - anything we can do to bound the problem will help > - we know what UNfairness is. Can we define tests for unfairness? > - can we describe principles for identifying unfairness? > - Lars: this is the biggest issue facing the group, need to make progress= this week > - can we agree on a list of priorities? > - how self-friendly is existing non-real time traffic? > - how self-friendly can we be with no other traffic, dedicated nets? > - need to think about what else we're competing against -RTCWeb data chan= nels > - Matt: one definition is impossible, think about what matters > - Lars: we need to form a design team this week > - is friendliness part of fairness? > - can we come up with a test plan to check for fairness? > - Lars: remember that bad congestion control makes it bad for everyone > - Colin: decide whether competing with TCP is a short-term goal > - Randall: especially competing against short-term TCP flows > - Pat: need to notice the effect of fairness constraints on other charact= eristics > Lars: this may be one of the hard problems in computer science, but we're= going to solve it before Berlin :-) >=20 > =3D=3D Evaluating Congestion Control - Varuna Singh > Now at -02 > - Open issue: two metrics under discussion, other metrics seem ok > - ideally, we do a distribution and then think about what "discard rate" = is > - needs to be more than one number > - we can do things during evaluation we can't do in deployments >=20 > We've identified 8 evaluation guidelines > - do we need a minimum set? > - are the identified guidelines sufficient? Have proposed 3 more > - Lars: if you are proposing a solution you need to look at proposal > - have included a proposal for various evaluation scenario parameters > - also want to limit combinatorial explosion of test scenarios > - do we use media packet generators or real video streams? > - video ends up trying to keep quality consistent, not bit rate > - Randall: have to know where the edges are - not one parameter set > - Harald: need to be able to show we aren't ruining video experience > - Gorry: what happens if your delay exceeds 300ms? Need to separate out t= he transport aspects and focus on them > - we need to start someplace - pick scenarios, parameters > - need to use simple and consistent traffic stream > - would like to see continuity from requirements draft to this draft > - need to characterize requirements for various media types > - need to look at multiple network types - wired, WiFi, cellular ... > - Magnus: video is so changeable - that's why it's important to look at v= arious media sources >=20 > Evaluation Scenarios > - fixed link capacity, variable link capacity, self-awareness > - do all scenarios use the same parameters? > - Matt: assuming single queue or multiple? Need to make that explicit > - Lars: want some scenarios that do it each way >=20 > =3D=3D Working Group Hums > Adopt requirements draft? 20 hands yes, no nos > Adopt evaluation draft? 10 hands yes, 4 nos > What do people want to see in the document to be "yes"? No comments from = the mikes >=20 > =3D=3D Coupled Congestion Control - Michael Wetzl > Controlling groups of flows has been tried in the past > - why didn't these see deployment? > - hard to identify flows, hard to implement >=20 > Flow State Exchange (FSE) > - Flows register with FSE when they start, stop, change rates > - could use various algorithms, but competing flows all use the same one > - not priorities, but proportional share > - Magnus: need to think about RTCWeb control channels, HTTP, etc > - need to figure out shared bottleneck detection, still working on this > - browser could use flow table to self-regulate > - Dale: if everyone builds the same state table, we can understand more > - this would have security implications > - current algorithm has two problems: flow told to use rate that's not wh= at congestion manager determined, highly asynchronous flows > - can this be sender-side only? Can do better management if receiver is i= nvolved >=20 > (Missed question here) >=20 > =3D=3D On the use of RTCP feedback for congestion control - Colin Perkins > Thinking about how existing feedback channel works (with AVPF) > - Per-packet feedback would be great, but RTCP feedback is much less freq= uent, and no mechanism to piggyback information > - per-video frame? 30 fps gives you 0.033 second RTCP control interval > - assuming compound RTCP, but not cross-reporting > - per-RTT? Longer than inter-frame interval > - Hannes: can't adjust sending rates arbitrarily with most codecs, and fr= equent quality changes cause problems with user experience anyway > - conclusion - RTCP suitable for per-frame, per-RTT, not per-packet > - Colin's presentation assumes no RTCP extensions > - remember you can lose feedback packets, too. Just need stable control s= ystem > - don't adjust what we do in RMCAT based on existing codec limitations > - may need to accommodate massive sending rate changes > - can we ignore the fact that this is audio/video? Video streams are like= ly to drive congestion, audio is small and you can end up sending more feed= back than audio > - packet rate in wireless networks more significant than bandwidth, need = piggybacking to reduce that > - what about sampling? Could give you enough feedback > - two issues - how often do you sample, latency for feedback to sender > - do we have any minimum requirements that cover feedback? > - this isn't easy stuff (and wasn't easy with TCP, either) >=20 > Colin wrote the draft to generate discussion, not planning to progress >=20 > =3D=3D NADA - a unified congestion control scheme for real-time media - R= ong Pan > Design goals: limit self-inflicted delay, leverage a suite of network fee= dback mechanisms (loss-based, delay-based, ECN, PCN) > Sender does linear prediction to accommodate feedback latency > Simulation of NADA with ECN shows improvement in avoiding queue build > PCN allows zero standing queue >=20 > Q and A > - PCN? Standards are out but haven't been deployed yet > - Rate-shaping buffer on frame basis? Different frame types - I-frames ca= n span packets, and buffering them can degrade predictive calculations for = receiving codec > - Do you see problems with self-interference after congestion happens? De= pends on traffic and where you stabilize > - 3-5 percent loss rates in your simulations are very bad for video traff= ic > - If we have a high loss rate, we need FEC or other recovery mechanisms t= hat come with overhead > - Have you looked at CoDeL? Not yet ... > - How does this compete with TCP? We're looking at that > - We don't know if ECN has benefits when you're already doing delay-based= mechanisms > - Should evaluation criteria look at both loss and delay? Probably not, w= e're evaluating the results of the algorithms - but we need to look at late= ncy and loss as part of the results > - If you cause other people 5 percent loss, that's worse than causing you= rself 5 percent loss that you can recover from From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Mar 28 06:50: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 AD77021F8AA8 for ; Thu, 28 Mar 2013 06:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, WEIRD_PORT=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 Yp1YnSf-0N1T for ; Thu, 28 Mar 2013 06:50:21 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 029DD21F877A for ; Thu, 28 Mar 2013 06:50:18 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id EAF32602EB; Thu, 28 Mar 2013 14:50:15 +0100 (CET) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id E1897602EA; Thu, 28 Mar 2013 14:50:15 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: rmcat@ietf.org Date: Thu, 28 Mar 2013 14:50:15 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201303281450.15800.mkuehle@ikr.uni-stuttgart.de> Cc: "Eggert, Lars" Subject: [rmcat] minutes IETF86 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, 28 Mar 2013 13:50:21 -0000 Hi, as we received three different minutes (thanks!), I tried to merge them: http://etherpad.tools.ietf.org:9007/p/notes-ietf-86-rmcat?useMonospaceFont=true If you have said something on the mic, please check the minutes and change if there is anything wrong! Mirja From dan@marketsoup.com Thu Mar 28 08:06:18 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 546CB21F8E5D for ; Thu, 28 Mar 2013 08:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.63 X-Spam-Level: X-Spam-Status: No, score=0.63 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, WEIRD_PORT=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 PooWZv4ogOum for ; Thu, 28 Mar 2013 08:06:17 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 792BA21F8BE4 for ; Thu, 28 Mar 2013 08:06:17 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so11462123iea.40 for ; Thu, 28 Mar 2013 08:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=i2ttD0U+LFG7/bi/zVyI+i9O7KA05U75ZvUCYr6/WLs=; b=L/fzZf/pyXhvN23hLl6NC5Pc6auZGF4xfQn+qL6kWPeo2zz5DWFcET3s5doN7yIyPf sf3pvrxscr9OF+QGRCQVI5vsDh12B+9SETAxev3H74hboXEMh40lt7TuUFTVY3wl9yTO md4EEhX3XZscTsiMbDTO7TXMUYjDW0Itr3R4o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=i2ttD0U+LFG7/bi/zVyI+i9O7KA05U75ZvUCYr6/WLs=; b=bZbbtcLTF+7Jws/7jur9xLC0ASFEjdTYmQk483yN+8rOVdUGlwCIf8ri/mPY59FYyf hDI5nnHR6F7rZZUkinIuhoPfBerFOMGA07xCFuA9N0bEg+ssCPfZWvCwPvJWqPaVQ1iV nR5v/a/2Y5xFv1ZL3YhNMC/CjXBxAckSOd98sbn1qfrARLkFn8rCeXfl/D7IxnJeEI82 ni7Q3OhvyOC8tQgQebbxkqDhbou/WMMRc/TPvLVMuVPwIXLgF3aRTlbz9gTu/jYcLHHI 6C8Nsd+fsCm66ZDC2MN3XdAB+ZRAqD9d+LbBF7PbBqgyU3kOi2i2792VsUKk+vjrGqXv rI3g== MIME-Version: 1.0 X-Received: by 10.42.126.133 with SMTP id e5mr6795044ics.17.1364483177029; Thu, 28 Mar 2013 08:06:17 -0700 (PDT) Received: by 10.42.41.2 with HTTP; Thu, 28 Mar 2013 08:06:16 -0700 (PDT) X-Originating-IP: [174.51.153.161] In-Reply-To: <201303281450.15800.mkuehle@ikr.uni-stuttgart.de> References: <201303281450.15800.mkuehle@ikr.uni-stuttgart.de> Date: Thu, 28 Mar 2013 09:06:16 -0600 Message-ID: From: Dan Weber To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=20cf301b643111d69f04d8fd7f5d X-Gm-Message-State: ALoCoQkdaSzSDOaP2VV0vv9LuvJkzMYynqJ/85WCC+PYMI4Y1IHGlhZMW8+Daakdcd6eE6EFQkqJ Cc: rmcat@ietf.org, "Eggert, Lars" Subject: Re: [rmcat] minutes IETF86 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, 28 Mar 2013 15:06:18 -0000 --20cf301b643111d69f04d8fd7f5d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is really good. Thanks for putting this together. Dan On Thu, Mar 28, 2013 at 7:50 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@ikr.uni-stuttgart.de> wrote: > Hi, > > as we received three different minutes (thanks!), I tried to merge them: > > > http://etherpad.tools.ietf.org:9007/p/notes-ietf-86-rmcat?useMonospaceFon= t=3Dtrue > > If you have said something on the mic, please check the minutes and chang= e > if > there is anything wrong! > > Mirja > > --20cf301b643111d69f04d8fd7f5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is really good.

Thanks for putting this together.

Dan

On Thu, Mar 2= 8, 2013 at 7:50 AM, Mirja K=C3=BChlewind <mirja.kuehle= wind@ikr.uni-stuttgart.de> wrote:
Hi,

as we received three different minutes (thanks!), I tried to merge them:
http://etherpad.tools.ietf.org:9007/p/= notes-ietf-86-rmcat?useMonospaceFont=3Dtrue

If you have said something on the mic, please check the minutes and change = if
there is anything wrong!

Mirja


--20cf301b643111d69f04d8fd7f5d-- From vsingh.ietf@gmail.com Thu Mar 28 08:34:27 2013 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C87221F8D46 for ; Thu, 28 Mar 2013 08:34:26 -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 bRQBpRPZ7C4B for ; Thu, 28 Mar 2013 08:34:22 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 83E3D21F8C9A for ; Thu, 28 Mar 2013 08:34:21 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id r13so7233487iar.37 for ; Thu, 28 Mar 2013 08:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=eMyuMBsQyu1C4K/9YFznFh1zPEpeMAlns0v7fGr+S8Q=; b=y06GJMD2cfbzGoEfAIj0O7V0KJI+S6ihEl4K++lVO09gwO1uicecR9bEPyK5CUArZt EK3R6emBTrBWdFvSqKuthnfuXaEjT9FH5cPXJkf6ZB3xJNoT3k683H8iu+VYFW6LlH7S UvRKZWYK910FJLclU8UCiFXZhe5rdkkAYivaquobh2Ih5MpUjHUB8G9hIPFDk/VPKApc kRrmRSZlzrckHxPs+bd26V/a+cdTR0wOkovJ2FTXvYqoERExAf3BBWsWbVuLxvpftk7X AW7Hd26MNYz0gSakPphWWdFrSve6a0EKwPlygimUWVxRVjZ41szjZNvqGAvNT61vqaub XLyQ== X-Received: by 10.50.126.5 with SMTP id mu5mr7355668igb.50.1364484861006; Thu, 28 Mar 2013 08:34:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.73.34 with HTTP; Thu, 28 Mar 2013 08:34:00 -0700 (PDT) In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F69733C@xmb-rcd-x14.cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D90F695EB5@xmb-rcd-x14.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D90F69733C@xmb-rcd-x14.cisco.com> From: Varun Singh Date: Thu, 28 Mar 2013 17:34:00 +0200 Message-ID: To: rmcat WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [rmcat] Virtual Design Meetings 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, 28 Mar 2013 15:34:27 -0000 Hi, Agenda: 5 mins: Recap of meeting Rest: How to proceed with the Fairness criteria At the IETF we discussed - application scenarios for fairness - discussion on fairness - packet logs for flows What is missing: - network scenarios - link characteristics On Tue, Mar 26, 2013 at 10:41 PM, Mo Zanaty (mzanaty) w= rote: > I sent a calendar invite for this Thursday at GMT 16:00 using this webex: > > https://cisco.webex.com/ciscosales/j.php?ED=3D221585972&UID=3D484666302&P= W=3DNNmNhZTJjYTI1&RT=3DMiMyMQ%3D%3D > > > > The webex is actually recurring every Thursday if we want to reuse the li= nk > for any future meetings (if the timeslot works again for enough folks). I= t > will be recorded (if everyone agrees), and the link to the recording will= be > sent to the list shortly after the meeting. (It will be a different link > than above.) > > > > I assume Varun will run the agenda, since it=92s his draft we=92re =93des= igning=94. > > > > Mo > > > > -----Original Message----- > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of > Varun Singh > Sent: Monday, March 25, 2013 1:58 PM > To: Dan Weber; rmcat WG > Cc: Mo Zanaty (mzanaty) > Subject: Re: [rmcat] Virtual Design Meetings > > > > Hi Dan, > > > > You can export it from doodle: > > http://www.doodle.com/export/ics?optionIndex=3D9&locale=3Den&timeZone=3DE= urope%2FHelsinki&adminKey=3D&pollId=3D2uci3a27nw37qwk4&participantKey=3D > > > > Additionally, Mo Zanaty may send and invite and instructions to access > > the meeting via Webex. > > > > Cheers, > > Varun > > > > On Mon, Mar 25, 2013 at 5:58 PM, Dan Weber wrote: > >> Can you send out a meeting invite for the time that is selected? > >> > >> Thanks, > >> Dan > >> > >> > >> On Mon, Mar 25, 2013 at 9:55 AM, Varun Singh >> wrote: > >>> > >>> Hi all, > >>> > >>> I chose the second of the two sessions on Thursday, > >>> it had the best participation. > >>> Of the tentatives: I will make it, Mirja what about you? > >>> > >>> > >>> Cheers, > >>> Varun > >>> > >>> On Fri, Mar 22, 2013 at 8:13 PM, Mo Zanaty (mzanaty) > >>> wrote: > >>> > Warning: Doodle appears to have a timezone bug. In the timezone > >>> > selection box, it thinks the US is still on standard/winter time, but >>> > we > >>> > already switched to daylight/summer time. After selecting a timezone, >>> > for > >>> > example EST (GMT-5), the times it shows as EST (GMT-5) are incorrect >>> > and are > >>> > actually EDT (GMT-4). > >>> > > >>> > I assume the meeting timeslots are GMT 15:00-16:00 and 16:00-17:00. >>> > That > >>> > would be EDT (GMT-4) 11:00-12:00 and 12:00-13:00. But Doodle shows ES= T > >>> > (GMT-5) 11:00-1200 and 12:00-13:00. So if you believed its timezone >>> > label > >>> > and manually added an hour to get daylight/summer time, you get the >>> > wrong > >>> > meeting times. If you ignore the timezone label and just look at the >>> > meeting > >>> > times, you get the right times. > >>> > > >>> > Mo > >>> > > >>> > -----Original Message----- > >>> > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behal= f > >>> > Of Varun Singh > >>> > Sent: Friday, March 22, 2013 5:48 AM > >>> > To: Kevin Gross > >>> > Cc: rmcat WG > >>> > Subject: Re: [rmcat] Virtual Design Meetings > >>> > > >>> > Hi Kevin, > >>> > > >>> > I was under the impression there was inclination to have a virtual > >>> > meeting > >>> > before Easter? and then every 3 weeks. > >>> > > >>> > From the doodle poll, I am leaning towards timeslots on > >>> > Wednesday/Thursday. > >>> > I'll leave the poll open until Saturday and inform the chosen time. > >>> > > >>> > -Varun > >>> > > >>> > On Mon, Mar 18, 2013 at 7:02 PM, Kevin Gross > >>> > wrote: > >>> >> Is there a plan for digesting what we accomplished in the IETF86 >>> >> design > >>> >> meetings? Right now we just have raw notes. At a minimum, I would > >>> >> expect > >>> >> revision to one of our existing drafts. I am willing to help but I >>> >> need > >>> >> to > >>> >> start by reading those drafts :) > >>> >> > >>> >> Kevin Gross > >>> >> +1-303-447-0517 > >>> >> Media Network Consultant > >>> >> AVA Networks - www.AVAnw.com, www.X192.org > >>> >> > >>> >> > >>> >> On Mon, Mar 18, 2013 at 9:23 AM, Varun Singh > >>> >> wrote: > >>> >>> > >>> >>> Hi all, > >>> >>> > >>> >>> To continue making progress on the fairness principles, > >>> >>> we will have virtual design meetings every few weeks. > >>> >>> > >>> >>> At the last design meeting, we discussed possible meeting times > >>> >>> (1hr timeslot: 1100-noon, noon-1300 eastern US time seemed > >>> >>> like a good fit for most people). However, I am open to expanding t= he > >>> >>> list of available times. Drop me a note and I will add it to the > >>> >>> doodle choice list. > >>> >>> > >>> >>> Here's a doodle poll for the next one: > >>> >>> http://www.doodle.com/2uci3a27nw37qwk4 > >>> >>> > >>> >>> Mo Zanaty and Michael Romalho offered to host this via webex (with > >>> >>> recording). > >>> >>> > >>> >>> Cheers, > >>> >>> Varun > >>> >>> > >>> >>> -- > >>> >>> http://www.netlab.tkk.fi/~varun/ > >>> >> > >>> >> > >>> > > >>> > > >>> > > >>> > -- > >>> > http://www.netlab.tkk.fi/~varun/ > >>> > >>> > >>> > >>> -- > >>> http://www.netlab.tkk.fi/~varun/ > >> > >> > > > > > > > > -- > > http://www.netlab.tkk.fi/~varun/ --=20 http://www.netlab.tkk.fi/~varun/ From lars@netapp.com Thu Mar 28 10:04:10 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 7B24121F9080 for ; Thu, 28 Mar 2013 10:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.288 X-Spam-Level: X-Spam-Status: No, score=-10.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 gxjwJ2FRWL-a for ; Thu, 28 Mar 2013 10:04:10 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 07BFC21F907E for ; Thu, 28 Mar 2013 10:04:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,927,1363158000"; d="scan'208";a="249395610" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 28 Mar 2013 10:04:09 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2SH47kh026189 for ; Thu, 28 Mar 2013 10:04:09 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0342.003; Thu, 28 Mar 2013 09:56:16 -0700 From: "Eggert, Lars" To: RMCAT Mailing List Thread-Topic: WG wiki Thread-Index: AQHOK9UpSYcM+VWUk0K+ZR96+PXSCQ== Date: Thu, 28 Mar 2013 16:56:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <03D0A5FC58ECD14EB989DE4274F687D7@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rmcat] WG wiki 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, 28 Mar 2013 17:04:10 -0000 Hi, since this just came up on the design team call: the WG wiki is at http://t= rac.tools.ietf.org/wg/rmcat/trac/wiki You can get a tools.ietf.org password here: https://tools.ietf.org/newlogin Lars= From dan@marketsoup.com Fri Mar 29 13:33: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 7B4D821F8E7B for ; Fri, 29 Mar 2013 13:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY1hhXIkTLvO for ; Fri, 29 Mar 2013 13:33:19 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 51E1921F84B7 for ; Fri, 29 Mar 2013 13:33:16 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id tp5so908505ieb.36 for ; Fri, 29 Mar 2013 13:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type; bh=qhYix4LLyNwvBVLejr92VS4cWgZE0Q+bZQwVwm78evw=; b=M+8yoxYL6Rgc4R2Md9Cn4zfiAufrGTX/CM+jWMESxkIlCtaD000t/gELYHEy0ov8TE GHFTU5TTPSwmiMFW3yBslCQZjh2MbO5BsMhDpBMrN8lAQbV6yfLVYjaa36uUtNz1b7by pXC/wQKgye3Qf+Qsyl7OIErZ2uZY5o+fHWDU0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=qhYix4LLyNwvBVLejr92VS4cWgZE0Q+bZQwVwm78evw=; b=ftLW6OOJMci8RBT1KY1lHXR5PAfdktXwysXS2W7KprHXGeDKt/WxVIDLtu0V8suR6D XHcPQ8M5M7hTg9e/roRg9t1Dd6edyL6Gc12zGPbYDYLl6440I/S3LsYfNiIyE2C80V+o qoZVeKu1T4ORYtFqEH/dVlCHMpqGflCnYTbW6vtsix1aFN9EqBQNARQGsr1e2cQgEt1s TLm6LcskmkFU3BVQI1b248g7WMpFa+681+09rRvCMO2OVc2ZBJyqZIYpuRZqeTmjeA2U ELxdpudFeDDTnRCK8pmyRI/V/5RCO3graTQmwWaAH3ds0uEVEXuIfAzctqMHWf4yuN8F 1BrQ== MIME-Version: 1.0 X-Received: by 10.50.112.100 with SMTP id ip4mr529651igb.87.1364589192483; Fri, 29 Mar 2013 13:33:12 -0700 (PDT) Received: by 10.42.41.2 with HTTP; Fri, 29 Mar 2013 13:33:12 -0700 (PDT) X-Originating-IP: [174.51.153.161] Date: Fri, 29 Mar 2013 14:33:12 -0600 Message-ID: From: Dan Weber To: rmcat@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a9ad2152a2804d9162eff X-Gm-Message-State: ALoCoQk2p06od+qgsRjqCL8hV+S9ZpEQ0CMBYVmUCiLUETj6/WIexqGXdTlXwi2O5/K3pcGE8suS Subject: [rmcat] The Definition of Fairness 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, 29 Mar 2013 20:33:20 -0000 --047d7b3a9ad2152a2804d9162eff Content-Type: text/plain; charset=UTF-8 As we all are aware, defining fairness presents challenges. Michael Ramhalko gives the best metaphor for describing it we know today, "I know it when I see it". To even more elaborate on his point, we can't say what is fair by seeing it, we can only identify what is unfair. When is something unfair? Two situations come to mind. "That's not fair!" These are the infamous words children say everyday when they don't get their way. Often times it could be some toy that is in use, or maybe someone gets preferential treatment. The child *"harmed'" *is limited from participating in the same way as the other. A similar case could be waiting on a list at a busy restaurant. If you've been waiting on the list for an hour, and someone walks in the door only to know the host personally and jump ahead to the next available table. Based on these examples, defining *unfairness* might be "when a participant seeks out its own self interest at the expense of everyone else". Because when that man cuts you in line, he probably does so without acknowledging your existence. Merely assuming there are other participants can allow one to adjust for their presence whether or not if their existence is clear. Then, the antonym of my unfairness definition or the fairness definition is the golden rule: "Treat others as you wish to be treated" If the man who cut in line then was subject to his own behavior elsewhere, he may become upset with it as well and change his own behavior. This is one of the major issues with bittorrent. Since bittorrent is so aggressive, everyone else finds themselves in positions trying to protect their own applications from its behavior, including competing bittorrents. In light of this, we come to the question, "Is seeking RTP fairness with itself enough?" I say yes. RTP in its current form exhibits the following behaviors: - It can be be short lived (short video clip) - It can be long lived (long telephone calls) - It can be bursty (i-frames go across the network) - It can be constant rate (constant bit rate audio codecs like mulaw) - It can be variable rate (video streams in general targeting consistent quality with changes in motion or picture) - It can be used in ways to maximize throughput (e.g. streaming movies at the highest quality a client can receive acceptably -- Hulu or equivalent) - It can be unresponsive to changes in the network (without any form of congestion control, RTP continues to send oblivious to other participants) - It competes with itself in the average case (audio + video streams from the same sender, multiple video streams for multi party conferencing) - It is time sensitive (as in real time media needs to be played back without prior to changes in human perception) - It assumes that network behavior is unpredictable (existence of RTCP + use of things like adaptive jitter buffers) Let's say we agree on all of these behaviors. It is safe to assume then that competing with RTP is a superset of behaviors then it is to compete with TCP, LEDBAT, or a web browser alone is it not? Thanks, Dan --047d7b3a9ad2152a2804d9162eff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As we all are aware, defining fairness presents challenges. =C2=A0Michael R= amhalko gives the best metaphor for describing it we know today, "I kn= ow it when I see it".

To even more elaborate on his= point, we can't say what is fair by seeing it, we can only identify wh= at is unfair. =C2=A0When is something unfair? =C2=A0Two situations come to = mind.

"That's not fair!" =C2=A0These are the in= famous words children say everyday when they don't get their way. =C2= =A0Often times it could be some toy that is in use, or maybe someone gets p= referential treatment. =C2=A0The child "harmed'"=C2=A0= is limited from participating in the same way as the other. =C2=A0A similar= case could be waiting on a list at a busy restaurant. If you've been w= aiting on the list for an hour, and someone walks in the door only to know = the host personally and jump ahead to the next available table.

Based on these examples, defining unfairness=C2= =A0might be "when a participant seeks out its own self interest at the= expense of everyone else". =C2=A0Because when that man cuts you in li= ne, he probably does so without acknowledging your existence. =C2=A0Merely = assuming there are other participants can allow one to adjust for their pre= sence whether or not if their existence is clear. =C2=A0

Then, the antonym of my unfairness definition or the fa= irness definition is the golden rule: "Treat others as you wish to be = treated" =C2=A0If the man who cut in line then was subject to his own = behavior elsewhere, he may become upset with it as well and change his own = behavior. =C2=A0This is one of the major issues with bittorrent. =C2=A0Sinc= e bittorrent is so aggressive, everyone else finds themselves in positions = trying to protect their own applications from its behavior, including compe= ting bittorrents.

In light of this, we come to the question, "Is see= king RTP fairness with itself enough?" =C2=A0I say yes.

=
RTP in its current form exhibits the following behaviors:
<= div>
  • It can be be short lived (short video clip)
  • It can be long = lived (long telephone calls)
  • It can be bursty (i-frames go across t= he network)
  • It can be constant rate (constant bit rate audio codecs= like mulaw)
  • It can be variable rate (video streams in general=C2=A0targeting=C2=A0c= onsistent quality with changes in motion or picture)
  • It can be used= in ways to maximize throughput (e.g. streaming movies at the highest quali= ty a client can receive acceptably -- Hulu or equivalent)
  • It can be unresponsive to changes in the network (without any form of c= ongestion control, RTP continues to send oblivious to other participants)
  • It competes with itself in the average case (audio + video streams f= rom the same sender, multiple video streams for multi party conferencing)
  • It is time sensitive (as in real time media needs to be played back wit= hout prior to changes in human perception)
  • It assumes that network = behavior is unpredictable (existence of RTCP + use of things like adaptive = jitter buffers)
Let's say we agree on all of these behaviors. =C2=A0It = is safe to assume then that competing with RTP is a superset of behaviors t= hen it is to compete with TCP, LEDBAT, or a web browser alone is it not?

Thanks,
Dan
=C2=A0
--047d7b3a9ad2152a2804d9162eff-- From versteb@cisco.com Fri Mar 29 14:09:11 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 E18FA21F8525 for ; Fri, 29 Mar 2013 14:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaPm20rV16xc for ; Fri, 29 Mar 2013 14:09:10 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9B57121F8ED3 for ; Fri, 29 Mar 2013 14:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27604; q=dns/txt; s=iport; t=1364591345; x=1365800945; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ZWA5f9bIoQrYZpiQ+rmc74OLmRQRkP5qfm7a1VWMWd4=; b=H6RSvNLkZLMSTkxst+TzecQlvHBi9zx39FZTC4YTFDOv8pe1x2VgPDZ0 rOJKHeXiATrXRFKpoJTMUQAq7Q+1necA/iK4foyg9bsffGNuiIWJkqQdR UM5GAbaKndJvzbS19UAZSpSPktny4QuOFNGFed7lvL9XjPuwUqEwKuGFI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFACcCVlGtJXG+/2dsb2JhbAA5CoJDd4MfvBANfRZ0gh8BAQEEIwpcAgEGAhEEAQELHQMCAgIwFAkIAgQBEggTh3mSdpsGkhOJDYReBIEHJhEBgi0yYQOndoMLgWo+ X-IronPort-AV: E=Sophos;i="4.87,375,1363132800"; d="scan'208,217";a="193065372" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 29 Mar 2013 21:08:58 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2TL8wbI003304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Mar 2013 21:08:58 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.121]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 29 Mar 2013 16:08:58 -0500 From: "Bill Ver Steeg (versteb)" To: Dan Weber , "rmcat@ietf.org" Thread-Topic: [rmcat] The Definition of Fairness Thread-Index: AQHOLLzTnPqdw5kzqUWnWtfAS0IBOpi9JCdA Date: Fri, 29 Mar 2013 21:08:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.14.117] Content-Type: multipart/alternative; boundary="_000_AE7F97DB5FEE054088D82E836BD15BE91EC0FC8Fxmbalnx05ciscoc_" MIME-Version: 1.0 Subject: Re: [rmcat] The Definition of Fairness 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, 29 Mar 2013 21:09:12 -0000 --_000_AE7F97DB5FEE054088D82E836BD15BE91EC0FC8Fxmbalnx05ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXQgdGhlIHJpc2sgb2Ygc3RhcnRpbmcgYSBwaGlsb3NvcGhpY2FsIGRlYmF0ZSwgSSB0aGluayB3 ZSBzaG91bGQgY29uc2lkZXIgc29tZSBsZXNzb25zIGZyb20gZ2FtZSB0aGVvcnkuDQoNClRoZSDi gJxQcmlzb25lcuKAmXMgRGlsZW1tYeKAnSBjb21lcyB0byBtaW5kLiBJZiBhbiBhcHBsaWNhdGlv biBzZW5zZXMgdGhhdCB0aGUgcHJvZ3JhbXMgdGhhdCBpdCBpcyBzaGFyaW5nIGEgbGluayB3aXRo IGFyZSDigJxmYWly4oCdICh3aGVyZSBmYWlyIGJvaWxzIGRvd24gdG8g4oCcZ2l2ZSBtZSBhIHJl YXNvbmFibGUgYW1vdW50IG9mIEJXIGFuZCBkbyBub3QgZXhjZXNzaXZlbHkgZGVsYXkgbXkgdHJh ZmZpY+KAnSksIHRoZSBsb2dpY2FsIHRoaW5nIHRvIGlzIHRvIGFsc28gYmUgZmFpci4gV2hlbiBh biBhcHBsaWNhdGlvbiBzZW5zZXMgdGhhdCBhbm90aGVyIHByb2dyYW0gaXMgdGFraW5nIHVwIGFs bCBvZiB0aGUgYXZhaWxhYmxlIGxpbmsgQlcgYW5kL29yIGNhdXNpbmcgZGVsYXkgZm9yIGl0cyBk YXRhLCB0aGF0IHByb2dyYW0gd291bGQgYmUgZm9vbGlzaCB0byBhbGxvdyB0aGUgbW9yZSBhZ2dy ZXNzaXZlIGNvbXBldGl0b3IgdG8gc2VpemUgYWxsIG9mIHRoZSBsaW5rIEJXLiBJdCB3b3VsZCwg aW4gdHVybiwgYmUgYWdncmVzc2l2ZSBpbiBpdHMgYmVoYXZpb3IuIFRoZXJlIGFyZSBhIGZldyBz b2x1dGlvbnMgdG8gdGhpcyBwcm9ibGVtLCBhbmQgSSBlbmNvdXJhZ2UgdGhlIGdyb3VwIHRvIGxv b2sgaW50byB0aGlzIGEgYml0LiBUaGUgd2lubmluZyBnYW1lIHRoZW9yeSBzdHJhdGVnaWVzIGJv aWwgZG93biB0byB2YXJpYXRpb25zIG9uIOKAnHRpdCBmb3IgdGF04oCdLCBpbiB3aGljaCBwYXJ0 aWNpcGFudCBzdGFydHMgb3V0IGJlaW5nIGNvb3BlcmF0aXZlLCBidXQgYmVjb21lcyB1bmNvb3Bl cmF0aXZlIHdoZW4gcGVlcnMgYXJlIHNlZW4gdG8gYmUgdW5jb29wZXJhdGl2ZS4NCg0KVGhlIOKA nHRyYWdlZHkgb2YgdGhlIGNvbW1vbnPigJ0gaXMgYSBzaW1pbGFyIGV4YW1wbGUuDQoNCkluIGEg cGVyZmVjdCB3b3JsZCwgdGhlIG5ldHdvcmsgd291bGQgaGF2ZSBhIHdheSB0byBpbmZsdWVuY2Ug YXBwbGljYXRpb24gYmVoYXZpb3JzIHRvd2FyZHMgdGhlIGRlc2lyZWQgYmVoYXZpb3IuIE1pc2Jl aGF2aW5nIGFwcGxpY2F0aW9ucyB3b3VsZCBzdWZmZXIgZnJvbSB0aGUgZGVsYXkgcGVuYWx0eSwg YnV0IHdlbGwgYmVoYXZlZCBhcHBsaWNhdGlvbnMgd291bGQgbm90Lg0KDQpUaGVyZSBhcmUgc29t ZSB0aGVvcmV0aWNhbCBzb2x1dGlvbnMgdGhhdCBmaXQgdGhlIGJpbGwuIEZvciBpbnN0YW5jZSwg dGhlIG1pZGRsZWJveCBjb3VsZCBzZWdyZWdhdGUgdGhlIHRyYWZmaWMgaW50byBhIChzZXQgb2Yp IHN1Yi1xdWV1ZShzKSBvbiBhIHBlciBRT1MgYnVja2V0IGJhc2lzLiBUaGVzZXMgc3ViIHF1ZXVl cyB3b3VsZCBiZSBkZXNpZ25lZCBzdWNoIHRoYXQgIGNvb3BlcmF0aXZlIGFwcGxpY2F0aW9ucyBj b21wZXRlZCB3aXRoIG90aGVyIGNvb3BlcmF0aXZlIGFwcGxpY2F0aW9ucyBpbiBhIChzZXQgb2Yp IHN1YiBxdWV1ZShzKSBhbmQgYWdncmVzc2l2ZS9taXNiZWhhdmluZyBhcHBsaWNhdGlvbnMgY29t cGV0ZWQgd2l0aCBvdGhlciBzaW1pbGFyIHRyYWZmaWMuIFNvLCBpZiB5b3UgdGVuZCB0byByZXNw b25kIHRvIGNvbmdlc3Rpb24gc2lnbmFscywgeW91IHdpbGwgYmUgaW4gYSAoc2V0IG9mKSBzdWIt cXVldWUocykgd2l0aCBnb29kIGRlbGF5IGNoYXJhY3RlcmlzdGljcyBhbmQgd2lsbCBnZXQgeW91 ciDigJxmYWly4oCdIHNoYXJlLiBJZiB5b3UgdGVuZCB0byBub3QgcmVzcG9uZCB0byBjb25nZXN0 aW9uIHNpZ25hbHMsIHlvdSB3aWxsIGJlIGluIGEgKHNldCBvZikgc3ViLXF1ZXVlKHMpIHdpdGgg cG9vciBkZWxheSBjaGFyYWN0ZXJpc3RpY3MgYW5kIHRoZSBuZXR3b3JrIHdpbGwgYmlhcyB0aGUg QlcgdG93YXJkcyB0aGUgd2VsbCBiZWhhdmVkIHF1ZXVlKHMpLg0KDQpVbmZvcnR1bmF0ZWx5LCB0 aGlzIGJlaGF2aW9yIGlzIGVhc2llciB0byB2aXN1YWxpemUgdGhhbiB0byBpbXBsZW1lbnQuIEl0 IGlzIGZyYXVnaHQgd2l0aCBjb3JuZXIgY2FzZXMsIGxvdHMgb2Ygc3RhdGUgYW5kIHRvdWdoIGRl Y2lzaW9ucy4gSSByZXR1cm4geW91IHRvICB0aGUgbmV0d29ya2luZyBkaXNjdXNzaW9uc+KApuKA pi4uDQoNCg0KQnZzDQoNCg0KRnJvbTogcm1jYXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJt Y2F0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYW4gV2ViZXINClNlbnQ6IEZyaWRh eSwgTWFyY2ggMjksIDIwMTMgNDozMyBQTQ0KVG86IHJtY2F0QGlldGYub3JnDQpTdWJqZWN0OiBb cm1jYXRdIFRoZSBEZWZpbml0aW9uIG9mIEZhaXJuZXNzDQoNCkFzIHdlIGFsbCBhcmUgYXdhcmUs IGRlZmluaW5nIGZhaXJuZXNzIHByZXNlbnRzIGNoYWxsZW5nZXMuICBNaWNoYWVsIFJhbWhhbGtv IGdpdmVzIHRoZSBiZXN0IG1ldGFwaG9yIGZvciBkZXNjcmliaW5nIGl0IHdlIGtub3cgdG9kYXks ICJJIGtub3cgaXQgd2hlbiBJIHNlZSBpdCIuDQoNClRvIGV2ZW4gbW9yZSBlbGFib3JhdGUgb24g aGlzIHBvaW50LCB3ZSBjYW4ndCBzYXkgd2hhdCBpcyBmYWlyIGJ5IHNlZWluZyBpdCwgd2UgY2Fu IG9ubHkgaWRlbnRpZnkgd2hhdCBpcyB1bmZhaXIuICBXaGVuIGlzIHNvbWV0aGluZyB1bmZhaXI/ ICBUd28gc2l0dWF0aW9ucyBjb21lIHRvIG1pbmQuDQoNCiJUaGF0J3Mgbm90IGZhaXIhIiAgVGhl c2UgYXJlIHRoZSBpbmZhbW91cyB3b3JkcyBjaGlsZHJlbiBzYXkgZXZlcnlkYXkgd2hlbiB0aGV5 IGRvbid0IGdldCB0aGVpciB3YXkuICBPZnRlbiB0aW1lcyBpdCBjb3VsZCBiZSBzb21lIHRveSB0 aGF0IGlzIGluIHVzZSwgb3IgbWF5YmUgc29tZW9uZSBnZXRzIHByZWZlcmVudGlhbCB0cmVhdG1l bnQuICBUaGUgY2hpbGQgImhhcm1lZCciIGlzIGxpbWl0ZWQgZnJvbSBwYXJ0aWNpcGF0aW5nIGlu IHRoZSBzYW1lIHdheSBhcyB0aGUgb3RoZXIuICBBIHNpbWlsYXIgY2FzZSBjb3VsZCBiZSB3YWl0 aW5nIG9uIGEgbGlzdCBhdCBhIGJ1c3kgcmVzdGF1cmFudC4gSWYgeW91J3ZlIGJlZW4gd2FpdGlu ZyBvbiB0aGUgbGlzdCBmb3IgYW4gaG91ciwgYW5kIHNvbWVvbmUgd2Fsa3MgaW4gdGhlIGRvb3Ig b25seSB0byBrbm93IHRoZSBob3N0IHBlcnNvbmFsbHkgYW5kIGp1bXAgYWhlYWQgdG8gdGhlIG5l eHQgYXZhaWxhYmxlIHRhYmxlLg0KDQpCYXNlZCBvbiB0aGVzZSBleGFtcGxlcywgZGVmaW5pbmcg dW5mYWlybmVzcyBtaWdodCBiZSAid2hlbiBhIHBhcnRpY2lwYW50IHNlZWtzIG91dCBpdHMgb3du IHNlbGYgaW50ZXJlc3QgYXQgdGhlIGV4cGVuc2Ugb2YgZXZlcnlvbmUgZWxzZSIuICBCZWNhdXNl IHdoZW4gdGhhdCBtYW4gY3V0cyB5b3UgaW4gbGluZSwgaGUgcHJvYmFibHkgZG9lcyBzbyB3aXRo b3V0IGFja25vd2xlZGdpbmcgeW91ciBleGlzdGVuY2UuICBNZXJlbHkgYXNzdW1pbmcgdGhlcmUg YXJlIG90aGVyIHBhcnRpY2lwYW50cyBjYW4gYWxsb3cgb25lIHRvIGFkanVzdCBmb3IgdGhlaXIg cHJlc2VuY2Ugd2hldGhlciBvciBub3QgaWYgdGhlaXIgZXhpc3RlbmNlIGlzIGNsZWFyLg0KDQpU aGVuLCB0aGUgYW50b255bSBvZiBteSB1bmZhaXJuZXNzIGRlZmluaXRpb24gb3IgdGhlIGZhaXJu ZXNzIGRlZmluaXRpb24gaXMgdGhlIGdvbGRlbiBydWxlOiAiVHJlYXQgb3RoZXJzIGFzIHlvdSB3 aXNoIHRvIGJlIHRyZWF0ZWQiICBJZiB0aGUgbWFuIHdobyBjdXQgaW4gbGluZSB0aGVuIHdhcyBz dWJqZWN0IHRvIGhpcyBvd24gYmVoYXZpb3IgZWxzZXdoZXJlLCBoZSBtYXkgYmVjb21lIHVwc2V0 IHdpdGggaXQgYXMgd2VsbCBhbmQgY2hhbmdlIGhpcyBvd24gYmVoYXZpb3IuICBUaGlzIGlzIG9u ZSBvZiB0aGUgbWFqb3IgaXNzdWVzIHdpdGggYml0dG9ycmVudC4gIFNpbmNlIGJpdHRvcnJlbnQg aXMgc28gYWdncmVzc2l2ZSwgZXZlcnlvbmUgZWxzZSBmaW5kcyB0aGVtc2VsdmVzIGluIHBvc2l0 aW9ucyB0cnlpbmcgdG8gcHJvdGVjdCB0aGVpciBvd24gYXBwbGljYXRpb25zIGZyb20gaXRzIGJl aGF2aW9yLCBpbmNsdWRpbmcgY29tcGV0aW5nIGJpdHRvcnJlbnRzLg0KDQpJbiBsaWdodCBvZiB0 aGlzLCB3ZSBjb21lIHRvIHRoZSBxdWVzdGlvbiwgIklzIHNlZWtpbmcgUlRQIGZhaXJuZXNzIHdp dGggaXRzZWxmIGVub3VnaD8iICBJIHNheSB5ZXMuDQoNClJUUCBpbiBpdHMgY3VycmVudCBmb3Jt IGV4aGliaXRzIHRoZSBmb2xsb3dpbmcgYmVoYXZpb3JzOg0KDQogICogICBJdCBjYW4gYmUgYmUg c2hvcnQgbGl2ZWQgKHNob3J0IHZpZGVvIGNsaXApDQogICogICBJdCBjYW4gYmUgbG9uZyBsaXZl ZCAobG9uZyB0ZWxlcGhvbmUgY2FsbHMpDQogICogICBJdCBjYW4gYmUgYnVyc3R5IChpLWZyYW1l cyBnbyBhY3Jvc3MgdGhlIG5ldHdvcmspDQogICogICBJdCBjYW4gYmUgY29uc3RhbnQgcmF0ZSAo Y29uc3RhbnQgYml0IHJhdGUgYXVkaW8gY29kZWNzIGxpa2UgbXVsYXcpDQogICogICBJdCBjYW4g YmUgdmFyaWFibGUgcmF0ZSAodmlkZW8gc3RyZWFtcyBpbiBnZW5lcmFsIHRhcmdldGluZyBjb25z aXN0ZW50IHF1YWxpdHkgd2l0aCBjaGFuZ2VzIGluIG1vdGlvbiBvciBwaWN0dXJlKQ0KICAqICAg SXQgY2FuIGJlIHVzZWQgaW4gd2F5cyB0byBtYXhpbWl6ZSB0aHJvdWdocHV0IChlLmcuIHN0cmVh bWluZyBtb3ZpZXMgYXQgdGhlIGhpZ2hlc3QgcXVhbGl0eSBhIGNsaWVudCBjYW4gcmVjZWl2ZSBh Y2NlcHRhYmx5IC0tIEh1bHUgb3IgZXF1aXZhbGVudCkNCiAgKiAgIEl0IGNhbiBiZSB1bnJlc3Bv bnNpdmUgdG8gY2hhbmdlcyBpbiB0aGUgbmV0d29yayAod2l0aG91dCBhbnkgZm9ybSBvZiBjb25n ZXN0aW9uIGNvbnRyb2wsIFJUUCBjb250aW51ZXMgdG8gc2VuZCBvYmxpdmlvdXMgdG8gb3RoZXIg cGFydGljaXBhbnRzKQ0KICAqICAgSXQgY29tcGV0ZXMgd2l0aCBpdHNlbGYgaW4gdGhlIGF2ZXJh Z2UgY2FzZSAoYXVkaW8gKyB2aWRlbyBzdHJlYW1zIGZyb20gdGhlIHNhbWUgc2VuZGVyLCBtdWx0 aXBsZSB2aWRlbyBzdHJlYW1zIGZvciBtdWx0aSBwYXJ0eSBjb25mZXJlbmNpbmcpDQogICogICBJ dCBpcyB0aW1lIHNlbnNpdGl2ZSAoYXMgaW4gcmVhbCB0aW1lIG1lZGlhIG5lZWRzIHRvIGJlIHBs YXllZCBiYWNrIHdpdGhvdXQgcHJpb3IgdG8gY2hhbmdlcyBpbiBodW1hbiBwZXJjZXB0aW9uKQ0K ICAqICAgSXQgYXNzdW1lcyB0aGF0IG5ldHdvcmsgYmVoYXZpb3IgaXMgdW5wcmVkaWN0YWJsZSAo ZXhpc3RlbmNlIG9mIFJUQ1AgKyB1c2Ugb2YgdGhpbmdzIGxpa2UgYWRhcHRpdmUgaml0dGVyIGJ1 ZmZlcnMpDQpMZXQncyBzYXkgd2UgYWdyZWUgb24gYWxsIG9mIHRoZXNlIGJlaGF2aW9ycy4gIEl0 IGlzIHNhZmUgdG8gYXNzdW1lIHRoZW4gdGhhdCBjb21wZXRpbmcgd2l0aCBSVFAgaXMgYSBzdXBl cnNldCBvZiBiZWhhdmlvcnMgdGhlbiBpdCBpcyB0byBjb21wZXRlIHdpdGggVENQLCBMRURCQVQs IG9yIGEgd2ViIGJyb3dzZXIgYWxvbmUgaXMgaXQgbm90Pw0KDQpUaGFua3MsDQpEYW4NCg0K --_000_AE7F97DB5FEE054088D82E836BD15BE91EC0FC8Fxmbalnx05ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDo4MDQ1NDkxNTY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjEyMTM3NzYxOTA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QXQgdGhlIHJpc2sgb2Ygc3RhcnRpbmcgYSBwaGlsb3NvcGhpY2FsIGRlYmF0 ZSwgSSB0aGluayB3ZSBzaG91bGQgY29uc2lkZXIgc29tZSBsZXNzb25zIGZyb20gZ2FtZSB0aGVv cnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGUg4oCcUHJpc29uZXLigJlzIERpbGVtbWHigJ0gY29tZXMgdG8gbWlu ZC4gSWYgYW4gYXBwbGljYXRpb24gc2Vuc2VzIHRoYXQgdGhlIHByb2dyYW1zIHRoYXQgaXQgaXMg c2hhcmluZyBhIGxpbmsgd2l0aCBhcmUg4oCcZmFpcuKAnSAod2hlcmUgZmFpciBib2lscyBkb3du IHRvIOKAnGdpdmUNCiBtZSBhIHJlYXNvbmFibGUgYW1vdW50IG9mIEJXIGFuZCBkbyBub3QgZXhj ZXNzaXZlbHkgZGVsYXkgbXkgdHJhZmZpY+KAnSksIHRoZSBsb2dpY2FsIHRoaW5nIHRvIGlzIHRv IGFsc28gYmUgZmFpci4gV2hlbiBhbiBhcHBsaWNhdGlvbiBzZW5zZXMgdGhhdCBhbm90aGVyIHBy b2dyYW0gaXMgdGFraW5nIHVwIGFsbCBvZiB0aGUgYXZhaWxhYmxlIGxpbmsgQlcgYW5kL29yIGNh dXNpbmcgZGVsYXkgZm9yIGl0cyBkYXRhLCB0aGF0IHByb2dyYW0gd291bGQNCiBiZSBmb29saXNo IHRvIGFsbG93IHRoZSBtb3JlIGFnZ3Jlc3NpdmUgY29tcGV0aXRvciB0byBzZWl6ZSBhbGwgb2Yg dGhlIGxpbmsgQlcuIEl0IHdvdWxkLCBpbiB0dXJuLCBiZSBhZ2dyZXNzaXZlIGluIGl0cyBiZWhh dmlvci4gVGhlcmUgYXJlIGEgZmV3IHNvbHV0aW9ucyB0byB0aGlzIHByb2JsZW0sIGFuZCBJIGVu Y291cmFnZSB0aGUgZ3JvdXAgdG8gbG9vayBpbnRvIHRoaXMgYSBiaXQuIFRoZSB3aW5uaW5nIGdh bWUgdGhlb3J5IHN0cmF0ZWdpZXMNCiBib2lsIGRvd24gdG8gdmFyaWF0aW9ucyBvbiDigJx0aXQg Zm9yIHRhdOKAnSwgaW4gd2hpY2ggcGFydGljaXBhbnQgc3RhcnRzIG91dCBiZWluZyBjb29wZXJh dGl2ZSwgYnV0IGJlY29tZXMgdW5jb29wZXJhdGl2ZSB3aGVuIHBlZXJzIGFyZSBzZWVuIHRvIGJl IHVuY29vcGVyYXRpdmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSDigJx0cmFnZWR5IG9mIHRoZSBjb21tb25z 4oCdIGlzIGEgc2ltaWxhciBleGFtcGxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gYSBwZXJmZWN0IHdvcmxkLCB0 aGUgbmV0d29yayB3b3VsZCBoYXZlIGEgd2F5IHRvIGluZmx1ZW5jZSBhcHBsaWNhdGlvbiBiZWhh dmlvcnMgdG93YXJkcyB0aGUgZGVzaXJlZCBiZWhhdmlvci4gTWlzYmVoYXZpbmcgYXBwbGljYXRp b25zIHdvdWxkIHN1ZmZlciBmcm9tDQogdGhlIGRlbGF5IHBlbmFsdHksIGJ1dCB3ZWxsIGJlaGF2 ZWQgYXBwbGljYXRpb25zIHdvdWxkIG5vdC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZSBhcmUgc29tZSB0aGVv cmV0aWNhbCBzb2x1dGlvbnMgdGhhdCBmaXQgdGhlIGJpbGwuIEZvciBpbnN0YW5jZSwgdGhlIG1p ZGRsZWJveCBjb3VsZCBzZWdyZWdhdGUgdGhlIHRyYWZmaWMgaW50byBhIChzZXQgb2YpIHN1Yi1x dWV1ZShzKSBvbiBhIHBlciBRT1MgYnVja2V0DQogYmFzaXMuIFRoZXNlcyBzdWIgcXVldWVzIHdv dWxkIGJlIGRlc2lnbmVkIHN1Y2ggdGhhdCAmbmJzcDtjb29wZXJhdGl2ZSBhcHBsaWNhdGlvbnMg Y29tcGV0ZWQgd2l0aCBvdGhlciBjb29wZXJhdGl2ZSBhcHBsaWNhdGlvbnMgaW4gYSAoc2V0IG9m KSBzdWIgcXVldWUocykgYW5kIGFnZ3Jlc3NpdmUvbWlzYmVoYXZpbmcgYXBwbGljYXRpb25zIGNv bXBldGVkIHdpdGggb3RoZXIgc2ltaWxhciB0cmFmZmljLiBTbywgaWYgeW91IHRlbmQgdG8gcmVz cG9uZCB0bw0KIGNvbmdlc3Rpb24gc2lnbmFscywgeW91IHdpbGwgYmUgaW4gYSAoc2V0IG9mKSBz dWItcXVldWUocykgd2l0aCBnb29kIGRlbGF5IGNoYXJhY3RlcmlzdGljcyBhbmQgd2lsbCBnZXQg eW91ciDigJxmYWly4oCdIHNoYXJlLiBJZiB5b3UgdGVuZCB0byBub3QgcmVzcG9uZCB0byBjb25n ZXN0aW9uIHNpZ25hbHMsIHlvdSB3aWxsIGJlIGluIGEgKHNldCBvZikgc3ViLXF1ZXVlKHMpIHdp dGggcG9vciBkZWxheSBjaGFyYWN0ZXJpc3RpY3MgYW5kIHRoZSBuZXR3b3JrDQogd2lsbCBiaWFz IHRoZSBCVyB0b3dhcmRzIHRoZSB3ZWxsIGJlaGF2ZWQgcXVldWUocykuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5VbmZv cnR1bmF0ZWx5LCB0aGlzIGJlaGF2aW9yIGlzIGVhc2llciB0byB2aXN1YWxpemUgdGhhbiB0byBp bXBsZW1lbnQuIEl0IGlzIGZyYXVnaHQgd2l0aCBjb3JuZXIgY2FzZXMsIGxvdHMgb2Ygc3RhdGUg YW5kIHRvdWdoIGRlY2lzaW9ucy4gSSByZXR1cm4geW91IHRvICZuYnNwO3RoZQ0KIG5ldHdvcmtp bmcgZGlzY3Vzc2lvbnPigKbigKYuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkJ2czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJtY2F0LWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpybWNhdC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5EYW4gV2ViZXI8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAyOSwgMjAxMyA0OjMz IFBNPGJyPg0KPGI+VG86PC9iPiBybWNhdEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBb cm1jYXRdIFRoZSBEZWZpbml0aW9uIG9mIEZhaXJuZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BcyB3ZSBhbGwgYXJlIGF3YXJlLCBkZWZpbmluZyBmYWlybmVzcyBwcmVzZW50cyBj aGFsbGVuZ2VzLiAmbmJzcDtNaWNoYWVsIFJhbWhhbGtvIGdpdmVzIHRoZSBiZXN0IG1ldGFwaG9y IGZvciBkZXNjcmliaW5nIGl0IHdlIGtub3cgdG9kYXksICZxdW90O0kga25vdyBpdCB3aGVuIEkg c2VlIGl0JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VG8gZXZlbiBtb3JlIGVsYWJvcmF0ZSBvbiBoaXMgcG9pbnQsIHdlIGNhbid0IHNheSB3aGF0 IGlzIGZhaXIgYnkgc2VlaW5nIGl0LCB3ZSBjYW4gb25seSBpZGVudGlmeSB3aGF0IGlzIHVuZmFp ci4gJm5ic3A7V2hlbiBpcyBzb21ldGhpbmcgdW5mYWlyPyAmbmJzcDtUd28gc2l0dWF0aW9ucyBj b21lIHRvIG1pbmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZxdW90O1RoYXQncyBub3QgZmFpciEmcXVvdDsgJm5ic3A7VGhlc2UgYXJlIHRo ZSBpbmZhbW91cyB3b3JkcyBjaGlsZHJlbiBzYXkgZXZlcnlkYXkgd2hlbiB0aGV5IGRvbid0IGdl dCB0aGVpciB3YXkuICZuYnNwO09mdGVuIHRpbWVzIGl0IGNvdWxkIGJlIHNvbWUgdG95IHRoYXQg aXMgaW4gdXNlLCBvciBtYXliZSBzb21lb25lIGdldHMgcHJlZmVyZW50aWFsIHRyZWF0bWVudC4g Jm5ic3A7VGhlIGNoaWxkDQo8aT4mcXVvdDtoYXJtZWQnJnF1b3Q7Jm5ic3A7PC9pPmlzIGxpbWl0 ZWQgZnJvbSBwYXJ0aWNpcGF0aW5nIGluIHRoZSBzYW1lIHdheSBhcyB0aGUgb3RoZXIuICZuYnNw O0Egc2ltaWxhciBjYXNlIGNvdWxkIGJlIHdhaXRpbmcgb24gYSBsaXN0IGF0IGEgYnVzeSByZXN0 YXVyYW50LiBJZiB5b3UndmUgYmVlbiB3YWl0aW5nIG9uIHRoZSBsaXN0IGZvciBhbiBob3VyLCBh bmQgc29tZW9uZSB3YWxrcyBpbiB0aGUgZG9vciBvbmx5IHRvIGtub3cgdGhlIGhvc3QgcGVyc29u YWxseSBhbmQNCiBqdW1wIGFoZWFkIHRvIHRoZSBuZXh0IGF2YWlsYWJsZSB0YWJsZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFzZWQgb24g dGhlc2UgZXhhbXBsZXMsIGRlZmluaW5nIDxpPnVuZmFpcm5lc3M8L2k+Jm5ic3A7bWlnaHQgYmUg JnF1b3Q7d2hlbiBhIHBhcnRpY2lwYW50IHNlZWtzIG91dCBpdHMgb3duIHNlbGYgaW50ZXJlc3Qg YXQgdGhlIGV4cGVuc2Ugb2YgZXZlcnlvbmUgZWxzZSZxdW90Oy4gJm5ic3A7QmVjYXVzZSB3aGVu IHRoYXQgbWFuIGN1dHMgeW91IGluIGxpbmUsIGhlIHByb2JhYmx5IGRvZXMgc28gd2l0aG91dCBh Y2tub3dsZWRnaW5nIHlvdXIgZXhpc3RlbmNlLg0KICZuYnNwO01lcmVseSBhc3N1bWluZyB0aGVy ZSBhcmUgb3RoZXIgcGFydGljaXBhbnRzIGNhbiBhbGxvdyBvbmUgdG8gYWRqdXN0IGZvciB0aGVp ciBwcmVzZW5jZSB3aGV0aGVyIG9yIG5vdCBpZiB0aGVpciBleGlzdGVuY2UgaXMgY2xlYXIuICZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGVuLCB0aGUgYW50b255bSBvZiBteSB1bmZhaXJuZXNzIGRlZmluaXRpb24gb3IgdGhlIGZh aXJuZXNzIGRlZmluaXRpb24gaXMgdGhlIGdvbGRlbiBydWxlOiAmcXVvdDtUcmVhdCBvdGhlcnMg YXMgeW91IHdpc2ggdG8gYmUgdHJlYXRlZCZxdW90OyAmbmJzcDtJZiB0aGUgbWFuIHdobyBjdXQg aW4gbGluZSB0aGVuIHdhcyBzdWJqZWN0IHRvIGhpcyBvd24gYmVoYXZpb3IgZWxzZXdoZXJlLCBo ZSBtYXkgYmVjb21lIHVwc2V0IHdpdGggaXQNCiBhcyB3ZWxsIGFuZCBjaGFuZ2UgaGlzIG93biBi ZWhhdmlvci4gJm5ic3A7VGhpcyBpcyBvbmUgb2YgdGhlIG1ham9yIGlzc3VlcyB3aXRoIGJpdHRv cnJlbnQuICZuYnNwO1NpbmNlIGJpdHRvcnJlbnQgaXMgc28gYWdncmVzc2l2ZSwgZXZlcnlvbmUg ZWxzZSBmaW5kcyB0aGVtc2VsdmVzIGluIHBvc2l0aW9ucyB0cnlpbmcgdG8gcHJvdGVjdCB0aGVp ciBvd24gYXBwbGljYXRpb25zIGZyb20gaXRzIGJlaGF2aW9yLCBpbmNsdWRpbmcgY29tcGV0aW5n IGJpdHRvcnJlbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiBsaWdodCBvZiB0aGlzLCB3ZSBjb21lIHRvIHRoZSBxdWVzdGlvbiwgJnF1 b3Q7SXMgc2Vla2luZyBSVFAgZmFpcm5lc3Mgd2l0aCBpdHNlbGYgZW5vdWdoPyZxdW90OyAmbmJz cDtJIHNheSB5ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJUUCBpbiBpdHMgY3VycmVudCBmb3JtIGV4aGliaXRzIHRoZSBmb2xsb3dpbmcg YmVoYXZpb3JzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJdCBj YW4gYmUgYmUgc2hvcnQgbGl2ZWQgKHNob3J0IHZpZGVvIGNsaXApPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSXQgY2FuIGJl IGxvbmcgbGl2ZWQgKGxvbmcgdGVsZXBob25lIGNhbGxzKTxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkl0IGNhbiBiZSBidXJz dHkgKGktZnJhbWVzIGdvIGFjcm9zcyB0aGUgbmV0d29yayk8bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJdCBjYW4gYmUgY29u c3RhbnQgcmF0ZSAoY29uc3RhbnQgYml0IHJhdGUgYXVkaW8gY29kZWNzIGxpa2UgbXVsYXcpPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KSXQgY2FuIGJlIHZhcmlhYmxlIHJhdGUgKHZpZGVvIHN0cmVhbXMgaW4gZ2VuZXJhbCZu YnNwO3RhcmdldGluZyZuYnNwO2NvbnNpc3RlbnQgcXVhbGl0eSB3aXRoIGNoYW5nZXMgaW4gbW90 aW9uIG9yIHBpY3R1cmUpPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSXQgY2FuIGJlIHVzZWQgaW4gd2F5cyB0byBtYXhpbWl6 ZSB0aHJvdWdocHV0IChlLmcuIHN0cmVhbWluZyBtb3ZpZXMgYXQgdGhlIGhpZ2hlc3QgcXVhbGl0 eSBhIGNsaWVudCBjYW4gcmVjZWl2ZSBhY2NlcHRhYmx5IC0tIEh1bHUgb3IgZXF1aXZhbGVudCk8 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQpJdCBjYW4gYmUgdW5yZXNwb25zaXZlIHRvIGNoYW5nZXMgaW4gdGhlIG5ldHdvcmsg KHdpdGhvdXQgYW55IGZvcm0gb2YgY29uZ2VzdGlvbiBjb250cm9sLCBSVFAgY29udGludWVzIHRv IHNlbmQgb2JsaXZpb3VzIHRvIG90aGVyIHBhcnRpY2lwYW50cyk8bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJdCBjb21wZXRl cyB3aXRoIGl0c2VsZiBpbiB0aGUgYXZlcmFnZSBjYXNlIChhdWRpbyAmIzQzOyB2aWRlbyBzdHJl YW1zIGZyb20gdGhlIHNhbWUgc2VuZGVyLCBtdWx0aXBsZSB2aWRlbyBzdHJlYW1zIGZvciBtdWx0 aSBwYXJ0eSBjb25mZXJlbmNpbmcpPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSXQgaXMgdGltZSBzZW5zaXRpdmUgKGFzIGlu IHJlYWwgdGltZSBtZWRpYSBuZWVkcyB0byBiZSBwbGF5ZWQgYmFjayB3aXRob3V0IHByaW9yIHRv IGNoYW5nZXMgaW4gaHVtYW4gcGVyY2VwdGlvbik8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJdCBhc3N1bWVzIHRoYXQgbmV0 d29yayBiZWhhdmlvciBpcyB1bnByZWRpY3RhYmxlIChleGlzdGVuY2Ugb2YgUlRDUCAmIzQzOyB1 c2Ugb2YgdGhpbmdzIGxpa2UgYWRhcHRpdmUgaml0dGVyIGJ1ZmZlcnMpPG86cD48L286cD48L2xp PjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXQncyBzYXkgd2Ug YWdyZWUgb24gYWxsIG9mIHRoZXNlIGJlaGF2aW9ycy4gJm5ic3A7SXQgaXMgc2FmZSB0byBhc3N1 bWUgdGhlbiB0aGF0IGNvbXBldGluZyB3aXRoIFJUUCBpcyBhIHN1cGVyc2V0IG9mIGJlaGF2aW9y cyB0aGVuIGl0IGlzIHRvIGNvbXBldGUgd2l0aCBUQ1AsIExFREJBVCwgb3IgYSB3ZWIgYnJvd3Nl ciBhbG9uZSBpcyBpdCBub3Q/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkRhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_AE7F97DB5FEE054088D82E836BD15BE91EC0FC8Fxmbalnx05ciscoc_-- From dan@marketsoup.com Fri Mar 29 14:32:47 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 31A4521F95EB for ; Fri, 29 Mar 2013 14:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.53 X-Spam-Level: X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUODtS8OxyI3 for ; Fri, 29 Mar 2013 14:32:46 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id CDC0021F95EC for ; Fri, 29 Mar 2013 14:32:42 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so922082iea.40 for ; Fri, 29 Mar 2013 14:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marketsoup.com; s=google; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6OA7BW/Oa+d9io9rCfmfUA1OaiYSJ2xePDulJn69HiU=; b=Y9J80QEmreYjOMIop4Uw0BOQ8wn1vJDhWHcMY7Ly6InI0+5IILVFalNshbZldDQLB3 FjTXSOHzocYimZvhUWunezTzKaG3XWL8erzLEAO9yIVZhmgTP25umeNCfjB5VpyuN0Vo 5hR4WJoc9C+93S6gM0BOHljHiPUspwtUXEr6E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6OA7BW/Oa+d9io9rCfmfUA1OaiYSJ2xePDulJn69HiU=; b=SdRT21KEHKCjj7I4MaKJmTAfeQ42tZC/veKbwpzGY+P6ct5dZ+u9dWH1v9AdHdSoRU F8hMxv/vL8IrEA+CvFnUhMcMSKBfyg3p8SJRrwMB8tefo7EqQEb5BC5O+n68c3y7TN4z O5hegCf2tfIXs2ublmmQHM4XR7lzucBGU0xSpFhoXYBnff+6+sznfQp919VyUDa67k6Q xW+1zEtyu8+Z18y3M4a/ZJ7u6bx5bCGMVLaP917bhxfsbYLQLLZpvkP9d4RQf2dFhfCy 2c6poNsKnOWz2IN5TQbuhgq/8xms5u++gqGr1crqqezRn8Es1Q+CdPExS5RoDx5hiLuf CsPQ== MIME-Version: 1.0 X-Received: by 10.50.25.2 with SMTP id y2mr173833igf.9.1364592755681; Fri, 29 Mar 2013 14:32:35 -0700 (PDT) Received: by 10.42.41.2 with HTTP; Fri, 29 Mar 2013 14:32:35 -0700 (PDT) X-Originating-IP: [174.51.153.161] In-Reply-To: References: Date: Fri, 29 Mar 2013 15:32:35 -0600 Message-ID: From: Dan Weber To: "Bill Ver Steeg (versteb)" Content-Type: multipart/alternative; boundary=047d7bd74a227743d404d9170207 X-Gm-Message-State: ALoCoQkx7lYK59NpLtXfoJIWRjOYM4RBwCu6spZpSvPWvUHcUtN/fj7+3qTSk4oiAZd8Y400Uaf8 Cc: "rmcat@ietf.org" Subject: Re: [rmcat] The Definition of Fairness 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, 29 Mar 2013 21:32:47 -0000 --047d7bd74a227743d404d9170207 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bill, The prisoner's dilemma is a good example if you want to use the court of public opinion as a moral compass. My suggestion is to have merely give RTP a conscience for its own behavior and not others. It seeks to treat itself and others by its own standards. In a world where land is plentiful, water flows cleanly, and sunlight is abundant, enough food can be grown to support everyone's needs. When battling plague or handling severe drought, everyone needs the bare minimum for survival. If that bare minimum can not be attained while seeking to apply each's own general principles first, than that man shall perish by the survival of the fittest. We have to run on the assumption that everyone will play fair and reasonably, otherwise, we run the risk of a never ending game. The US court system exists to implement fairness understands these problems and has settled on the premise that everyone acts in good faith unless proven otherwise. Thanks, Dan On Fri, Mar 29, 2013 at 3:08 PM, Bill Ver Steeg (versteb) wrote: > At the risk of starting a philosophical debate, I think we should > consider some lessons from game theory.**** > > ** ** > > The =E2=80=9CPrisoner=E2=80=99s Dilemma=E2=80=9D comes to mind. If an app= lication senses that the > programs that it is sharing a link with are =E2=80=9Cfair=E2=80=9D (where= fair boils down > to =E2=80=9Cgive me a reasonable amount of BW and do not excessively dela= y my > traffic=E2=80=9D), the logical thing to is to also be fair. When an appli= cation > senses that another program is taking up all of the available link BW > and/or causing delay for its data, that program would be foolish to allow > the more aggressive competitor to seize all of the link BW. It would, in > turn, be aggressive in its behavior. There are a few solutions to this > problem, and I encourage the group to look into this a bit. The winning > game theory strategies boil down to variations on =E2=80=9Ctit for tat=E2= =80=9D, in which > participant starts out being cooperative, but becomes uncooperative when > peers are seen to be uncooperative. **** > > ** ** > > The =E2=80=9Ctragedy of the commons=E2=80=9D is a similar example.**** > > ** ** > > In a perfect world, the network would have a way to influence application > behaviors towards the desired behavior. Misbehaving applications would > suffer from the delay penalty, but well behaved applications would not. *= * > ** > > ** ** > > There are some theoretical solutions that fit the bill. For instance, the > middlebox could segregate the traffic into a (set of) sub-queue(s) on a p= er > QOS bucket basis. Theses sub queues would be designed such that > cooperative applications competed with other cooperative applications in= a > (set of) sub queue(s) and aggressive/misbehaving applications competed wi= th > other similar traffic. So, if you tend to respond to congestion signals, > you will be in a (set of) sub-queue(s) with good delay characteristics an= d > will get your =E2=80=9Cfair=E2=80=9D share. If you tend to not respond to= congestion > signals, you will be in a (set of) sub-queue(s) with poor delay > characteristics and the network will bias the BW towards the well behaved > queue(s).**** > > ** ** > > Unfortunately, this behavior is easier to visualize than to implement. It > is fraught with corner cases, lots of state and tough decisions. I return > you to the networking discussions=E2=80=A6=E2=80=A6..**** > > ** ** > > ** ** > > Bvs**** > > ** ** > > ** ** > > *From:* rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] *On Behalf > Of *Dan Weber > *Sent:* Friday, March 29, 2013 4:33 PM > *To:* rmcat@ietf.org > *Subject:* [rmcat] The Definition of Fairness**** > > ** ** > > As we all are aware, defining fairness presents challenges. Michael > Ramhalko gives the best metaphor for describing it we know today, "I know > it when I see it".**** > > ** ** > > To even more elaborate on his point, we can't say what is fair by seeing > it, we can only identify what is unfair. When is something unfair? Two > situations come to mind.**** > > ** ** > > "That's not fair!" These are the infamous words children say everyday > when they don't get their way. Often times it could be some toy that is = in > use, or maybe someone gets preferential treatment. The child *"harmed'" = *is > limited from participating in the same way as the other. A similar case > could be waiting on a list at a busy restaurant. If you've been waiting o= n > the list for an hour, and someone walks in the door only to know the host > personally and jump ahead to the next available table.**** > > ** ** > > Based on these examples, defining *unfairness* might be "when a > participant seeks out its own self interest at the expense of everyone > else". Because when that man cuts you in line, he probably does so witho= ut > acknowledging your existence. Merely assuming there are other participan= ts > can allow one to adjust for their presence whether or not if their > existence is clear. **** > > ** ** > > Then, the antonym of my unfairness definition or the fairness definition > is the golden rule: "Treat others as you wish to be treated" If the man > who cut in line then was subject to his own behavior elsewhere, he may > become upset with it as well and change his own behavior. This is one of > the major issues with bittorrent. Since bittorrent is so aggressive, > everyone else finds themselves in positions trying to protect their own > applications from its behavior, including competing bittorrents.**** > > ** ** > > In light of this, we come to the question, "Is seeking RTP fairness with > itself enough?" I say yes.**** > > ** ** > > RTP in its current form exhibits the following behaviors:**** > > - It can be be short lived (short video clip)**** > - It can be long lived (long telephone calls)**** > - It can be bursty (i-frames go across the network)**** > - It can be constant rate (constant bit rate audio codecs like mulaw)*= * > ** > - It can be variable rate (video streams in > general targeting consistent quality with changes in motion or picture= ) > **** > - It can be used in ways to maximize throughput (e.g. streaming movies > at the highest quality a client can receive acceptably -- Hulu or > equivalent)**** > - It can be unresponsive to changes in the network (without any form > of congestion control, RTP continues to send oblivious to other > participants)**** > - It competes with itself in the average case (audio + video streams > from the same sender, multiple video streams for multi party conferenc= ing) > **** > - It is time sensitive (as in real time media needs to be played back > without prior to changes in human perception)**** > - It assumes that network behavior is unpredictable (existence of RTCP > + use of things like adaptive jitter buffers)**** > > Let's say we agree on all of these behaviors. It is safe to assume then > that competing with RTP is a superset of behaviors then it is to compete > with TCP, LEDBAT, or a web browser alone is it not?**** > > ** ** > > Thanks,**** > > Dan**** > > **** > --047d7bd74a227743d404d9170207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bill,

The prisoner's dilemma is a good example if= you want to use the court of public opinion as a moral compass. =C2=A0My s= uggestion is to have merely give RTP a conscience for its own behavior and = not others. =C2=A0It seeks to treat itself and others by its own standards.= =C2=A0In a world where land is plentiful, water flows cleanly, and sunligh= t is abundant, enough food can be grown to support everyone's needs. = =C2=A0When battling plague or handling severe drought, everyone needs the b= are minimum for survival. =C2=A0 If that bare minimum can not be attained w= hile seeking to apply each's own general principles first, than that ma= n shall perish by the survival of the fittest. =C2=A0

We have to run on the assumption that everyone will pla= y fair and reasonably, otherwise, we run the risk of a never ending game. = =C2=A0The US court system exists to implement fairness understands these pr= oblems and has settled on the premise that everyone acts in good faith unle= ss proven otherwise.

Thanks,
Dan

On Fri, Mar 29, 2013 at 3:08 PM, Bill Ver Steeg (versteb) <versteb= @cisco.com> wrote:

At the risk of starting a= philosophical debate, I think we should consider some lessons from game th= eory.

=C2=A0

The =E2=80=9CPrisoner=E2= =80=99s Dilemma=E2=80=9D comes to mind. If an application senses that the p= rograms that it is sharing a link with are =E2=80=9Cfair=E2=80=9D (where fa= ir boils down to =E2=80=9Cgive me a reasonable amount of BW and do not excessively delay my traffic=E2=80= =9D), the logical thing to is to also be fair. When an application senses t= hat another program is taking up all of the available link BW and/or causin= g delay for its data, that program would be foolish to allow the more aggressive competitor to seize all of the lin= k BW. It would, in turn, be aggressive in its behavior. There are a few sol= utions to this problem, and I encourage the group to look into this a bit. = The winning game theory strategies boil down to variations on =E2=80=9Ctit for tat=E2=80=9D, in which partici= pant starts out being cooperative, but becomes uncooperative when peers are= seen to be uncooperative.

=C2=A0

The =E2=80=9Ctragedy of t= he commons=E2=80=9D is a similar example.

=C2=A0

In a perfect world, the n= etwork would have a way to influence application behaviors towards the desi= red behavior. Misbehaving applications would suffer from the delay penalty, but well behaved applications would not. =

=C2=A0

There are some theoretica= l solutions that fit the bill. For instance, the middlebox could segregate = the traffic into a (set of) sub-queue(s) on a per QOS bucket basis. Theses sub queues would be designed such that =C2=A0cooperative app= lications competed with other cooperative applications in a (set of) sub qu= eue(s) and aggressive/misbehaving applications competed with other similar = traffic. So, if you tend to respond to congestion signals, you will be in a (set of) sub-queue(s) with good delay= characteristics and will get your =E2=80=9Cfair=E2=80=9D share. If you ten= d to not respond to congestion signals, you will be in a (set of) sub-queue= (s) with poor delay characteristics and the network will bias the BW towards the well behaved queue(s).

=C2=A0

Unfortunately, this behav= ior is easier to visualize than to implement. It is fraught with corner cas= es, lots of state and tough decisions. I return you to =C2=A0the networking discussions=E2=80=A6=E2=80=A6..

=C2=A0

=C2=A0

Bvs<= /p>

=C2=A0

=C2=A0

From: rmcat-bounces@ietf.org= [mailto:rm= cat-bounces@ietf.org] On Behalf Of Dan Weber
Sent: Friday, March 29, 2013 4:33 PM
To: rmcat@ietf.o= rg
Subject: [rmcat] The Definition of Fairness

=

=C2=A0

As we all are aware, defining fairness presents chal= lenges. =C2=A0Michael Ramhalko gives the best metaphor for describing it we= know today, "I know it when I see it".

=C2=A0

To even more elaborate on his point, we can't sa= y what is fair by seeing it, we can only identify what is unfair. =C2=A0Whe= n is something unfair? =C2=A0Two situations come to mind.

=C2=A0

"That's not fair!" =C2=A0These are the= infamous words children say everyday when they don't get their way. = =C2=A0Often times it could be some toy that is in use, or maybe someone get= s preferential treatment. =C2=A0The child "harmed'"=C2=A0is limited from participating in the sa= me way as the other. =C2=A0A similar case could be waiting on a list at a b= usy restaurant. If you've been waiting on the list for an hour, and som= eone walks in the door only to know the host personally and jump ahead to the next available table.

=C2=A0

Based on these examples, defining unfairness= =C2=A0might be "when a participant seeks out its own self interest at = the expense of everyone else". =C2=A0Because when that man cuts you in= line, he probably does so without acknowledging your existence. =C2=A0Merely assuming there are other participants can allow one to adjust= for their presence whether or not if their existence is clear. =C2=A0

=C2=A0

Then, the antonym of my unfairness definition or the= fairness definition is the golden rule: "Treat others as you wish to = be treated" =C2=A0If the man who cut in line then was subject to his o= wn behavior elsewhere, he may become upset with it as well and change his own behavior. =C2=A0This is one of the major issues= with bittorrent. =C2=A0Since bittorrent is so aggressive, everyone else fi= nds themselves in positions trying to protect their own applications from i= ts behavior, including competing bittorrents.

=C2=A0

In light of this, we come to the question, "Is = seeking RTP fairness with itself enough?" =C2=A0I say yes.

=C2=A0

RTP in its current form exhibits the following behav= iors:

  • It can be be short lived (short video clip)
  • It can be long lived (long telephone calls)
  • It can be bursty (i-frames go across the network)
  • It can be constant rate (constant bit rate audio codecs like mulaw)<= u>
  • It can be variable rate (video streams in general=C2=A0targeting=C2=A0consi= stent quality with changes in motion or picture)
  • It can be used in ways to maximize throughput (e.g. streaming movies at the= highest quality a client can receive acceptably -- Hulu or equivalent)<= /u>
  • It can be unresponsive to changes in the network (without any form of conge= stion control, RTP continues to send oblivious to other participants)
  • It competes with itself in the average case (audio + video streams from the= same sender, multiple video streams for multi party conferencing)
  • It is time sensitive (as in real time media needs to be played back without= prior to changes in human perception)
  • It assumes that network behavior is unpredictable (existence of RTCP + use = of things like adaptive jitter buffers)

Let's say we agree on all of these behaviors. = =C2=A0It is safe to assume then that competing with RTP is a superset of be= haviors then it is to compete with TCP, LEDBAT, or a web browser alone is i= t not?

=C2=A0

Thanks,

Dan

=C2=A0


--047d7bd74a227743d404d9170207--