From nobody Mon Feb 9 05:37:00 2015 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26CA1A00BB for ; Mon, 9 Feb 2015 05:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7LHq_f_7cHj for ; Mon, 9 Feb 2015 05:36:55 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7271A0018 for ; Mon, 9 Feb 2015 05:36:54 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id k48so5933656wev.3 for ; Mon, 09 Feb 2015 05:36:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=RznaUi/69fhf8AWsBygvhc9+rfFaeT7mUq6R/IIbbcs=; b=l7Vhf7PpsyKtFSwfup5ksbRJVzHa4eBJ9sQjocw53i9gnVbpuuCGNPVUvl6aU4fY/G ZWNzBLHQGZivIDUR6J/EfHUhcmus3zN5KLPTxGgVEuqMfXns0n0qwUq7JY+F+TybKWhd Khk/RQAb5tTZO66CzHHKfAEXDUkk3qOAi8+N8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc:content-type; bh=RznaUi/69fhf8AWsBygvhc9+rfFaeT7mUq6R/IIbbcs=; b=lH2fBNEbQsGtDyVLmiwx7KGBztioRMcqxAiWNaCLTn68rfuHeHmpxUVCHLttvqbRem OORaY6S+5UgMvg3wx9n1X+rghtHYJ1cmdZafse3QitF3ZBTYuioIUxBiIbxXRgngcvt8 iAbdbqSBsrYY4mi916K1xzuwQxOM+6uLSpmyWsnOHSes/HedR9Ac6Bb4vKAFzmYCIG2w /D5T2MYA3Z4flZ4p2K1PhOz9ADVZOeiYbW3U2a23mGnqRwPmhEpVzbQLeBvxC4is7GRS 6t64lU2y3B6QYjvb2RvZDW0aUbolbsiUQW/v5XLJdUdvFwbLdA4/1KOue937FRaJZLOU yt3w== X-Gm-Message-State: ALoCoQntlkgUoNDqURrJO7/xIGHOEczOIQCcXHstCjMcjHewBwgPC/GCOnH8F/s0QAxqkVXxVn/U4QzVdHwryYSbw2yrmD4CJmIIWRgR8NrST8qKRDK32zk= X-Received: by 10.180.89.210 with SMTP id bq18mr35633249wib.45.1423489013629; Mon, 09 Feb 2015 05:36:53 -0800 (PST) From: Karen Elisabeth Egede Nielsen MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBEbXbah9G2ZjxsQbuA5mk0hSePmA== Date: Mon, 9 Feb 2015 14:36:53 +0100 Message-ID: <8606b1095e02d3c6b1c6429171cfd938@mail.gmail.com> To: rmcat WG Content-Type: multipart/alternative; boundary=e89a8f3ba5e3ffd9fb050ea7dce1 X-DomainID: tieto.com Archived-At: Cc: rmcat-chairs@tools.ietf.org Subject: Re: [rmcat] IETF91 RMCAT Interim ? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 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, 09 Feb 2015 13:36:57 -0000 --e89a8f3ba5e3ffd9fb050ea7dce1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi , This is send to re-solicit your input for whether you would consider an RMCAT interim at Dallas as time well spend. Please let us what you think and which new information on RMCAT topics you possibly could provide for discussion at the meeting. MANY THANKS ! Karen RMCAT INTERIM: ----------------------- We propose to have an Interim meeting Sunday morning March 22 in Dallas =E2= =80=93 scheduled for some hours somewhere in between 9 AM =E2=80=93 1 PM. The suggested purpose of the meeting would be (again) to work on and discuss the solution candidates =E2=80=93 here: =C2=B7 updates of the solutions significant for evaluations =C2=B7 new evaluations Potentially, depending on how the situation is at this point in time (i.e., this work may have concluded already before): =C2=B7 discussion/work on the common framework elements, common interfaces to framework and/or application elements The aim/plan is still to call for wg-adopt of NADA and SCREAM at the RMCAT session. The Interim is not a prerequisite for this to happen. Juts to be clear. It is intended for the meeting to be a working meeting supporting progress of the work. *We solicit for people working with other solution candidates to bring their solutions and evaluations forward. In which case this * *Interim meeting would be the perfect place for detailed discussions ! **J* *PLEASE LET US KNOW if you think this meeting is a good idea/of value and also please let us know if you intend to participate. * *Audio will be sought to arranged as the last time, but f2f participation is widely preferable.* FURTHER we are of course open for suggestions for other RMCAT wg items which it would be relevant to work with/discuss in detail at the Interim. Chairs/Karen --e89a8f3ba5e3ffd9fb050ea7dce1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi ,

