From mayutan.arumaithurai@gmail.com Mon Oct 4 05:58:52 2010 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 652083A6FA3 for ; Mon, 4 Oct 2010 05:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 h-+9obFG01TQ for ; Mon, 4 Oct 2010 05:58:50 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 403D83A6F8D for ; Mon, 4 Oct 2010 05:58:43 -0700 (PDT) Received: by qyk5 with SMTP id 5so1364513qyk.10 for ; Mon, 04 Oct 2010 05:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=8arfWwJ5Zjd1nVSmJ+N8y4USD7g9js7dKFm4YeagSg8=; b=mq+I5AsSAav7BI9d/zHi5nIhzELi9TLFhIFZcjLZY9UfNCdaG8ubzQbHE95iksuLys DEU1JKoaBhSaDIMcC6yQbcdm7d37TqCOx5A42ym2sLql7cQEDP2yhiv5TbTg2089B6nD 4CqG+7y7XCvmKBpp4YkHNvr5EcvKIXfKGhbpA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=mPxx1ssXCBJQgNHianEh3kyDu2g79hJaMCBvgr8EAsbvRHUlLGBZRbT4HkXjla6cZn lHgYOxtQccn8a6d8/7CymFVBBU3gAQA4ioWjGUy0FIFsahi7VGPaAalxf14j1W/vFzYv i1jPcG+GbmH4l19EEAx6Xh1tuWOeVbwEQdrmE= Received: by 10.229.251.197 with SMTP id mt5mr6878984qcb.131.1286197172576; Mon, 04 Oct 2010 05:59:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.26.213 with HTTP; Mon, 4 Oct 2010 05:59:01 -0700 (PDT) In-Reply-To: <785EC96C-D9EB-42FE-BBDD-62D8A7D05503@telecom-bretagne.eu> References: <791AD3077F94194BB2BDD13565B6295D780EE4@PALLENE.office.hd> <2B950633-46E1-4607-ADE7-C50D9A52DE48@ifi.uio.no> <791AD3077F94194BB2BDD13565B6295D788110@PALLENE.office.hd> <54B4B5D3-73F0-4604-9491-06550A34D196@ifi.uio.no> <791AD3077F94194BB2BDD13565B6295D78A1C4@PALLENE.office.hd> <683F48D1-A646-4F25-8199-085D84B00108@ifi.uio.no> <785EC96C-D9EB-42FE-BBDD-62D8A7D05503@telecom-bretagne.eu> From: "Mayutan A." Date: Mon, 4 Oct 2010 14:59:01 +0200 Message-ID: To: David Ros Content-Type: multipart/alternative; boundary=00163630fb919528f80491ca1d23 Cc: ledbat@ietf.org, Rolf Winter , "RAMAKRISHNAN, KADANGODE K \(K. K.\)" Subject: Re: [ledbat] status update and way forward 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, 04 Oct 2010 12:58:52 -0000 --00163630fb919528f80491ca1d23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I would like to draw the group's attention to our work titled "NF-TCP: Network Friendly TCP", that was published at the 17th IEEE Workshop on Local and Metropolitan Area Networks (LANMAN 2010). *The abstract is as follows:* Delay-insensitive applications such as P2P file sharing, data center backups and software updates generate substantial amounts of traffic. This traffic, transported potentially over multiple TCP connections, competes with traffic from other possibly interactive applications. Today, with TCP, they compete on an equal level for each individual connection. In this paper, we propose a new TCP variant for such delay-insensitive applications, which we call Network Friendly TCP (NF-TCP). NF-TCP is responsive to available bandwidth, seeking to quickly and efficiently utilize the same in a congestion-free situation, while backing-off more aggressively than standard TCP on encountering competing traffic in a congested network. NF-TCP uses a novel combination of utilizin= g measurement of available bandwidth and ECN-based congestion avoidance techniques to ensure that it is truly friendly to existing TCP connections. We evaluate the performance of NF-TCP through ns-2 simulations and present the initial results enlightening the friendly nature of NF-TCP compared to standard TCP. *A more detailed version of the paper is available at: http://www.net.informatik.uni-goettingen.de/publications/1718/NF-TCP-techre= port.pdf * Feedback is welcome. Cheers, Mayutan Le 30 sept. 2010 =C3=A0 19:07, Murari Sridharan a =C3=A9crit : > > > Michael, to reiterate what Rolf said if you can pull this off prior to > Beijing that would be great. We went through several deliberations at our > end these past months and given the lack of activity both from authors an= d > in the WG mailing lists and given the fact that our most important > deliverable is the congestion control draft we decided to proceed forward > trying to complete just that. > > > > Thanks > > > > -----Original Message----- > > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behal= f > Of Michael Welzl > > Sent: Thursday, September 30, 2010 8:30 AM > > To: Rolf Winter > > Cc: ledbat@ietf.org; David Ros > > Subject: Re: [ledbat] status update and way forward > > > > Absolutely! We'll do our best, promise!! > > > > Cheers, > > Michael > > > > > > On Sep 30, 2010, at 5:10 PM, Rolf Winter wrote: > > > >> Michael, > >> > >> The plan is to close the WG once the congestion control draft is done. > >> If you can finish the document before that and get consensus on this > >> list then that would be great. I also hope something similar can be > >> done for the other remaining draft that we have. Given the little > >> feedback recently, I would like to have at least three (3) people to > >> commit to reviewing the document thoroughly though. > >> > >> Do you think this is a workable way forward? > >> > >> Best, > >> > >> Rolf > >> > >> > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >> London W3 6BL | Registered in England 2832014 > >> > >> > >>> -----Original Message----- > >>> From: Michael Welzl [mailto:michawe@ifi.uio.no] > >>> Sent: Donnerstag, 30. September 2010 15:47 > >>> To: Rolf Winter > >>> Cc: ledbat@ietf.org; David Ros > >>> Subject: Re: [ledbat] status update and way forward > >>> > >>> Hi, > >>> > >>> I took this message as procedural - that was, I think, regarding the > >>> necessity to present it at a meeting or not (I think it was because > >>> LEDBAT didn't meet in Maastricht, and then we wondered how to > >>> proceed). > >>> Anyway: indeed we were expecting to get a new version done very soon > >>> then, but after that it was preempted by things with deadlines in our > >>> todo list. I really didn't see how urgent this is, I just understood > >>> that it's ok for you to complete the discussion via email. Had I > >>> known that this is urgent and you really *need* us to do an update > >>> soon, we would have quickly done that! > >>> > >>> Very sorry for misunderstanding the situation, and for having > >>> announced an update which then didn't happen for a long time. The > >>> sense of urgency is crystal clear now, so we would definitely move > >>> ahead fast - but I hope the document doesn't have to be dropped! > >>> > >>> Cheers, > >>> Michael > >>> > >>> > >>> On Sep 30, 2010, at 3:19 PM, Rolf Winter wrote: > >>> > >>>> Hi Michael, > >>>> > >>>> this shouldn't come as a complete surprise. Four (4) months ago we > >>>> sent an Email to the list about how we could go forward and asked > >>>> for feedback. Quoting: > >>>> > >>>> "Our recommendation is to make changes to the ledbat draft and > >>>> complete the discussion over email, forward the document to IESG and > >>>> close the WG." > >>>> > >>>> After which ALL document authors said that a new version is just > >>>> around the corner, including you. As you know this has not happened. > >>>> > >>>> Best, > >>>> > >>>> Rolf > >>>> > >>>> > >>>> > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >>>> London W3 6BL | Registered in England 2832014 > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > >>>>> Behalf Of Michael Welzl > >>>>> Sent: Donnerstag, 30. September 2010 10:14 > >>>>> To: Rolf Winter > >>>>> Cc: ledbat@ietf.org; David Ros > >>>>> Subject: Re: [ledbat] status update and way forward > >>>>> > >>>>>> 2. We decided to drop draft-ietf-ledbat-survey as a milestone. The > >>>>>> draft has already expired and has not seen an update since the > >>>>>> adoption as a WG item. > >>>>> > >>>>> ARGH!! PLEASE! Without even a comment to us authors?! > >>>>> > >>>>> I'm terribly sorry for the draft's expiry; this didn't go unnoticed > >>>>> to us, and we are trying to get this updated just now, definitely > >>>>> in time before the next IETF! > >>>>> Had we known that you're considering dropping it, we would have of > >>>>> course updated it faster!! I thought it's not a big deal that it > >>>>> expired as long as we were going to provide an update by the next > >>>>> meeting anyway. > >>>>> > >>>>> Either way this next one is quite a minor update, as we believe > >>>>> that the document is already in quite a good shape. A lot of work > >>>>> has already gone into this, before approving it as a WG item I ask > >>>>> you to PLEASE reconsider this! > >>>>> > >>>>> Michael > >>>>> > >>>>> _______________________________________________ > >>>>> ledbat mailing list > >>>>> ledbat@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ledbat > >> > > > > _______________________________________________ > > ledbat mailing list > > ledbat@ietf.org > > https://www.ietf.org/mailman/listinfo/ledbat > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David ROS > http://www.rennes.enst-bretagne.fr/~dros/ > > I love deadlines. I like the whooshing sound they make as they fly by. -- > Douglas Adams > > > > > --=20 Mayutan Arumaithurai 0049-551-2712647 (Home number) 0049-176-20322049 (mobile number) --00163630fb919528f80491ca1d23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

I would like to draw the group's attention to our work titl= ed "NF-TCP: Network Friendly TCP", that was published at
the 17th IEEE Workshop on Local and Metropolitan Area Networks (LANMAN 2010= ).

The abstract is as follows:
Delay-insensitive applications such as P2P file sharing, data center
backups and software updates generate substantial amounts of traffic.
This traffic, transported potentially over multiple TCP connections,
competes with traffic from other possibly interactive applications. Today, = with TCP, they compete
on an equal level for each individual connection. In this paper, we propose= a new TCP variant for
such delay-insensitive applications, which we call Network Friendly TCP
(NF-TCP). NF-TCP is responsive to available bandwidth, seeking to quickly and efficiently utilize the same in a congestion-free situation,
while backing-off more aggressively than standard TCP on encountering compe= ting
traffic in a congested network. NF-TCP uses a novel combination of utilizin= g measurement
of available bandwidth and ECN-based congestion avoidance techniques to ens= ure
that it is truly friendly to existing TCP connections. We evaluate the perf= ormance of NF-TCP
through ns-2 simulations and present the
initial results enlightening the friendly nature of NF-TCP compared to
standard TCP.

A more detailed version of the paper is available at:
http://www.net.informatik.uni-goettingen.de/publicatio= ns/1718/NF-TCP-techreport.pdf

Feedback is welcome.

Cheers,
Mayutan


Le 30 sept. 2010 =C3=A0 19:07, Murari Sridharan a =C3=A9crit :

> Michael, to reiterate what Rolf said if you can pull this off prior to= Beijing that would be great. We went through several deliberations at our = end these past months and given the lack of activity both from authors and = in the WG mailing lists and given the fact that our most important delivera= ble is the congestion control draft we decided to proceed forward trying to= complete just that.
>
> Thanks
>
> -----Original Message-----
> From: ledbat-bounces@ietf.o= rg [mailto:ledbat-bounces@ie= tf.org] On Behalf Of Michael Welzl
> Sent: Thursday, September 30, 2010 8:30 AM
> To: Rolf Winter
> Cc: ledbat@ietf.org; David Ros<= br> > Subject: Re: [ledbat] status update and way forward
>
> Absolutely! We'll do our best, promise!!
>
> Cheers,
> Michael
>
>
> On Sep 30, 2010, at 5:10 PM, Rolf Winter wrote:
>
>> Michael,
>>
>> The plan is to close the WG once the congestion control draft is d= one.
>> If you can finish the document before that and get consensus on th= is
>> list then that would be great. I also hope something similar can b= e
>> done for the other remaining draft that we have. Given the little<= br> >> feedback recently, I would like to have at least three (3) people = to
>> commit to reviewing the document thoroughly though.
>>
>> Do you think this is a workable way forward?
>>
>> Best,
>>
>> =C2=A0 =C2=A0 =C2=A0Rolf
>>
>>
>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road= ,
>> London W3 6BL | Registered in England 2832014
>>
>>
>>> -----Original Message-----
>>> From: Michael Welzl [mailto:michawe@ifi.uio.no]
>>> Sent: Donnerstag, 30. September 2010 15:47
>>> To: Rolf Winter
>>> Cc: ledbat@ietf.org; Da= vid Ros
>>> Subject: Re: [ledbat] status update and way forward
>>>
>>> Hi,
>>>
>>> I took this message as procedural - that was, I think, regardi= ng the
>>> necessity to present it at a meeting or not (I think it was be= cause
>>> LEDBAT didn't meet in Maastricht, and then we wondered how= to
>>> proceed).
>>> Anyway: indeed we were expecting to get a new version done ver= y soon
>>> then, but after that it was preempted by things with deadlines= in our
>>> todo list. I really didn't see how urgent this is, I just = understood
>>> that it's ok for you to complete the discussion via email.= Had I
>>> known that this is urgent and you really *need* us to do an up= date
>>> soon, we would have quickly done that!
>>>
>>> Very sorry for misunderstanding the situation, and for having<= br> >>> announced an update which then didn't happen for a long ti= me. The
>>> sense of urgency is crystal clear now, so we would definitely = move
>>> ahead fast - but I hope the document doesn't have to be dr= opped!
>>>
>>> Cheers,
>>> Michael
>>>
>>>
>>> On Sep 30, 2010, at 3:19 PM, Rolf Winter wrote:
>>>
>>>> Hi Michael,
>>>>
>>>> this shouldn't come as a complete surprise. Four (4) m= onths ago we
>>>> sent an Email to the list about how we could go forward an= d asked
>>>> for feedback. Quoting:
>>>>
>>>> "Our recommendation is to make changes to the ledbat = draft and
>>>> complete the discussion over email, forward the document t= o IESG and
>>>> close the WG."
>>>>
>>>> After which ALL document authors said that a new version i= s just
>>>> around the corner, including you. As you know this has not= happened.
>>>>
>>>> Best,
>>>>
>>>> =C2=A0 =C2=A0Rolf
>>>>
>>>>
>>>>
>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victo= ria Road,
>>>> London W3 6BL | Registered in England 2832014
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: ledba= t-bounces@ietf.org [mailto:l= edbat-bounces@ietf.org] On
>>>>> Behalf Of Michael Welzl
>>>>> Sent: Donnerstag, 30. September 2010 10:14
>>>>> To: Rolf Winter
>>>>> Cc: ledbat@ietf.org= ; David Ros
>>>>> Subject: Re: [ledbat] status update and way forward >>>>>
>>>>>> 2. We decided to drop draft-ietf-ledbat-survey as = a milestone. The
>>>>>> draft has already expired and has not seen an upda= te since the
>>>>>> adoption as a WG item.
>>>>>
>>>>> ARGH!! PLEASE! =C2=A0 Without even a comment to us aut= hors?!
>>>>>
>>>>> I'm terribly sorry for the draft's expiry; thi= s didn't go unnoticed
>>>>> to us, and we are trying to get this updated just now,= definitely
>>>>> in time before the next IETF!
>>>>> Had we known that you're considering dropping it, = we would have of
>>>>> course updated it faster!! =C2=A0I thought it's no= t a big deal that it
>>>>> expired as long as we were going to provide an update = by the next
>>>>> meeting anyway.
>>>>>
>>>>> Either way this next one is quite a minor update, as w= e believe
>>>>> that the document is already in quite a good shape. A = lot of work
>>>>> has already gone into this, before approving it as a W= G item I ask
>>>>> you to PLEASE reconsider this!
>>>>>
>>>>> Michael
>>>>>
>>>>> _______________________________________________
>>>>> ledbat mailing list
>>>>> ledbat@ietf.org=
>>>>> https://www.ietf.org/mailman/listinfo/ledbat
>>
>
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat
>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David ROS
h= ttp://www.rennes.enst-bretagne.fr/~dros/

I love deadlines. I like the whooshing sound they make as they fly by. -- D= ouglas Adams








--
Mayutan Arumaithura= i
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number) --00163630fb919528f80491ca1d23-- From david.ros@telecom-bretagne.eu Fri Oct 8 17:58:51 2010 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 6DEEE3A699F for ; Fri, 8 Oct 2010 17:58:51 -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_FR=0.35] 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 7UK6RqHng6dg for ; Fri, 8 Oct 2010 17:58:50 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id 0C8BB3A698F for ; Fri, 8 Oct 2010 17:58:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o99101Is015362 for ; Sat, 9 Oct 2010 03:00:01 +0200 Received: from courrier.enst-bretagne.fr (smtps.telecom-bretagne.eu [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o990xq6m015353 for ; Sat, 9 Oct 2010 02:59:56 +0200 Received: from [192.168.0.10] (dhcp-salsa-i136.rennes.enst-bretagne.fr [10.35.128.136]) (user=dros mech=PLAIN bits=0) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2010.02.22) with ESMTP id o990xFNh017221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 9 Oct 2010 02:59:46 +0200 From: David Ros Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Oct 2010 02:59:15 +0200 References: <20101009004622.772783A69A3@core3.amsl.com> To: ledbat@ietf.org Message-Id: <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: amavisd-new at enst-bretagne.fr Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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: Sat, 09 Oct 2010 00:58:51 -0000 Dear all, We've posted an update to the survey draft, see announcement below. = Comments are very welcome. Thanks in advance, David. D=E9but du message r=E9exp=E9di=E9 : > De : IETF I-D Submission Tool > Date : 9 octobre 2010 02:46:22 HAEC > =C0 : david.ros@telecom-bretagne.eu > Cc : michawe@ifi.uio.no > Objet : New Version Notification for draft-ietf-ledbat-survey-01=20 >=20 >=20 > A new version of I-D, draft-ietf-ledbat-survey-01.txt has been = successfully submitted by David Ros and posted to the IETF repository. >=20 > Filename: draft-ietf-ledbat-survey > Revision: 01 > Title: A Survey of Lower-than-Best-Effort Transport = Protocols > Creation_date: 2010-10-09 > WG ID: ledbat > Number_of_pages: 16 >=20 > Abstract: > This document provides a survey of transport protocols which are > designed to have a smaller bandwidth and/or delay impact on standard > TCP than standard TCP itself when they share a bottleneck with it. > Such protocols could be used for low-priority "background" traffic, > as they provide what is sometimes called a "less than" (or "lower > than") best-effort service. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David ROS http://www.rennes.enst-bretagne.fr/~dros/ I love deadlines. I like the whooshing sound they make as they fly by. = -- Douglas Adams From Rolf.Winter@neclab.eu Wed Oct 13 10:55:44 2010 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 032F43A682D for ; Wed, 13 Oct 2010 10:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.793 X-Spam-Level: X-Spam-Status: No, score=-101.793 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 ULCwkHx5+hRP for ; Wed, 13 Oct 2010 10:55:43 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 1E34F3A691F for ; Wed, 13 Oct 2010 10:55:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A34E12800017A for ; Wed, 13 Oct 2010 19:56:59 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2oRgYj2mbFF for ; Wed, 13 Oct 2010 19:56:59 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 898CA2800015D for ; Wed, 13 Oct 2010 19:56:54 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.120]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0218.012; Wed, 13 Oct 2010 19:56:54 +0200 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: Agenda for Beijing Thread-Index: ActrAARdl7MFMoneSHOekIaau7+6Rg== Date: Wed, 13 Oct 2010 17:56:53 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D7E4B12@PALLENE.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ledbat] Agenda for Beijing 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: Wed, 13 Oct 2010 17:55:44 -0000 Hi, the overall meeting agenda hasn't fully settled yet, but this should not hi= nder us from filling the two hour slot that we got. The intention is to con= centrate on the congestion control part but there is of course time to disc= uss all WG items. Best, =09 Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From Rolf.Winter@neclab.eu Wed Oct 13 11:36:47 2010 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 441E83A69F4 for ; Wed, 13 Oct 2010 11:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.808 X-Spam-Level: X-Spam-Status: No, score=-101.808 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 tbOJYLCo+K+u for ; Wed, 13 Oct 2010 11:36:46 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id BC06A3A69FB for ; Wed, 13 Oct 2010 11:36:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8F0492800017A; Wed, 13 Oct 2010 20:38:02 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2YFgF87xXae; Wed, 13 Oct 2010 20:38:02 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7511C2800015D; Wed, 13 Oct 2010 20:37:52 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.120]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0218.012; Wed, 13 Oct 2010 20:37:52 +0200 From: Rolf Winter To: David Ros , "ledbat@ietf.org" Thread-Topic: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 Thread-Index: AQHLZ01VyuPtrH630kW2F0EGTJv1YJM/PAMg Date: Wed, 13 Oct 2010 18:37:51 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> References: <20101009004622.772783A69A3@core3.amsl.com> <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> In-Reply-To: <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.196] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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: Wed, 13 Oct 2010 18:36:47 -0000 Hi, as mentioned earlier, I would like to have at least 3 people from the group= that agree to do a thorough review of this draft (well written, reasonably= complete, correct etc). Volunteers please speak up! A lot of people on the= list have been working in this field and should be able to do this easily = e.g. Mirja, Dario and others. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > Behalf Of David Ros > Sent: Samstag, 9. Oktober 2010 02:59 > To: ledbat@ietf.org > Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat- > survey-01 >=20 > Dear all, >=20 > We've posted an update to the survey draft, see announcement below. > Comments are very welcome. >=20 > Thanks in advance, >=20 > David. >=20 >=20 > D=E9but du message r=E9exp=E9di=E9 : >=20 > > De : IETF I-D Submission Tool > > Date : 9 octobre 2010 02:46:22 HAEC > > =C0 : david.ros@telecom-bretagne.eu > > Cc : michawe@ifi.uio.no > > Objet : New Version Notification for draft-ietf-ledbat-survey-01 > > > > > > A new version of I-D, draft-ietf-ledbat-survey-01.txt has been > successfully submitted by David Ros and posted to the IETF repository. > > > > Filename: draft-ietf-ledbat-survey > > Revision: 01 > > Title: A Survey of Lower-than-Best-Effort Transport > Protocols > > Creation_date: 2010-10-09 > > WG ID: ledbat > > Number_of_pages: 16 > > > > Abstract: > > This document provides a survey of transport protocols which are > > designed to have a smaller bandwidth and/or delay impact on standard > > TCP than standard TCP itself when they share a bottleneck with it. > > Such protocols could be used for low-priority "background" traffic, > > as they provide what is sometimes called a "less than" (or "lower > > than") best-effort service. > > > > > > > > The IETF Secretariat. > > > > >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David ROS > http://www.rennes.enst-bretagne.fr/~dros/ >=20 > I love deadlines. I like the whooshing sound they make as they fly by. > -- Douglas Adams >=20 >=20 >=20 >=20 > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Oct 13 14:02:54 2010 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 896833A6A2D for ; Wed, 13 Oct 2010 14:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.614 X-Spam-Level: X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_20=-0.74, HELO_EQ_DE=0.35] 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 3R83E52sHWs6 for ; Wed, 13 Oct 2010 14:02:53 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 210733A69EF for ; Wed, 13 Oct 2010 14:02:53 -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 26051633B1 for ; Wed, 13 Oct 2010 23:04:09 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 0513259A8A for ; Wed, 13 Oct 2010 23:04:09 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: ledbat@ietf.org Date: Wed, 13 Oct 2010 23:04:08 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <20101009004622.772783A69A3@core3.amsl.com> <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> 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: <201010132304.08445.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [ledbat] =?iso-8859-1?q?Fwd=3A_New_Version_Notification_for=09dra?= =?iso-8859-1?q?ft-ietf-ledbat-survey-01?= 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: Wed, 13 Oct 2010 21:02:54 -0000 Yes, I will make a review. And I recommend as well to include RAPID. Mirja On Wednesday 13 October 2010 20:37:51 Rolf Winter wrote: > Hi, > > as mentioned earlier, I would like to have at least 3 people from the gro= up > that agree to do a thorough review of this draft (well written, reasonably > complete, correct etc). Volunteers please speak up! A lot of people on the > list have been working in this field and should be able to do this easily > e.g. Mirja, Dario and others. > > Best, > > Rolf > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London > W3 6BL | Registered in England 2832014 > > > -----Original Message----- > > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > > Behalf Of David Ros > > Sent: Samstag, 9. Oktober 2010 02:59 > > To: ledbat@ietf.org > > Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat- > > survey-01 > > > > Dear all, > > > > We've posted an update to the survey draft, see announcement below. > > Comments are very welcome. > > > > Thanks in advance, > > > > David. > > > > D=E9but du message r=E9exp=E9di=E9 : > > > De : IETF I-D Submission Tool > > > Date : 9 octobre 2010 02:46:22 HAEC > > > =C0 : david.ros@telecom-bretagne.eu > > > Cc : michawe@ifi.uio.no > > > Objet : New Version Notification for draft-ietf-ledbat-survey-01 > > > > > > > > > A new version of I-D, draft-ietf-ledbat-survey-01.txt has been > > > > successfully submitted by David Ros and posted to the IETF repository. > > > > > Filename: draft-ietf-ledbat-survey > > > Revision: 01 > > > Title: A Survey of Lower-than-Best-Effort Transport > > > > Protocols > > > > > Creation_date: 2010-10-09 > > > WG ID: ledbat > > > Number_of_pages: 16 > > > > > > Abstract: > > > This document provides a survey of transport protocols which are > > > designed to have a smaller bandwidth and/or delay impact on standard > > > TCP than standard TCP itself when they share a bottleneck with it. > > > Such protocols could be used for low-priority "background" traffic, > > > as they provide what is sometimes called a "less than" (or "lower > > > than") best-effort service. > > > > > > > > > > > > The IETF Secretariat. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > David ROS > > http://www.rennes.enst-bretagne.fr/~dros/ > > > > I love deadlines. I like the whooshing sound they make as they fly by. > > -- Douglas Adams > > > > > > > > > > _______________________________________________ > > ledbat mailing list > > ledbat@ietf.org > > https://www.ietf.org/mailman/listinfo/ledbat > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat =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 michawe@ulrik.uio.no Wed Oct 13 14:07:44 2010 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 4A7583A69C1 for ; Wed, 13 Oct 2010 14:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 mgVmw93WGWci for ; Wed, 13 Oct 2010 14:07:43 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id A519A3A69B0 for ; Wed, 13 Oct 2010 14:07:42 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1P68ZG-0002lz-UC; Wed, 13 Oct 2010 23:08:58 +0200 Received: from w3prod-wm01.uio.no ([129.240.4.214] helo=webmail.uio.no) by mail-mx2.uio.no with esmtpsa (TLSv1:AES256-SHA:256) user michawe (Exim 4.69) (envelope-from ) id 1P68ZG-000085-89; Wed, 13 Oct 2010 23:08:58 +0200 Received: from 217.203.187.141 (SquirrelMail authenticated user michawe) by webmail.uio.no with HTTP; Wed, 13 Oct 2010 23:08:58 +0200 Message-ID: <4da0790acf9803b5b5e9c1552a23ebef.squirrel@webmail.uio.no> In-Reply-To: <201010132304.08445.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <20101009004622.772783A69A3@core3.amsl.com> <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> <201010132304.08445.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Wed, 13 Oct 2010 23:08:58 +0200 From: michawe@ifi.uio.no To: "Mirja Kuehlewind" User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 3 sum rcpts/h 6 sum msgs/h 5 total rcpts 3284 max rcpts/h 27 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 318F7346F51B53E8DA796A78797F881AD0B9CBEC X-UiO-SPAM-Test: remote_host: 129.240.4.214 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 30 total 718839 max/h 663 blacklist 0 greylist 0 ratelimit 0 Cc: ledbat@ietf.org Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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: Wed, 13 Oct 2010 21:07:44 -0000 Thank you very much! About RAPID, see my previous response on the issue - we're considering it. Cheers, Michael > Yes, I will make a review. And I recommend as well to include RAPID. > > Mirja > > > On Wednesday 13 October 2010 20:37:51 Rolf Winter wrote: >> Hi, >> >> as mentioned earlier, I would like to have at least 3 people from the >> group >> that agree to do a thorough review of this draft (well written, >> reasonably >> complete, correct etc). Volunteers please speak up! A lot of people on >> the >> list have been working in this field and should be able to do this >> easily >> e.g. Mirja, Dario and others. >> >> Best, >> >> Rolf >> >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> London >> W3 6BL | Registered in England 2832014 >> >> > -----Original Message----- >> > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On >> > Behalf Of David Ros >> > Sent: Samstag, 9. Oktober 2010 02:59 >> > To: ledbat@ietf.org >> > Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat- >> > survey-01 >> > >> > Dear all, >> > >> > We've posted an update to the survey draft, see announcement below. >> > Comments are very welcome. >> > >> > Thanks in advance, >> > >> > David. >> > >> > Début du message réexpédié : >> > > De : IETF I-D Submission Tool >> > > Date : 9 octobre 2010 02:46:22 HAEC >> > > À : david.ros@telecom-bretagne.eu >> > > Cc : michawe@ifi.uio.no >> > > Objet : New Version Notification for draft-ietf-ledbat-survey-01 >> > > >> > > >> > > A new version of I-D, draft-ietf-ledbat-survey-01.txt has been >> > >> > successfully submitted by David Ros and posted to the IETF repository. >> > >> > > Filename: draft-ietf-ledbat-survey >> > > Revision: 01 >> > > Title: A Survey of Lower-than-Best-Effort Transport >> > >> > Protocols >> > >> > > Creation_date: 2010-10-09 >> > > WG ID: ledbat >> > > Number_of_pages: 16 >> > > >> > > Abstract: >> > > This document provides a survey of transport protocols which are >> > > designed to have a smaller bandwidth and/or delay impact on standard >> > > TCP than standard TCP itself when they share a bottleneck with it. >> > > Such protocols could be used for low-priority "background" traffic, >> > > as they provide what is sometimes called a "less than" (or "lower >> > > than") best-effort service. >> > > >> > > >> > > >> > > The IETF Secretariat. >> > >> > ================================================================= >> > David ROS >> > http://www.rennes.enst-bretagne.fr/~dros/ >> > >> > I love deadlines. I like the whooshing sound they make as they fly by. >> > -- Douglas Adams >> > >> > >> > >> > >> > _______________________________________________ >> > ledbat mailing list >> > ledbat@ietf.org >> > https://www.ietf.org/mailman/listinfo/ledbat >> >> _______________________________________________ >> ledbat mailing list >> ledbat@ietf.org >> https://www.ietf.org/mailman/listinfo/ledbat > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja Kühlewind > 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 > ------------------------------------------------------------------- > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > From mayutan.arumaithurai@gmail.com Wed Oct 13 22:45:19 2010 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 3167E3A68BC for ; Wed, 13 Oct 2010 22:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, 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 QDl7OL3r2iYb for ; Wed, 13 Oct 2010 22:45:17 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id CFC663A68A8 for ; Wed, 13 Oct 2010 22:45:14 -0700 (PDT) Received: by qyk36 with SMTP id 36so5192516qyk.10 for ; Wed, 13 Oct 2010 22:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=IFix6Du0iqmVIDV4LXMkIfrRnsII5JrX6ye4mkb3wAo=; b=h1t0Z64KBGbUipLAPV37gIgs7M+/W2GmIRNGFYzG5Wbq7pauJf1tIbMyqKv91akBY9 75+nmKRg7jBXdkB4WIjjulghRXumii6nSoDUGjwS3Qka1RbuIc44JI1AXi9RtC3nZxhl KJQ5ag21XVhEmfEz9ey2Na4C5jFwgIvh0wtCE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=gKishj1fkcwyVvpRk7LfAshgLa4i4hYWDGFf17E5K8hhFkbnObtP/E8LbAK4D7CUTh /wA8g9aRJ4v3Uf87EiACAGumbCcuSYaBAw/d8ri1UDuz7YMqf3/bQ9QbbAksJe6s/S+v s7dfqCotMsgrGWRb6GLU/Fhu2XsbnOEI0tlKU= Received: by 10.224.190.3 with SMTP id dg3mr8111458qab.68.1287035191186; Wed, 13 Oct 2010 22:46:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.130.88 with HTTP; Wed, 13 Oct 2010 22:46:11 -0700 (PDT) In-Reply-To: <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> References: <20101009004622.772783A69A3@core3.amsl.com> <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> From: "Mayutan A." Date: Thu, 14 Oct 2010 07:46:11 +0200 Message-ID: To: Rolf Winter Content-Type: multipart/alternative; boundary=20cf300fac9b62560404928d3bb3 Cc: "ledbat@ietf.org" Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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, 14 Oct 2010 05:45:19 -0000 --20cf300fac9b62560404928d3bb3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have been working on this topic too and will review this document. Mayutan On Wed, Oct 13, 2010 at 8:37 PM, Rolf Winter wrote: > Hi, > > as mentioned earlier, I would like to have at least 3 people from the gro= up > that agree to do a thorough review of this draft (well written, reasonabl= y > complete, correct etc). Volunteers please speak up! A lot of people on th= e > list have been working in this field and should be able to do this easily > e.g. Mirja, Dario and others. > > Best, > > Rolf > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n > W3 6BL | Registered in England 2832014 > > > > -----Original Message----- > > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > > Behalf Of David Ros > > Sent: Samstag, 9. Oktober 2010 02:59 > > To: ledbat@ietf.org > > Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat- > > survey-01 > > > > Dear all, > > > > We've posted an update to the survey draft, see announcement below. > > Comments are very welcome. > > > > Thanks in advance, > > > > David. > > > > > > D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : > > > > > De : IETF I-D Submission Tool > > > Date : 9 octobre 2010 02:46:22 HAEC > > > =C3=80 : david.ros@telecom-bretagne.eu > > > Cc : michawe@ifi.uio.no > > > Objet : New Version Notification for draft-ietf-ledbat-survey-01 > > > > > > > > > A new version of I-D, draft-ietf-ledbat-survey-01.txt has been > > successfully submitted by David Ros and posted to the IETF repository. > > > > > > Filename: draft-ietf-ledbat-survey > > > Revision: 01 > > > Title: A Survey of Lower-than-Best-Effort Transport > > Protocols > > > Creation_date: 2010-10-09 > > > WG ID: ledbat > > > Number_of_pages: 16 > > > > > > Abstract: > > > This document provides a survey of transport protocols which are > > > designed to have a smaller bandwidth and/or delay impact on standard > > > TCP than standard TCP itself when they share a bottleneck with it. > > > Such protocols could be used for low-priority "background" traffic, > > > as they provide what is sometimes called a "less than" (or "lower > > > than") best-effort service. > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > David ROS > > http://www.rennes.enst-bretagne.fr/~dros/ > > > > I love deadlines. I like the whooshing sound they make as they fly by. > > -- Douglas Adams > > > > > > > > > > _______________________________________________ > > ledbat mailing list > > ledbat@ietf.org > > https://www.ietf.org/mailman/listinfo/ledbat > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > --=20 Mayutan Arumaithurai 0049-551-2712647 (Home number) 0049-176-20322049 (mobile number) --20cf300fac9b62560404928d3bb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have been working on this topic too and will review this document.

