From lars.eggert@nokia.com Mon Oct 5 04:24:35 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DEE93A69C1 for ; Mon, 5 Oct 2009 04:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTtKVOJASU2q for ; Mon, 5 Oct 2009 04:24:35 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id A5DE23A69BD for ; Mon, 5 Oct 2009 04:24:34 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n95BQ1EJ023556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Oct 2009 14:26:01 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Lars Eggert In-Reply-To: <03520536067DF14395EA93FE7ECFDCF0045A3FE7@TK5EX14MBXC130.redmond.corp.microsoft.com> Date: Mon, 5 Oct 2009 14:26:00 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <03520536067DF14395EA93FE7ECFDCF0045A3FE7@TK5EX14MBXC130.redmond.corp.microsoft.com> To: Murari Sridharan X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Mon, 05 Oct 2009 14:26:01 +0300 (EEST) Cc: "ledbat@ietf.org" Subject: Re: [ledbat] LEDBAT Status 9/23/09 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 11:24:35 -0000 Hi, thanks for sending this, Murari. On 2009-9-23, at 16:02, Murari Sridharan wrote: > http://tools.ietf.org/html/draft-shulanov-ledbat-congestion > http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendations Authors, it'd be REALLY good if we could see updates to this documents soon. The WG can't really do much if the working documents aren't up- to-date. Thanks, Lars From rpenno@juniper.net Mon Oct 5 12:59:22 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E51128C280 for ; Mon, 5 Oct 2009 12:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v+btc9Tjjjp for ; Mon, 5 Oct 2009 12:59:21 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id F125028C231 for ; Mon, 5 Oct 2009 12:59:16 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSspQdOtwlxQvY3dVd5ES2D7pKOkpwK+r@postini.com; Mon, 05 Oct 2009 13:00:56 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 5 Oct 2009 12:57:18 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 5 Oct 2009 15:57:17 -0400 From: Reinaldo Penno To: Lars Eggert , Murari Sridharan Date: Mon, 5 Oct 2009 15:55:32 -0400 Thread-Topic: [ledbat] LEDBAT Status 9/23/09 Thread-Index: AcpFrqU2xyESGCJGQ5eXQNcELbXW6gARyc5n Message-ID: <998644D4818FC74AA6232DE1D35379779B5CB309E9@EMBX01-WF.jnpr.net> References: <03520536067DF14395EA93FE7ECFDCF0045A3FE7@TK5EX14MBXC130.redmond.corp.microsoft.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" Subject: Re: [ledbat] LEDBAT Status 9/23/09 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 19:59:22 -0000 We are actively working together on a new version of http://tools.ietf.org/= id/draft-penno-ledbat-app-practices-recommendations.=20 thanks, Reinaldo Penno Rich Woundy Vijay K. Gurbani ________________________________________ From: ledbat-bounces@ietf.org [ledbat-bounces@ietf.org] On Behalf Of Lars E= ggert [lars.eggert@nokia.com] Sent: Monday, October 05, 2009 4:26 AM To: Murari Sridharan Cc: ledbat@ietf.org Subject: Re: [ledbat] LEDBAT Status 9/23/09 Hi, thanks for sending this, Murari. On 2009-9-23, at 16:02, Murari Sridharan wrote: > http://tools.ietf.org/html/draft-shulanov-ledbat-congestion > http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendations Authors, it'd be REALLY good if we could see updates to this documents soon. The WG can't really do much if the working documents aren't up- to-date. Thanks, Lars _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From muraris@microsoft.com Sun Oct 11 22:32:02 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB47A3A6899 for ; Sun, 11 Oct 2009 22:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxICEaO24u-D for ; Sun, 11 Oct 2009 22:32:02 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id DF6303A6873 for ; Sun, 11 Oct 2009 22:32:01 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 11 Oct 2009 22:32:01 -0700 Received: from TK5EX14MBXC130.redmond.corp.microsoft.com ([169.254.9.154]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Sun, 11 Oct 2009 22:32:01 -0700 From: Murari Sridharan To: "ledbat@ietf.org" Thread-Topic: LEDBAT Status 9/23/09 Thread-Index: Aco8TiVWEnYV7Ui9RRuNElww9MuKJwOrwpqC Date: Mon, 12 Oct 2009 05:31:02 +0000 Message-ID: <03520536067DF14395EA93FE7ECFDCF0045F9FA5@TK5EX14MBXC130.redmond.corp.microsoft.com> References: <03520536067DF14395EA93FE7ECFDCF0045A3FE7@TK5EX14MBXC130.redmond.corp.microsoft.com> In-Reply-To: <03520536067DF14395EA93FE7ECFDCF0045A3FE7@TK5EX14MBXC130.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_03520536067DF14395EA93FE7ECFDCF0045F9FA5TK5EX14MBXC130r_" MIME-Version: 1.0 Subject: Re: [ledbat] LEDBAT Status 9/23/09 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 05:32:02 -0000 --_000_03520536067DF14395EA93FE7ECFDCF0045F9FA5TK5EX14MBXC130r_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, we need to see updated documents soon. Its getting late and for the = meeting to be productive we need to get the updated documents reviewed. ________________________________ From: ledbat-bounces@ietf.org [ledbat-bounces@ietf.org] on behalf of Murari= Sridharan [muraris@microsoft.com] Sent: Wednesday, September 23, 2009 6:02 AM To: ledbat@ietf.org Subject: [ledbat] LEDBAT Status 9/23/09 We have two WG items and one that requires some new editors http://tools.ietf.org/html/draft-shulanov-ledbat-congestion ACTION: Several action items from the last meeting. Stas please update if = you have another document for the list to review. 1. Improve pverview of the congestion control and pseudo code 2. Explicitly talk about framing being out of scope 3. Experimental data/discussion for proving/disproving late comer=92s ad= vantage. Starvation or the lack of it 4. More discussion and data on fairness in the presence of multiple flow= s 5. Discussion on the choice of parameter values http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendations-0= 0.txt ACTION: Requires new editors, we had two volunteers (Rich and Vijay). Have = you guys picked this up, any updates here? http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendations-0= 0.txt Adopted as a WG item but I don=92t remember many reviews and discussion on = whether any related work needs to be added. Infact from the SFO meeting I r= emember that not many people had read the document, hope people have had a = chance to read it since. ACTION: Provide more reviews and reference suggestion to Michael. Thanks --_000_03520536067DF14395EA93FE7ECFDCF0045F9FA5TK5EX14MBXC130r_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Folks, we need to see updated documents soon. Its getting late and for= the meeting to be productive we need to get the updated documents reviewed= .
From: ledbat-bounces@ietf.org [ledbat-boun= ces@ietf.org] on behalf of Murari Sridharan [muraris@microsoft.com]
Sent: Wednesday, September 23, 2009 6:02 AM
To: ledbat@ietf.org
Subject: [ledbat] LEDBAT Status 9/23/09