=C2=A0=

This is sen= d to re-solicit your input for whether you would consider an RMCAT interim = at Dallas as time well spend.

=C2=A0

Please let us what you think and which new information on RMC= AT topics you possibly could provide for discussion at the meeting.<= /p>

=C2=A0

MANY THANKS !

=

=C2=A0

Karen

=C2=A0

=C2=A0

=C2=A0

RMCAT INTERIM:

-----------------------

<= p class=3D"MsoNormal">=C2=A0

We propose to have a= n Interim meeting Sunday morning March 22 in Dallas =E2=80=93 scheduled for= some hours somewhere in between 9 AM =E2=80=93 1 PM.

=C2=A0

The suggested purpose of the meeting = would be (again) to work on and discuss the solution candidates =E2=80=93 h= ere:

=C2=B7=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 new evaluations

Potentially, depending on how the situation is at this point in t= ime (i.e., this work may have concluded already before):

=C2=B7<= span style=3D"font:7.0pt "Times New Roman"">=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 discussion/work on the com= mon framework elements, common interfaces to framework and/or application e= lements

=C2=A0

The aim/= plan is still to call for wg-adopt of NADA and SCREAM at the RMCAT session.= The Interim is not a prerequisite for this to happen.

Juts to be clear.

=C2=A0

It is intended for the meeting to be a working meeting supporting p= rogress of the work.

=C2=A0

We solicit for people working with other solution candidates to bri= ng their solutions and evaluations forward. In which case this

Interim meeting would be the perfect place for detail= ed discussions ! J<= /p>

=C2=A0

PLEASE= LET US KNOW if you think this meeting is a good idea/of value and also ple= ase let us know if you intend to participate.

Audio will be sought to =C2=A0arranged as the last time, but f2f parti= cipation is widely preferable.

=C2=A0

FURTHER we are of course open for suggestions for other = RMCAT wg items which it would be relevant to work with/discuss in detail at= the Interim.

=C2=A0

Ch= airs/Karen

=C2=A0

=C2= =A0