Mayutan


On Wed, Oct 13, 2010 at 8:37= PM, Rolf Winter <Rolf.Winter@neclab.eu> wrote:
Hi,

as mentioned earlier, I would like to have at least 3 people from the group= that agree to do a thorough review of this draft (well written, reasonably= complete, correct etc). Volunteers please speak up! A lot of people on the= list have been working in this field and should be able to do this easily = e.g. Mirja, Dario and others.

Best,

=C2=A0 =C2=A0 =C2=A0 =C2=A0Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014


> -----Original Message-----
> From: ledbat-bounces@ietf.o= rg [mailto:ledbat-bounces@ie= tf.org] On
> Behalf Of David Ros
> Sent: Samstag, 9. Oktober 2010 02:59
> To: ledbat@ietf.org
> Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-=
> survey-01
>
> Dear all,
>
> We've posted an update to the survey draft, see announcement below= .
> Comments are very welcome.
>
> Thanks in advance,
>
> David.
>
>
> D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 :
>
> > De : IETF I-D Submission Tool <idsubmission@ietf.org>
> > Date : 9 octobre 2010 02:46:22 HAEC
> > =C3=80 : david.r= os@telecom-bretagne.eu
> > Cc : michawe@ifi.uio.no=
> > Objet : New Version Notification for draft-ietf-ledbat-survey-01<= br> > >
> >
> > A new version of I-D, draft-ietf-ledbat-survey-01.txt has been > successfully submitted by David Ros and posted to the IETF repository.=
> >
> > Filename: =C2=A0 =C2=A0draft-ietf-ledbat-survey
> > Revision: =C2=A0 =C2=A001
> > Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A Survey = of Lower-than-Best-Effort Transport
> Protocols
> > Creation_date: =C2=A0 =C2=A0 =C2=A0 2010-10-09
> > WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ledbat > > Number_of_pages: 16
> >
> > Abstract:
> > This document provides a survey of transport protocols which are<= br> > > designed to have a smaller bandwidth and/or delay impact on stand= ard
> > TCP than standard TCP itself when they share a bottleneck with it= .
> > Such protocols could be used for low-priority "background&qu= ot; traffic,
> > as they provide what is sometimes called a "less than" = (or "lower
> > than") best-effort service.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> David ROS
> http://www.rennes.enst-bretagne.fr/~dros/
>
> I love deadlines. I like the whooshing sound they make as they fly by.=
> -- Douglas Adams
>
>
>
>
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat
_______________________________________________
ledbat mailing list
ledbat@ietf.org
= https://www.ietf.org/mailman/listinfo/ledbat



--
Mayutan Aru= maithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile n= umber)
--20cf300fac9b62560404928d3bb3-- From michawe@ifi.uio.no Thu Oct 14 00:57:52 2010 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 B1C683A6832 for ; Thu, 14 Oct 2010 00:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.484 X-Spam-Level: X-Spam-Status: No, score=-96.484 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396, RCVD_BAD_ID=2.837, USER_IN_WHITELIST=-100] 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 axQxMSLH3qDI for ; Thu, 14 Oct 2010 00:57:51 -0700 (PDT) Received: from mail1.unitn.it (mail1.unitn.it [193.205.206.53]) by core3.amsl.com (Postfix) with ESMTP id 2C0883A677C for ; Thu, 14 Oct 2010 00:57:50 -0700 (PDT) Received: from mail1.unitn.it (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A73E2547CB; Thu, 14 Oct 2010 09:59:08 +0200 (CEST) Received: from mailhub2.unitn.it (mailhub.unitn.it [192.168.206.47]) by mail1.unitn.it (Postfix) with ESMTP id 2B7DF5461C; Thu, 14 Oct 2010 09:59:08 +0200 (CEST) Received: from science.unitn.it (science.unitn.it [193.205.194.23]) by mailhub2.unitn.it (Postfix) with ESMTP id 20537B0D3D3; Thu, 14 Oct 2010 09:59:08 +0200 (CEST) Received: by science.unitn.it with ESMTP id o9E7x7MB028706; Thu, 14 Oct 2010 09:59:07 +0200 Message-Id: <0E32E27F-1211-498F-BE6B-64F9C0E90D13@ifi.uio.no> From: Michael Welzl To: "Mayutan A." In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 14 Oct 2010 09:59:41 +0200 References: <20101009004622.772783A69A3@core3.amsl.com> <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> X-Mailer: Apple Mail (2.936) Cc: "ledbat@ietf.org" , Rolf Winter Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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, 14 Oct 2010 07:57:52 -0000 great! thank you so much! On Oct 14, 2010, at 7:46 AM, Mayutan A. wrote: > I have been working on this topic too and will review this document. > > Mayutan > > > On Wed, Oct 13, 2010 at 8:37 PM, Rolf Winter =20= > wrote: > Hi, > > as mentioned earlier, I would like to have at least 3 people from =20 > the group that agree to do a thorough review of this draft (well =20 > written, reasonably complete, correct etc). Volunteers please speak =20= > up! A lot of people on the list have been working in this field and =20= > should be able to do this easily e.g. Mirja, Dario and others. > > Best, > > Rolf > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, =20= > London W3 6BL | Registered in England 2832014 > > > > -----Original Message----- > > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > > Behalf Of David Ros > > Sent: Samstag, 9. Oktober 2010 02:59 > > To: ledbat@ietf.org > > Subject: [ledbat] Fwd: New Version Notification for draft-ietf-=20 > ledbat- > > survey-01 > > > > Dear all, > > > > We've posted an update to the survey draft, see announcement below. > > Comments are very welcome. > > > > Thanks in advance, > > > > David. > > > > > > D=E9but du message r=E9exp=E9di=E9 : > > > > > De : IETF I-D Submission Tool > > > Date : 9 octobre 2010 02:46:22 HAEC > > > =C0 : david.ros@telecom-bretagne.eu > > > Cc : michawe@ifi.uio.no > > > Objet : New Version Notification for draft-ietf-ledbat-survey-01 > > > > > > > > > A new version of I-D, draft-ietf-ledbat-survey-01.txt has been > > successfully submitted by David Ros and posted to the IETF =20 > repository. > > > > > > Filename: draft-ietf-ledbat-survey > > > Revision: 01 > > > Title: A Survey of Lower-than-Best-Effort Transport > > Protocols > > > Creation_date: 2010-10-09 > > > WG ID: ledbat > > > Number_of_pages: 16 > > > > > > Abstract: > > > This document provides a survey of transport protocols which are > > > designed to have a smaller bandwidth and/or delay impact on =20 > standard > > > TCP than standard TCP itself when they share a bottleneck with it. > > > Such protocols could be used for low-priority "background" =20 > traffic, > > > as they provide what is sometimes called a "less than" (or "lower > > > than") best-effort service. > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > David ROS > > http://www.rennes.enst-bretagne.fr/~dros/ > > > > I love deadlines. I like the whooshing sound they make as they fly =20= > by. > > -- Douglas Adams > > > > > > > > > > _______________________________________________ > > ledbat mailing list > > ledbat@ietf.org > > https://www.ietf.org/mailman/listinfo/ledbat > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > > > > --=20 > Mayutan Arumaithurai > 0049-551-2712647 (Home number) > 0049-176-20322049 (mobile number) > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From David.Ros@telecom-bretagne.eu Thu Oct 14 01:13:48 2010 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 730103A68A8 for ; Thu, 14 Oct 2010 01:13:48 -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_FR=0.35] 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 DPSi7B++2b+n for ; Thu, 14 Oct 2010 01:13:45 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id 769973A6832 for ; Thu, 14 Oct 2010 01:13:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o9E8F31P014607; Thu, 14 Oct 2010 10:15:03 +0200 Received: from courrier.enst-bretagne.fr (vss-mail-02.priv.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o9E8EwHD014563; Thu, 14 Oct 2010 10:15:01 +0200 Received: from dhcp-salsa-i168.rennes.enst-bretagne.fr (dhcp-salsa-i168.rennes.enst-bretagne.fr [10.35.128.168]) (user=dros mech=PLAIN bits=0) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2010.02.22) with ESMTP id o9E8EDmf011264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Oct 2010 10:14:56 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: David Ros In-Reply-To: <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> Date: Thu, 14 Oct 2010 10:14:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101009004622.772783A69A3@core3.amsl.com> <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> To: ledbat@ietf.org X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: amavisd-new at enst-bretagne.fr Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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, 14 Oct 2010 08:13:48 -0000 Hi all, Thanks a lot to Mirja and Mayutan for volunteering! Hoping to seeing you in Beijing, David. Le 13 oct. 2010 =E0 20:37, Rolf Winter a =E9crit : > Hi, >=20 > as mentioned earlier, I would like to have at least 3 people from the = group that agree to do a thorough review of this draft (well written, = reasonably complete, correct etc). Volunteers please speak up! A lot of = people on the list have been working in this field and should be able to = do this easily e.g. Mirja, Dario and others. >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 >=20 >=20 >> -----Original Message----- >> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On >> Behalf Of David Ros >> Sent: Samstag, 9. Oktober 2010 02:59 >> To: ledbat@ietf.org >> Subject: [ledbat] Fwd: New Version Notification for = draft-ietf-ledbat- >> survey-01 >>=20 >> Dear all, >>=20 >> We've posted an update to the survey draft, see announcement below. >> Comments are very welcome. >>=20 >> Thanks in advance, >>=20 >> David. >>=20 >>=20 >> D=E9but du message r=E9exp=E9di=E9 : >>=20 >>> De : IETF I-D Submission Tool >>> Date : 9 octobre 2010 02:46:22 HAEC >>> =C0 : david.ros@telecom-bretagne.eu >>> Cc : michawe@ifi.uio.no >>> Objet : New Version Notification for draft-ietf-ledbat-survey-01 >>>=20 >>>=20 >>> A new version of I-D, draft-ietf-ledbat-survey-01.txt has been >> successfully submitted by David Ros and posted to the IETF = repository. >>>=20 >>> Filename: draft-ietf-ledbat-survey >>> Revision: 01 >>> Title: A Survey of Lower-than-Best-Effort Transport >> Protocols >>> Creation_date: 2010-10-09 >>> WG ID: ledbat >>> Number_of_pages: 16 >>>=20 >>> Abstract: >>> This document provides a survey of transport protocols which are >>> designed to have a smaller bandwidth and/or delay impact on standard >>> TCP than standard TCP itself when they share a bottleneck with it. >>> Such protocols could be used for low-priority "background" traffic, >>> as they provide what is sometimes called a "less than" (or "lower >>> than") best-effort service. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> David ROS >> http://www.rennes.enst-bretagne.fr/~dros/ >>=20 >> I love deadlines. I like the whooshing sound they make as they fly = by. >> -- Douglas Adams >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> ledbat mailing list >> ledbat@ietf.org >> https://www.ietf.org/mailman/listinfo/ledbat >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David ROS http://www.rennes.enst-bretagne.fr/~dros/ I love deadlines. I like the whooshing sound they make as they fly by. = -- Douglas Adams From mayutan.arumaithurai@gmail.com Fri Oct 15 06:55:07 2010 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 D77483A6A18 for ; Fri, 15 Oct 2010 06:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, 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 hGM8df7OCSSG for ; Fri, 15 Oct 2010 06:55:05 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 7359B3A68E1 for ; Fri, 15 Oct 2010 06:55:04 -0700 (PDT) Received: by qyk8 with SMTP id 8so1477656qyk.10 for ; Fri, 15 Oct 2010 06:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=3LyeIoLu/JV2H+yz/fLL9KuczC6fuBy2+W2Tj2k9O44=; b=HBQECI4B1M8ahMv6GyqqeGYhzcQuopsKx5SB8TBuioYrHedw5h5jlBosiRPZpudQUv kBGvkoTr2tTSybgSsXwJs5WtxWBgvGueyykA9wEm+7vHYBdvMeRKW9fGtFE6cftfJjcn 4egxDUa+li0iZYfyo17YAPtyumiZshB8n85Pc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=X3vNW0Eg/aRWUQRtDXmjvRLMkSuoNFilxVvqBgNTAHfFagws9vPVtp1n7jcI3NMGWM Rh1ng5GIgK3p8qzRljbwePwufYltLMyVtRB3K2VAo4+0ZiPTNRtC4RLAsdQbDvRp7m/m Bg3VbvQtkZbFZxDsHC28FK8fv6fAnIC253BIA= Received: by 10.224.49.72 with SMTP id u8mr9045681qaf.9.1287150985196; Fri, 15 Oct 2010 06:56:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.130.88 with HTTP; Fri, 15 Oct 2010 06:56:05 -0700 (PDT) In-Reply-To: References: <20101009004622.772783A69A3@core3.amsl.com> <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> From: "Mayutan A." Date: Fri, 15 Oct 2010 15:56:05 +0200 Message-ID: To: David Ros Content-Type: multipart/alternative; boundary=001485e7c4043eb50e0492a8310e Cc: ledbat@ietf.org Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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, 15 Oct 2010 13:55:08 -0000 --001485e7c4043eb50e0492a8310e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I have finished a round of reviewing and here are my comments: Overall, the document does not compare the goals of the LEDBAT WG to the state of the art. Therefore it is very difficult to identify with the pros and cons of the mentioned approaches. Moreover, it is difficult to see why LEDBAT was developed instead of using TCP-Vegas, TCP-LP and etc. I feel that the draft is taking a neutral approach by just mentioning the existing approaches, and leaves it to the readers to figure out what LEDBAT is trying to do differently. My apologies in case I missed out on the early discussions where such a decision was taken. Some minor comments: 1) Abstract: I am not comfortable with the usage of the term "low-prioritybackground traffic". It might be better to use a term that is consistent with the ledbat-congestion control draft and the terms used in the LEDBAT WG. The LEDBAT WG, describes applications such as VoIP as delay-sensitive, therefore it might be appropriate to use the term delay-insensitive. Or use the term "less-than-best-effort "background" transmissions", to be consistent with the LEDBAT WG charter. 2) TCP vegas: The draft states that "TCP Vegas [Bra+94] is one of the first protocols that was known to have a smaller sending rate than standard TCP when both protocols share a bottleneck [Kur+00] -- yet it was designed to achieve more, not less throughput than standard TCP. " 2.a ) What is the point of this statement? Does it imply that it is not a good candidate for a LEDBAT like protocol? "Indeed, when it is the only protocol on the bottleneck, the throughput of TCP Vegas is greater than the throughput of standard TCP. " 2.b) Again does this statement imply that it is not a good candidate for a LEDBAT like approach? Depending on the bottleneck queue length, TCP Vegas itself can be starved by standard TCP flows. This can be remedied to some degree by the RED Active Queue Management mechanism [RFC2309]." 2.c) Is TCP Vegas being starved a positive or a negative with regards to the goals of the LEDBAT WG? 3) In Section-2, 5th para, TCP-LP and TCP-Nice are mentioned. In the same para, there is an additional line about TCP-LP. The next para (6th para) talks about TCP-Nice and then the 7th para onwards the draft talks about TCP-LP. This i= s a bit confusing. I suggest that it is reorganized it a bit. 4) Section -2, 8th Para: The draft states: "Regarding its reaction to an early congestion indication, TCP-LP tries to strike a middle ground between the overly conservative choice of immediately setting the congestion window to one packet and the presumably too aggressive choice of halving the congestion window like standard TCP." Why does the draft state that TCP-LP takes a middle ground approach. TCP-LP also reduces its congestion window by half, similar to TCP. 5) Section 3: How is MulTCP a candidate for LEDBAT like approach if it trie= s to be as friendly as N TCP flows (where N is greater than or equal to 1)? 6) In section 4: It would be nice to mention some of the advantages/disadvantages of an application layer approach. Mayutan On Thu, Oct 14, 2010 at 10:14 AM, David Ros wrote: > Hi all, > > Thanks a lot to Mirja and Mayutan for volunteering! > > Hoping to seeing you in Beijing, > > David. > > > Le 13 oct. 2010 =C3=A0 20:37, Rolf Winter a =C3=A9crit : > > > Hi, > > > > as mentioned earlier, I would like to have at least 3 people from the > group that agree to do a thorough review of this draft (well written, > reasonably complete, correct etc). Volunteers please speak up! A lot of > people on the list have been working in this field and should be able to = do > this easily e.g. Mirja, Dario and others. > > > > Best, > > > > Rolf > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > > >> -----Original Message----- > >> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > >> Behalf Of David Ros > >> Sent: Samstag, 9. Oktober 2010 02:59 > >> To: ledbat@ietf.org > >> Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat- > >> survey-01 > >> > >> Dear all, > >> > >> We've posted an update to the survey draft, see announcement below. > >> Comments are very welcome. > >> > >> Thanks in advance, > >> > >> David. > >> > >> > >> D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : > >> > >>> De : IETF I-D Submission Tool > >>> Date : 9 octobre 2010 02:46:22 HAEC > >>> =C3=80 : david.ros@telecom-bretagne.eu > >>> Cc : michawe@ifi.uio.no > >>> Objet : New Version Notification for draft-ietf-ledbat-survey-01 > >>> > >>> > >>> A new version of I-D, draft-ietf-ledbat-survey-01.txt has been > >> successfully submitted by David Ros and posted to the IETF repository. > >>> > >>> Filename: draft-ietf-ledbat-survey > >>> Revision: 01 > >>> Title: A Survey of Lower-than-Best-Effort Transport > >> Protocols > >>> Creation_date: 2010-10-09 > >>> WG ID: ledbat > >>> Number_of_pages: 16 > >>> > >>> Abstract: > >>> This document provides a survey of transport protocols which are > >>> designed to have a smaller bandwidth and/or delay impact on standard > >>> TCP than standard TCP itself when they share a bottleneck with it. > >>> Such protocols could be used for low-priority "background" traffic, > >>> as they provide what is sometimes called a "less than" (or "lower > >>> than") best-effort service. > >>> > >>> > >>> > >>> The IETF Secretariat. > >>> > >>> > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> David ROS > >> http://www.rennes.enst-bretagne.fr/~dros/ > >> > >> I love deadlines. I like the whooshing sound they make as they fly by. > >> -- Douglas Adams > >> > >> > >> > >> > >> _______________________________________________ > >> ledbat mailing list > >> ledbat@ietf.org > >> https://www.ietf.org/mailman/listinfo/ledbat > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David ROS > http://www.rennes.enst-bretagne.fr/~dros/ > > I love deadlines. I like the whooshing sound they make as they fly by. -- > Douglas Adams > > > > > --=20 Mayutan Arumaithurai 0049-551-2712647 (Home number) 0049-176-20322049 (mobile number) --001485e7c4043eb50e0492a8310e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi a= ll,=C2=A0

I have finished a round of reviewing and= here are my comments:

Overall, the document does not compare the goals of the = LEDBAT WG to the state of the art. Therefore it is very difficult to identi= fy with=C2=A0
t= he pros and cons of the mentioned approaches. Moreover, it is difficult to = see why LEDBAT was developed instead of=C2=A0
using TCP-Vegas, TCP-LP and etc.=C2=A0I feel that the draft is taking a ne= utral approach by just mentioning the existing approaches, and leaves it to= the readers to figure out what LEDBAT is trying to do differently. My=C2= =A0apologies in case=C2=A0I missed out on the early discussions where such = a decision was taken.=C2=A0

Some minor comments:

1) Abstract: I am not comfortable with the usage of the term = "low-priority background traffic". It=C2=A0
might=C2=A0be better to use a term that is consistent with the ledbat-cong= estion control draft
and the terms used in the LEDBAT WG. The = LEDBAT WG,=C2=A0
describes applications such as VoIP as delay-sensitive, therefore it might= be appropriate to use the term delay-insensitive. =C2=A0Or
= =C2=A0use the term "less-than-best-effort "background" transmissi= ons", to be consistent with the LEDBAT WG charter.= =C2=A0 <= br>
2) TCP vegas: The draft states that=C2=A0
"TCP Vegas [Bra+94] is = one of the first protocols that was known to

   have a smaller sending ra=