We have two WG items and one that requires some new = editors

 

http://tools.ietf.org/html/draft-shulanov-l= edbat-congestion

 

ACTION: Several  action items from the last meeting. = Stas please update if you have another document for the list to review.

1.    Improve pverview of the congestion control and pseudo = code

2.    Explicitly talk about framing being out of scope

3.    Experimental data/discussion for proving/disproving la= te comer=92s advantage. Starvation or the lack of it

4.    More discussion and data on fairness in the presence o= f multiple flows

5.    Discussion on the choice of parameter values

 

http://tools.iet= f.org/id/draft-penno-ledbat-app-practices-recommendations-00.txt

ACTION: Requires new editors, we had two volunteers = (Rich and Vijay). Have you guys picked this up, any updates here?

 

http://tools.iet= f.org/id/draft-penno-ledbat-app-practices-recommendations-00.txt

Adopted as a WG item but I don=92t remember many rev= iews and discussion on whether any related work needs to be added. Infact f= rom the SFO meeting I remember that not many people had read the document, = hope people have had a chance to read it since.

ACTION: Provide more reviews and reference suggestio= n to Michael.

 

Thanks

 

 

 

--_000_03520536067DF14395EA93FE7ECFDCF0045F9FA5TK5EX14MBXC130r_-- From muraris@microsoft.com Tue Oct 13 09:03:57 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01B53A6814 for ; Tue, 13 Oct 2009 09:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.298 X-Spam-Level: X-Spam-Status: No, score=-9.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxfMnLsCXl04 for ; Tue, 13 Oct 2009 09:03:55 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 1B3423A6405 for ; Tue, 13 Oct 2009 09:03:55 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 13 Oct 2009 09:03:53 -0700 Received: from TK5EX14MBXC130.redmond.corp.microsoft.com ([169.254.9.154]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi; Tue, 13 Oct 2009 09:03:53 -0700 From: Murari Sridharan To: "ledbat@ietf.org" , "iccrg@cs.ucl.ac.uk" Thread-Topic: Ledbat presentation slots for Hiroshima Thread-Index: AcpMHsGKHZDjtXJvSlGbtgVfm8GZ+g== Date: Tue, 13 Oct 2009 16:03:51 +0000 Message-ID: <03520536067DF14395EA93FE7ECFDCF004602142@TK5EX14MBXC130.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_03520536067DF14395EA93FE7ECFDCF004602142TK5EX14MBXC130r_" MIME-Version: 1.0 Subject: [ledbat] Ledbat presentation slots for Hiroshima X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 16:03:57 -0000 --_000_03520536067DF14395EA93FE7ECFDCF004602142TK5EX14MBXC130r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We'll hopefully get the updated drafts soon. Meanwhile please send agenda r= equests. We know we will have two slots for each of the WG documents. Micha= el won't be making any updates to the LEDBAT survey document for Hiroshima. Other than the above I'd like to propose a few topics that I think will hel= p the WG immensely. I am cross-posting the invite to ICCRG folks as well. A= s we are working on finalizing a lower than best-effort transport that is b= ased on delay measurement there have been questions around experimental dat= a/discussion around proving/disproving late comer's advantage, whether flow= s can be starved, fairness in the presence of multiple flows etc. As with a= ll congestion control laws the one being discussed has a choice of paramete= r values to choose from. A lot of the work here is building on earlier work= on delay and loss based algorithms so it would be good to hear views form = others who have done this type of work in the past. I know there are folks = that have implementation experience with delay and loss based algorithms. M= ay be you have some interesting data to share that is relevant to the probl= em being discussed. You can look at the current proposal at http://tools.ie= tf.org/html/draft-shulanov-ledbat-congestion If you are interested, please send us details including title/topic, presen= ter name and requested time. Thanks Murari --_000_03520536067DF14395EA93FE7ECFDCF004602142TK5EX14MBXC130r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We’ll hopefully get the updated drafts soon. Meanwhile please send agenda requests. We know we will have two slots for e= ach of the WG documents. Michael won’t be making any updates to the LEDBA= T survey document for Hiroshima.

 

Other than the above I’d like to propose a fe= w topics that I think will help the WG immensely. I am cross-posting the invi= te to ICCRG folks as well. As we are working on finalizing a lower than best-effort transport that is based on delay measurement there have been questions around experimental data/discussion around proving/disproving lat= e comer’s advantage, whether flows can be starved, fairness in the pres= ence of multiple flows etc. As with all congestion control laws the one being discussed has a choice of parameter values to choose from. A lot of the wor= k here is building on earlier work on delay and loss based algorithms so it w= ould be good to hear views form others who have done this type of work in the pa= st. I know there are folks that have implementation experience with delay and los= s based algorithms. May be you have some interesting data to share that is relevant to the problem being discussed. You can look at the current propos= al at http://tools.ietf.org/html/draft-shulanov-ledbat-congesti= on

 

If you are interested, please send us details including title/topic, presenter name and requested time.

 

Thanks

Murari

 

--_000_03520536067DF14395EA93FE7ECFDCF004602142TK5EX14MBXC130r_-- From philip.eardley@bt.com Mon Oct 19 02:30:20 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A8028C101 for ; Mon, 19 Oct 2009 02:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeOm4NTjvKkj for ; Mon, 19 Oct 2009 02:30:15 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 4355C28C147 for ; Mon, 19 Oct 2009 02:30:15 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 10:30:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA509E.C6BD3CBF" Date: Mon, 19 Oct 2009 10:30:20 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363991@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Congestion Exposure (CONEX) Bof in Hiroshima thread-index: AcpQnfGYekowSDoPSBKmVe+l8UDcfAAACBygAAARuRA= From: To: X-OriginalArrivalTime: 19 Oct 2009 09:30:20.0864 (UTC) FILETIME=[C715F400:01CA509E] Cc: leslie@thinkingcat.com Subject: [ledbat] Congestion Exposure (CONEX) Bof in Hiroshima X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 09:30:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA509E.C6BD3CBF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An alert of the Congestion Exposure (CONEX) Bof in Hiroshima - currently scheduled for Tues 15.20 - 18.10.=20 Best wishes, Philip Eardley & Leslie Daigle (BoF Chairs) =20 Congestion Exposure (CONEX) (was re-ECN) =20 Description Congestion Exposure (ConEx) is a proposed new IETF activity to enable congestion to be exposed along the forwarding path of the Internet. By revealing expected congestion in the IP header of every packet, congestion exposure provides a generic network capability which allows greater freedom over how capacity is shared. Such information could be used for many purposes, including congestion policing, accountability and inter-domain SLAs. It may also open new approaches to QoS and traffic engineering. =20 The Internet is, in essence, about pooling resources. The ability to share capacity has been paramount to its success and has traditionally been managed through the voluntary use of TCP congestion control. However, TCP alone is unable to prevent bandwidth intensive applications, such as peer-to-peer or streaming video, from causing enough congestion to severely limit the user-experience of many other end-hosts. This has led ISPs to deploy ad-hoc solutions such as volume accounting, rate policing and deep packet inspection in an attempt to distribute capacity differently. The consequences of such practices are increasingly leading to calls for government regulations and stifling innovation at the transport and application layer (see for example, the problem statement I-D (ref below) and RFC5594). =20 We believe these problems stem from the lack of a network-layer system for accountability -- among all parties -- for sending traffic which causes congestion. We propose a metric where IP packets carry information about the expected rest-of-path congestion, so that any network node may estimate how much congestion it is likely to cause by forwarding traffic. A network operator can then count the volume of congestion about to be caused by an aggregate of traffic as easily as it can count the volume of bytes entering its network today. Once ISPs can see rest-of-path congestion, they can actively discourage users from causing large volumes of congestion, discourage other networks from allowing their users to cause congestion, and more meaningfully differentiate between the qualities of services offered from potential connectivity partners. Meanwhile end-hosts may be freed from rate restrictions where their traffic causes little congestion. =20 The purpose of the BoF is to explore the support for and viability of pursuing an IETF activity to define a basic protocol to expose the expected rest-of-path congestion in the IP header. Any such protocol should work with minimal changes to the existing network, in particular it should work with unmodified routers. There is already one existing proposal that builds on ECN to provide rest-of-path congestion information in every IP header and other proposals may come forward. =20 If supported, an eventual WG would focus on the development of that protocol as its main work item. Additional work items could include detailing the motivations for congestion exposure, a threat analysis of the subsequent protocol, providing feedback on experimental trials and describing deployment considerations. Importantly, the proposed WG would encourage experimentation but not deliberate on how congestion exposure should be used: our concern would be how flexibly the resulting protocol can support differing needs at run-time, rather than dictating a particular usage at design time. =20 Related Internet-Drafts include: =20 http://www.ietf.org/id/draft-moncaster-congestion-exposure-problem-01.tx t=20 http://www.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-08.txt=20 http://www.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-motivation-01.txt =20 Other useful reference material: =20 http://www.bobbriscoe.net/projects/refb/FairerFasterWP.pdf =20 =20 Mailing list for discussion:=20 re-ecn@ietf.org =20 =20 BoF Wiki:=20 http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN =20 ------_=_NextPart_001_01CA509E.C6BD3CBF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An alert of the Congestion Exposure (CONEX) Bof in = Hiroshima - currently scheduled for Tues 15.20 – 18.10.

Best wishes,

Philip Eardley & Leslie Daigle (BoF = Chairs)

 

Congestion Exposure (CONEX)

(was re-ECN)

 

Description

Congestion Exposure (ConEx) is a proposed new IETF activity to = enable congestion to be exposed along the forwarding path of the Internet. By revealing expected congestion in the IP header of every packet, = congestion exposure provides a generic network capability which allows greater = freedom over how capacity is shared. Such information could be used for many = purposes, including congestion policing, accountability and inter-domain SLAs. It = may also open new approaches to QoS and traffic = engineering.

 

The Internet is, in essence, about pooling resources. The = ability to share capacity has been paramount to its success and has traditionally = been managed through the voluntary use of TCP congestion control. However, = TCP alone is unable to prevent bandwidth intensive applications, such as = peer-to-peer or streaming video, from causing enough congestion to severely limit the user-experience of many other end-hosts. This has led ISPs to deploy = ad-hoc solutions such as volume accounting, rate policing and deep packet = inspection in an attempt to distribute capacity differently. The consequences of = such practices are increasingly leading to calls for government regulations = and stifling innovation at the transport and application layer (see for = example, the problem statement I-D (ref below) and RFC5594).

 

We believe these problems stem from the lack of a network-layer = system for accountability -- among all parties -- for sending traffic which = causes congestion. We propose a metric where IP packets carry information about = the expected rest-of-path congestion, so that any network node may estimate = how much congestion it is likely to cause by forwarding traffic. A network = operator can then count the volume of congestion about to be caused by an = aggregate of traffic as easily as it can count the volume of bytes entering its = network today. Once ISPs can see rest-of-path congestion, they can actively = discourage users from causing large volumes of congestion, discourage other = networks from allowing their users to cause congestion, and more meaningfully = differentiate between the qualities of services offered from potential connectivity = partners. Meanwhile end-hosts may be freed from rate restrictions where their = traffic causes little congestion.

 

The purpose of the BoF is to explore the support for and = viability of pursuing an IETF activity to define a basic protocol to expose the = expected rest-of-path congestion in the IP header. Any such protocol should work = with minimal changes to the existing network, in particular it should work = with unmodified routers. There is already one existing proposal that builds = on ECN to provide rest-of-path congestion information in every IP header and = other proposals may come forward.

 

If supported, an eventual WG would focus on the development of = that protocol as its main work item. Additional work items could include = detailing the motivations for congestion exposure, a threat analysis of the = subsequent protocol, providing feedback on experimental trials and describing = deployment considerations. Importantly, the proposed WG would encourage = experimentation but not deliberate on how congestion exposure should be used: our = concern would be how flexibly the resulting protocol can support differing needs at = run-time, rather than dictating a particular usage at design = time.

 

Related Internet-Drafts include: 

http://www.ietf.org/id/draft-moncaster-congestion-exposure-prob= lem-01.txt

htt= p://www.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-08.txt

http://www.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-motivation-= 01.txt  

 

Other useful reference material: 

http:= //www.bobbriscoe.net/projects/refb/FairerFasterWP.pdf  

 

Mailing list for discussion:

re-ecn@ietf.org =   

 

BoF Wiki:

http://trac= .tools.ietf.org/area/tsv/trac/wiki/re-ECN    

=00 ------_=_NextPart_001_01CA509E.C6BD3CBF-- From shalunov@bittorrent.com Tue Oct 20 02:55:38 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75BA13A67F8 for ; Tue, 20 Oct 2009 02:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qh4SRO6WQLQ for ; Tue, 20 Oct 2009 02:55:37 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 32FBD3A67E1 for ; Tue, 20 Oct 2009 02:55:34 -0700 (PDT) Received: by ewy10 with SMTP id 10so5046175ewy.9 for ; Tue, 20 Oct 2009 02:55:39 -0700 (PDT) Received: by 10.216.87.147 with SMTP id y19mr2086246wee.12.1256032538468; Tue, 20 Oct 2009 02:55:38 -0700 (PDT) Received: from ?192.168.1.105? (c-67-188-254-19.hsd1.ca.comcast.net [67.188.254.19]) by mx.google.com with ESMTPS id g9sm6995028gvc.10.2009.10.20.02.55.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Oct 2009 02:55:37 -0700 (PDT) Message-Id: <92895699-AF3B-4741-AC54-93A3271D67E1@bittorrent.com> From: Stanislav Shalunov To: ledbat@ietf.org In-Reply-To: <20091016183043.3A42C3A685A@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Oct 2009 02:55:33 -0700 References: <20091016183043.3A42C3A685A@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [ledbat] LEDBAT session at IETF 76 will be on Friday 9am X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 09:55:38 -0000 The LEDBAT session has been scheduled by the secretariat on Friday 9am. Please make a note of this when planning your travel. See you in Hiroshima. We recognize that the Friday time can be somewhat unexpected. I must say it was unexpected for me. However, the secretariat has been treating the Friday slots as any others for a while now. If there are people who would attend the LEDBAT session if it were on a different day, but will not be able to attend because of the scheduling on Friday, please reply to this thread so that we have a record of it. Thank you, -- Stas -- Stanislav Shalunov BitTorrent Inc shalunov@bittorrent.com personal: http://shlang.com On Oct 16, 2009, at 11:30 AM, IETF Secretariat wrote: > Dear Murari Sridhavan, > > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the information of sessions that you have requested. > > LEDBAT Session 1 (2 hours) > Friday, Morning Session I 0900-1130 > Room Name: Cattleya East > ---------------------------------------------- > > > > Requested Information: > > > --------------------------------------------------------- > Working Group Name: ledbat > Area Name: Transport Area > Session Requester: Murari Sridhavan > > Number of Sessions: 1 > Length of Session(s): 2 hours > > > Number of Attendees: 50 > Conflicts to Avoid: > First Priority: tcpm tsvarea dccp tsvwg > > Special Requests: > > --------------------------------------------------------- > > From rpenno@juniper.net Wed Oct 21 21:30:12 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC83928C108 for ; Wed, 21 Oct 2009 21:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeGvS94v+hE9 for ; Wed, 21 Oct 2009 21:30:11 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id B04B328C110 for ; Wed, 21 Oct 2009 21:30:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSt/f2P6FrkVEwDIL109d3yjuzhfW8zsY@postini.com; Wed, 21 Oct 2009 21:30:21 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 21 Oct 2009 21:29:45 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 22 Oct 2009 00:29:45 -0400 From: Reinaldo Penno To: Lars Eggert , Murari Sridharan , "ledbat@ietf.org" Date: Thu, 22 Oct 2009 00:29:43 -0400 Thread-Topic: New version of LEDBAT App Practices and Recommendations posted Thread-Index: AcpFrqU2xyESGCJGQ5eXQNcELbXW6gARyc5nAzaen5Y= Message-ID: In-Reply-To: <998644D4818FC74AA6232DE1D35379779B5CB309E9@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ledbat] New version of LEDBAT App Practices and Recommendations posted X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 04:30:12 -0000 http://www.ietf.org/id/draft-penno-ledbat-app-practices-recommendations-01.= t xt Thanks, Reinaldo From muraris@microsoft.com Thu Oct 29 18:10:17 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92993A6996 for ; Thu, 29 Oct 2009 18:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.165 X-Spam-Level: X-Spam-Status: No, score=-10.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbKpZIQf5Ft9 for ; Thu, 29 Oct 2009 18:10:12 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 8E5833A67FC for ; Thu, 29 Oct 2009 18:10:12 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 29 Oct 2009 18:10:41 -0700 Received: from TK5EX14MBXC130.redmond.corp.microsoft.com ([169.254.9.154]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Thu, 29 Oct 2009 18:10:28 -0700 From: Murari Sridharan To: "ledbat@ietf.org" , "iccrg@cs.ucl.ac.uk" Thread-Topic: Ledbat presentation slots for Hiroshima Thread-Index: AcpMHsGKHZDjtXJvSlGbtgVfm8GZ+gM3NxQQ Date: Fri, 30 Oct 2009 01:10:27 +0000 Message-ID: <03520536067DF14395EA93FE7ECFDCF0097211B1@TK5EX14MBXC130.redmond.corp.microsoft.com> References: <03520536067DF14395EA93FE7ECFDCF004602142@TK5EX14MBXC130.redmond.corp.microsoft.com> In-Reply-To: <03520536067DF14395EA93FE7ECFDCF004602142@TK5EX14MBXC130.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_03520536067DF14395EA93FE7ECFDCF0097211B1TK5EX14MBXC130r_" MIME-Version: 1.0 Subject: Re: [ledbat] Ledbat presentation slots for Hiroshima X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 01:10:18 -0000 --_000_03520536067DF14395EA93FE7ECFDCF0097211B1TK5EX14MBXC130r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the agenda. LEDBAT WG Meeting, IETF 76 Friday, November 13 Cattleya East 9:00 AM Preliminaries (10 mts) 9:10-9:40 Low Extra Delay Background Transport (LEDBAT), S. Shalunov (30 m= inutes) http://tools.ietf.org/id/draft-ietf-ledbat-congestion-00.txt Looks like there were some minor edits made but the version is still 00? Is= this correct Stas? http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-ledbat-= congestion-00.txt 9:40-10:10 LEDBAT Practices and Recommendations for Managing Multiple Concu= rrent TCP Connections, R. Penno (30 minutes) http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendations-0= 1.txt 10:10 - 10:30 Next Steps and Wrap-up (20 minutes) Thanks Murari From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Murari Sridharan Sent: Tuesday, October 13, 2009 9:04 AM To: ledbat@ietf.org; iccrg@cs.ucl.ac.uk Subject: [ledbat] Ledbat presentation slots for Hiroshima Hi, We'll hopefully get the updated drafts soon. Meanwhile please send agenda r= equests. We know we will have two slots for each of the WG documents. Micha= el won't be making any updates to the LEDBAT survey document for Hiroshima. Other than the above I'd like to propose a few topics that I think will hel= p the WG immensely. I am cross-posting the invite to ICCRG folks as well. A= s we are working on finalizing a lower than best-effort transport that is b= ased on delay measurement there have been questions around experimental dat= a/discussion around proving/disproving late comer's advantage, whether flow= s can be starved, fairness in the presence of multiple flows etc. As with a= ll congestion control laws the one being discussed has a choice of paramete= r values to choose from. A lot of the work here is building on earlier work= on delay and loss based algorithms so it would be good to hear views form = others who have done this type of work in the past. I know there are folks = that have implementation experience with delay and loss based algorithms. M= ay be you have some interesting data to share that is relevant to the probl= em being discussed. You can look at the current proposal at http://tools.ie= tf.org/html/draft-shulanov-ledbat-congestion If you are interested, please send us details including title/topic, presen= ter name and requested time. Thanks Murari --_000_03520536067DF14395EA93FE7ECFDCF0097211B1TK5EX14MBXC130r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is the agenda.

 

LEDBAT WG Meeting, IETF 76

Friday, November 13

Cattleya East

 

9:00 AM Preliminaries (10 mts)

 

9:10-9:40 Low Extra Delay Background  Transport (LEDBAT), S. Shalunov (30 minutes)

http:= //tools.ietf.org/id/draft-ietf-ledbat-congestion-00.txt

Looks like there were some minor edits made but the version is still 00? Is this correct Stas?

http://tools.ietf.org/rfcdiff?difftype=3D--h= wdiff&url2=3Ddraft-ietf-ledbat-congestion-00.txt<= /p>

 

9:40-10:10 LEDBAT Practices and Recommendations for Managing Multiple Concurrent TCP Connections, R. Penno (30 minutes)

http://tools.ietf.org/id/draft-penno-ledbat-app-practices-re= commendations-01.txt

 

10:10 – 10:30 Next Steps and Wrap-up (20 minutes)

 

Thanks

Murari

 =

From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of Murari Sridharan
Sent: Tuesday, October 13, 2009 9:04 AM
To: ledbat@ietf.org; iccrg@cs.ucl.ac.uk
Subject: [ledbat] Ledbat presentation slots for Hiroshima=

 

Hi,

 

We’ll hopefully get the updated drafts soon. Meanwhile please send agenda requests. We know we will have two slots for e= ach of the WG documents. Michael won’t be making any updates to the LEDBA= T survey document for Hiroshima.

 

Other than the above I’d like to propose a fe= w topics that I think will help the WG immensely. I am cross-posting the invi= te to ICCRG folks as well. As we are working on finalizing a lower than best-effort transport that is based on delay measurement there have been qu= estions around experimental data/discussion around proving/disproving late comer’s advantage, whether flows can be starved, fairness in the pres= ence of multiple flows etc. As with all congestion control laws the one being discussed has a choice of parameter values to choose from. A lot of the wor= k here is building on earlier work on delay and loss based algorithms so it w= ould be good to hear views form others who have done this type of work in the pa= st. I know there are folks that have implementation experience with delay and l= oss based algorithms. May be you have some interesting data to share that is relevant to the problem being discussed. You can look at the current propos= al at http://tools.ietf.org/html/draft-shulanov-ledbat-congesti= on

 

If you are interested, please send us details including title/topic, presenter name and requested time.

 

Thanks

Murari

 

--_000_03520536067DF14395EA93FE7ECFDCF0097211B1TK5EX14MBXC130r_-- From richard_woundy@cable.comcast.com Fri Oct 30 07:01:41 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628D83A6964 for ; Fri, 30 Oct 2009 07:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-1.597, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmQILnLyhw-s for ; Fri, 30 Oct 2009 07:01:35 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 396803A6896 for ; Fri, 30 Oct 2009 07:01:35 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.81573442; Fri, 30 Oct 2009 10:01:36 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 10:01:37 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5969.7EF50E0B" Date: Fri, 30 Oct 2009 10:01:36 -0400 Message-ID: <8A82D1BFEDDE7E4597978355239BBBCB5CC24D@PACDCEXCMB06.cable.comcast.com> In-Reply-To: <03520536067DF14395EA93FE7ECFDCF0097211B1@TK5EX14MBXC130.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ledbat] Ledbat presentation slots for Hiroshima Thread-Index: AcpMHsGKHZDjtXJvSlGbtgVfm8GZ+gM3NxQQABtlRSA= References: <03520536067DF14395EA93FE7ECFDCF004602142@TK5EX14MBXC130.redmond.corp.microsoft.com> <03520536067DF14395EA93FE7ECFDCF0097211B1@TK5EX14MBXC130.redmond.corp.microsoft.com> From: "Woundy, Richard" To: "Murari Sridharan" X-OriginalArrivalTime: 30 Oct 2009 14:01:37.0147 (UTC) FILETIME=[7F0CE4B0:01CA5969] Cc: ledbat@ietf.org, iccrg@cs.ucl.ac.uk Subject: Re: [ledbat] Ledbat presentation slots for Hiroshima X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 14:01:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5969.7EF50E0B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I suspect the diff is against http://tools.ietf.org/html/draft-shalunov-ledbat-congestion-00, since the previous draft prior to approval as an official WG item. =20 =20 From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of Murari Sridharan Sent: Thursday, October 29, 2009 9:10 PM To: ledbat@ietf.org; iccrg@cs.ucl.ac.uk Subject: Re: [ledbat] Ledbat presentation slots for Hiroshima =20 Here is the agenda.=20 =20 LEDBAT WG Meeting, IETF 76 Friday, November 13 Cattleya East =20 9:00 AM Preliminaries (10 mts) =20 9:10-9:40 Low Extra Delay Background Transport (LEDBAT), S. Shalunov (30 minutes) http://tools.ietf.org/id/draft-ietf-ledbat-congestion-00.txt Looks like there were some minor edits made but the version is still 00? Is this correct Stas? http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-ledba= t-c ongestion-00.txt =20 9:40-10:10 LEDBAT Practices and Recommendations for Managing Multiple Concurrent TCP Connections, R. Penno (30 minutes) http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendation s-01.txt =20 10:10 - 10:30 Next Steps and Wrap-up (20 minutes) =20 Thanks Murari=20 =20 From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of Murari Sridharan Sent: Tuesday, October 13, 2009 9:04 AM To: ledbat@ietf.org; iccrg@cs.ucl.ac.uk Subject: [ledbat] Ledbat presentation slots for Hiroshima =20 Hi, =20 We'll hopefully get the updated drafts soon. Meanwhile please send agenda requests. We know we will have two slots for each of the WG documents. Michael won't be making any updates to the LEDBAT survey document for Hiroshima.=20 =20 Other than the above I'd like to propose a few topics that I think will help the WG immensely. I am cross-posting the invite to ICCRG folks as well. As we are working on finalizing a lower than best-effort transport that is based on delay measurement there have been questions around experimental data/discussion around proving/disproving late comer's advantage, whether flows can be starved, fairness in the presence of multiple flows etc. As with all congestion control laws the one being discussed has a choice of parameter values to choose from. A lot of the work here is building on earlier work on delay and loss based algorithms so it would be good to hear views form others who have done this type of work in the past. I know there are folks that have implementation experience with delay and loss based algorithms. May be you have some interesting data to share that is relevant to the problem being discussed. You can look at the current proposal at http://tools.ietf.org/html/draft-shulanov-ledbat-congestion =20 If you are interested, please send us details including title/topic, presenter name and requested time.=20 =20 Thanks Murari=20 =20 ------_=_NextPart_001_01CA5969.7EF50E0B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I suspect the diff is = against h= ttp://tools.ietf.org/html/draft-shalunov-ledbat-congestion-00, since the previous draft prior to approval as an official WG = item.

 

 

From:= ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of = Murari Sridharan
Sent: Thursday, October 29, 2009 9:10 PM
To: ledbat@ietf.org; iccrg@cs.ucl.ac.uk
Subject: Re: [ledbat] Ledbat presentation slots for = Hiroshima

 

Here is the agenda.

 

LEDBAT WG Meeting, IETF 76

Friday, November 13

Cattleya East

 

9:00 AM Preliminaries (10 mts)

 

9:10-9:40 Low Extra Delay Background  Transport (LEDBAT), S. Shalunov (30 = minutes)

htt= p://tools.ietf.org/id/draft-ietf-ledbat-congestion-00.txt<= /span>

Looks like there were some minor edits made but the version is still 00? Is = this correct Stas?

http://tools.ietf.org/rfcdiff?difftype=3D= --hwdiff&url2=3Ddraft-ietf-ledbat-congestion-00.txt

 =

9:40-10:10 LEDBAT Practices and Recommendations for Managing Multiple Concurrent = TCP Connections, R. Penno (30 minutes)

http://tools.ietf.org/id/draft-penno-ledbat-app-practice= s-recommendations-01.txt

 

10:10 – 10:30 Next Steps and Wrap-up (20 minutes)

 =

Thanks=

Murari

 

From:= ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of = Murari Sridharan
Sent: Tuesday, October 13, 2009 9:04 AM
To: ledbat@ietf.org; iccrg@cs.ucl.ac.uk
Subject: [ledbat] Ledbat presentation slots for = Hiroshima

 

Hi,

 

We’ll hopefully get the updated drafts = soon. Meanwhile please send agenda requests. We know we will have two slots for each of = the WG documents. Michael won’t be making any updates to the LEDBAT = survey document for Hiroshima.

 

Other than the above I’d like to propose a = few topics that I think will help the WG immensely. I am cross-posting the invite = to ICCRG folks as well. As we are working on finalizing a lower than best-effort transport that is based on delay measurement there have been questions = around experimental data/discussion around proving/disproving late = comer’s advantage, whether flows can be starved, fairness in the presence of multiple flows = etc. As with all congestion control laws the one being discussed has a choice = of parameter values to choose from. A lot of the work here is building on = earlier work on delay and loss based algorithms so it would be good to hear = views form others who have done this type of work in the past. I know there are = folks that have implementation experience with delay and loss based algorithms. May = be you have some interesting data to share that is relevant to the problem = being discussed. You can look at the current proposal at http://tools.ietf.org/html/draft-shulanov-ledbat-conges= tion

 

If you are interested, please send us details including title/topic, presenter name and requested time.

 

Thanks

Murari

 

------_=_NextPart_001_01CA5969.7EF50E0B--