--e89a8f3ba5e3ffd9fb050ea7dce1-- From nobody Tue Feb 10 14:41:30 2015 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E591A1AC3 for ; Tue, 10 Feb 2015 14:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f8f7IcKckiK for ; Tue, 10 Feb 2015 14:41:14 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446831A0126 for ; Tue, 10 Feb 2015 14:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16080; q=dns/txt; s=iport; t=1423608074; x=1424817674; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4Zo63XU8+v/SJio2gugHmZgXQHYxDSfhp4fJgAfet3M=; b=Va3rjs7bO1xXtJzB+RuTTuNWWgyvHKFgX3shHI9C4uXovGDbAKSIA3Wm Re17vf+4lYpTj4VisC+RIf3mb2x1H4ip+VrU+HaNbCP2mqGqrTzJ1j5PJ HX/bDBDdm8DIrIYiyN7UF/6hi9IeKyRl9SOXoA1r+zDU28qB9GIYwNGEL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAFAFCI2lStJV2R/2dsb2JhbABbgkNDUloEwxKFcQKBH0MBAQEBAQF8hAwBAQEEHVwQAgEIEQMBAigHMhQJCAEBBAENBRuIEg3QegEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj2YNBAYBhCoFhVKHaYFlg1GFXYEYgwOIGoMDgz4ig25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,553,1418083200"; d="scan'208,217";a="395144554" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 10 Feb 2015 22:41:14 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t1AMfDhL018062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Feb 2015 22:41:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.159]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Tue, 10 Feb 2015 16:41:12 -0600 From: "Xiaoqing Zhu (xiaoqzhu)" To: Karen Elisabeth Egede Nielsen , rmcat WG Thread-Topic: [rmcat] IETF91 RMCAT Interim ? Thread-Index: AdBEbXbah9G2ZjxsQbuA5mk0hSePmABFTQaA Date: Tue, 10 Feb 2015 22:41:12 +0000 Message-ID: References: <8606b1095e02d3c6b1c6429171cfd938@mail.gmail.com> In-Reply-To: <8606b1095e02d3c6b1c6429171cfd938@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.152.12.219] Content-Type: multipart/alternative; boundary="_000_D0FFE3CF10EF9xiaoqzhuciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rmcat-chairs@tools.ietf.org" Subject: Re: [rmcat] IETF91 RMCAT Interim ? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2015 22:41:22 -0000 --_000_D0FFE3CF10EF9xiaoqzhuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Karen, >From our side (NADA draft contributors) we found the last Interim very help= ful, and we are looking forward to the upcoming interim at Dallas. Our plan is to: a) provide an update on our solution (mainly in explaining how we handle no= ise and outliers and delay measurements); and b) present both simulation and testbed evaluation results for the updated s= olution in various RMCAT test cases according to draft https://tools.ietf.o= rg/html/draft-ietf-rmcat-eval-test-00 c ) if time permits we will also be happy to share some evaluation results = on how NADA interacts with various AQM schemes (e.g., RED, PIE and CoDel) I=92ll make sure that I update the draft several weeks before the Dallas me= eting so people have plenty of time to review it. Thanks, Xiaoqing From: Karen Elisabeth Egede Nielsen > Date: Monday, February 9, 2015 at 7:36 AM To: rmcat WG > Cc: "rmcat-chairs@tools.ietf.org" > Subject: Re: [rmcat] IETF91 RMCAT Interim ? Hi , This is send to re-solicit your input for whether you would consider an RMC= AT interim at Dallas as time well spend. Please let us what you think and which new information on RMCAT topics you = possibly could provide for discussion at the meeting. MANY THANKS ! Karen RMCAT INTERIM: ----------------------- We propose to have an Interim meeting Sunday morning March 22 in Dallas =96= scheduled for some hours somewhere in between 9 AM =96 1 PM. The suggested purpose of the meeting would be (again) to work on and discus= s the solution candidates =96 here: =B7 updates of the solutions significant for evaluations =B7 new evaluations Potentially, depending on how the situation is at this point in time (i.e.,= this work may have concluded already before): =B7 discussion/work on the common framework elements, common interf= aces to framework and/or application elements The aim/plan is still to call for wg-adopt of NADA and SCREAM at the RMCAT = session. The Interim is not a prerequisite for this to happen. Juts to be clear. It is intended for the meeting to be a working meeting supporting progress = of the work. We solicit for people working with other solution candidates to bring their= solutions and evaluations forward. In which case this Interim meeting would be the perfect place for detailed discussions ! :) PLEASE LET US KNOW if you think this meeting is a good idea/of value and al= so please let us know if you intend to participate. Audio will be sought to arranged as the last time, but f2f participation i= s widely preferable. FURTHER we are of course open for suggestions for other RMCAT wg items whic= h it would be relevant to work with/discuss in detail at the Interim. Chairs/Karen --_000_D0FFE3CF10EF9xiaoqzhuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Karen, 

From our side (NADA draft contributors) we found the last Interim very= helpful, and we are looking forward to the upcoming interim at Dallas.&nbs= p;

Our plan is to: 
a) provide an update on our solution (mainly in explaining how we hand= le noise and outliers and delay measurements); and 
b) present both simulation and testbed evaluation results for the upda= ted solution in various RMCAT test cases according to draft https://tools.i= etf.org/html/draft-ietf-rmcat-eval-test-00 
c ) if time permits we will also be happy to share some evaluation res= ults on how NADA interacts with various AQM schemes (e.g., RED, PIE and CoD= el)

I=92ll make sure that I update the draft several weeks before the Dall= as meeting so people have plenty of time to review it. 

Thanks,
Xiaoqing


From: Karen Elisabeth Egede Nielsen= <karen.nielsen@tieto.com= >
Date: Monday, February 9, 2015 at 7= :36 AM
To: rmcat WG <rmcat@ietf.org>
Cc: "rmcat-chairs@tools.ietf.org" <rmcat-chairs@tools.ietf.org>
Subject: Re: [rmcat] IETF91 RMCAT I= nterim ?

Hi ,

 

This is send to re-sol= icit your input for whether you would consider an RMCAT interim at Dallas a= s time well spend.

 