te than standard TCP when both protocols
   share a bottleneck [Kur+00] -- yet it was designed to achieve more,
   not less throughput than standard TCP. =C2=A0"
<= pre style=3D"line-height: 1.2em; margin-top: 0px; margin-right: 0px; margin= -bottom: 0px; margin-left: 0px; ">
2.a ) What is the point of this=
 statement? Does it imply that it is not a 
good candidate for a LEDBAT like protocol? <=
/font>


   "Indeed, when it =
is the only
   protocol on the bottleneck, the throughput of TCP Vegas is grea=
ter
   than the throughput of standard TCP.=C2=A0"
2.b) Again does this statement imply that it is = not a good candidate for a LEDBAT 
like approach? 


=

   Depending on the bottleneck
   queue length, TCP Vegas itself can be starved by standard TCP flows.
  =C2=A0This c=
an be remedied to some degree by the RED Active Queue
Management mechanism [RFC230= 9].= &quo= t;<= font class=3D"Apple-style-span" face=3D"arial, helvetica, sans-serif">=C2= =A0
2.c) Is TCP Vegas being starved a positive or a negative with regards to= =C2=A0
the goals of the LEDBAT WG?

3) In Section-2, 5th para, TCP-LP and TCP-Nice are menti= oned. In the same=C2=A0
para, there is an additional line about TCP-LP. The next para (6th para) t= alks about=C2=A0
TCP-Nice and then the 7th para onwards the dr= aft talks about TCP-LP. This is a bit confusing.=C2=A0
I suggest that it is reorganized it a bit.=C2=A0