Please let us what you= think and which new information on RMCAT topics you possibly could provide= for discussion at the meeting.

 

MANY THANKS !

 

Karen

 

 

 

RMCAT INTERIM:

-----------------------

 

We propose to have an Interim meeting Sunday morning= March 22 in Dallas =96 scheduled for some hours somewhere in between 9 AM = =96 1 PM.

 

The suggested purpose of the meeting would be (again= ) to work on and discuss the solution candidates =96 here:

= =B7         updates of the solutions significant for evaluations <= /p>

= =B7         new evaluations

Potentially, depending on how the situation is at th= is point in time (i.e., this work may have concluded already before):

= =B7         discussion/work on the common framework elements, comm= on interfaces to framework and/or application elements

 

The aim/plan is still to call for wg-adopt of NADA a= nd SCREAM at the RMCAT session. The Interim is not a prerequisite for this = to happen.

Juts to be clear.

 

It is intended for the meeting to be a working meeti= ng supporting progress of the work.

 

We solicit for people working with other solution= candidates to bring their solutions and evaluations forward. In which case= this

Interim meeting would be the perfect place for de= tailed discussions ! J

 

PLEASE LET US KNOW if you think this meeting is a= good idea/of value and also please let us know if you intend to participat= e.

Audio will be sought to  arranged as the las= t time, but f2f participation is widely preferable.

 

FURTHER we are of course open for suggestions for ot= her RMCAT wg items which it would be relevant to work with/discuss in detai= l at the Interim.

 