<= /div>
4) S= ection -2, 8th Para: The draft states:
"Regarding its reaction to an early congestion = indication, TCP-LP

   tries to strike a middle =
ground between the overly conservative
   choice of immediately setting the congestion window to one packet and
   the presumably too aggressive choice of halving the congestion window=C2=
=A0
like standard TCP."

Why does the draft state that TCP-LP takes a middle grou= nd approach. TCP-LP=C2=A0
also reduces its congestion window by half, similar to TCP. =C2=A0<= /div>
=C2=A0
5) Section 3: How is MulTCP a candidate for LEDBAT like approach if it tri= es to be as friendly as N TCP flows (where N is greater than or equal to 1)= ?=C2=A0
=C2=A0
6) In section 4: It would be nice to mention some of t= he advantages/disadvantages of an application layer approach.=C2=A0<= /div>

Mayutan
=C2=A0

On Thu, Oct 14, 2010 at 10:14 AM, David = Ros <David.Ros@telecom-bretagne.eu> wrote:
Hi all,

Thanks a lot to Mirja and Mayutan for volunteering!

Hoping to seeing you in Beijing,

David.


Le 13 oct. 2010 =C3=A0 20:37, Rolf Winter a =C3=A9crit :

> Hi,
>
> as mentioned earlier, I would like to have at least 3 people from the = group that agree to do a thorough review of this draft (well written, reaso= nably complete, correct etc). Volunteers please speak up! A lot of people o= n the list have been working in this field and should be able to do this ea= sily e.g. Mirja, Dario and others.
>
> Best,
>
> =C2=A0 =C2=A0 =C2=A0 Rolf
>
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lo= ndon W3 6BL | Registered in England 2832014
>
>
>> -----Original Message-----
>> From: ledbat-bounces= @ietf.org [mailto:= ledb= at-bounces@ietf.org] On
>> Behalf Of David Ros
>> Sent: Samstag, 9. Oktober 2010 02:59
>> To: ledbat@ietf.org >> Subject: [ledbat] Fwd: New Version Notification for draft-ietf-led= bat-
>> survey-01
>>
>> Dear all,
>>
>> We've posted an update to the survey draft, see announcement b= elow.
>> Comments are very welcome.
>>
>> Thanks in advance,
>>
>> David.
>>
>>
>> D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 :
>>
>>> De : IETF I-D Submission Tool <idsubmission@ietf.org>
>>> Date : 9 octobre 2010 02:46:22 HAEC
>>> =C3=80 : d= avid.ros@telecom-bretagne.eu
>>> Cc : michawe@ifi.uio= .no
>>> Objet : New Version Notification for draft-ietf-ledbat-survey-= 01
>>>
>>>
>>> A new version of I-D, draft-ietf-ledbat-survey-01.txt has been=
>> successfully submitted by David Ros and posted to the IETF reposit= ory.
>>>
>>> Filename: =C2=A0 =C2=A0draft-ietf-ledbat-survey
>>> Revision: =C2=A0 =C2=A001
>>> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A Surv= ey of Lower-than-Best-Effort Transport
>> Protocols
>>> Creation_date: =C2=A0 =C2=A0 =C2=A0 2010-10-09
>>> WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ledbat=
>>> Number_of_pages: 16
>>>
>>> Abstract:
>>> This document provides a survey of transport protocols which a= re
>>> designed to have a smaller bandwidth and/or delay impact on st= andard
>>> TCP than standard TCP itself when they share a bottleneck with= it.
>>> Such protocols could be used for low-priority "background= " traffic,
>>> as they provide what is sometimes called a "less than&quo= t; (or "lower
>>> than") best-effort service.
>>>
>>>
>>>
>>> The IETF Secretariat.
>>>
>>>
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> David ROS
>> http://www.rennes.enst-bretagne.fr/~dros/
>>
>> I love deadlines. I like the whooshing sound they make as they fly= by.
>> -- Douglas Adams
>>
>>
>>
>>
>> _______________________________________________
>> ledbat mailing list
>> ledbat@ietf.org
>> https://www.ietf.org/mailman/listinfo/ledbat
>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David ROS
 http://= www.rennes.enst-bretagne.fr/~dros/

I love deadlines. I like the whooshing sound they make as they fly by. -- D= ouglas Adams



--
Mayutan Arumait= hurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile numbe= r)
--001485e7c4043eb50e0492a8310e-- From mirja.kuehlewind@ikr.uni-stuttgart.de Sun Oct 17 09:40:56 2010 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 960983A6971 for ; Sun, 17 Oct 2010 09:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 fJbo651dv90b for ; Sun, 17 Oct 2010 09:40:55 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id B0BA53A69FF for ; Sun, 17 Oct 2010 09:40:54 -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 3BD14633B9; Sun, 17 Oct 2010 18:42:19 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 0216F59A8A; Sun, 17 Oct 2010 18:42:18 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: ledbat@ietf.org Date: Sun, 17 Oct 2010 18:42:18 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201010171842.18245.mkuehle@ikr.uni-stuttgart.de> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Rolf Winter Subject: [ledbat] Review of draft-ietf-ledbat-survey-01 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: Sun, 17 Oct 2010 16:40:56 -0000 Hi, before giving a detailed review I would like to give you a short overview what I was generally expecting to be the content of this doc before reading it. I was hoping to get the following question answered: 1. Which protocols do exist and how do they work? I would suggest to mention all protocols by name. Sometimes you just put the reference, which makes it harder to follow the text. Maybe even have a separate subsection for each protocol. That helps to achieve a faster overview. About the description how a protocol works I wasn't always able to understand your all explanations without looking up the original paper. Sometimes it was more written like a related work section, which is not intended to be completely understandable but gives the right pointers if something sounds intresting. I think this doc should be understandable without looking up the references. (see later detailed comments as well) 2. What are the advantages and disadvantages of a protocol? This is only discussed completely for some of the protocol so far. I would except this to be more explicit for every described protocol. 3. How do the protocols differ from each other? Would be nice to have a paragraph at the beginning or the end that goes quickly through all the described protocols and explains the differences or the one specific feature about a protocol compared to others. I don't know if those questions go in-line with what your goals are in this doc. But if yes, I think they are not fully addressed yet. Here the more detailed comments: 1. Introduction: ------------------- I don't understand your classification. What does 'non-delay-based' and 'orthogonal' actually mean? I guess the delay-based ones are mainly scavenger protocol which means they are not only lower than best effort but moreover try to be non-intrusive. Whereas the non-delay-based one just try to be less aggressive than TCP. I'm also not sure if 'application layer approaches' is the right term. Some of the approaches are actually implemented in Linux and not in application layer...? But all of them assume to have some application knowledge, i guess (as well as some of the approaches mention in section 5 'orthogonal work'). 'Orthogonal work' mostly refers to approaches with network-support...? 2. Delay-based transport protocol ------------------- 1. paragraph: - the connection to delay is missing - maybe give an overview which protocols will be discussed first and then have differnet subsections for the protocols 3. paragraph: "The congestion avoidance behavior is the protocol's most important feature in terms of historical relevance as well as relevance in the context of this document (it has been shown that other elements of the protocol can sometimes play a greater role for its overall behavior [Hen+00])." Congestion Avoidance is not explained/introduced. But why is this information need here? - The explanation of TCP Veags seems quite complicated. Maybe give first an overview in one sentence like: " TCP Vegas linearly increases or decreases the rate based on the difference of estimated throughput and actual troughput. The estimation is based on RTT measurements." - I would say to write "linear increase" is not enough. I would explicitly write "linear increase by one segment per RTT" - Disadvantages of TCP Vegas should be discussed here as well. 4. paragraph: I looked at the reference Bra+94. I could only find one reference to another delay-based protocol. Maybe I looked wrong but please check. But I would anyway prefer to have protocol names instead of a (random) reference. And maybe move this whole paragraph to the beginning of this section. The structure of this section is quite hard to follow. 5. paragraph: - Move to beginning of section? Otherwise the link to non-intrusive protocol in general is missing. - I would introduce the protocol with the full name -> TCP Low Priority (TCP-LP) - What does "...due to the non-linear relationship between throughput and RTT mean". This is quite hard to understand without reading the reference. I would prefer to have those things more explained instead of just giving the reference. - "... have a larger RTT than standard TCP flows". I though the problem is if they have a smaller RTT. Please explain. 6. paragraph (TCP-Nice): - What is "... a fixed predefined fraction of delay-based incipient congestion signals"? Please give more details. - "One more feature of TCP-Nice is the ability to support a congestion window of less than one packt..." It this a specific feature of TCP-Nice or could every other protocol do this as well. If so I would phrase that differently e.g. "Furthermore, TCP-Nice introduced a way to..." - "the authors of [Ven+02] show that TCP Nice achieves its goal of efficiently utilizing spare capacity..." What does efficiently mean? 7. paragraph (TCP-LP): s/TCP-LP uses only the one-way delay/TCP-LP uses only the variation of one-way delay/ 8. paragraph: What does "maintaining the window size" mean? 9. paragraph: What does "largely non-intrusive" mean? I know, it is hard to give a short overview of a protocol without going to much into detail but still keep the important bits. But I'm afraid these vague information doesn't help the reader a lot. 10. paragraph (Sync-TCP): - I looked a the paper and I don't see what you mean by "Sync-TCP adapts the parameters...". What they do is, they try to synchronize all flow to do the same thing at the same time by using a parametrization which needs to be the same for all flow globally. I think that's a very bad idea. And this should be explained here. Furthermore, they actually wait a while until they react to congestion to be sure that every other flow got the signal as well. Not sure about this idea neither. Please explain Sync-TCP more detailed and discuss advantages and disadvantages. 11. paragraph: Please mention the names of the protocol instead of just giving the reference that makes it easier to follow. 2.1. Accuracy of delay-based congestion predictors -------------------- - Are those points given in a specific order? I think the most import one should come first. - I looked up Fig 2 in McC+08. I don't see the point and Fig. 2 didn't even seemed to be explained... please check. - Another point is, that the minmum delay you measure is usually not the actual base delay if there is permanently traffic on the link. Thus different flows might operate with different values for the base delay. - But I'm not sure if this whole section belongs into this doc. Some of the points are discussed in the LEDBAT protocol spec. 2.2. Delay-based congestion control = LBE? -------------------- - I think these are the more important points. Maybe merge the previous section with this one. I would prefer a different title for this section... 3. Non-delay-based transport protocol --------------------- - There should be some introduction what this section is about/ what the common thing of the protocols explained here is. - 2. paragraph: Only the case where the weight is smaller than 1 actually belong here. Maybe take the 3. paragraph first. - A general discussion what is good or bad about these approaches is missing. 4. Application layer approaches -------------------- - Again, give an overview first. - "A simplistic, application-level approach to a background transport service may just consist in scheduling automated transfers at times when the network is lightly loaded, as described in e.g. [Dyk+02]." This sentence sounds wired to me, maybe s/consist in scheduling/be to schedule/ - Why don't you say that this approach is about 'cooperative proxy caching'? That would make it much easier to understand for me. - In the 2. paragraphyou talk about a "Linux implemenation". I guess that is not really application layer anymore than...? As mention before, I don't really see your classification. - 3. paragraph: "A similar method..." I don't see the similarity except that there are both receiver-based. I would e.g. take 'having receiver involvement' for classification. 5. paragraph: Is this approach is really non-intrusive? I guess you disturb a TCP flow as long as your rate is not zero and you probably can disturb a lot if your minimun rate is too high for a given bottleneck. 6. paragraph: This is only done on your own interface to not distrub other flows from the same system right? Its nothing about TCP flows from other systems, right? Please make this clear. - Are all this approaches actually belonging in this doc? Maybe don't discuss in such a detail or if your think they are important please discuss use cases and advantages/disadvantages. Or maybe just change the structure to make the link to Lower-than-Best-Effort Transport Protocols more clear. I don't know... 5. Orthogonal work -------------------- - I guess the right classification would be 'with network support'...? - NF-TCP is also delay-based. Not sure where this protocol belongs in your classification, but it seems to be added later on to this place. - Please discuss pros and cons Maybe add a summary at the end to show the most important features/difference of the discussed approaches. This would help to get a better overall view of this area. Hope my comments help. Mirja From David.Ros@telecom-bretagne.eu Mon Oct 18 13:32:41 2010 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 26B9A3A6E3D for ; Mon, 18 Oct 2010 13:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_QP_LONG_LINE=1.396] 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 K024Iy+Ji+2G for ; Mon, 18 Oct 2010 13:32:34 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id A583F3A6E99 for ; Mon, 18 Oct 2010 13:32:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o9IKXrsX007492; Mon, 18 Oct 2010 22:33:53 +0200 Received: from courrier.enst-bretagne.fr (vss-mail-02.priv.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o9IKXivj007458; Mon, 18 Oct 2010 22:33:48 +0200 Received: from [192.168.0.10] (passerelle-interne.enst-bretagne.fr [192.108.117.210]) (user=dros mech=PLAIN bits=0) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2010.02.22) with ESMTP id o9IKXdEa007378; Mon, 18 Oct 2010 22:33:39 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: David Ros In-Reply-To: Date: Mon, 18 Oct 2010 22:33:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34F992CD-6D0B-445F-87D7-BE1E5E625E11@telecom-bretagne.eu> References: <20101009004622.772783A69A3@core3.amsl.com> <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> To: "Mayutan A." X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: ledbat@ietf.org Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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, 18 Oct 2010 20:32:41 -0000 Le 15 oct. 2010 =E0 15:56, Mayutan A. a =E9crit : > Hi all,=20 >=20 > I have finished a round of reviewing and here are my comments: Hi, Mayutan, thanks a lot for the review. Comments inline... > Overall, the document does not compare the goals of the LEDBAT WG to = the state of the art. Therefore it is very difficult to identify with=20 > the pros and cons of the mentioned approaches. Moreover, it is = difficult to see why LEDBAT was developed instead of=20 > using TCP-Vegas, TCP-LP and etc. I feel that the draft is taking a = neutral approach by just mentioning the existing approaches, and leaves = it to the readers to figure out what LEDBAT is trying to do differently. = My apologies in case I missed out on the early discussions where such a = decision was taken.=20 I'm myself a latecomer (LEDBAT pun intended) to this draft, thus, I may = have missed some old discussions; I'll let Michael chime in if needed. = However, AFAIK such a discussion never took place, so the draft has = adopted a neutral stance. The point of the document, it seems to us, is = to show that LEDBAT is not the only existing algorithm and that there = are other related approaches out there. > Some minor comments: >=20 > 1) Abstract: I am not comfortable with the usage of the term = "low-priority background traffic". It=20 > might be better to use a term that is consistent with the = ledbat-congestion control draft > and the terms used in the LEDBAT WG. The LEDBAT WG,=20 > describes applications such as VoIP as delay-sensitive, therefore it = might be appropriate to use the term delay-insensitive. Or > use the term "less-than-best-effort "background" transmissions", to = be consistent with the LEDBAT WG charter.=20 We have no particular preference on this, though "low-priority" = immediately suggests "LBE service" to us. =3D> We have no problem with changing the wording to = "delay-insensitive". > 2) TCP vegas: The draft states that=20 > "TCP Vegas [Bra+94] is one of the first protocols that was known to >=20 > have a smaller sending rate than standard TCP when both protocols > share a bottleneck [Kur+00] -- yet it was designed to achieve more, > not less throughput than standard TCP. " >=20 > 2.a ) What is the point of this statement? Does it imply that it is = not a=20 > good candidate for a LEDBAT like protocol?=20 >=20 > "Indeed, when it is the only > protocol on the bottleneck, the throughput of TCP Vegas is greater > than the throughput of standard TCP. " >=20 > 2.b) Again does this statement imply that it is not a good candidate = for a LEDBAT=20 > like approach?=20 >=20 > Depending on the bottleneck > queue length, TCP Vegas itself can be starved by standard TCP = flows. > =20 > This can be remedied to some degree by the RED Active Queue > Management mechanism [RFC2309]."=20 > 2.c) Is TCP Vegas being starved a positive or a negative with regards = to=20 > the goals of the LEDBAT WG? As I said above, the draft takes a neutral stance -- it simply reports = some facts about Vegas. > 3) In Section-2, 5th para, TCP-LP and TCP-Nice are mentioned. In the = same=20 > para, there is an additional line about TCP-LP. The next para (6th = para) talks about=20 > TCP-Nice and then the 7th para onwards the draft talks about TCP-LP. = This is a bit confusing.=20 > I suggest that it is reorganized it a bit.=20 Thanks for the suggestion, we'll do it. > 4) Section -2, 8th Para: The draft states: > "Regarding its reaction to an early congestion indication, TCP-LP >=20 > tries to strike a middle ground between the overly conservative > choice of immediately setting the congestion window to one packet = and > the presumably too aggressive choice of halving the congestion = window=20 >=20 > like standard TCP." >=20 > Why does the draft state that TCP-LP takes a middle ground approach. = TCP-LP=20 > also reduces its congestion window by half, similar to TCP. =20 My understanding of TCP-LP is as follows, please feel free to correct = me. When receiving the first early congestion indication, TCP-LP does indeed = halve the window, as you say. Then it starts a so-called "inference = timer" (the authors suggest setting such timer to 3 RTTs). If in the = next RTT there's yet another early congestion indication, and the = inference timer has not expired, then the window is set to 1. So the "middle ground" is between *immediately* decreasing the window to = 1 and simply halving it, like plain TCP; they try to delay the former = action by an additional RTT, to see if there is persistent congestion or = not. =3D> There's perhaps a wording issue here (BTW, the authors of TCP-LP = employ some similar terms -- they talk about a "compromise"). We may try = to explain this a little better. > 5) Section 3: How is MulTCP a candidate for LEDBAT like approach if = it tries to be as friendly as N TCP flows (where N is greater than or = equal to 1)?=20 This is Michael being too modest about his own work :-). You are right, = the focus here should be on MulTFRC, since it can use an N between 0 and = 1. However, by allowing N < 1 MulTFRC takes one basic idea of MulTCP a = step further, so MulTCP & similar approaches should perhaps be mentioned = but, clearly, *not* suggesting that they are somehow an alternative for = an LBE transport. =3D> Thanks for the remark, we'll try to make this clearer. > =20 > 6) In section 4: It would be nice to mention some of the = advantages/disadvantages of an application layer approach.=20 >=20 Thanks for the suggestion, we'll do it. Again, thanks a lot for the remarks! David. > Mayutan > =20 >=20 > On Thu, Oct 14, 2010 at 10:14 AM, David Ros = wrote: > Hi all, >=20 > Thanks a lot to Mirja and Mayutan for volunteering! >=20 > Hoping to seeing you in Beijing, >=20 > David. >=20 >=20 > Le 13 oct. 2010 =E0 20:37, Rolf Winter a =E9crit : >=20 > > Hi, > > > > as mentioned earlier, I would like to have at least 3 people from = the group that agree to do a thorough review of this draft (well = written, reasonably complete, correct etc). Volunteers please speak up! = A lot of people on the list have been working in this field and should = be able to do this easily e.g. Mirja, Dario and others. > > > > Best, > > > > Rolf > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 > > > > > >> -----Original Message----- > >> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > >> Behalf Of David Ros > >> Sent: Samstag, 9. Oktober 2010 02:59 > >> To: ledbat@ietf.org > >> Subject: [ledbat] Fwd: New Version Notification for = draft-ietf-ledbat- > >> survey-01 > >> > >> Dear all, > >> > >> We've posted an update to the survey draft, see announcement below. > >> Comments are very welcome. > >> > >> Thanks in advance, > >> > >> David. > >> > >> > >> D=E9but du message r=E9exp=E9di=E9 : > >> > >>> De : IETF I-D Submission Tool > >>> Date : 9 octobre 2010 02:46:22 HAEC > >>> =C0 : david.ros@telecom-bretagne.eu > >>> Cc : michawe@ifi.uio.no > >>> Objet : New Version Notification for draft-ietf-ledbat-survey-01 > >>> > >>> > >>> A new version of I-D, draft-ietf-ledbat-survey-01.txt has been > >> successfully submitted by David Ros and posted to the IETF = repository. > >>> > >>> Filename: draft-ietf-ledbat-survey > >>> Revision: 01 > >>> Title: A Survey of Lower-than-Best-Effort Transport > >> Protocols > >>> Creation_date: 2010-10-09 > >>> WG ID: ledbat > >>> Number_of_pages: 16 > >>> > >>> Abstract: > >>> This document provides a survey of transport protocols which are > >>> designed to have a smaller bandwidth and/or delay impact on = standard > >>> TCP than standard TCP itself when they share a bottleneck with it. > >>> Such protocols could be used for low-priority "background" = traffic, > >>> as they provide what is sometimes called a "less than" (or "lower > >>> than") best-effort service. > >>> > >>> > >>> > >>> The IETF Secretariat. > >>> > >>> > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> David ROS > >> http://www.rennes.enst-bretagne.fr/~dros/ > >> > >> I love deadlines. I like the whooshing sound they make as they fly = by. > >> -- Douglas Adams > >> > >> > >> > >> > >> _______________________________________________ > >> ledbat mailing list > >> ledbat@ietf.org > >> https://www.ietf.org/mailman/listinfo/ledbat > > >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David ROS > http://www.rennes.enst-bretagne.fr/~dros/ >=20 > I love deadlines. I like the whooshing sound they make as they fly by. = -- Douglas Adams >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Mayutan Arumaithurai > 0049-551-2712647 (Home number)=20 > 0049-176-20322049 (mobile number) > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David ROS http://www.rennes.enst-bretagne.fr/~dros/ I love deadlines. I like the whooshing sound they make as they fly by. = -- Douglas Adams From Rolf.Winter@neclab.eu Wed Oct 27 01:40:33 2010 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 442483A6923 for ; Wed, 27 Oct 2010 01:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.878 X-Spam-Level: X-Spam-Status: No, score=-101.878 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 jkRKuuVEXQdF for ; Wed, 27 Oct 2010 01:40:32 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 508743A677E for ; Wed, 27 Oct 2010 01:40:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 4E4632800017D for ; Wed, 27 Oct 2010 10:42:21 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 872NWbaMxq6n for ; Wed, 27 Oct 2010 10:42:21 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3270B2800017A for ; Wed, 27 Oct 2010 10:42:16 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.152]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0255.000; Wed, 27 Oct 2010 10:42:16 +0200 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: new version of the congestion control draft Thread-Index: Act1strYu7Jn+8vbR2WX46+4ghEwaA== Date: Wed, 27 Oct 2010 08:42:14 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D8300DF@PALLENE.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ledbat] new version of the congestion control draft 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: Wed, 27 Oct 2010 08:40:33 -0000 Hi group, there is a new version of the congestion control draft online: http://tools= .ietf.org/html/draft-ietf-ledbat-congestion-03. It has been reworked substa= ntially based on the comments received (big thanks to Jana). Please start r= eviewing this new version as our main focus during the upcoming meeting is = this document. Thanks, Rolf=20 NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From Rolf.Winter@neclab.eu Thu Oct 28 04:12:20 2010 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 CE1423A6875 for ; Thu, 28 Oct 2010 04:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.895 X-Spam-Level: X-Spam-Status: No, score=-101.895 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 xee6O3p4A4e9 for ; Thu, 28 Oct 2010 04:12:20 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id E8EDE3A67EF for ; Thu, 28 Oct 2010 04:12:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 632012800017F for ; Thu, 28 Oct 2010 13:14:11 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzJKOozBtCpo for ; Thu, 28 Oct 2010 13:14:11 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2274728000178 for ; Thu, 28 Oct 2010 13:14:06 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.152]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0255.000; Thu, 28 Oct 2010 13:14:06 +0200 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: Agenda online Thread-Index: Act2kTs52eMvQHmWRMWZFGD45SwzNg== Date: Thu, 28 Oct 2010 11:14:04 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D832828@PALLENE.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ledbat] Agenda online 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, 28 Oct 2010 11:12:20 -0000 Hello WG, the agenda is online. The meeting coordinates are: Tuesday, 1300-1500 Afternoon Session I (Pearl) The agenda is at http://www.ietf.org/proceedings/79/agenda/ledbat.txt. Again, the main outcome of the meeting is to discuss the final open points = of the congestion control draft so that we can last call it after the meeti= ng and finally declare success. Thanks everybody, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From mayutan.arumaithurai@gmail.com Thu Oct 28 07:48:11 2010 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 811023A6839 for ; Thu, 28 Oct 2010 07:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, 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 OBuS9+CVTWgG for ; Thu, 28 Oct 2010 07:48:09 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id BAC213A67DA for ; Thu, 28 Oct 2010 07:48:08 -0700 (PDT) Received: by qyk5 with SMTP id 5so2053980qyk.10 for ; Thu, 28 Oct 2010 07:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=s7+HHWG2SALwsV8UZL5+9onmHpLzHAc465tIIxsueHA=; b=W1eYGGDfN9P/U5pKhLbYODUsWepwJ0HIjn+jRrHE/G3dnrczkjDxnsIFMgb+Qypd16 r3ue2rrKlztVJKqAQzUDojjNaWDqCXE/82frzUK08+iVqcimZzWecObXVHwgIHUqftNS R3s6RW2qGUDWL+qNc8Vo6+0Idc2Gug1PWQmcc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=VUz+GzAKBy2/bLmtsavQuMvb0HnfFyPlu2H/fcYGxCh7p9LB8GyrWyeCyKdkcxM847 r1ybKhk6Qjt5a3d1nGx9HssxvvxbhjzxJ4O7s9lWIc4ZH1ehgN0euqIb0V975npiDZ7g eY+4x6kDAlsW8VvM09Rkjo4cFeMj2Bey5er8Q= Received: by 10.229.227.12 with SMTP id iy12mr5323573qcb.101.1288277400665; Thu, 28 Oct 2010 07:50:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.130.88 with HTTP; Thu, 28 Oct 2010 07:49:39 -0700 (PDT) In-Reply-To: <34F992CD-6D0B-445F-87D7-BE1E5E625E11@telecom-bretagne.eu> References: <20101009004622.772783A69A3@core3.amsl.com> <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> <34F992CD-6D0B-445F-87D7-BE1E5E625E11@telecom-bretagne.eu> From: "Mayutan A." Date: Thu, 28 Oct 2010 16:49:39 +0200 Message-ID: To: David Ros Content-Type: multipart/alternative; boundary=00163630f435d6bf350493ae74e5 Cc: ledbat@ietf.org Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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, 28 Oct 2010 14:48:11 -0000 --00163630f435d6bf350493ae74e5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David, Sorry for the delay in replying, was held up with another deadline. See inline for comments: On Mon, Oct 18, 2010 at 10:33 PM, David Ros wrote: > Le 15 oct. 2010 =C3=A0 15:56, Mayutan A. a =C3=A9crit : > > > Hi all, > > > > I have finished a round of reviewing and here are my comments: > > Hi, > > Mayutan, thanks a lot for the review. Comments inline... > > > > Overall, the document does not compare the goals of the LEDBAT WG to th= e > state of the art. Therefore it is very difficult to identify with > > the pros and cons of the mentioned approaches. Moreover, it is difficul= t > to see why LEDBAT was developed instead of > > using TCP-Vegas, TCP-LP and etc. I feel that the draft is taking a > neutral approach by just mentioning the existing approaches, and leaves i= t > to the readers to figure out what LEDBAT is trying to do differently. My > apologies in case I missed out on the early discussions where such a > decision was taken. > > I'm myself a latecomer (LEDBAT pun intended) to this draft, thus, I may > have missed some old discussions; I'll let Michael chime in if needed. > However, AFAIK such a discussion never took place, so the draft has adopt= ed > a neutral stance. The point of the document, it seems to us, is to show t= hat > LEDBAT is not the only existing algorithm and that there are other relate= d > approaches out there. > > It would still be nice to see come comparison to LEDBAT congestion control, and to state the features that LEDBAT CC borrows from existing approaches. If not, the draft should atleast state the pros and cons of the approaches, else it is difficult to understand the need for LEDBAT CC when there are many existing approaches. I am not sure if this fits in the survey draft or the LEDBAT congestion control draft. The motivation behind developing LEDBA= T CC as an alternate to all the existing approaches must be documented in one of the two drafts, preferably in the survey draft. > > > Some minor comments: > > > > 1) Abstract: I am not comfortable with the usage of the term > "low-priority background traffic". It > > might be better to use a term that is consistent with the > ledbat-congestion control draft > > and the terms used in the LEDBAT WG. The LEDBAT WG, > > describes applications such as VoIP as delay-sensitive, therefore it > might be appropriate to use the term delay-insensitive. Or > > use the term "less-than-best-effort "background" transmissions", to be > consistent with the LEDBAT WG charter. > > We have no particular preference on this, though "low-priority" immediate= ly > suggests "LBE service" to us. > > =3D> We have no problem with changing the wording to "delay-insensitive". > > > > 2) TCP vegas: The draft states that > > "TCP Vegas [Bra+94] is one of the first protocols that was known to > > > > have a smaller sending rate than standard TCP when both protocols > > share a bottleneck [Kur+00] -- yet it was designed to achieve more, > > not less throughput than standard TCP. " > > > > 2.a ) What is the point of this statement? Does it imply that it is not= a > > good candidate for a LEDBAT like protocol? > > > > "Indeed, when it is the only > > protocol on the bottleneck, the throughput of TCP Vegas is greater > > than the throughput of standard TCP. " > > > > 2.b) Again does this statement imply that it is not a good candidate fo= r > a LEDBAT > > like approach? > > > > Depending on the bottleneck > > queue length, TCP Vegas itself can be starved by standard TCP flows. > > > > This can be remedied to some degree by the RED Active Queue > > Management mechanism [RFC2309]." > > 2.c) Is TCP Vegas being starved a positive or a negative with regards t= o > > the goals of the LEDBAT WG? > > As I said above, the draft takes a neutral stance -- it simply reports so= me > facts about Vegas. > > > > 3) In Section-2, 5th para, TCP-LP and TCP-Nice are mentioned. In the sa= me > > para, there is an additional line about TCP-LP. The next para (6th para= ) > talks about > > TCP-Nice and then the 7th para onwards the draft talks about TCP-LP. Th= is > is a bit confusing. > > I suggest that it is reorganized it a bit. > > Thanks for the suggestion, we'll do it. > > > > 4) Section -2, 8th Para: The draft states: > > "Regarding its reaction to an early congestion indication, TCP-LP > > > > tries to strike a middle ground between the overly conservative > > choice of immediately setting the congestion window to one packet an= d > > the presumably too aggressive choice of halving the congestion windo= w > > > > like standard TCP." > > > > Why does the draft state that TCP-LP takes a middle ground approach. > TCP-LP > > also reduces its congestion window by half, similar to TCP. > > My understanding of TCP-LP is as follows, please feel free to correct me. > > When receiving the first early congestion indication, TCP-LP does indeed > halve the window, as you say. Then it starts a so-called "inference timer= " > (the authors suggest setting such timer to 3 RTTs). If in the next RTT > there's yet another early congestion indication, and the inference timer = has > not expired, then the window is set to 1. > > Right. This is how I have understood it too. > So the "middle ground" is between *immediately* decreasing the window to = 1 > and simply halving it, like plain TCP; they try to delay the former actio= n > by an additional RTT, to see if there is persistent congestion or not. > =3D> There's perhaps a wording issue here (BTW, the authors of TCP-LP emplo= y > some similar terms -- they talk about a "compromise"). We may try to expl= ain > this a little better. > > The term "middle ground" was confusing since in the first RTT TCP-LP halv= es its window similar to TCP. But it makes sense when you consider the protoco= l behaviour over a couple of RTTs, wherein TCP-LP cwnd either goes to 1 or remains at half. > > > 5) Section 3: How is MulTCP a candidate for LEDBAT like approach if it > tries to be as friendly as N TCP flows (where N is greater than or equal = to > 1)? > > This is Michael being too modest about his own work :-). You are right, t= he > focus here should be on MulTFRC, since it can use an N between 0 and 1. > However, by allowing N < 1 MulTFRC takes one basic idea of MulTCP a step > further, so MulTCP & similar approaches should perhaps be mentioned but, > clearly, *not* suggesting that they are somehow an alternative for an LBE > transport. > > =3D> Thanks for the remark, we'll try to make this clearer. > > You could probably rewrite it as above. That makes it clear that MulTFRC = is a good candidate for LEDBAT and that it is based on MulTCP. > > > > > 6) In section 4: It would be nice to mention some of the > advantages/disadvantages of an application layer approach. > > > > Thanks for the suggestion, we'll do it. > > > Again, thanks a lot for the remarks! > > David. > Cheers, Mayutan > > Mayutan > > > > > > On Thu, Oct 14, 2010 at 10:14 AM, David Ros < > David.Ros@telecom-bretagne.eu> wrote: > > Hi all, > > > > Thanks a lot to Mirja and Mayutan for volunteering! > > > > Hoping to seeing you in Beijing, > > > > David. > > > > > > Le 13 oct. 2010 =C3=A0 20:37, Rolf Winter a =C3=A9crit : > > > > > Hi, > > > > > > as mentioned earlier, I would like to have at least 3 people from the > group that agree to do a thorough review of this draft (well written, > reasonably complete, correct etc). Volunteers please speak up! A lot of > people on the list have been working in this field and should be able to = do > this easily e.g. Mirja, Dario and others. > > > > > > Best, > > > > > > Rolf > > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > > > > > >> -----Original Message----- > > >> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > > >> Behalf Of David Ros > > >> Sent: Samstag, 9. Oktober 2010 02:59 > > >> To: ledbat@ietf.org > > >> Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledba= t- > > >> survey-01 > > >> > > >> Dear all, > > >> > > >> We've posted an update to the survey draft, see announcement below. > > >> Comments are very welcome. > > >> > > >> Thanks in advance, > > >> > > >> David. > > >> > > >> > > >> D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : > > >> > > >>> De : IETF I-D Submission Tool > > >>> Date : 9 octobre 2010 02:46:22 HAEC > > >>> =C3=80 : david.ros@telecom-bretagne.eu > > >>> Cc : michawe@ifi.uio.no > > >>> Objet : New Version Notification for draft-ietf-ledbat-survey-01 > > >>> > > >>> > > >>> A new version of I-D, draft-ietf-ledbat-survey-01.txt has been > > >> successfully submitted by David Ros and posted to the IETF repositor= y. > > >>> > > >>> Filename: draft-ietf-ledbat-survey > > >>> Revision: 01 > > >>> Title: A Survey of Lower-than-Best-Effort Transport > > >> Protocols > > >>> Creation_date: 2010-10-09 > > >>> WG ID: ledbat > > >>> Number_of_pages: 16 > > >>> > > >>> Abstract: > > >>> This document provides a survey of transport protocols which are > > >>> designed to have a smaller bandwidth and/or delay impact on standar= d > > >>> TCP than standard TCP itself when they share a bottleneck with it. > > >>> Such protocols could be used for low-priority "background" traffic, > > >>> as they provide what is sometimes called a "less than" (or "lower > > >>> than") best-effort service. > > >>> > > >>> > > >>> > > >>> The IETF Secretariat. > > >>> > > >>> > > >> > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> David ROS > > >> http://www.rennes.enst-bretagne.fr/~dros/ > > >> > > >> I love deadlines. I like the whooshing sound they make as they fly b= y. > > >> -- Douglas Adams > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> ledbat mailing list > > >> ledbat@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ledbat > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > David ROS > > http://www.rennes.enst-bretagne.fr/~dros/ > > > > I love deadlines. I like the whooshing sound they make as they fly by. = -- > Douglas Adams > > > > > > > > > > > > > > > > -- > > Mayutan Arumaithurai > > 0049-551-2712647 (Home number) > > 0049-176-20322049 (mobile number) > > _______________________________________________ > > ledbat mailing list > > ledbat@ietf.org > > https://www.ietf.org/mailman/listinfo/ledbat > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David ROS > http://www.rennes.enst-bretagne.fr/~dros/ > > I love deadlines. I like the whooshing sound they make as they fly by. -- > Douglas Adams > > > > > --=20 Mayutan Arumaithurai 0049-551-2712647 (Home number) 0049-176-20322049 (mobile number) --00163630f435d6bf350493ae74e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David,