Chairs/Karen

 

 

 --_000_D0FFE3CF10EF9xiaoqzhuciscocom_-- From nobody Mon Feb 23 05:39:24 2015 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241681A1B92 for ; Mon, 23 Feb 2015 05:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBCpa4shMZgk for ; Mon, 23 Feb 2015 05:39:20 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400061A1B8F for ; Mon, 23 Feb 2015 05:39:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 15495D930E for ; Mon, 23 Feb 2015 14:39:18 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aW6vnk2aHoNV for ; Mon, 23 Feb 2015 14:39:17 +0100 (MET) Received: from mirjas-air.fritz.box (stgt-5f7018df.pool.mediaWays.net [95.112.24.223]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BC552D930C for ; Mon, 23 Feb 2015 14:39:17 +0100 (MET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <6D836A36-61D0-4876-B533-B1593E0B33F6@tik.ee.ethz.ch> Date: Mon, 23 Feb 2015 14:39:16 +0100 To: "rmcat WG (rmcat@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [rmcat] Please send agenda requests! X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 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, 23 Feb 2015 13:39:23 -0000 Hi all, the rmcat session is scheduled for Thursday, March 26, 0900-1130 CDT (Thursday Morning Session I). Please send requests for agenda items now! Karen & Mirja From nobody Mon Feb 23 23:42:24 2015 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A625D1A8709 for ; Mon, 23 Feb 2015 23:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAE1unMND1su for ; Mon, 23 Feb 2015 23:42:21 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AE71A870B for ; Mon, 23 Feb 2015 23:42:20 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-1b-54ec2b594e61 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AD.1F.04231.95B2CE45; Tue, 24 Feb 2015 08:42:18 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.163]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Tue, 24 Feb 2015 08:42:17 +0100 From: Ingemar Johansson S To: =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: SCReAM feedback rate (was RE: Feedback format for SCReAM) Thread-Index: AdBQAWxmnGK6oN6zQBmDpKOSgQkAYQ== Date: Tue, 24 Feb 2015 07:42:17 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA320A20C3@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+JvjW6U9psQgzOfuS2WvzzBaHGodSaL xYvXPSwWG1ZPYbFYffMDmwOrx7T799k8liz5yeQx49MXNo9Dz4M8jn34yhbAGsVlk5Kak1mW WqRvl8CVMWePb8EVg4onuycxNjD2qHcxcnJICJhIfGlZzgJhi0lcuLeerYuRi0NI4AijxNdp 3awQzhJGiedf5zGBVLEJ2EisPPSdEcQWEfCQuNR3kBmkiFlgE5NE18Ub7F2MHBzCAk4Sh36X gJgiAu4S66eWQ5TrSbQ2zgIbwyKgKjGn+RyYzSvgK7Fy0QOwIxgFZCXuf78HZjMLiEvcejKf CeI4AYkle84zQ9iiEi8f/2OFsBUlPr7axwhRrydxY+oUNghbW2LZwtfMEPMFJU7OfMIygVFk FpKxs5C0zELSMgtJywJGllWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgXF0cMtv3R2Mq187 HmIU4GBU4uEtUHwTIsSaWFZcmXuIUZqDRUmc1874UIiQQHpiSWp2ampBalF8UWlOavEhRiYO TqkGxhiN+77fMx6uuXdVl2/mxTOdR3xrWt9qn5rxs7jhs12Zzv5Pj/lOSLctYP1wl4vvxdNM ncMdgfr/Nb8Y3Py70vTTNvcV2wL7Ml+qJu6Ivjj71e2Y76XF0vfD18a4Ke3I69nCzf/vm9mN cCmu4NgIySnbQ1ar/+rpuR2+hImv9YmTqMOsNzGT3ymxFGckGmoxFxUnAgDwWL7ChAIAAA== Archived-At: Cc: Magnus Westerlund , "Karen E. E. Nielsen" , Ingemar Johansson S , "rmcat WG \(rmcat@ietf.org\)" , "Eggert, Lars \(lars@netapp.com\)" , "csp@csperkins.org" Subject: [rmcat] SCReAM feedback rate (was RE: Feedback format for SCReAM) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2015 07:42:23 -0000 Hi Mirja Added the RMCAT list to this thread. The relatively high feedback rate in SCReAM is not really of importance for= the congestion window growth, for that to work it is likely sufficient wit= h one feedback per RTT as you say.=20 The issue is with the ACK clocking in SCReAM, a low feedback rate will ackn= owledge many packets but as the transmission scheduling cannot transmit mor= e than the available send window. I low feedback will thus make packets pil= e up in the RTP queue until the feedback is received and as the video rate = control monitors the size of the RTP queue the effect is that the video bit= rate is reduced. This has made SCReAM vulnerable to reverse path congestion= before, the algorithm is not that vulnerable today as the video target bit= rate is calculated differently (see section 4.1.3 " maximum value of rate_t= ransmit and rate_acked "). If low feedback rate is necessary, one idea would be to predict how many by= tes that will be ACKed but that would risk make reaction to congestion wors= e.=20 With that said. A high feedback rate is most important at high bitrates. S= ome experimentation shows that at 10Mbps it is necessary with a feedback in= terval of 20-30m in order to sustain the high thorughput. While at 100kbps = (think audio) a feedback interval of 200ms will work. This would give an RTCP overhead of ~0.5% at 10Mbps and ~2-3% at 100kbps, a= ssuming 50byte RTCP (Reduced Size) /Ingemar -----Original Message----- From: Mirja K=FChlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]=20 Sent: den 23 februari 2015 17:12 To: Ingemar Johansson S Cc: Magnus Westerlund; Karen E. E. Nielsen; Eggert, Lars (lars@netapp.com);= csp@csperkins.org Subject: Re: Feedback format for SCReAM Hi Ingemar, okay, get the argument about the overhead. Still the question if it's reall= y worth it to have an other report format here. However, that's on the RTP/= WebRTC guys to decide. The other question is, how often is the feedback really needed. That questi= on really depends on your algorithm design. If you have a packet based send= ing window and increase by at max one packet per RTT, in fact you only need= on feedback report per RTT (expect of redundancy in case of loss; but in t= his case it might potentially even make sense to request a higher rate some= how dynamically.). So what would be the minimum feedback frequency you'd need? Mirja > Am 23.02.2015 um 15:57 schrieb Ingemar Johansson S : >=20 > Hi >=20 > The receive timestamp is for the highest received sequence number. On the= sender side this is compared against the wallclock timestamp when said RTP= packet was transmitted, this makes it possible to compute the one way dela= y. It is not necessary to ACK every RTP packet for a good estimate of the O= WD, a too sparse feedback can however reduce the max throughput for higher = bitrate video as the ACK-clocking becomes less efficient (at 10Mbps it is n= ecessary with a feedback roughly every 20-30ms). >=20 > PT in feedback : My though was that it is necessary to discriminate the f= eedback based on the {SSRC,PT} tuple, this because two PTs may have differe= nt sequence number space, but if that is not the case then I am happy to re= move the PT from the feedback. >=20 > Regarding a reusing or extending RTCP XR, my only concern is that the=20 > feedback is sufficiently slim to support the relatively high feedback=20 > rate at high video bitrates without necessitating a very high RTCP BW,=20 > of course reduced size RTCP helps a bit here >=20 > /Ingemar >=20 >=20 >=20 > -----Original Message----- > From: Magnus Westerlund > Sent: den 23 februari 2015 15:41 > To: Mirja K=FChlewind; Ingemar Johansson S > Cc: Karen E. E. Nielsen; Eggert, Lars (lars@netapp.com);=20 > csp@csperkins.org > Subject: Re: Feedback format for SCReAM >=20 > On 2015-02-23 15:11, Mirja K=FChlewind wrote: >> Hi, >>=20 >> see below. >>=20 >>=20 >>> Am 23.02.2015 um 12:45 schrieb Ingemar Johansson S : >>>=20 >>> Hi >>>=20 >>> OK, good that you agree on the ACK vector Yes, one could use RFC6679=20 >>> ECN feedback report format as it contains a lost packets counter. >>> The missing elements are >>> + RTP PT (8bit) >>> + Receive timestamp (32bit) >>=20 >> Okay, one potentially stupid question because I'm not an RTCP >> expert: > Wouldn't it be sufficient to simply define another extended report with t= hese information? >=20 > Yes, that is reasonably straight forward. The PT we may not need. The que= stion is which Receive timestamp do you need? Just for the latest received = packet? >=20 > One possibility is to use the RTCP XR formats Packet Receipt Times Report= Block, which is defined in Section 4.3 of RFC 3611. I think one could pote= ntially use this with just a single sequence number. >=20 > But, if more efficient packing is needed for Scream, defining a new forma= t is relatively easy. >=20 >>=20 >>> The RTP PT is needed for the cases where a session runs the same=20 >>> SSRC but multiplex media over two different PT. >>=20 >> Is this really the way this is used? And do you need to split this up=20 >> to perform congestion control separately for the two PTs.? Is this=20 >> the right way to do this? >=20 > No, it is not. I haven't discussed this with Ingemar. But one SSRC is one= media source, or at least packet source (in case of Retransmission or laye= red codecs). The PT really only indicates how the packet was encoded, it sh= all not be necessary to use to do flow separation. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Wed Feb 25 11:48:17 2015 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D0F1A1BCC; Wed, 25 Feb 2015 11:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzg_muJ-DY5q; Wed, 25 Feb 2015 11:48:12 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A401A870C; Wed, 25 Feb 2015 11:48:11 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTP id 8E972F23A1; Wed, 25 Feb 2015 11:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.corp.phx1.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVQcihBm4HCg; Wed, 25 Feb 2015 11:48:10 -0800 (PST) Received: from [10.252.26.110] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 64110F2181; Wed, 25 Feb 2015 11:48:10 -0800 (PST) Message-ID: <54EE26FA.4060009@mozilla.com> Date: Wed, 25 Feb 2015 11:48:10 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "rtcweb@ietf.org" , "rmcat@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------000702040600000706080702" Archived-At: Subject: [rmcat] Fwd: [video-codec] Come hack on Daala @ IETF 92 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2015 19:48:16 -0000 This is a multi-part message in MIME format. --------------000702040600000706080702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Distributing more broadly on Charles's suggestion. -------- Forwarded Message -------- Subject: [video-codec] Come hack on Daala @ IETF 92 Date: Wed, 25 Feb 2015 12:38:00 -0700 From: Jack Moffitt To: video-codec@ietf.org , daala@xiph.org Charles Eckel has organized an IETF hackathon the weekend before IETF. Daala is one of the groups participating and we'd love to have some others come hack with us on video codecs. There are Daala projects appropriate for many skills levels, and several of the Daala team will be there to mentor people who need some. Be sure to register early as there are only so many spots available. Here are the details from Charles: The Internet Engineering Task Force (IETF) is holding a Hackathon to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. It takes place just before IETF 92, and it¹s free and open to everyone. All you need is a knowledge of networking technologies, and you¹ll be guaranteed to learn something new and have fun! Event details: https://developer.cisco.com/site/ietf-hackathon Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html --------------000702040600000706080702 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec --------------000702040600000706080702--