Sorry for the delay in replying, was held up with= another deadline. See inline for comments:

On Mon, Oct 18, 2010 at 10:33 PM, David Ros = <David.Ros@telecom-bretagne.eu> wrote:
Le 15 oct. 2010 = =C3=A0 15:56, Mayutan A. a =C3=A9crit :

> Hi all,
>
> I have finished a round of reviewing and here are my comments:

Hi,

Mayutan, thanks a lot for the review. Comments inline...


> Overall, the document does not compare the goals of the LEDBAT WG to t= he state of the art. Therefore it is very difficult to identify with
> the pros and cons of the mentioned approaches. Moreover, it is difficu= lt to see why LEDBAT was developed instead of
> using TCP-Vegas, TCP-LP and etc. I feel that the draft is taking a neu= tral approach by just mentioning the existing approaches, and leaves it to = the readers to figure out what LEDBAT is trying to do differently. My apolo= gies in case I missed out on the early discussions where such a decision wa= s taken.

I'm myself a latecomer (LEDBAT pun intended) to this draft, thus,= I may have missed some old discussions; I'll let Michael chime in if n= eeded. However, AFAIK such a discussion never took place, so the draft has = adopted a neutral stance. The point of the document, it seems to us, is to = show that LEDBAT is not the only existing algorithm and that there are othe= r related approaches out there.


It would still be nice to see come comparison to LEDBAT congestion contr= ol, and to state the features that LEDBAT CC borrows from existing approach= es. If not, the draft should atleast state the pros and cons of the approac= hes, else it is difficult to understand the need for LEDBAT CC when there a= re many existing approaches. I am not sure if this fits in the survey draft= or the LEDBAT congestion control draft. The motivation behind developing L= EDBAT CC as an alternate to all the existing approaches must be documented = in one of the two drafts, preferably in the survey draft.
=C2=A0

> Some minor comments:
>
> 1) Abstract: I am not comfortable with the usage of the term "low= -priority background traffic". It
> might be better to use a term that is consistent with the ledbat-conge= stion control draft
> and the terms used in the LEDBAT WG. The LEDBAT WG,
> describes applications such as VoIP as delay-sensitive, therefore it m= ight be appropriate to use the term delay-insensitive. =C2=A0Or
> =C2=A0use the term "less-than-best-effort "background" = transmissions", to be consistent with the LEDBAT WG charter.

We have no particular preference on this, though "low-priority&q= uot; immediately suggests "LBE service" to us.

=3D> We have no problem with changing the wording to "delay-insensi= tive".


> 2) TCP vegas: The draft states that
> "TCP Vegas [Bra+94] is one of the first protocols that was known = to
>
> =C2=A0 =C2=A0have a smaller sending rate than standard TCP when both p= rotocols
> =C2=A0 =C2=A0share a bottleneck [Kur+00] -- yet it was designed to ach= ieve more,
> =C2=A0 =C2=A0not less throughput than standard TCP. =C2=A0"
>
> 2.a ) What is the point of this statement? Does it imply that it is no= t a
> good candidate for a LEDBAT like protocol?
>
> =C2=A0 =C2=A0"Indeed, when it is the only
> =C2=A0 =C2=A0protocol on the bottleneck, the throughput of TCP Vegas i= s greater
> =C2=A0 =C2=A0than the throughput of standard TCP. "
>
> 2.b) Again does this statement imply that it is not a good candidate f= or a LEDBAT
> like approach?
>
> =C2=A0Depending on the bottleneck
> =C2=A0 =C2=A0queue length, TCP Vegas itself can be starved by standard= TCP flows.
>
> This can be remedied to some degree by the RED Active Queue
> =C2=A0 =C2=A0Management mechanism [RFC2309]."
> 2.c) Is TCP Vegas being starved a positive or a negative with regards = to
> the goals of the LEDBAT WG?

As I said above, the draft takes a neutral stance -- it simply report= s some facts about Vegas.


> 3) In Section-2, 5th para, TCP-LP and TCP-Nice are mentioned. In the s= ame
> para, there is an additional line about TCP-LP. The next para (6th par= a) talks about
> TCP-Nice and then the 7th para onwards the draft talks about TCP-LP. T= his is a bit confusing.
> I suggest that it is reorganized it a bit.

Thanks for the suggestion, we'll do it.


> 4) Section -2, 8th Para: The draft states:
> "Regarding its reaction to an early congestion indication, TCP-LP=
>
> =C2=A0 =C2=A0tries to strike a middle ground between the overly conser= vative
> =C2=A0 =C2=A0choice of immediately setting the congestion window to on= e packet and
> =C2=A0 =C2=A0the presumably too aggressive choice of halving the conge= stion window
>
> =C2=A0 =C2=A0like standard TCP."
>
> Why does the draft state that TCP-LP takes a middle ground approach. T= CP-LP
> also reduces its congestion window by half, similar to TCP.

My understanding of TCP-LP is as follows, please feel free to correct= me.

When receiving the first early congestion indication, TCP-LP does indeed ha= lve the window, as you say. Then it starts a so-called "inference time= r" (the authors suggest setting such timer to 3 RTTs). If in the next = RTT there's yet another early congestion indication, and the inference = timer has not expired, then the window is set to 1.

Right. This = is how I have understood it too.
=C2=A0
So the "middle ground" is between *immediately* decreasing the wi= ndow to 1 and simply halving it, like plain TCP; they try to delay the form= er action by an additional RTT, to see if there is persistent congestion or= not.
=3D&= gt; There's perhaps a wording issue here (BTW, the authors of TCP-LP em= ploy some similar terms -- they talk about a "compromise"). We ma= y try to explain this a little better.

<= /span>The term "middle ground= " was=20 confusing since in the first RTT TCP-LP halves its window similar to=20 TCP. But it makes sense when you consider the protocol behaviour over a=20 couple of RTTs, wherein TCP-LP cwnd either goes to 1 or remains at=20 half. =C2=A0

> =C2=A05) Section 3: How is MulTCP a candidate for LEDBAT like approach= if it tries to be as friendly as N TCP flows (where N is greater than or e= qual to 1)?

This is Michael being too modest about his own work :-). You are righ= t, the focus here should be on MulTFRC, since it can use an N between 0 and= 1. However, by allowing N < 1 MulTFRC takes one basic idea of MulTCP a = step further, so MulTCP & similar approaches should perhaps be mentione= d but, clearly, *not* suggesting that they are somehow an alternative for a= n LBE transport.

=3D> Thanks for the remark, we'll try to make this clearer.

Y= ou could probably rewrite it as above. That makes it clear that MulTFRC is = a good candidate for LEDBAT and that it is based on MulTCP.
=C2= =A0

>
> 6) In section 4: It would be nice to mention some of the advantages/di= sadvantages of an application layer approach.
>

Thanks for the suggestion, we'll do it.


Again, thanks a lot for the remarks!

David.

Cheers,
Mayutan


> Mayutan
>
>
> On Thu, Oct 14, 2010 at 10:14 AM, David Ros <David.Ros@telecom-bretagne.eu<= /a>> wrote:
> Hi all,
>
> Thanks a lot to Mirja and Mayutan for volunteering!
>
> Hoping to seeing you in Beijing,
>
> David.
>
>
> Le 13 oct. 2010 =C3=A0 20:37, Rolf Winter a =C3=A9crit :
>
> > Hi,
> >
> > as mentioned earlier, I would like to have at least 3 people from= the group that agree to do a thorough review of this draft (well written, = reasonably complete, correct etc). Volunteers please speak up! A lot of peo= ple on the list have been working in this field and should be able to do th= is easily e.g. Mirja, Dario and others.
> >
> > Best,
> >
> > =C2=A0 =C2=A0 =C2=A0 Rolf
> >
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Roa= d, London W3 6BL | Registered in England 2832014
> >
> >
> >> -----Original Message-----
> >> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On
> >> Behalf Of David Ros
> >> Sent: Samstag, 9. Oktober 2010 02:59
> >> To: ledb= at@ietf.org
> >> Subject: [ledbat] Fwd: New Version Notification for draft-iet= f-ledbat-
> >> survey-01
> >>
> >> Dear all,
> >>
> >> We've posted an update to the survey draft, see announcem= ent below.
> >> Comments are very welcome.
> >>
> >> Thanks in advance,
> >>
> >> David.
> >>
> >>
> >> D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 :
> >>
> >>> De : IETF I-D Submission Tool <idsubmission@ietf.org>
> >>> Date : 9 octobre 2010 02:46:22 HAEC
> >>> =C3=80 : david.ros@telecom-bretagne.eu
> >>> Cc : michawe@ifi.uio.no
> >>> Objet : New Version Notification for draft-ietf-ledbat-su= rvey-01
> >>>
> >>>
> >>> A new version of I-D, draft-ietf-ledbat-survey-01.txt has= been
> >> successfully submitted by David Ros and posted to the IETF re= pository.
> >>>
> >>> Filename: =C2=A0 =C2=A0draft-ietf-ledbat-survey
> >>> Revision: =C2=A0 =C2=A001
> >>> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A= Survey of Lower-than-Best-Effort Transport
> >> Protocols
> >>> Creation_date: =C2=A0 =C2=A0 =C2=A0 2010-10-09
> >>> WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 l= edbat
> >>> Number_of_pages: 16
> >>>
> >>> Abstract:
> >>> This document provides a survey of transport protocols wh= ich are
> >>> designed to have a smaller bandwidth and/or delay impact = on standard
> >>> TCP than standard TCP itself when they share a bottleneck= with it.
> >>> Such protocols could be used for low-priority "backg= round" traffic,
> >>> as they provide what is sometimes called a "less tha= n" (or "lower
> >>> than") best-effort service.
> >>>
> >>>
> >>>
> >>> The IETF Secretariat.
> >>>
> >>>
> >>
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> David ROS
> >> http://www.rennes.enst-bretagne.fr/~dros/
> >>
> >> I love deadlines. I like the whooshing sound they make as the= y fly by.
> >> -- Douglas Adams
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> ledbat mailing list
> >> ledbat@i= etf.org
> >> https://www.ietf.org/mailman/listinfo/ledbat
> >
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> David ROS
> http://www.rennes.enst-bretagne.fr/~dros/
>
> I love deadlines. I like the whooshing sound they make as they fly by.= -- Douglas Adams
>
>
>
>
>
>
>
> --
> Mayutan Arumaithurai
> 0049-551-2712647 (Home number)
> 0049-176-20322049 (mobile number)
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David ROS
h= ttp://www.rennes.enst-bretagne.fr/~dros/

I love deadlines. I like the whooshing sound they make as they fly by. -- D= ouglas Adams







--
Mayutan Aru= maithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile n= umber)
--00163630f435d6bf350493ae74e5-- From michawe@ifi.uio.no Thu Oct 28 08:37:04 2010 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 F39103A683C for ; Thu, 28 Oct 2010 08:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.442 X-Spam-Level: X-Spam-Status: No, score=-106.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 sMvj5AfsUzhA for ; Thu, 28 Oct 2010 08:37:02 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 439A33A69B1 for ; Thu, 28 Oct 2010 08:37:02 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1PBUZ3-0001Pz-L9; Thu, 28 Oct 2010 17:38:53 +0200 Received: from div-8021x-dhcp216.uio.no ([193.157.176.225]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from ) id 1PBUZ2-0002OQ-SA; Thu, 28 Oct 2010 17:38:53 +0200 Message-Id: <98D17230-A036-4A2E-8D31-2CE97358821D@ifi.uio.no> From: Michael Welzl To: Mayutan A. In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Oct 2010 17:38:52 +0200 References: <20101009004622.772783A69A3@core3.amsl.com> <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> <34F992CD-6D0B-445F-87D7-BE1E5E625E11@telecom-bretagne.eu> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 15 sum msgs/h 6 total rcpts 3673 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 72BE3768B8F6D216626DA56E31C71681166E3BBA X-UiO-SPAM-Test: remote_host: 193.157.176.225 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1265 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: ledbat@ietf.org, David Ros Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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, 28 Oct 2010 15:37:04 -0000 Hi Mayutan! Thanks for your comments! I leave the others for David, but just this one I want to comment on: > It would still be nice to see come comparison to LEDBAT congestion > control, and to state the features that LEDBAT CC borrows from > existing approaches. If not, the draft should atleast state the pros > and cons of the approaches, else it is difficult to understand the > need for LEDBAT CC when there are many existing approaches. I am not > sure if this fits in the survey draft or the LEDBAT congestion > control draft. The motivation behind developing LEDBAT CC as an > alternate to all the existing approaches must be documented in one > of the two drafts, preferably in the survey draft. I agree that this would make sense if we would now be at a different point in history. That is, if this discussion would take place a few years ago, there was no LEDBAT CC mechanism yet, and the survey would form the basis for developing LEDBAT, then I would agree. But this is not how things happened: I was just about to finish the first version of the draft (and I was fast with it!) when the LEDBAT CC mechanism was presented... I agree that it would be nice to see "the motivation behind developing LEDBAT CC as an alternate to all the existing approaches", but honestly I have no clue what this motivation was (well: my educated guess is that Stas had good real life experiences with this scheme, and no real reason to fool around with the others, but that isn't appropriate text for the draft I guess). If Stas could provide a better explanation of his motivations to develop LEDBAT as opposed to picking one of the existing alternatives, this would be nice, I think - but since our draft doesn't (and, I think, shouldn't) describe LEDBAT but everything else, I really think that such a paragraph would better fit in the LEDBAT CC draft. To conclude: the survey draft is not, and has never been, a basis for developing LEDBAT, and therefore its only purpose can be to inform people about other stuff that exists out there. I think that this is valuable, but in this context it's probably inappropriate to discuss pro's and con's which really can't be given without making the discussion biased. Since most mechanisms essentially share the exact same goal of being inobtrusive, this is a bit like asking for a pros and cons discussion of CUBIC vs HTCP vs CTCP vs .... - where there is no simple answer, and upon digging through the authors' papers, you would just find that certain mechanisms have been found to be better than others under certain circumstances. Cheers, Michael From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Oct 28 08:47:48 2010 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 B1B8A3A683C for ; Thu, 28 Oct 2010 08:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 8bG-yIMnqopb for ; Thu, 28 Oct 2010 08:47:48 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 37F813A677C for ; Thu, 28 Oct 2010 08:47:46 -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 61BE6633B4 for ; Thu, 28 Oct 2010 17:49:36 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5B79559A8A for ; Thu, 28 Oct 2010 17:49:36 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: ledbat@ietf.org Date: Thu, 28 Oct 2010 17:49:35 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <20101009004622.772783A69A3@core3.amsl.com> <98D17230-A036-4A2E-8D31-2CE97358821D@ifi.uio.no> In-Reply-To: <98D17230-A036-4A2E-8D31-2CE97358821D@ifi.uio.no> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201010281749.35911.mkuehle@ikr.uni-stuttgart.de> Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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, 28 Oct 2010 15:47:48 -0000 Hi Micheal, > To conclude: the survey draft is not, and has never been, a basis for > developing LEDBAT, and therefore its only purpose can be to inform > people about other stuff that exists out there. I think that this is > valuable, but in this context it's probably inappropriate to discuss > pro's and con's which really can't be given without making the > discussion biased. Since most mechanisms essentially share the exact > same goal of being inobtrusive, this is a bit like asking for a pros > and cons discussion of CUBIC vs HTCP vs CTCP vs .... - where there > is no simple answer, and upon digging through the authors' papers, you > would just find that certain mechanisms have been found to be better > than others under certain circumstances. We are not asking you to answer the question what is the best choice or to give a ranking but you can still list the positive and negative points about the separate approaches, e.g. approaches based on OWD instead of RTT are more accurate because they don't react wrongly in congestion on the return link but harder to implement because of receiver-side involvement.... Mirja From michawe@ifi.uio.no Thu Oct 28 08:56:35 2010 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 E49C93A683C for ; Thu, 28 Oct 2010 08:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.312 X-Spam-Level: X-Spam-Status: No, score=-106.312 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 e3YsjK1ruqpO for ; Thu, 28 Oct 2010 08:56:35 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id B56CA3A67E7 for ; Thu, 28 Oct 2010 08:56:34 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1PBUry-0001GT-7G; Thu, 28 Oct 2010 17:58:26 +0200 Received: from div-8021x-dhcp216.uio.no ([193.157.176.225]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from ) id 1PBUrx-0000Bc-Qh; Thu, 28 Oct 2010 17:58:26 +0200 Message-Id: <89CB8A64-8F67-49D5-B14E-5430F60007DB@ifi.uio.no> From: Michael Welzl To: =?ISO-8859-1?Q?Mirja_K=FChlewind?= In-Reply-To: <201010281749.35911.mkuehle@ikr.uni-stuttgart.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Oct 2010 17:58:25 +0200 References: <20101009004622.772783A69A3@core3.amsl.com> <98D17230-A036-4A2E-8D31-2CE97358821D@ifi.uio.no> <201010281749.35911.mkuehle@ikr.uni-stuttgart.de> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 6 sum rcpts/h 19 sum msgs/h 9 total rcpts 3677 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9F7C930E4C0900A3126F9C7BAB36F701C018C1B7 X-UiO-SPAM-Test: remote_host: 193.157.176.225 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 1268 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: ledbat@ietf.org Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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, 28 Oct 2010 15:56:36 -0000 > Hi Micheal, > >> To conclude: the survey draft is not, and has never been, a basis for >> developing LEDBAT, and therefore its only purpose can be to inform >> people about other stuff that exists out there. I think that this is >> valuable, but in this context it's probably inappropriate to discuss >> pro's and con's which really can't be given without making the >> discussion biased. Since most mechanisms essentially share the exact >> same goal of being inobtrusive, this is a bit like asking for a pros >> and cons discussion of CUBIC vs HTCP vs CTCP vs .... - where there >> is no simple answer, and upon digging through the authors' papers, >> you >> would just find that certain mechanisms have been found to be better >> than others under certain circumstances. > > We are not asking you to answer the question what is the best choice > or to > give a ranking but you can still list the positive and negative > points about > the separate approaches, e.g. approaches based on OWD instead of RTT > are more > accurate because they don't react wrongly in congestion on the > return link > but harder to implement because of receiver-side involvement.... oh, ok! that's different; that can be done. thanks! michael From mayutan.arumaithurai@gmail.com Thu Oct 28 11:43:56 2010 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 167DD3A69B6 for ; Thu, 28 Oct 2010 11:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, 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 eiW4g4iZbhTP for ; Thu, 28 Oct 2010 11:43:54 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 938CE3A6966 for ; Thu, 28 Oct 2010 11:43:54 -0700 (PDT) Received: by qyk5 with SMTP id 5so2296663qyk.10 for ; Thu, 28 Oct 2010 11:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=mNDtEfKyNwQ2MJ69JqXPConfYsBU2qz9Vp05lPG+0rc=; b=Ovk9zhThRTU/VWIF61s1XlvecrwoYoOurYae5Wi6Zaw2bMyzMOQERGf5XbsDAS1Txe JwICVljIc/sLSX56JZshh8iU1V4XZKYmXVBuTMH+bt7ttYvGsR5B4oJXrzuNkq/ecSdQ sc8duAmjZcoDxA6KBGmSngei9XxsHHEPR9BbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=bMxcFNPg1a9j8OFNtqn3Q0ZPljjUIesrIzniV5IVa58uw7KTBL+/E9TI4JfCmEnkGl eivvKzpYfywSeHV6bWKQdzqeY8F4q0cK3CQ8TAVM/oYk0vgXhV/bxdb88tkGw57qCBCg yEjVM+dmed2HcpUSKS2ebbjSNwzCfZZwnEgfQ= Received: by 10.229.249.198 with SMTP id ml6mr10474582qcb.117.1288291546357; Thu, 28 Oct 2010 11:45:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.130.88 with HTTP; Thu, 28 Oct 2010 11:45:25 -0700 (PDT) In-Reply-To: <89CB8A64-8F67-49D5-B14E-5430F60007DB@ifi.uio.no> References: <20101009004622.772783A69A3@core3.amsl.com> <98D17230-A036-4A2E-8D31-2CE97358821D@ifi.uio.no> <201010281749.35911.mkuehle@ikr.uni-stuttgart.de> <89CB8A64-8F67-49D5-B14E-5430F60007DB@ifi.uio.no> From: "Mayutan A." Date: Thu, 28 Oct 2010 20:45:25 +0200 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=0016e64bb7c2fcdf700493b1bf0d Cc: ledbat@ietf.org Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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, 28 Oct 2010 18:43:56 -0000 --0016e64bb7c2fcdf700493b1bf0d Content-Type: text/plain; charset=UTF-8 On Thu, Oct 28, 2010 at 5:58 PM, Michael Welzl wrote: > Hi Micheal, >> >> To conclude: the survey draft is not, and has never been, a basis for >>> developing LEDBAT, and therefore its only purpose can be to inform >>> people about other stuff that exists out there. I think that this is >>> valuable, but in this context it's probably inappropriate to discuss >>> pro's and con's which really can't be given without making the >>> discussion biased. Since most mechanisms essentially share the exact >>> same goal of being inobtrusive, this is a bit like asking for a pros >>> and cons discussion of CUBIC vs HTCP vs CTCP vs .... - where there >>> is no simple answer, and upon digging through the authors' papers, you >>> would just find that certain mechanisms have been found to be better >>> than others under certain circumstances. >>> >> >> We are not asking you to answer the question what is the best choice or to >> give a ranking but you can still list the positive and negative points >> about >> the separate approaches, e.g. approaches based on OWD instead of RTT are >> more >> accurate because they don't react wrongly in congestion on the return link >> but harder to implement because of receiver-side involvement.... >> > > oh, ok! that's different; that can be done. > > thanks! > > michael > > Great. > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > -- Mayutan Arumaithurai 0049-551-2712647 (Home number) 0049-176-20322049 (mobile number) --0016e64bb7c2fcdf700493b1bf0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 28, 2010 at 5:58 PM, Michael= Welzl <michawe@= ifi.uio.no> wrote:
Hi Micheal,

To conclude: the survey draft is not, and has never been, a basis for
developing LEDBAT, and therefore its only purpose can be to inform
people about other stuff that exists out there. I think that this is
valuable, but in this context it's probably inappropriate to discuss pro's and con's which really can't be given without making the<= br> discussion biased. Since most mechanisms essentially share the exact
same goal of being inobtrusive, this is a bit like asking for a pros
and cons discussion of CUBIC vs HTCP vs CTCP vs .... =C2=A0 =C2=A0- where t= here
is no simple answer, and upon digging through the authors' papers, you<= br> would just find that certain mechanisms have been found to be better
than others under certain circumstances.

We are not asking you to answer the question what is the best choice or to<= br> give a ranking but you can still list the positive and negative points abou= t
the separate approaches, e.g. approaches based on OWD instead of RTT are mo= re
accurate because they don't react wrongly in congestion on the return l= ink
but harder to implement because of receiver-side involvement....

oh, ok! that's different; that can be done.

thanks!

michael

=
Great.
=C2=A0

_______________________________________________
ledbat mailing list
ledbat@ietf.org = https://www.ietf.org/mailman/listinfo/ledbat



--
Mayutan Aru= maithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile n= umber)
--0016e64bb7c2fcdf700493b1bf0d-- From David.Ros@telecom-bretagne.eu Fri Oct 29 01:46:42 2010 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 5FA6C3A67D1 for ; Fri, 29 Oct 2010 01:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 a22dYgIoQZfO for ; Fri, 29 Oct 2010 01:46:41 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id 9841E3A6807 for ; Fri, 29 Oct 2010 01:46:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o9T8mYlt008732; Fri, 29 Oct 2010 10:48:34 +0200 Received: from courrier.enst-bretagne.fr (vss-mail-02.priv.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o9T8mT73008710; Fri, 29 Oct 2010 10:48:32 +0200 Received: from [10.35.128.118] ([10.35.128.118]) (user=dros mech=PLAIN bits=0) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2010.02.22) with ESMTP id o9T8mR7f001228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Oct 2010 10:48:27 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Ros In-Reply-To: Date: Fri, 29 Oct 2010 10:48:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101009004622.772783A69A3@core3.amsl.com> <8962E1B6-5963-4670-8C22-C3ADFDF1459A@telecom-bretagne.eu> <791AD3077F94194BB2BDD13565B6295D7E5B61@PALLENE.office.hd> <34F992CD-6D0B-445F-87D7-BE1E5E625E11@telecom-bretagne.eu> To: "Mayutan A." X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: ledbat@ietf.org Subject: Re: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01 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, 29 Oct 2010 08:46:42 -0000 Hi Mayutan, My answers inline... >> My understanding of TCP-LP is as follows, please feel free to correct = me. >>=20 >> When receiving the first early congestion indication, TCP-LP does = indeed halve the window, as you say. Then it starts a so-called = "inference timer" (the authors suggest setting such timer to 3 RTTs). If = in the next RTT there's yet another early congestion indication, and the = inference timer has not expired, then the window is set to 1. >=20 > Right. This is how I have understood it too.=20 >=20 >> So the "middle ground" is between *immediately* decreasing the window = to 1 and simply halving it, like plain TCP; they try to delay the former = action by an additional RTT, to see if there is persistent congestion or = not. >> =3D> There's perhaps a wording issue here (BTW, the authors of TCP-LP = employ some similar terms -- they talk about a "compromise"). We may try = to explain this a little better. >=20 > The term "middle ground" was confusing since in the first RTT TCP-LP = halves its window similar to TCP. But it makes sense when you consider = the protocol behaviour over a couple of RTTs, wherein TCP-LP cwnd either = goes to 1 or remains at half. =20 OK, we'll try to rephrase this to make it clearer, by better explaining = this behavior-over-several-RTTs stuff. Thanks for the suggestion. >> > 5) Section 3: How is MulTCP a candidate for LEDBAT like approach = if it tries to be as friendly as N TCP flows (where N is greater than or = equal to 1)? >>=20 >> This is Michael being too modest about his own work :-). You are = right, the focus here should be on MulTFRC, since it can use an N = between 0 and 1. However, by allowing N < 1 MulTFRC takes one basic idea = of MulTCP a step further, so MulTCP & similar approaches should perhaps = be mentioned but, clearly, *not* suggesting that they are somehow an = alternative for an LBE transport. >>=20 >> =3D> Thanks for the remark, we'll try to make this clearer. >=20 > You could probably rewrite it as above. That makes it clear that = MulTFRC is a good candidate for LEDBAT and that it is based on MulTCP.=20= Will do. Thanks! David. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David ROS http://www.rennes.enst-bretagne.fr/~dros/ I love deadlines. I like the whooshing sound they make as they fly by. = -- Douglas Adams