From michawe@ifi.uio.no Thu Feb 3 17:54:36 2011 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 DDE6A3A6768 for ; Thu, 3 Feb 2011 17:54:36 -0800 (PST) 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 E24ka3yPmVDt for ; Thu, 3 Feb 2011 17:54:34 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 84B2E3A68E7 for ; Thu, 3 Feb 2011 17:54:34 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1PlAvt-0004nv-A5 for ledbat@ietf.org; Fri, 04 Feb 2011 02:57:57 +0100 Received: from [136.186.229.244] by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1PlAvr-0000XR-KM for ledbat@ietf.org; Fri, 04 Feb 2011 02:57:57 +0100 Message-Id: <803FC6E5-9906-4402-AD46-B0EC26EC6546@ifi.uio.no> From: Michael Welzl To: ledbat@ietf.org In-Reply-To: <4BDBB5BF-2D33-44E6-91C9-F6541E7E0684@ifi.uio.no> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 4 Feb 2011 12:57:52 +1100 References: <4BDBB5BF-2D33-44E6-91C9-F6541E7E0684@ifi.uio.no> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 4 sum msgs/h 4 total rcpts 6320 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BDE41B88F40B82C70F7721E3F5D3412CB7DC63C3 X-UiO-SPAM-Test: remote_host: 136.186.229.244 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 283 max/h 10 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [ledbat] draft-ietf-ledbat-survey-04 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, 04 Feb 2011 01:54:37 -0000 Hmmm... silence... may I ask the reviewers to do a quick check, to see whether there comments are now amply addressed or tell us if there's still something missing? Thanks! Michael On Jan 15, 2011, at 3:36 AM, michawe wrote: > Hi, > > We have updated our survey draft, which is now available from here: > http://www.ietf.org/id/draft-ietf-ledbat-survey-04.txt > > Please find our answers to the remaining reviewer comments (just > Mirja, unless we missed something). Reviewers, please let us know if > you think that we addressed your comments now, or if you require > further changes. Thanks! > > Cheers, > Michael > > ----- > > todo list: > > One small thing: NF-TCP is not introduced as 'Network-Friendly TCP'... > > -- Done. > > > Some more high level comments: > > 1) I would like to RAPID Congestion Control in this document because > it a new > and really different approach in the area of delay-based congestion > control. > > -- We believe that adding a mechanism like RAPID, which was not > designed for LBE but occasionally happens to show this behavior, is > opening a can of worms. For example, in Fig.8 of the Infocom RAPID > paper, it looks as if FAST would then be the next candidate to talk > about. Sometimes it may be LBE - sometimes not. e.g., from our > reference [Aru10]: "Fig. 9(a) illustrates that although NF-TCP has a > much shorter RTT, it is friendly towards TCP flows while also > opportunistically utilizing the spare bandwidth. TCP-LP (Fig. 9(c)) > is also friendly to standard TCP, but is not compeletly submissive. > RAPID (Fig. 9(b)) and LEDBAT (Fig. 9(d)) are both not submissive. > For RAPID, this is due to the combination of its aggressive nature > and its complete reliance on delay-based probing to measure > available bandwidth." > > (a side note: regarding LEDBAT, the authors might have evaluated an > old version, I didn't check) > > > 2) Not sure if section 2.1. is needed at all in this document as > these are > general issues about delay measurements and not especially for LBE > transports. > > -- We think it adds value to the document because there is such a > weight on the delay-based side in it. This section is also really > only about measuring delay within a congestion control mechanism, > not delay measurements in general. > > > 3) Why is there only a 'potential issues' section (2.2.) for the > delay based > approaches? I would say every approach has its issues, e.g. the non- > delay > based approaches in section 3. have to send with a certain minimum > rate; they > will never give all the available capacity to the competing TCP > connection. > Application level approach introduce often more overhead and network- > assisted > approaches require the bottleneck to cooperate. > > -- Similar to the case above, we felt that this adds value because > there is such a weight on the delay-based side in the document. We > briefly addressed the fact that, of course, all approaches have > their issues at the beginning of the respective section. e.g., in > section 3, we have the statement: "such mechanisms likely cause more > queuing delay and react to congestion more slowly than delay-based > ones." I could come up with quite a number of other problems - e.g. > corruption loss, etc.; many of these things are covered in draft- > irtf-iccrg-welzl-congestion-control-open-research-08.txt. We believe > that going into more details on issues of non-delay-based approaches > (enough to justify adding a section of its own) would stretch this > too far and make the document unnecessarily boring and hard to read. > > > 4) In section 5 I suggest to weighted fair queuing. > > -- We decide against this because the scope of our document is on > *transport protocols*, i.e. protocols operating at the transport > layer, i.e. protocols involving end systems. Section 5 deals with > such protocols that receive assistance from the network - i.e. there > is some form of design which involves the end systems and the > network. This does not include pure inside-the-network approaches; > e.g., RFC 3662 very explicitly introduces a LBE behavior (and so > might a ton of other work, possibly even from the MPLS world!), but > also doesn't fit for the reasons above. > > > ... from Mirja's second email: > > from my point of there does not need to be a comparison with only > LEDBAT. For > me it would be okay to have the pro's and con's for every approach in > relation to each other or with a general point of view. But I would > like to > see a really short discussion for every approach that gives the > reader a > change to get a first impression in which cases which mechanism can > be used > or should not be used. > > -- For LEDBAT, we now added a "Conclusion and LEDBAT considerations" > section. For the rest, we think that we have covered this (short, as > you say) in the first paragraph of every section in the last update. > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Feb 7 02:17:39 2011 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 997023A6D8E for ; Mon, 7 Feb 2011 02:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[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 98INIxwS-qO9 for ; Mon, 7 Feb 2011 02:17:38 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 215253A6D89 for ; Mon, 7 Feb 2011 02:17:37 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 8A962633B2 for ; Mon, 7 Feb 2011 11:17:40 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 7A02359A8A for ; Mon, 7 Feb 2011 11:17:40 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: ledbat@ietf.org Date: Mon, 7 Feb 2011 11:17:40 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <4BDBB5BF-2D33-44E6-91C9-F6541E7E0684@ifi.uio.no> <803FC6E5-9906-4402-AD46-B0EC26EC6546@ifi.uio.no> In-Reply-To: <803FC6E5-9906-4402-AD46-B0EC26EC6546@ifi.uio.no> 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: <201102071117.40244.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [ledbat] draft-ietf-ledbat-survey-04 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, 07 Feb 2011 10:17:39 -0000 I'm fine with it. On Friday 04 February 2011 02:57:52 Michael Welzl wrote: > Hmmm... silence... > > may I ask the reviewers to do a quick check, to see whether there > comments are now amply addressed or tell us if there's still something > missing? > > Thanks! > > Michael > > On Jan 15, 2011, at 3:36 AM, michawe wrote: > > Hi, > > > > We have updated our survey draft, which is now available from here: > > http://www.ietf.org/id/draft-ietf-ledbat-survey-04.txt > > > > Please find our answers to the remaining reviewer comments (just > > Mirja, unless we missed something). Reviewers, please let us know if > > you think that we addressed your comments now, or if you require > > further changes. Thanks! > > > > Cheers, > > Michael > > > > ----- > > > > todo list: > > > > One small thing: NF-TCP is not introduced as 'Network-Friendly TCP'... > > > > -- Done. > > > > > > Some more high level comments: > > > > 1) I would like to RAPID Congestion Control in this document because > > it a new > > and really different approach in the area of delay-based congestion > > control. > > > > -- We believe that adding a mechanism like RAPID, which was not > > designed for LBE but occasionally happens to show this behavior, is > > opening a can of worms. For example, in Fig.8 of the Infocom RAPID > > paper, it looks as if FAST would then be the next candidate to talk > > about. Sometimes it may be LBE - sometimes not. e.g., from our > > reference [Aru10]: "Fig. 9(a) illustrates that although NF-TCP has a > > much shorter RTT, it is friendly towards TCP flows while also > > opportunistically utilizing the spare bandwidth. TCP-LP (Fig. 9(c)) > > is also friendly to standard TCP, but is not compeletly submissive. > > RAPID (Fig. 9(b)) and LEDBAT (Fig. 9(d)) are both not submissive. > > For RAPID, this is due to the combination of its aggressive nature > > and its complete reliance on delay-based probing to measure > > available bandwidth." > > > > (a side note: regarding LEDBAT, the authors might have evaluated an > > old version, I didn't check) > > > > > > 2) Not sure if section 2.1. is needed at all in this document as > > these are > > general issues about delay measurements and not especially for LBE > > transports. > > > > -- We think it adds value to the document because there is such a > > weight on the delay-based side in it. This section is also really > > only about measuring delay within a congestion control mechanism, > > not delay measurements in general. > > > > > > 3) Why is there only a 'potential issues' section (2.2.) for the > > delay based > > approaches? I would say every approach has its issues, e.g. the non- > > delay > > based approaches in section 3. have to send with a certain minimum > > rate; they > > will never give all the available capacity to the competing TCP > > connection. > > Application level approach introduce often more overhead and network- > > assisted > > approaches require the bottleneck to cooperate. > > > > -- Similar to the case above, we felt that this adds value because > > there is such a weight on the delay-based side in the document. We > > briefly addressed the fact that, of course, all approaches have > > their issues at the beginning of the respective section. e.g., in > > section 3, we have the statement: "such mechanisms likely cause more > > queuing delay and react to congestion more slowly than delay-based > > ones." I could come up with quite a number of other problems - e.g. > > corruption loss, etc.; many of these things are covered in draft- > > irtf-iccrg-welzl-congestion-control-open-research-08.txt. We believe > > that going into more details on issues of non-delay-based approaches > > (enough to justify adding a section of its own) would stretch this > > too far and make the document unnecessarily boring and hard to read. > > > > > > 4) In section 5 I suggest to weighted fair queuing. > > > > -- We decide against this because the scope of our document is on > > *transport protocols*, i.e. protocols operating at the transport > > layer, i.e. protocols involving end systems. Section 5 deals with > > such protocols that receive assistance from the network - i.e. there > > is some form of design which involves the end systems and the > > network. This does not include pure inside-the-network approaches; > > e.g., RFC 3662 very explicitly introduces a LBE behavior (and so > > might a ton of other work, possibly even from the MPLS world!), but > > also doesn't fit for the reasons above. > > > > > > ... from Mirja's second email: > > > > from my point of there does not need to be a comparison with only > > LEDBAT. For > > me it would be okay to have the pro's and con's for every approach in > > relation to each other or with a general point of view. But I would > > like to > > see a really short discussion for every approach that gives the > > reader a > > change to get a first impression in which cases which mechanism can > > be used > > or should not be used. > > > > -- For LEDBAT, we now added a "Conclusion and LEDBAT considerations" > > section. For the rest, we think that we have covered this (short, as > > you say) in the first paragraph of every section in the last update. > > > > _______________________________________________ > > 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 mayutan.arumaithurai@gmail.com Mon Feb 7 02:23:04 2011 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 CC76E3A6D84 for ; Mon, 7 Feb 2011 02:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjVx452Zn8tE for ; Mon, 7 Feb 2011 02:23:02 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 145843A6929 for ; Mon, 7 Feb 2011 02:23:01 -0800 (PST) Received: by qyk34 with SMTP id 34so1299050qyk.10 for ; Mon, 07 Feb 2011 02:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6E1wKt1CnaWXw2uDtbrUJn1pYrGp4KvoZoTeFn0WpjI=; b=nStzcL+w11BYRBIZ42dl/zZlIgx+9MwhmNthYKHKA1mcNEo5Eczb43DKnrIyOE2aZ5 1O1LqE4cneO8tmSrdsWc9pd4dBUpuheanueLUCLici6PaTEqQQUaEK12bAHVjufYeVam qtUk1gENSstb0zksTYq059qTzP9ZWzexjLM18= 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=V72UMOV5ZapGRAgkFkeg6OnEgzzeTcZcDW3TE0X3eT9a1DGaH+Y2dT588ypUeqUL23 CLDCl9YXAovYYxCA1spapOyfKiduRzCR8wtTqRwrLMSupoTS0r80+R9QJrnmcjVlNDkB t6QtTUyCoICuDJFJ8L+XgGOY7Gb2nQS7SsTEg= Received: by 10.229.240.85 with SMTP id kz21mr12824280qcb.2.1297074185431; Mon, 07 Feb 2011 02:23:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.191.140 with HTTP; Mon, 7 Feb 2011 02:22:45 -0800 (PST) In-Reply-To: <803FC6E5-9906-4402-AD46-B0EC26EC6546@ifi.uio.no> References: <4BDBB5BF-2D33-44E6-91C9-F6541E7E0684@ifi.uio.no> <803FC6E5-9906-4402-AD46-B0EC26EC6546@ifi.uio.no> From: "Mayutan A." Date: Mon, 7 Feb 2011 11:22:45 +0100 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=0016363101e511ef3b049bae9eba Cc: ledbat@ietf.org Subject: Re: [ledbat] draft-ietf-ledbat-survey-04 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, 07 Feb 2011 10:23:05 -0000 --0016363101e511ef3b049bae9eba Content-Type: text/plain; charset=UTF-8 Fine by me. On Fri, Feb 4, 2011 at 2:57 AM, Michael Welzl wrote: > Hmmm... silence... > > may I ask the reviewers to do a quick check, to see whether there comments > are now amply addressed or tell us if there's still something missing? > > Thanks! > > Michael > > > > On Jan 15, 2011, at 3:36 AM, michawe wrote: > > Hi, >> >> We have updated our survey draft, which is now available from here: >> http://www.ietf.org/id/draft-ietf-ledbat-survey-04.txt >> >> Please find our answers to the remaining reviewer comments (just Mirja, >> unless we missed something). Reviewers, please let us know if you think that >> we addressed your comments now, or if you require further changes. Thanks! >> >> Cheers, >> Michael >> >> ----- >> >> todo list: >> >> One small thing: NF-TCP is not introduced as 'Network-Friendly TCP'... >> >> -- Done. >> >> >> Some more high level comments: >> >> 1) I would like to RAPID Congestion Control in this document because it a >> new >> and really different approach in the area of delay-based congestion >> control. >> >> -- We believe that adding a mechanism like RAPID, which was not designed >> for LBE but occasionally happens to show this behavior, is opening a can of >> worms. For example, in Fig.8 of the Infocom RAPID paper, it looks as if FAST >> would then be the next candidate to talk about. Sometimes it may be LBE - >> sometimes not. e.g., from our reference [Aru10]: "Fig. 9(a) illustrates that >> although NF-TCP has a much shorter RTT, it is friendly towards TCP flows >> while also opportunistically utilizing the spare bandwidth. TCP-LP (Fig. >> 9(c)) is also friendly to standard TCP, but is not compeletly submissive. >> RAPID (Fig. 9(b)) and LEDBAT (Fig. 9(d)) are both not submissive. For RAPID, >> this is due to the combination of its aggressive nature and its complete >> reliance on delay-based probing to measure available bandwidth." >> >> (a side note: regarding LEDBAT, the authors might have evaluated an old >> version, I didn't check) >> >> >> 2) Not sure if section 2.1. is needed at all in this document as these are >> general issues about delay measurements and not especially for LBE >> transports. >> >> -- We think it adds value to the document because there is such a weight >> on the delay-based side in it. This section is also really only about >> measuring delay within a congestion control mechanism, not delay >> measurements in general. >> >> 3) Why is there only a 'potential issues' section (2.2.) for the delay >> based >> approaches? I would say every approach has its issues, e.g. the non-delay >> based approaches in section 3. have to send with a certain minimum rate; >> they >> will never give all the available capacity to the competing TCP >> connection. >> Application level approach introduce often more overhead and >> network-assisted >> approaches require the bottleneck to cooperate. >> >> -- Similar to the case above, we felt that this adds value because there >> is such a weight on the delay-based side in the document. We briefly >> addressed the fact that, of course, all approaches have their issues at the >> beginning of the respective section. e.g., in section 3, we have the >> statement: "such mechanisms likely cause more queuing delay and react to >> congestion more slowly than delay-based ones." I could come up with quite a >> number of other problems - e.g. corruption loss, etc.; many of these things >> are covered in >> draft-irtf-iccrg-welzl-congestion-control-open-research-08.txt. We believe >> that going into more details on issues of non-delay-based approaches (enough >> to justify adding a section of its own) would stretch this too far and make >> the document unnecessarily boring and hard to read. >> >> >> 4) In section 5 I suggest to weighted fair queuing. >> >> -- We decide against this because the scope of our document is on >> *transport protocols*, i.e. protocols operating at the transport layer, i.e. >> protocols involving end systems. Section 5 deals with such protocols that >> receive assistance from the network - i.e. there is some form of design >> which involves the end systems and the network. This does not include pure >> inside-the-network approaches; e.g., RFC 3662 very explicitly introduces a >> LBE behavior (and so might a ton of other work, possibly even from the MPLS >> world!), but also doesn't fit for the reasons above. >> >> >> ... from Mirja's second email: >> >> from my point of there does not need to be a comparison with only LEDBAT. >> For >> me it would be okay to have the pro's and con's for every approach in >> relation to each other or with a general point of view. But I would like >> to >> see a really short discussion for every approach that gives the reader a >> change to get a first impression in which cases which mechanism can be >> used >> or should not be used. >> >> -- For LEDBAT, we now added a "Conclusion and LEDBAT considerations" >> section. For the rest, we think that we have covered this (short, as you >> say) in the first paragraph of every section in the last update. >> >> _______________________________________________ >> 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 Arumaithurai 0049-551-2712647 (Home number) 0049-176-20322049 (mobile number) --0016363101e511ef3b049bae9eba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fine by me.=C2=A0

On Fri, Feb 4, 2011 at = 2:57 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
Hmmm... silence...

may I ask the reviewers to do a quick check, to see whether there comments = are now amply addressed or tell us if there's still something missing?<= br>
Thanks!

Michael



On Jan 15, 2011, at 3:36 AM, michawe wrote:

Hi,

We have updated our survey draft, which is now available from here:
http://www.ietf.org/id/draft-ietf-ledbat-survey-04.txt

Please find our answers to the remaining reviewer comments (just Mirja, unl= ess we missed something). Reviewers, please let us know if you think that w= e addressed your comments now, or if you require further changes. Thanks!
Cheers,
Michael

-----

todo list:

One small thing: NF-TCP is not introduced as 'Network-Friendly TCP'= ...

-- Done.


Some more high level comments:

1) I would like to RAPID Congestion Control in this document because it a n= ew
and really different approach in the area of delay-based congestion control= .

-- We believe that adding a mechanism like RAPID, which was not designed fo= r LBE but occasionally happens to show this behavior, is opening a can of w= orms. For example, in Fig.8 of the Infocom RAPID paper, it looks as if FAST= would then be the next candidate to talk about. Sometimes it may be LBE - = sometimes not. e.g., from our reference [Aru10]: "Fig. 9(a) illustrate= s that although NF-TCP has a much shorter RTT, it is friendly towards TCP f= lows while also opportunistically utilizing the spare bandwidth. TCP-LP (Fi= g. 9(c)) is also friendly to standard TCP, but is not compeletly submissive= . RAPID (Fig. 9(b)) and LEDBAT (Fig. 9(d)) are both not submissive. For RAP= ID, this is due to the combination of its aggressive nature and its complet= e reliance on delay-based probing to measure available bandwidth."

(a side note: regarding LEDBAT, the authors might have evaluated an old ver= sion, I didn't check)


2) Not sure if section 2.1. is needed at all in this document as these are<= br> general issues about delay measurements and not especially for LBE
transports.

-- We think it adds value to the document because there is such a weight on= the delay-based side in it. This section is also really only about measuri= ng delay within a congestion control mechanism, not delay measurements in g= eneral.

3) Why is there only a 'potential issues' section (2.2.) for the de= lay based
approaches? I would say every approach has its issues, e.g. the non-delay based approaches in section 3. have to send with a certain minimum rate; th= ey
will never give all the available capacity to the competing TCP connection.=
Application level approach introduce often more overhead and network-assist= ed
approaches require the bottleneck to cooperate.

-- Similar to the case above, we felt that this adds value because there is= such a weight on the delay-based side in the document. We briefly addresse= d the fact that, of course, all approaches have their issues at the beginni= ng of the respective section. e.g., in section 3, we have the statement: &q= uot;such mechanisms likely cause more queuing delay and react to congestion= more slowly than delay-based ones." I could come up with quite a numb= er of other problems - e.g. corruption loss, etc.; many of these things are= covered in draft-irtf-iccrg-welzl-congestion-control-open-research-08.txt.= We believe that going into more details on issues of non-delay-based appro= aches (enough to justify adding a section of its own) would stretch this to= o far and make the document unnecessarily boring and hard to read.


4) In section 5 I suggest to weighted fair queuing.

-- We decide against this because the scope of our document is on *transpor= t protocols*, i.e. protocols operating at the transport layer, i.e. protoco= ls involving end systems. Section 5 deals with such protocols that receive = assistance from the network - i.e. there is some form of design which invol= ves the end systems and the network. This does not include pure inside-the-= network approaches; e.g., RFC 3662 very explicitly introduces a LBE behavio= r (and so might a ton of other work, possibly even from the MPLS world!), b= ut also doesn't fit for the reasons above.


... from Mirja's second email:

from my point of there does not need to be a comparison with only LEDBAT. F= or
me it would be okay to have the pro's and con's for every approach = in
relation to each other or with a general point of view. But I would like to=
see a really short discussion for every approach that gives the reader a change to get a first impression in which cases which mechanism can be used=
or should not be used.

-- For LEDBAT, we now added a "Conclusion and LEDBAT considerations&qu= ot; section. For the rest, we think that we have covered this (short, as yo= u say) in the first paragraph of every section in the last update.

_______________________________________________
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)
--0016363101e511ef3b049bae9eba-- From Rolf.Winter@neclab.eu Tue Feb 8 07:10:48 2011 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 9AD683A6774 for ; Tue, 8 Feb 2011 07:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 0nzCgnp3PJ2y for ; Tue, 8 Feb 2011 07:10:46 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id D53783A67B4 for ; Tue, 8 Feb 2011 07:10:45 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 56A58280001DB for ; Tue, 8 Feb 2011 16:12:08 +0100 (CET) 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 IuJ5iHa2wjGv for ; Tue, 8 Feb 2011 16:12:08 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3B3FC2800017B for ; Tue, 8 Feb 2011 16:12:03 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.15]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Tue, 8 Feb 2011 16:10:47 +0100 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: review of draft-ietf-ledbat-survey-04 Thread-Index: AcvHolzK+KC1fwPtSJanzJ1oD0+cNw== Date: Tue, 8 Feb 2011 15:10:46 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D8F355F@DAPHNIS.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] review of draft-ietf-ledbat-survey-04 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:10:49 -0000 Hi, I just reviewed the new version. Please see some comments below. Please tre= at them as any other comment you have received. "This document is a product of the Low Extra Delay Background Transport (LE= DBAT) Working Group for comparison with the chosen approach." This sounds weird in the text because it is not clear what "the chosen appr= oach" refers to. I'd rather write something along these lines: "This document is a product of the Low Extra Delay Background Transport (LE= DBAT) Working Group. It aims at putting the congestion control algorithm th= at the working group is specifying into the context of the state of the art= in LBE transport." s/LEDBAT's algorithm/the LEDBAT algorithm/ s/under widespread deployment/widely deployed/ "protocol on the bottleneck" ... not sure you can actually say that this wa= y... I guess "the only congestion control algorithm used by flows going thr= ough the bottleneck" or similar s/may therefore depend/may depend/ s/ be appropriate to/ be applicable to/ s/how to use existing or even new transport protocols to realize the LEDBAT= algorithm/how to use existing or even new transport protocols together wit= h the LEDBAT algorithm/ s/LEDBAT is still a moving target/ LEDBAT was still a moving target/ Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From David.Ros@telecom-bretagne.eu Tue Feb 8 09:41:39 2011 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 515E13A67F1 for ; Tue, 8 Feb 2011 09:41:39 -0800 (PST) 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 GLZROwqiq5PT for ; Tue, 8 Feb 2011 09:41:38 -0800 (PST) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id B91233A67AD for ; Tue, 8 Feb 2011 09:41:37 -0800 (PST) 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 p18HfmBV014855 for ; Tue, 8 Feb 2011 18:41:48 +0100 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 p18HfeQp014833 for ; Tue, 8 Feb 2011 18:41:44 +0100 Received: from [192.168.0.11] (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 p18Hfakm004972 for ; Tue, 8 Feb 2011 18:41:36 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1082) From: David Ros In-Reply-To: <791AD3077F94194BB2BDD13565B6295D8F355F@DAPHNIS.office.hd> Date: Tue, 8 Feb 2011 18:41:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <791AD3077F94194BB2BDD13565B6295D8F355F@DAPHNIS.office.hd> To: ledbat@ietf.org X-Mailer: Apple Mail (2.1082) X-Virus-Scanned: amavisd-new at enst-bretagne.fr Subject: Re: [ledbat] review of draft-ietf-ledbat-survey-04 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:41:39 -0000 Le 8 f=E9vr. 2011 =E0 16:10, Rolf Winter a =E9crit : > Hi, >=20 > I just reviewed the new version. Please see some comments below. = Please treat them as any other comment you have received. Hi, Rolf, thanks for the remarks. We'll integrate them and upload a = (hopefully, final) version ASAP. Regards, David. >=20 > "This document is a product of the Low Extra Delay Background = Transport (LEDBAT) Working Group for comparison with the chosen = approach." >=20 > This sounds weird in the text because it is not clear what "the chosen = approach" refers to. I'd rather write something along these lines: >=20 > "This document is a product of the Low Extra Delay Background = Transport (LEDBAT) Working Group. It aims at putting the congestion = control algorithm that the working group is specifying into the context = of the state of the art in LBE transport." >=20 > s/LEDBAT's algorithm/the LEDBAT algorithm/ >=20 > s/under widespread deployment/widely deployed/ >=20 > "protocol on the bottleneck" ... not sure you can actually say that = this way... I guess "the only congestion control algorithm used by flows = going through the bottleneck" or similar >=20 > s/may therefore depend/may depend/ >=20 > s/ be appropriate to/ be applicable to/ >=20 > s/how to use existing or even new transport protocols to realize the = LEDBAT algorithm/how to use existing or even new transport protocols = together with the LEDBAT algorithm/ >=20 > s/LEDBAT is still a moving target/ LEDBAT was still a moving target/ >=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 > _______________________________________________ > 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/ "It would seem that you have no useful skill or talent whatsoever," he = said. "Have you thought of going into teaching?" -- Terry Pratchett From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Feb 15 07:11:05 2011 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 42FDB3A6D56 for ; Tue, 15 Feb 2011 07:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=0.780, 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 fJPX+vIScg-t for ; Tue, 15 Feb 2011 07:11:00 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 9C0803A6D54 for ; Tue, 15 Feb 2011 07:10:59 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 61F04633B1 for ; Tue, 15 Feb 2011 16:11:23 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4872B59A8A for ; Tue, 15 Feb 2011 16:11:23 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: ledbat@ietf.org Date: Tue, 15 Feb 2011 16:11:21 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201102151611.22310.mkuehle@ikr.uni-stuttgart.de> Subject: [ledbat] limitation of increase X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 15:11:06 -0000 Hi everybody, the current LEDBAT spec doesn't seem to be correct. The text is stating that the increase should be limited to be not faster than standard TCP's increase but the pseudo code doesn't limitate the increase correctly. I would like to propose to change the pseudo code to cwnd += GAIN * off_target / TARGET / cwnd instead of cwnd += GAIN * off_target / cwnd Now GAIN=1 would limit the increase correctly and this is conform with the implementation of the uTP client from BitTorrent. This change would also slow down the decrease. That could disturb competing standard TCPs slightly. But it will not keep the TCPs from sharing the capacity equally. Moreover, a less aggressive reaction on delay changes will make LEDBAT more noise robust. There are other proposals to change the decrease, e.g. to have an multiplicative decrease which could also help the intra-protocol fairness problem (if the queue get empty for a short time). I wouldn't wanne support this approach, as then LEDBAT will oscillate more strongly and thus not utilize the available capacity fully. I would say its more import to utilize the capacity fully than having intra-protocol fairness. If LEDBAT is friendly to every other TCP connection, it can also be friendly to another LEDBAT connection as the user will not care about the completion time when using LEDBAT. Maybe its even better to have one LEDBAT flow after the other using all the capacity. Maybe there is a case where a higher GAIN factor for the decrease than for the increase makes sense (e.g. to distrub completing standard TCP's less) but I couldn't figure out any reasonable value for a 'decrease GAIN'. Thus I would only like to add this 1/TARGET for the cwnd change and I will include a discussion on different decrease behavior as well as the pointers to recent papers. Any options? Mirja From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Feb 15 09:22:03 2011 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 2CC553A6CD9 for ; Tue, 15 Feb 2011 09:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[AWL=0.390, 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 RK-qZjHnk5g1 for ; Tue, 15 Feb 2011 09:22:02 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 22FAE3A6D10 for ; Tue, 15 Feb 2011 09:22:01 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 07CB6633B1 for ; Tue, 15 Feb 2011 18:22:27 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id E13E359A8A for ; Tue, 15 Feb 2011 18:22:26 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: ledbat@ietf.org Date: Tue, 15 Feb 2011 18:22:26 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201102151822.26045.mkuehle@ikr.uni-stuttgart.de> Subject: [ledbat] max cwnd X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 17:22:03 -0000 Hi again, there is another line in the pseudo code: max_allowed_cwnd = ALLOWED_INCREASE + TETHER*flight_size() The current spec says: "ALLOWED_INCREASE SHOULD be 1 packet; it MUST be at least 1 packet and SHOULD NOT be more than 3 packets. TETHER SHOULD be 1.5; it MUST be greater than 1. " This is the cwnd limitation when there are no enough data to fill the cwnd. As far as I can see the implementation in Linux would limit to max_allowed_cwnd = 3 + 1*flight_size(). 3 is the default value for tcp_reordering which is the maximum a packet can be reordered in a TCP packet stream without TCP assuming packet loss and going into slow start. In RFC 2861 its written cwnd = (win + W_used)/2 which would be similar to cwnd = (cwnd + fight_size()) / 2 (as far as I understood). Can somebody tell me whats the right thing to do here? Mirja From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Feb 16 08:15:30 2011 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 40FD43A6E6A for ; Wed, 16 Feb 2011 08:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.260, 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 UTiF2f3eB6GP for ; Wed, 16 Feb 2011 08:15:29 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 6669C3A6E2C for ; Wed, 16 Feb 2011 08:15:29 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 3F2FE633B1 for ; Wed, 16 Feb 2011 17:15:56 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 2EF8459A8A for ; Wed, 16 Feb 2011 17:15:56 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: ledbat@ietf.org Date: Wed, 16 Feb 2011 17:15:54 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201102161715.54959.mkuehle@ikr.uni-stuttgart.de> Subject: [ledbat] random input 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, 16 Feb 2011 16:15:30 -0000 Hi, I would like to remove the part about the random input from the draft. It might be helpful for LEDBAT if there actually is some variation in delay on link as this could cause the bottleneck queue to empty from time to time. If this would happen, all LEDBAT connections will be able to measure the real base delay. But adding some random delay factor when calculation the cwnd at the sender doesn't help to empty the queue at all. Is it okay to remove the random input part or does anybody have different results? Actually, regarding the intra-protocol fairness issue. I wouldn't care too much about multiple LEDBAT's which will not share the capacity equally, as this was not one of the design goals (as already stated in the previous mail). But the other problem is that a LEDBAT that will never measure the true base delay, will add its own TARGET on top of the wrong base delay. In the worst case when the old LEDBAT connection is decreasing as fast as the new one is increasing, the new LEDBAT will actually add double the TARGET. Maybe this is a case for having a higher GAIN value for the decrease...? But what's the right value here? Mirja From lars.eggert@nokia.com Thu Feb 17 05:33:33 2011 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 4E4CB3A6CCA for ; Thu, 17 Feb 2011 05:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.678 X-Spam-Level: X-Spam-Status: No, score=-102.678 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, 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 IRwByioaM56g for ; Thu, 17 Feb 2011 05:33:32 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 500A63A6C8B for ; Thu, 17 Feb 2011 05:33:32 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1HDY1rd000409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2011 15:34:02 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-70--332624978; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 17 Feb 2011 15:33:58 +0200 Message-Id: <21A518B3-EFE5-4843-9675-280669ABA6B7@nokia.com> To: ledbat@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 17 Feb 2011 15:33:59 +0200 (EET) X-Nokia-AV: Clean Subject: [ledbat] push forward draft-ietf-ledbat-congestion 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, 17 Feb 2011 13:33:33 -0000 --Apple-Mail-70--332624978 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, thanks, Mirja, for getting the ball rolling again on = draft-ietf-ledbat-congestion.=20 WG participants, please discuss these and all other remaining issues. = LEDBAT needs to wrap up its charter ASAP, it has taken entirely too long = to get these work items out. Lars= --Apple-Mail-70--332624978 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIxNzEzMzM1OFowIwYJKoZIhvcNAQkE MRYEFITif+U6CsofA8RL9Fpsikxv6bYnMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB ABM1W1HiiWt0RItucAI1JQYvNGBWq5AchZhgGiF+0/vW6c+Qp679GHmEFU3dn6Zv2zJvN7sZld+r 7TU02zCAJb9KfI6s9knCthXwl2azOga19m4YvbjjapmGYX2R67O0UfWjghLlWQUGu15vq6Cgc6Ri 9+iiePgU7Y7ug7WM93O+x0HmoJQ/jlx6YFaHkuUhPhSsWV65/2Z8SRKZS8Ph8naHNrbuUDr21JTG l4i452abP4Jxscnfr8f1+XHGJREAVF4aovjadhXorKnZthF3JiNASGrYOd6SQT3qEZFrZkpDRNTN +P3gO82rpO88vnYHxkjjkYP+Nem45b0/HfBzx74AAAAAAAA= --Apple-Mail-70--332624978-- From Rolf.Winter@neclab.eu Thu Feb 17 05:46:59 2011 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 3BD303A6D12 for ; Thu, 17 Feb 2011 05:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[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 XUd50DXHzdj1 for ; Thu, 17 Feb 2011 05:46:58 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 2E58B3A6CC6 for ; Thu, 17 Feb 2011 05:46:58 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 032002800018C for ; Thu, 17 Feb 2011 14:48:45 +0100 (CET) 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 wW10DpUMAZMc for ; Thu, 17 Feb 2011 14:48:44 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DAEB22800017B for ; Thu, 17 Feb 2011 14:48:39 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.162]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Thu, 17 Feb 2011 14:47:23 +0100 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: regarding intra-protocol fairness Thread-Index: AcvOqTOdyR6NtvSyS4Wx44y6zZKp8Q== Date: Thu, 17 Feb 2011 13:47:22 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DBB108@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] regarding intra-protocol fairness 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, 17 Feb 2011 13:46:59 -0000 Hi, =20 picking up the point about intra-protocol fairness. In general intra-protoc= ol fairness does not seem to be the biggest issue: 1) assuming multiple flows work on downloading the same file (as one exampl= e of using LEDBAT), then the aggregate is of interest, not that each indivi= dual flow get's an equal share. 2) assuming multiple flows work on downloading multiple files, then one dow= nload will be faster than others (apps can deal with this, esp. as we now a= llow to have targets lower (but not higher) than 100ms, so users can set pr= iorities this way - other trivial mechanisms are of course conceivable) 3) assuming multiple apps compete (people having more than one teenager in = the household might experience this situation), then one app might be starv= ed, this is not nice, but I don't think we can or should solve this.=20 At this point in time I think input from the BitTorrent folks would be real= ly useful. In their absence, I think intra-protocol fairness is not our big= gest concern. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From Rolf.Winter@neclab.eu Thu Feb 17 05:54:12 2011 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 B98713A6CAC for ; Thu, 17 Feb 2011 05:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 zehAKaCkmKKq for ; Thu, 17 Feb 2011 05:54:11 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 9743B3A6C8B for ; Thu, 17 Feb 2011 05:54:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 725EC2800018C; Thu, 17 Feb 2011 14:55:58 +0100 (CET) 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 zTFEH13NOqls; Thu, 17 Feb 2011 14:55:58 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 553E22800017B; Thu, 17 Feb 2011 14:55:48 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.162]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Thu, 17 Feb 2011 14:54:32 +0100 From: Rolf Winter To: =?iso-8859-1?Q?Mirja_K=FChlewind?= , "ledbat@ietf.org" Thread-Topic: [ledbat] random input Thread-Index: AQHLzfTVRUh/ZVTYF0GQuzza1z8aVJQFtvyA Date: Thu, 17 Feb 2011 13:54:31 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DBB11B@PALLENE.office.hd> References: <201102161715.54959.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: <201102161715.54959.mkuehle@ikr.uni-stuttgart.de> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ledbat] random input 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, 17 Feb 2011 13:54:12 -0000 Hi, I think that it might be OK to remove random factor, especially as the dela= y measurement should add sufficient randomness. The draft currently recomme= nd a random value of 0 anyway. Regarding the point about not being able to = measure the real base delay, I guess the hope is that other (TCP/UDP) traff= ic will force all LEDBAT flows once in a while to back off completely, allo= wing all flows at some point to measure the true base delay. Again, BitTorrent input would be helpful on this point. 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 Mirja K=FChlewind > Sent: Mittwoch, 16. Februar 2011 17:16 > To: ledbat@ietf.org > Subject: [ledbat] random input >=20 > Hi, >=20 > I would like to remove the part about the random input from the draft. > It > might be helpful for LEDBAT if there actually is some variation in > delay on > link as this could cause the bottleneck queue to empty from time to > time. If > this would happen, all LEDBAT connections will be able to measure the > real > base delay. But adding some random delay factor when calculation the > cwnd at > the sender doesn't help to empty the queue at all. Is it okay to remove > the > random input part or does anybody have different results? >=20 > Actually, regarding the intra-protocol fairness issue. I wouldn't care > too > much about multiple LEDBAT's which will not share the capacity equally, > as > this was not one of the design goals (as already stated in the previous > mail). But the other problem is that a LEDBAT that will never measure > the > true base delay, will add its own TARGET on top of the wrong base delay. > In > the worst case when the old LEDBAT connection is decreasing as fast as > the > new one is increasing, the new LEDBAT will actually add double the > TARGET. > Maybe this is a case for having a higher GAIN value for the > decrease...? But > what's the right value here? >=20 > Mirja > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From wes@mti-systems.com Thu Feb 17 06:43:07 2011 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 C0F273A6EFC for ; Thu, 17 Feb 2011 06:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 SlkX97o9i6s7 for ; Thu, 17 Feb 2011 06:43:04 -0800 (PST) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by core3.amsl.com (Postfix) with ESMTP id D81883A6EEE for ; Thu, 17 Feb 2011 06:43:03 -0800 (PST) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p1HEhYKN030862 for ; Thu, 17 Feb 2011 09:43:34 -0500 Authentication-Results: cm-omr8 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [173.106.197.239] ([173.106.197.239:55206] helo=[192.168.9.2]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 63/10-21703-3143D5D4; Thu, 17 Feb 2011 09:43:33 -0500 Message-ID: <4D5D3411.4070200@mti-systems.com> Date: Thu, 17 Feb 2011 09:43:29 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: ledbat@ietf.org References: <4BDBB5BF-2D33-44E6-91C9-F6541E7E0684@ifi.uio.no> <803FC6E5-9906-4402-AD46-B0EC26EC6546@ifi.uio.no> In-Reply-To: <803FC6E5-9906-4402-AD46-B0EC26EC6546@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ledbat] draft-ietf-ledbat-survey-04 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, 17 Feb 2011 14:43:07 -0000 On 2/3/2011 8:57 PM, Michael Welzl wrote: > Hmmm... silence... > > may I ask the reviewers to do a quick check, to see whether there > comments are now amply addressed or tell us if there's still something > missing? > > Thanks! > > Michael > > I checked it over, and it looks good to me. -- Wes Eddy MTI Systems From david.ros@telecom-bretagne.eu Thu Feb 17 07:13:48 2011 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 96E003A6F25 for ; Thu, 17 Feb 2011 07:13:48 -0800 (PST) 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 STdInP1arQDG for ; Thu, 17 Feb 2011 07:13:47 -0800 (PST) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id 28BAB3A6E28 for ; Thu, 17 Feb 2011 07:13:46 -0800 (PST) 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 p1HFEK4l011084; Thu, 17 Feb 2011 16:14:20 +0100 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 p1HFEDsQ011053; Thu, 17 Feb 2011 16:14:17 +0100 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 p1HFEAJY023787; Thu, 17 Feb 2011 16:14:10 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1082) From: David Ros Date: Thu, 17 Feb 2011 16:14:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <094AA2FD-4077-4A39-A0AF-AC136BBFAF81@telecom-bretagne.eu> References: <20110217150533.387E73A6F1D@core3.amsl.com> To: ledbat@ietf.org X-Mailer: Apple Mail (2.1082) X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: Rolf Winter Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-05 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, 17 Feb 2011 15:13:48 -0000 Hi, We've uploaded a new version of draft-ietf-ledbat-survey, see below. = It's a very minor update, taking into account Rolf's remarks. Thanks, David. D=E9but du message r=E9exp=E9di=E9 : > De : IETF I-D Submission Tool > Date : 17 f=E9vrier 2011 16:05:33 HNEC > =C0 : david.ros@telecom-bretagne.eu > Cc : michawe@ifi.uio.no > Objet : New Version Notification for draft-ietf-ledbat-survey-05=20 >=20 >=20 > A new version of I-D, draft-ietf-ledbat-survey-05.txt has been = successfully submitted by David Ros and posted to the IETF repository. >=20 > Filename: draft-ietf-ledbat-survey > Revision: 05 > Title: A Survey of Lower-than-Best-Effort Transport = Protocols > Creation_date: 2011-02-17 > WG ID: ledbat > Number_of_pages: 18 >=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 delay-insensitive "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 could certainly run a marvellous university here if only we didn't = have to have all these damn students underfoot all the time." -- Terry = Pratchett From Rolf.Winter@neclab.eu Thu Feb 17 07:18:53 2011 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 97E833A6F2A for ; Thu, 17 Feb 2011 07:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.212 X-Spam-Level: X-Spam-Status: No, score=-102.212 tagged_above=-999 required=5 tests=[AWL=0.038, 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 sKqfvuXJwmBv for ; Thu, 17 Feb 2011 07:18:53 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id E19013A6F24 for ; Thu, 17 Feb 2011 07:18:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DBAE12800018E for ; Thu, 17 Feb 2011 16:20:39 +0100 (CET) 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 UClkh2PM+mqc for ; Thu, 17 Feb 2011 16:20:39 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C02102800018C for ; Thu, 17 Feb 2011 16:20:34 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.162]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Thu, 17 Feb 2011 16:19:18 +0100 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: LEDBAT WG last call on draft-ietf-ledbat-survey-05 Thread-Index: AcvOtgrL/lxgu3lMTJ2fixNnnXX9pA== Date: Thu, 17 Feb 2011 15:19:18 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DBB212@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] LEDBAT WG last call on draft-ietf-ledbat-survey-05 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, 17 Feb 2011 15:18:53 -0000 Working group, this is to start a two week WG last call on "A Survey of Lower-than-Best-Ef= fort Transport Protocols" (draft-ietf-ledbat-survey-05).=20 Please send comments to the ledbat@ietf.org mailing list. This working group last call ends on March 03, 2011. The chairs. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From richard_woundy@cable.comcast.com Thu Feb 17 11:07:26 2011 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 250D83A6D15 for ; Thu, 17 Feb 2011 11:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.949 X-Spam-Level: X-Spam-Status: No, score=-106.949 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 dwlV4NBvks-A for ; Thu, 17 Feb 2011 11:07:24 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 8B16E3A6D26 for ; Thu, 17 Feb 2011 11:07:24 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114001895; Thu, 17 Feb 2011 14:07:52 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Thu, 17 Feb 2011 14:07:51 -0500 From: "Woundy, Richard" To: Rolf Winter , =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: [ledbat] random input Thread-Index: AQHLzfnWEDgtkuI/V0q4VTM+9vk+R5QGDESAgAAA0QA= Date: Thu, 17 Feb 2011 19:07:50 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11341186E@PACDCEXMB05.cable.comcast.com> References: <201102161715.54959.mkuehle@ikr.uni-stuttgart.de> <791AD3077F94194BB2BDD13565B6295D05DBB11B@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DBB11B@PALLENE.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.75.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" Subject: Re: [ledbat] random input 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, 17 Feb 2011 19:07:26 -0000 > Again, BitTorrent input would be helpful on this point. Agreed. But I should point out that this topic has been raised frequently i= n past face to face meetings. Even if we remove the explicit random factor, can we at least summarize tha= t at least some random fluctuation in base delay measurement is assumed? Below are relevant minutes from the last three LEDBAT meetings. >From http://www.ietf.org/proceedings/76/minutes/ledbat.txt: Late comer's (non)-advantage ----- Lars: implementation depends on side effects on user's operating system, an= d looks like only might work by serendipity. It seems to be just a hack tha= t might not work all the time. Slav: if your machine is so good, then you can introduce noise / random flu= ctuations in inter-packet transmission time. Stewart: As world moves to flash disk, high-performance CPUs, timers are mo= re and more precise. Cannot depend on the end system introducing random noi= se. Murari: problem is non-existent on many systems. Rich: Assumption about a backoff time is random. Need to clearly state expe= ctation that things back off with a random component. The random component = is an implementation detail. (ACTION) Lars: Better to have something explicit in the document. Slav: Need to flush queue to figure out RTT on second stream to really know= . Lars: That is too heavy weight (Slav clearly agrees) Bob Briscoe: Late-comer's advantage: please add it to the draft as describe= d on the list. Disadvantage: late-comer does not know base delay. Advantag= e: if it does know base delay, other flows will not necessarily get out of = the way of the new flow. Draft says randomness fixes this, but that means r= andomness needs to be ensured (ACTION) Fairness ----- Bob: Need to write down assumptions. Random walks with a lot of flows compe= ting with each other; do not see how ones will a small amount of bandwidth = will ever get large or vice versa. Need to state why randomness helps and i= mportance of true randomness in the algorithm. =20 (ACTION) Andrew: randomness protocol adds needs an estimator to know what randomness= is available so it knows how much randomness to add. Bob: May be we see randomness in networks because today's protocols have ra= ndomness built in. If on a ledbat-only network, no randomness. =20 E.g., data center Slav: experience is randomness still there. Stuart: every network does NOT have randomness. Slav: every network I have = TRIED has randomness, but not necessarily true for all networks. =20 Stuart: MacOS 8.6 (?) had this problem; throughput cut in half. No randomne= ss, so everyone had the same collisions repeating. Bob: just need to note this in spec. >From http://www.ietf.org/proceedings/77/minutes/ledbat.txt: Fairness Lars: Measurements in Trilogy project is not enough, minutes may be needed = to determine baseline delay measurement. Explicit randomization should help= .=20 Rolf Winter NEC: An issue is one minute slots for base delay, with history= of ten minutes. A long delay in a one minute slot will not be aged out unt= il ten minutes.=20 Stanislav: Clarification, inserts small random (zero mean) values to delay = which changes amount of capacity that is distributed to other flows. Paramt= er should be related to the target.=20 >From http://www.ietf.org/proceedings/79/minutes/ledbat.txt: SC - we don't need to agonise too much about fairness - apps that are using= this have already made a decision to play nice RoW - not sure I agree - competing apps in the same space may have motivati= ons to try to deliver better performance by increasing the base delay very = slightly. this should be discussed in the draft. Random reshuffling for fairness slide RoW - have results that demonstrate latecomer advantage SC - Stas Shalunov (SS) asserted that OS scheduler would give enough random= ness, I asked how much randomness was needed, didn't get a response. Don't = hold up the document for this, if we don't have a firm answer then leave te= xt vague 'some amount of randomness is believed to help' LE - people implementing this should experiment with this. does adding more= entropy improve behaviour they observe? this might be an improvement but w= e really don't know and we need someone to tell us. MS - don't know if BitTorrent do this in their implementation today SC - quite certain they don't as SS asserted that entropy of OS scheduling = would deal with this. But it won't if we're talking about MacOSX. MS - if you have few connections then the synch problem seems real, but we = don't have data. -- Rich -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Rolf Winter Sent: Thursday, February 17, 2011 8:55 AM To: Mirja K=FChlewind; ledbat@ietf.org Subject: Re: [ledbat] random input Hi, I think that it might be OK to remove random factor, especially as the dela= y measurement should add sufficient randomness. The draft currently recomme= nd a random value of 0 anyway. Regarding the point about not being able to = measure the real base delay, I guess the hope is that other (TCP/UDP) traff= ic will force all LEDBAT flows once in a while to back off completely, allo= wing all flows at some point to measure the true base delay. Again, BitTorrent input would be helpful on this point. 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 Mirja K=FChlewind > Sent: Mittwoch, 16. Februar 2011 17:16 > To: ledbat@ietf.org > Subject: [ledbat] random input >=20 > Hi, >=20 > I would like to remove the part about the random input from the draft. > It > might be helpful for LEDBAT if there actually is some variation in > delay on > link as this could cause the bottleneck queue to empty from time to > time. If > this would happen, all LEDBAT connections will be able to measure the > real > base delay. But adding some random delay factor when calculation the > cwnd at > the sender doesn't help to empty the queue at all. Is it okay to remove > the > random input part or does anybody have different results? >=20 > Actually, regarding the intra-protocol fairness issue. I wouldn't care > too > much about multiple LEDBAT's which will not share the capacity equally, > as > this was not one of the design goals (as already stated in the previous > mail). But the other problem is that a LEDBAT that will never measure > the > true base delay, will add its own TARGET on top of the wrong base delay. > In > the worst case when the old LEDBAT connection is decreasing as fast as > the > new one is increasing, the new LEDBAT will actually add double the > TARGET. > Maybe this is a case for having a higher GAIN value for the > decrease...? But > what's the right value here? >=20 > Mirja > _______________________________________________ > 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 From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Feb 18 04:18:48 2011 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 151983A6C82 for ; Fri, 18 Feb 2011 04:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, 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 OConHlcTTJJc for ; Fri, 18 Feb 2011 04:18:46 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 63FA73A6DEC for ; Fri, 18 Feb 2011 04:18:45 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 50530633B2; Fri, 18 Feb 2011 13:19:17 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 3841959A8A; Fri, 18 Feb 2011 13:19:17 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: "Woundy, Richard" Date: Fri, 18 Feb 2011 13:19:16 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <201102161715.54959.mkuehle@ikr.uni-stuttgart.de> <791AD3077F94194BB2BDD13565B6295D05DBB11B@PALLENE.office.hd> <1CA25301D2219F40B3AA37201F0EACD11341186E@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD11341186E@PACDCEXMB05.cable.comcast.com> 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: <201102181319.16627.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: "ledbat@ietf.org" , Rolf Winter Subject: Re: [ledbat] random input 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, 18 Feb 2011 12:18:48 -0000 Those minutes show exactly the point. As Stas said "random fluctuations in= =20 inter-packet transmission time" is needed. But the random factor in the dra= ft=20 doesn't bring any randomness for the inter-packet transmission times! On Thursday 17 February 2011 20:07:50 Woundy, Richard wrote: > > Again, BitTorrent input would be helpful on this point. > > Agreed. But I should point out that this topic has been raised frequently > in past face to face meetings. > > Even if we remove the explicit random factor, can we at least summarize > that at least some random fluctuation in base delay measurement is assume= d? > > Below are relevant minutes from the last three LEDBAT meetings. > > From http://www.ietf.org/proceedings/76/minutes/ledbat.txt: > > Late comer's (non)-advantage > ----- > > Lars: implementation depends on side effects on user's operating system, > and looks like only might work by serendipity. It seems to be just a hack > that might not work all the time. > > Slav: if your machine is so good, then you can introduce noise / random > fluctuations in inter-packet transmission time. > > Stewart: As world moves to flash disk, high-performance CPUs, timers are > more and more precise. Cannot depend on the end system introducing random > noise. > > Murari: problem is non-existent on many systems. > > Rich: Assumption about a backoff time is random. Need to clearly state > expectation that things back off with a random component. The random > component is an implementation detail. (ACTION) > > Lars: Better to have something explicit in the document. > > Slav: Need to flush queue to figure out RTT on second stream to really > know. > > Lars: That is too heavy weight (Slav clearly agrees) > > Bob Briscoe: Late-comer's advantage: please add it to the draft as > described on the list. Disadvantage: late-comer does not know base delay. > Advantage: if it does know base delay, other flows will not necessarily g= et > out of the way of the new flow. Draft says randomness fixes this, but that > means randomness needs to be ensured (ACTION) > > Fairness > ----- > > Bob: Need to write down assumptions. Random walks with a lot of flows > competing with each other; do not see how ones will a small amount of > bandwidth will ever get large or vice versa. Need to state why randomness > helps and importance of true randomness in the algorithm. (ACTION) > > Andrew: randomness protocol adds needs an estimator to know what randomne= ss > is available so it knows how much randomness to add. > > Bob: May be we see randomness in networks because today's protocols have > randomness built in. If on a ledbat-only network, no randomness. E.g., da= ta > center > > Slav: experience is randomness still there. > > Stuart: every network does NOT have randomness. Slav: every network I have > TRIED has randomness, but not necessarily true for all networks. Stuart: > MacOS 8.6 (?) had this problem; throughput cut in half. No randomness, so > everyone had the same collisions repeating. > > Bob: just need to note this in spec. > > From http://www.ietf.org/proceedings/77/minutes/ledbat.txt: > > Fairness > Lars: Measurements in Trilogy project is not enough, minutes may be needed > to determine baseline delay measurement. Explicit randomization should > help. > > Rolf Winter NEC: An issue is one minute slots for base delay, with histo= ry > of ten minutes. A long delay in a one minute slot will not be aged out > until ten minutes. > > Stanislav: Clarification, inserts small random (zero mean) values to delay > which changes amount of capacity that is distributed to other flows. > Paramter should be related to the target. > > From http://www.ietf.org/proceedings/79/minutes/ledbat.txt: > > SC - we don't need to agonise too much about fairness - apps that are usi= ng > this have already made a decision to play nice > > RoW - not sure I agree - competing apps in the same space may have > motivations to try to deliver better performance by increasing the base > delay very slightly. this should be discussed in the draft. > > Random reshuffling for fairness slide > > RoW - have results that demonstrate latecomer advantage > > SC - Stas Shalunov (SS) asserted that OS scheduler would give enough > randomness, I asked how much randomness was needed, didn't get a response. > Don't hold up the document for this, if we don't have a firm answer then > leave text vague 'some amount of randomness is believed to help' > > LE - people implementing this should experiment with this. does adding mo= re > entropy improve behaviour they observe? this might be an improvement but = we > really don't know and we need someone to tell us. > > MS - don't know if BitTorrent do this in their implementation today > > SC - quite certain they don't as SS asserted that entropy of OS scheduling > would deal with this. But it won't if we're talking about MacOSX. > > MS - if you have few connections then the synch problem seems real, but we > don't have data. > > -- Rich > > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf = Of > Rolf Winter Sent: Thursday, February 17, 2011 8:55 AM > To: Mirja K=FChlewind; ledbat@ietf.org > Subject: Re: [ledbat] random input > > Hi, > > > > I think that it might be OK to remove random factor, especially as the > delay measurement should add sufficient randomness. The draft currently > recommend a random value of 0 anyway. Regarding the point about not being > able to measure the real base delay, I guess the hope is that other > (TCP/UDP) traffic will force all LEDBAT flows once in a while to back off > completely, allowing all flows at some point to measure the true base > delay. > > Again, BitTorrent input would be helpful on this point. > > 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 Mirja K=FChlewind > > Sent: Mittwoch, 16. Februar 2011 17:16 > > To: ledbat@ietf.org > > Subject: [ledbat] random input > > > > Hi, > > > > I would like to remove the part about the random input from the draft. > > It > > might be helpful for LEDBAT if there actually is some variation in > > delay on > > link as this could cause the bottleneck queue to empty from time to > > time. If > > this would happen, all LEDBAT connections will be able to measure the > > real > > base delay. But adding some random delay factor when calculation the > > cwnd at > > the sender doesn't help to empty the queue at all. Is it okay to remove > > the > > random input part or does anybody have different results? > > > > Actually, regarding the intra-protocol fairness issue. I wouldn't care > > too > > much about multiple LEDBAT's which will not share the capacity equally, > > as > > this was not one of the design goals (as already stated in the previous > > mail). But the other problem is that a LEDBAT that will never measure > > the > > true base delay, will add its own TARGET on top of the wrong base delay. > > In > > the worst case when the old LEDBAT connection is decreasing as fast as > > the > > new one is increasing, the new LEDBAT will actually add double the > > TARGET. > > Maybe this is a case for having a higher GAIN value for the > > decrease...? But > > what's the right value here? > > > > Mirja > > _______________________________________________ > > 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 richard_woundy@cable.comcast.com Fri Feb 18 08:08:16 2011 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 7226E3A6E67 for ; Fri, 18 Feb 2011 08:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.342 X-Spam-Level: X-Spam-Status: No, score=-104.342 tagged_above=-999 required=5 tests=[AWL=-2.607, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 7UrR-KqBzu1Z for ; Fri, 18 Feb 2011 08:08:15 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id D73703A6C6A for ; Fri, 18 Feb 2011 08:08:14 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.26498540; Fri, 18 Feb 2011 09:19:56 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Fri, 18 Feb 2011 11:08:27 -0500 From: "Woundy, Richard" To: Mirja Kuehlewind Thread-Topic: [ledbat] random input Thread-Index: AQHLzfnWEDgtkuI/V0q4VTM+9vk+R5QGDESAgAAA0QCAAXbnAP//6hTg Date: Fri, 18 Feb 2011 16:08:26 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1134122C8@PACDCEXMB05.cable.comcast.com> References: <201102161715.54959.mkuehle@ikr.uni-stuttgart.de> <791AD3077F94194BB2BDD13565B6295D05DBB11B@PALLENE.office.hd> <1CA25301D2219F40B3AA37201F0EACD11341186E@PACDCEXMB05.cable.comcast.com> <201102181319.16627.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201102181319.16627.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.75.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" , Rolf Winter Subject: Re: [ledbat] random input 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, 18 Feb 2011 16:08:16 -0000 Mirja, The current text has: off_target =3D TARGET - queuing_delay + random_input() cwnd +=3D GAIN * off_target / cwnd and random_input() # random() is a PRNG between 0.0 and 1.0 # NB: RANDOMNESS_AMOUNT is normally 0 RANDOMNESS_AMOUNT * TARGET * ((random() - 0.5)*2) Are you suggesting to delete "random_input()" entirely? Or do you want to change the definition of random_input() to a set of comme= nts that says 'some amount of randomness is believed to help' and 'there ma= y be sufficient randomness in some environments'? Or do you want to change the effect of GAIN on cwnd? -- Rich -----Original Message----- From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de]=20 Sent: Friday, February 18, 2011 7:19 AM To: Woundy, Richard Cc: Rolf Winter; ledbat@ietf.org Subject: Re: [ledbat] random input Those minutes show exactly the point. As Stas said "random fluctuations in= =20 inter-packet transmission time" is needed. But the random factor in the dra= ft=20 doesn't bring any randomness for the inter-packet transmission times! On Thursday 17 February 2011 20:07:50 Woundy, Richard wrote: > > Again, BitTorrent input would be helpful on this point. > > Agreed. But I should point out that this topic has been raised frequently > in past face to face meetings. > > Even if we remove the explicit random factor, can we at least summarize > that at least some random fluctuation in base delay measurement is assume= d? > > Below are relevant minutes from the last three LEDBAT meetings. > > From http://www.ietf.org/proceedings/76/minutes/ledbat.txt: > > Late comer's (non)-advantage > ----- > > Lars: implementation depends on side effects on user's operating system, > and looks like only might work by serendipity. It seems to be just a hack > that might not work all the time. > > Slav: if your machine is so good, then you can introduce noise / random > fluctuations in inter-packet transmission time. > > Stewart: As world moves to flash disk, high-performance CPUs, timers are > more and more precise. Cannot depend on the end system introducing random > noise. > > Murari: problem is non-existent on many systems. > > Rich: Assumption about a backoff time is random. Need to clearly state > expectation that things back off with a random component. The random > component is an implementation detail. (ACTION) > > Lars: Better to have something explicit in the document. > > Slav: Need to flush queue to figure out RTT on second stream to really > know. > > Lars: That is too heavy weight (Slav clearly agrees) > > Bob Briscoe: Late-comer's advantage: please add it to the draft as > described on the list. Disadvantage: late-comer does not know base delay= . > Advantage: if it does know base delay, other flows will not necessarily g= et > out of the way of the new flow. Draft says randomness fixes this, but tha= t > means randomness needs to be ensured (ACTION) > > Fairness > ----- > > Bob: Need to write down assumptions. Random walks with a lot of flows > competing with each other; do not see how ones will a small amount of > bandwidth will ever get large or vice versa. Need to state why randomness > helps and importance of true randomness in the algorithm. (ACTION) > > Andrew: randomness protocol adds needs an estimator to know what randomne= ss > is available so it knows how much randomness to add. > > Bob: May be we see randomness in networks because today's protocols have > randomness built in. If on a ledbat-only network, no randomness. E.g., da= ta > center > > Slav: experience is randomness still there. > > Stuart: every network does NOT have randomness. Slav: every network I hav= e > TRIED has randomness, but not necessarily true for all networks. Stuart: > MacOS 8.6 (?) had this problem; throughput cut in half. No randomness, so > everyone had the same collisions repeating. > > Bob: just need to note this in spec. > > From http://www.ietf.org/proceedings/77/minutes/ledbat.txt: > > Fairness > Lars: Measurements in Trilogy project is not enough, minutes may be neede= d > to determine baseline delay measurement. Explicit randomization should > help. > > Rolf Winter NEC: An issue is one minute slots for base delay, with histo= ry > of ten minutes. A long delay in a one minute slot will not be aged out > until ten minutes. > > Stanislav: Clarification, inserts small random (zero mean) values to dela= y > which changes amount of capacity that is distributed to other flows. > Paramter should be related to the target. > > From http://www.ietf.org/proceedings/79/minutes/ledbat.txt: > > SC - we don't need to agonise too much about fairness - apps that are usi= ng > this have already made a decision to play nice > > RoW - not sure I agree - competing apps in the same space may have > motivations to try to deliver better performance by increasing the base > delay very slightly. this should be discussed in the draft. > > Random reshuffling for fairness slide > > RoW - have results that demonstrate latecomer advantage > > SC - Stas Shalunov (SS) asserted that OS scheduler would give enough > randomness, I asked how much randomness was needed, didn't get a response= . > Don't hold up the document for this, if we don't have a firm answer then > leave text vague 'some amount of randomness is believed to help' > > LE - people implementing this should experiment with this. does adding mo= re > entropy improve behaviour they observe? this might be an improvement but = we > really don't know and we need someone to tell us. > > MS - don't know if BitTorrent do this in their implementation today > > SC - quite certain they don't as SS asserted that entropy of OS schedulin= g > would deal with this. But it won't if we're talking about MacOSX. > > MS - if you have few connections then the synch problem seems real, but w= e > don't have data. > > -- Rich > > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf = Of > Rolf Winter Sent: Thursday, February 17, 2011 8:55 AM > To: Mirja K=FChlewind; ledbat@ietf.org > Subject: Re: [ledbat] random input > > Hi, > > > > I think that it might be OK to remove random factor, especially as the > delay measurement should add sufficient randomness. The draft currently > recommend a random value of 0 anyway. Regarding the point about not being > able to measure the real base delay, I guess the hope is that other > (TCP/UDP) traffic will force all LEDBAT flows once in a while to back off > completely, allowing all flows at some point to measure the true base > delay. > > Again, BitTorrent input would be helpful on this point. > > 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 Mirja K=FChlewind > > Sent: Mittwoch, 16. Februar 2011 17:16 > > To: ledbat@ietf.org > > Subject: [ledbat] random input > > > > Hi, > > > > I would like to remove the part about the random input from the draft. > > It > > might be helpful for LEDBAT if there actually is some variation in > > delay on > > link as this could cause the bottleneck queue to empty from time to > > time. If > > this would happen, all LEDBAT connections will be able to measure the > > real > > base delay. But adding some random delay factor when calculation the > > cwnd at > > the sender doesn't help to empty the queue at all. Is it okay to remove > > the > > random input part or does anybody have different results? > > > > Actually, regarding the intra-protocol fairness issue. I wouldn't care > > too > > much about multiple LEDBAT's which will not share the capacity equally, > > as > > this was not one of the design goals (as already stated in the previous > > mail). But the other problem is that a LEDBAT that will never measure > > the > > true base delay, will add its own TARGET on top of the wrong base delay= . > > In > > the worst case when the old LEDBAT connection is decreasing as fast as > > the > > new one is increasing, the new LEDBAT will actually add double the > > TARGET. > > Maybe this is a case for having a higher GAIN value for the > > decrease...? But > > what's the right value here? > > > > Mirja > > _______________________________________________ > > 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 ------------------------------------------------------------------- Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de ------------------------------------------------------------------- From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Feb 18 08:19:39 2011 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 5777E3A6CA1 for ; Fri, 18 Feb 2011 08:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, 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 8mooFfDtixCP for ; Fri, 18 Feb 2011 08:19:37 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 92A913A6C6A for ; Fri, 18 Feb 2011 08:19:37 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 30261633B2; Fri, 18 Feb 2011 17:20:10 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 1C16459A8A; Fri, 18 Feb 2011 17:20:10 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: "Woundy, Richard" Date: Fri, 18 Feb 2011 17:20:09 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <201102161715.54959.mkuehle@ikr.uni-stuttgart.de> <201102181319.16627.mirja.kuehlewind@ikr.uni-stuttgart.de> <1CA25301D2219F40B3AA37201F0EACD1134122C8@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1134122C8@PACDCEXMB05.cable.comcast.com> 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: <201102181720.09659.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: "ledbat@ietf.org" , Rolf Winter Subject: Re: [ledbat] random input 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, 18 Feb 2011 16:19:39 -0000 I want to delete random_input() from the pseudo code and add/extend an sect= ion=20 (probably in 5.3 Fairness between LEDBAT flows) to say 'some amount of=20 randomness is believed to help' and 'there may be sufficient randomness in= =20 some environments'.=20 I'm afraid that was not completely one of your three given options, but doe= s=20 this work for you? If someone has some more experience on how much randomness can be found in= =20 real systems, I would be happy about additional information or even a piece= =20 of text as contribution for the draft! On Friday 18 February 2011 17:08:26 Woundy, Richard wrote: > Mirja, > > The current text has: > > off_target =3D TARGET - queuing_delay + random_input() > cwnd +=3D GAIN * off_target / cwnd > > and > > random_input() > # random() is a PRNG between 0.0 and 1.0 > # NB: RANDOMNESS_AMOUNT is normally 0 > RANDOMNESS_AMOUNT * TARGET * ((random() - 0.5)*2) > > Are you suggesting to delete "random_input()" entirely? > > Or do you want to change the definition of random_input() to a set of > comments that says 'some amount of randomness is believed to help' and > 'there may be sufficient randomness in some environments'? > > Or do you want to change the effect of GAIN on cwnd? > > -- Rich > > -----Original Message----- > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > Sent: Friday, February 18, 2011 7:19 AM > To: Woundy, Richard > Cc: Rolf Winter; ledbat@ietf.org > Subject: Re: [ledbat] random input > > Those minutes show exactly the point. As Stas said "random fluctuations in > inter-packet transmission time" is needed. But the random factor in the > draft doesn't bring any randomness for the inter-packet transmission time= s! > > On Thursday 17 February 2011 20:07:50 Woundy, Richard wrote: > > > Again, BitTorrent input would be helpful on this point. > > > > Agreed. But I should point out that this topic has been raised frequent= ly > > in past face to face meetings. > > > > Even if we remove the explicit random factor, can we at least summarize > > that at least some random fluctuation in base delay measurement is > > assumed? > > > > Below are relevant minutes from the last three LEDBAT meetings. > > > > From http://www.ietf.org/proceedings/76/minutes/ledbat.txt: > > > > Late comer's (non)-advantage > > ----- > > > > Lars: implementation depends on side effects on user's operating system, > > and looks like only might work by serendipity. It seems to be just a ha= ck > > that might not work all the time. > > > > Slav: if your machine is so good, then you can introduce noise / random > > fluctuations in inter-packet transmission time. > > > > Stewart: As world moves to flash disk, high-performance CPUs, timers are > > more and more precise. Cannot depend on the end system introducing rand= om > > noise. > > > > Murari: problem is non-existent on many systems. > > > > Rich: Assumption about a backoff time is random. Need to clearly state > > expectation that things back off with a random component. The random > > component is an implementation detail. (ACTION) > > > > Lars: Better to have something explicit in the document. > > > > Slav: Need to flush queue to figure out RTT on second stream to really > > know. > > > > Lars: That is too heavy weight (Slav clearly agrees) > > > > Bob Briscoe: Late-comer's advantage: please add it to the draft as > > described on the list. Disadvantage: late-comer does not know base > > delay. Advantage: if it does know base delay, other flows will not > > necessarily get out of the way of the new flow. Draft says randomness > > fixes this, but that means randomness needs to be ensured (ACTION) > > > > Fairness > > ----- > > > > Bob: Need to write down assumptions. Random walks with a lot of flows > > competing with each other; do not see how ones will a small amount of > > bandwidth will ever get large or vice versa. Need to state why randomne= ss > > helps and importance of true randomness in the algorithm. (ACTION) > > > > Andrew: randomness protocol adds needs an estimator to know what > > randomness is available so it knows how much randomness to add. > > > > Bob: May be we see randomness in networks because today's protocols have > > randomness built in. If on a ledbat-only network, no randomness. E.g., > > data center > > > > Slav: experience is randomness still there. > > > > Stuart: every network does NOT have randomness. Slav: every network I > > have TRIED has randomness, but not necessarily true for all networks. > > Stuart: MacOS 8.6 (?) had this problem; throughput cut in half. No > > randomness, so everyone had the same collisions repeating. > > > > Bob: just need to note this in spec. > > > > From http://www.ietf.org/proceedings/77/minutes/ledbat.txt: > > > > Fairness > > Lars: Measurements in Trilogy project is not enough, minutes may be > > needed to determine baseline delay measurement. Explicit randomization > > should help. > > > > Rolf Winter NEC: An issue is one minute slots for base delay, with > > history of ten minutes. A long delay in a one minute slot will not be > > aged out until ten minutes. > > > > Stanislav: Clarification, inserts small random (zero mean) values to > > delay which changes amount of capacity that is distributed to other > > flows. Paramter should be related to the target. > > > > From http://www.ietf.org/proceedings/79/minutes/ledbat.txt: > > > > SC - we don't need to agonise too much about fairness - apps that are > > using this have already made a decision to play nice > > > > RoW - not sure I agree - competing apps in the same space may have > > motivations to try to deliver better performance by increasing the base > > delay very slightly. this should be discussed in the draft. > > > > Random reshuffling for fairness slide > > > > RoW - have results that demonstrate latecomer advantage > > > > SC - Stas Shalunov (SS) asserted that OS scheduler would give enough > > randomness, I asked how much randomness was needed, didn't get a > > response. Don't hold up the document for this, if we don't have a firm > > answer then leave text vague 'some amount of randomness is believed to > > help' > > > > LE - people implementing this should experiment with this. does adding > > more entropy improve behaviour they observe? this might be an improveme= nt > > but we really don't know and we need someone to tell us. > > > > MS - don't know if BitTorrent do this in their implementation today > > > > SC - quite certain they don't as SS asserted that entropy of OS > > scheduling would deal with this. But it won't if we're talking about > > MacOSX. > > > > MS - if you have few connections then the synch problem seems real, but > > we don't have data. > > > > -- Rich > > > > -----Original Message----- > > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf > > Of Rolf Winter Sent: Thursday, February 17, 2011 8:55 AM > > To: Mirja K=FChlewind; ledbat@ietf.org > > Subject: Re: [ledbat] random input > > > > Hi, > > > > > > > > I think that it might be OK to remove random factor, especially as the > > delay measurement should add sufficient randomness. The draft currently > > recommend a random value of 0 anyway. Regarding the point about not bei= ng > > able to measure the real base delay, I guess the hope is that other > > (TCP/UDP) traffic will force all LEDBAT flows once in a while to back o= ff > > completely, allowing all flows at some point to measure the true base > > delay. > > > > Again, BitTorrent input would be helpful on this point. > > > > 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 Mirja K=FChlewind > > > Sent: Mittwoch, 16. Februar 2011 17:16 > > > To: ledbat@ietf.org > > > Subject: [ledbat] random input > > > > > > Hi, > > > > > > I would like to remove the part about the random input from the draft. > > > It > > > might be helpful for LEDBAT if there actually is some variation in > > > delay on > > > link as this could cause the bottleneck queue to empty from time to > > > time. If > > > this would happen, all LEDBAT connections will be able to measure the > > > real > > > base delay. But adding some random delay factor when calculation the > > > cwnd at > > > the sender doesn't help to empty the queue at all. Is it okay to remo= ve > > > the > > > random input part or does anybody have different results? > > > > > > Actually, regarding the intra-protocol fairness issue. I wouldn't care > > > too > > > much about multiple LEDBAT's which will not share the capacity equall= y, > > > as > > > this was not one of the design goals (as already stated in the previo= us > > > mail). But the other problem is that a LEDBAT that will never measure > > > the > > > true base delay, will add its own TARGET on top of the wrong base > > > delay. In > > > the worst case when the old LEDBAT connection is decreasing as fast as > > > the > > > new one is increasing, the new LEDBAT will actually add double the > > > TARGET. > > > Maybe this is a case for having a higher GAIN value for the > > > decrease...? But > > > what's the right value here? > > > > > > Mirja > > > _______________________________________________ > > > 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 richard_woundy@cable.comcast.com Fri Feb 18 10:49:59 2011 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 C92223A6E28 for ; Fri, 18 Feb 2011 10:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.837 X-Spam-Level: X-Spam-Status: No, score=-106.837 tagged_above=-999 required=5 tests=[AWL=1.626, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, 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 Jg7ML-LlZSYU for ; Fri, 18 Feb 2011 10:49:58 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 99FE33A6F08 for ; Fri, 18 Feb 2011 10:49:57 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114203643; Fri, 18 Feb 2011 13:50:30 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Fri, 18 Feb 2011 13:50:29 -0500 From: "Woundy, Richard" To: Mirja Kuehlewind Thread-Topic: [ledbat] random input Thread-Index: AQHLzfnWEDgtkuI/V0q4VTM+9vk+R5QGDESAgAAA0QCAAXbnAP//6hTggABZOYD//64p4A== Date: Fri, 18 Feb 2011 18:50:28 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1134125FD@PACDCEXMB05.cable.comcast.com> References: <201102161715.54959.mkuehle@ikr.uni-stuttgart.de> <201102181319.16627.mirja.kuehlewind@ikr.uni-stuttgart.de> <1CA25301D2219F40B3AA37201F0EACD1134122C8@PACDCEXMB05.cable.comcast.com> <201102181720.09659.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201102181720.09659.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.75.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" , Rolf Winter Subject: Re: [ledbat] random input 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, 18 Feb 2011 18:49:59 -0000 > I'm afraid that was not completely one of your three given options, but d= oes=20 this work for you? Could you also add a comment somewhere within the algorithm in 3.4.2 that s= ays something to this effect? # See section 5.3 for a discussion of how randomness is assumed in the calc= ulation above. > If someone has some more experience on how much randomness can be found i= n real systems, I would be happy about additional information or even a pie= ce of text as contribution for the draft! Unfortunately I don't have personal knowledge. But the conversation below (= from the IETF76 minutes) among Murari Sridharan (Microsoft), Stuart Cheshir= e (Apple) and Stanislav Shalunov (BitTorrent) seems instructive -- that is,= many environments have some amount of 'randomness' due to operating system= details (e.g. process/thread scheduling and/or less precise timers) and/or= the use of hard disk drives (e.g. rotational delays at 'random' times). Stuart points out that recent MacOS versions may not have these same random= side-effects, and that has caused throughput issues in the past. Also, har= d disk drives are being slowly replaced by solid state drives without rotat= ional delays (or moving parts in general). > > [Stuart]: As world moves to flash disk, high-performance CPUs, timers a= re > > more and more precise. Cannot depend on the end system introducing rand= om > > noise. ... > > Stuart: every network does NOT have randomness. Slav: every network I > > have TRIED has randomness, but not necessarily true for all networks. > > Stuart: MacOS 8.6 (?) had this problem; throughput cut in half. No > > randomness, so everyone had the same collisions repeating. I wonder if we'll get any more detailed guidance than that? -- Rich -----Original Message----- From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de]=20 Sent: Friday, February 18, 2011 11:20 AM To: Woundy, Richard Cc: Rolf Winter; ledbat@ietf.org Subject: Re: [ledbat] random input I want to delete random_input() from the pseudo code and add/extend an sect= ion=20 (probably in 5.3 Fairness between LEDBAT flows) to say 'some amount of=20 randomness is believed to help' and 'there may be sufficient randomness in= =20 some environments'.=20 I'm afraid that was not completely one of your three given options, but doe= s=20 this work for you? If someone has some more experience on how much randomness can be found in= =20 real systems, I would be happy about additional information or even a piece= =20 of text as contribution for the draft! On Friday 18 February 2011 17:08:26 Woundy, Richard wrote: > Mirja, > > The current text has: > > off_target =3D TARGET - queuing_delay + random_input() > cwnd +=3D GAIN * off_target / cwnd > > and > > random_input() > # random() is a PRNG between 0.0 and 1.0 > # NB: RANDOMNESS_AMOUNT is normally 0 > RANDOMNESS_AMOUNT * TARGET * ((random() - 0.5)*2) > > Are you suggesting to delete "random_input()" entirely? > > Or do you want to change the definition of random_input() to a set of > comments that says 'some amount of randomness is believed to help' and > 'there may be sufficient randomness in some environments'? > > Or do you want to change the effect of GAIN on cwnd? > > -- Rich > > -----Original Message----- > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > Sent: Friday, February 18, 2011 7:19 AM > To: Woundy, Richard > Cc: Rolf Winter; ledbat@ietf.org > Subject: Re: [ledbat] random input > > Those minutes show exactly the point. As Stas said "random fluctuations i= n > inter-packet transmission time" is needed. But the random factor in the > draft doesn't bring any randomness for the inter-packet transmission time= s! > > On Thursday 17 February 2011 20:07:50 Woundy, Richard wrote: > > > Again, BitTorrent input would be helpful on this point. > > > > Agreed. But I should point out that this topic has been raised frequent= ly > > in past face to face meetings. > > > > Even if we remove the explicit random factor, can we at least summarize > > that at least some random fluctuation in base delay measurement is > > assumed? > > > > Below are relevant minutes from the last three LEDBAT meetings. > > > > From http://www.ietf.org/proceedings/76/minutes/ledbat.txt: > > > > Late comer's (non)-advantage > > ----- > > > > Lars: implementation depends on side effects on user's operating system= , > > and looks like only might work by serendipity. It seems to be just a ha= ck > > that might not work all the time. > > > > Slav: if your machine is so good, then you can introduce noise / random > > fluctuations in inter-packet transmission time. > > > > Stewart: As world moves to flash disk, high-performance CPUs, timers ar= e > > more and more precise. Cannot depend on the end system introducing rand= om > > noise. > > > > Murari: problem is non-existent on many systems. > > > > Rich: Assumption about a backoff time is random. Need to clearly state > > expectation that things back off with a random component. The random > > component is an implementation detail. (ACTION) > > > > Lars: Better to have something explicit in the document. > > > > Slav: Need to flush queue to figure out RTT on second stream to really > > know. > > > > Lars: That is too heavy weight (Slav clearly agrees) > > > > Bob Briscoe: Late-comer's advantage: please add it to the draft as > > described on the list. Disadvantage: late-comer does not know base > > delay. Advantage: if it does know base delay, other flows will not > > necessarily get out of the way of the new flow. Draft says randomness > > fixes this, but that means randomness needs to be ensured (ACTION) > > > > Fairness > > ----- > > > > Bob: Need to write down assumptions. Random walks with a lot of flows > > competing with each other; do not see how ones will a small amount of > > bandwidth will ever get large or vice versa. Need to state why randomne= ss > > helps and importance of true randomness in the algorithm. (ACTION) > > > > Andrew: randomness protocol adds needs an estimator to know what > > randomness is available so it knows how much randomness to add. > > > > Bob: May be we see randomness in networks because today's protocols hav= e > > randomness built in. If on a ledbat-only network, no randomness. E.g., > > data center > > > > Slav: experience is randomness still there. > > > > Stuart: every network does NOT have randomness. Slav: every network I > > have TRIED has randomness, but not necessarily true for all networks. > > Stuart: MacOS 8.6 (?) had this problem; throughput cut in half. No > > randomness, so everyone had the same collisions repeating. > > > > Bob: just need to note this in spec. > > > > From http://www.ietf.org/proceedings/77/minutes/ledbat.txt: > > > > Fairness > > Lars: Measurements in Trilogy project is not enough, minutes may be > > needed to determine baseline delay measurement. Explicit randomization > > should help. > > > > Rolf Winter NEC: An issue is one minute slots for base delay, with > > history of ten minutes. A long delay in a one minute slot will not be > > aged out until ten minutes. > > > > Stanislav: Clarification, inserts small random (zero mean) values to > > delay which changes amount of capacity that is distributed to other > > flows. Paramter should be related to the target. > > > > From http://www.ietf.org/proceedings/79/minutes/ledbat.txt: > > > > SC - we don't need to agonise too much about fairness - apps that are > > using this have already made a decision to play nice > > > > RoW - not sure I agree - competing apps in the same space may have > > motivations to try to deliver better performance by increasing the base > > delay very slightly. this should be discussed in the draft. > > > > Random reshuffling for fairness slide > > > > RoW - have results that demonstrate latecomer advantage > > > > SC - Stas Shalunov (SS) asserted that OS scheduler would give enough > > randomness, I asked how much randomness was needed, didn't get a > > response. Don't hold up the document for this, if we don't have a firm > > answer then leave text vague 'some amount of randomness is believed to > > help' > > > > LE - people implementing this should experiment with this. does adding > > more entropy improve behaviour they observe? this might be an improveme= nt > > but we really don't know and we need someone to tell us. > > > > MS - don't know if BitTorrent do this in their implementation today > > > > SC - quite certain they don't as SS asserted that entropy of OS > > scheduling would deal with this. But it won't if we're talking about > > MacOSX. > > > > MS - if you have few connections then the synch problem seems real, but > > we don't have data. > > > > -- Rich > > > > -----Original Message----- > > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behal= f > > Of Rolf Winter Sent: Thursday, February 17, 2011 8:55 AM > > To: Mirja K=FChlewind; ledbat@ietf.org > > Subject: Re: [ledbat] random input > > > > Hi, > > > > > > > > I think that it might be OK to remove random factor, especially as the > > delay measurement should add sufficient randomness. The draft currently > > recommend a random value of 0 anyway. Regarding the point about not bei= ng > > able to measure the real base delay, I guess the hope is that other > > (TCP/UDP) traffic will force all LEDBAT flows once in a while to back o= ff > > completely, allowing all flows at some point to measure the true base > > delay. > > > > Again, BitTorrent input would be helpful on this point. > > > > 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 Mirja K=FChlewind > > > Sent: Mittwoch, 16. Februar 2011 17:16 > > > To: ledbat@ietf.org > > > Subject: [ledbat] random input > > > > > > Hi, > > > > > > I would like to remove the part about the random input from the draft= . > > > It > > > might be helpful for LEDBAT if there actually is some variation in > > > delay on > > > link as this could cause the bottleneck queue to empty from time to > > > time. If > > > this would happen, all LEDBAT connections will be able to measure the > > > real > > > base delay. But adding some random delay factor when calculation the > > > cwnd at > > > the sender doesn't help to empty the queue at all. Is it okay to remo= ve > > > the > > > random input part or does anybody have different results? > > > > > > Actually, regarding the intra-protocol fairness issue. I wouldn't car= e > > > too > > > much about multiple LEDBAT's which will not share the capacity equall= y, > > > as > > > this was not one of the design goals (as already stated in the previo= us > > > mail). But the other problem is that a LEDBAT that will never measure > > > the > > > true base delay, will add its own TARGET on top of the wrong base > > > delay. In > > > the worst case when the old LEDBAT connection is decreasing as fast a= s > > > the > > > new one is increasing, the new LEDBAT will actually add double the > > > TARGET. > > > Maybe this is a case for having a higher GAIN value for the > > > decrease...? But > > > what's the right value here? > > > > > > Mirja > > > _______________________________________________ > > > 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 ------------------------------------------------------------------- Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de ------------------------------------------------------------------- From jana.iyengar@gmail.com Wed Feb 23 06:47:33 2011 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 165413A6A1D for ; Wed, 23 Feb 2011 06:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7ntA3jXgOck for ; Wed, 23 Feb 2011 06:47:29 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id C6DB03A6A24 for ; Wed, 23 Feb 2011 06:47:28 -0800 (PST) Received: by vws6 with SMTP id 6so2190443vws.31 for ; Wed, 23 Feb 2011 06:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:reply-to:organization :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=yKc3uatX0PpY9CXXAKZvI9BGb5LRamqOqYbyq/dHW4g=; b=lFhQpHIKPU6/5PNX4N54+TYF3oIrxUaRZM+QdPJAbTLFa62k8rhs6WHBK5tijCaHvh It7jbTIY4qq8Yy7hNA+O51kowypOCOyqWSOsp/bzhC+uco7yYYFQ1kYLK2rBP+ZFFADF 9ts6wJ2dIkfOUW4akd/KFk0aLqG8NIUyN8MQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:subject:content-type:content-transfer-encoding; b=RdQ4LyHOa0uEw1OLL2UmXbwKcvkITfSAJ2QE86hZ/hwHgOSNWOiEGqZyM1W8/BIUCa fTm4qnXF1iUHq/I2XMfbxpSjRuthiXKEh2Yrrlgq2GyczwGU9sPIuKnLatVzRW9covn/ gLp1pvUtvcEPaiMYGXtJToSunliR0tYTjO3Cs= Received: by 10.52.160.130 with SMTP id xk2mr6241537vdb.202.1298472494679; Wed, 23 Feb 2011 06:48:14 -0800 (PST) Received: from surutti.fandm.edu ([155.68.120.206]) by mx.google.com with ESMTPS id k39sm3573192vcr.2.2011.02.23.06.48.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Feb 2011 06:48:13 -0800 (PST) Message-ID: <4D651E2C.2070005@fandm.edu> Date: Wed, 23 Feb 2011 09:48:12 -0500 From: Janardhan Iyengar Organization: Franklin & Marshall College User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mirja Kuehlewind , ledbat@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ledbat] max cwnd X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: janardhan.iyengar@fandm.edu List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 14:47:33 -0000 Mirja, (I agree with you on normalizing off_target with TARGET. That part was fully broken in the original algorithm.) > there is another line in the pseudo code: > > max_allowed_cwnd = ALLOWED_INCREASE + TETHER*flight_size() > > The current spec says: > "ALLOWED_INCREASE SHOULD be 1 packet; it MUST be at least 1 packet and SHOULD > NOT be more than 3 packets. TETHER SHOULD be 1.5; it MUST be greater than > 1. " So, after thinking about ALLOWED_INCREASE, TETHER, and GAIN, I'm increasingly leaning towards eliminating all of these variables in favor of simplicity. > This is the cwnd limitation when there are no enough data to fill the cwnd. > As far as I can see the implementation in Linux would limit to > > max_allowed_cwnd = 3 + 1*flight_size(). [...] This use of cwnd comes from TCP's definition of cwnd which conflates the sender's cwnd size with the actual send_window itself. In other words, TCP conflates *what* is outstanding with *how much* is outstanding. The cwnd ought to reflect *how much* and not *what*. From RFC 5681, CONGESTION WINDOW (cwnd): A TCP state variable that limits the amount of data a TCP can send. At any given time, a TCP MUST NOT send data with a sequence number higher than the sum of the highest acknowledged sequence number and the minimum of cwnd and rwnd. TCP's cwnd is also its send_window. When there's no loss, this is fine, but when there's loss, the left edge of the send window is stuck to the last acknowledged byte. At the same time, duplicate acks received do not move the left edge of the send_window, but indicate to the sender that packets are leaving the wire. To compensate for this discrepancy, the window is allowed to artificially inflate until a new ack allows the left edge of the send_window (and cwnd) to move. I propose the following: First, a clean definition of cwnd is in order: cwnd: A sender-side variable that limits the amount of data, regardless of sequence number, that the sender is allowed to have outstanding in the network. Note that the cwnd variable used in this document reflects and controls the amount of data that a sender is allowed to have outstanding, and is different from TCP's definition of cwnd [RFC5681] in not controlling the actual data being transmitted. This cwnd MAY be in bytes or packets; for ease of exposition, this document uses cwnd in packets. Then the modified increase algorithm: On an ack: ... cwnd_rate = (TARGET - queuing_delay) / TARGET if flight_size() >= cwnd: cwnd += cwnd_rate / cwnd else: cwnd = flight_size() Thoughts? - jana -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Feb 23 07:14:58 2011 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 B36053A6A34 for ; Wed, 23 Feb 2011 07:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.047, 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 wpOkFpJ47Sq0 for ; Wed, 23 Feb 2011 07:14:58 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id DC9513A6A2A for ; Wed, 23 Feb 2011 07:14:57 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id C466C633B2; Wed, 23 Feb 2011 16:15:41 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id B516559A8A; Wed, 23 Feb 2011 16:15:41 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: janardhan.iyengar@fandm.edu Date: Wed, 23 Feb 2011 16:15:40 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <4D651E2C.2070005@fandm.edu> In-Reply-To: <4D651E2C.2070005@fandm.edu> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201102231615.40941.mkuehle@ikr.uni-stuttgart.de> Cc: ledbat@ietf.org Subject: Re: [ledbat] max cwnd 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, 23 Feb 2011 15:14:58 -0000 Hi Jana, > So, after thinking about ALLOWED_INCREASE, TETHER, and GAIN, I'm > increasingly leaning towards eliminating all of these variables in favor of > simplicity. I'm not sure if I want to change the algorithm proposed by Bittorrent completely. As we don't get a response when asking about the reason for these parameters, we might just keep them and specify the values as MUST. About GAIN: I'm still thinking about a comment that a higher GAIN value only for the decrease case might be helpful in some case. I'm just not sure how those cases exactly look like. ALLOWED_INCREASE and TETHER doesn't make the algorithm much more complicated but still not sure about the right thing here (see below) > Then the modified increase algorithm: > On an ack: > ... > cwnd_rate = (TARGET - queuing_delay) / TARGET > if flight_size() >= cwnd: > cwnd += cwnd_rate / cwnd > else: > cwnd = flight_size() > > Thoughts? Still not sure, this might decrease the window unnecessarily if there are not enough data for only a short time and than a whole bunch of data are available at once. I'm really not sure if there is THE right solution. That is why I was asking for references or best practice on the list. Maybe we can be a little more restrictive than usual because we assume time-insensitive bulk traffic. On the other hand we have a mechanism to detect congestion before packet loss occurs and can decrease the cwnd earlier anyway. Mirja From jana.iyengar@gmail.com Wed Feb 23 07:22:36 2011 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 A7A353A6A28 for ; Wed, 23 Feb 2011 07:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.851 X-Spam-Level: * X-Spam-Status: No, score=1.851 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYTy1iLIz+Lm for ; Wed, 23 Feb 2011 07:22:35 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 1B5FB3A68E0 for ; Wed, 23 Feb 2011 07:22:35 -0800 (PST) Received: by vws6 with SMTP id 6so2226048vws.31 for ; Wed, 23 Feb 2011 07:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:reply-to:organization :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=/IcJqVoU8lBW239blwgQhZKIxJ/TS9ey8TojdGW0WZw=; b=GnuQiSGs7rePGP34WDKOcBbZhB06j7/C6p5nyfEm2jmUB4hKEoDszTwNKg/OWmMLG1 1jg721OOwb8ovNegIQvbaoYqvTt6XMfXpUdLrVSzMhPxLgoCyrptG2zzxXhKAZJkyQGO mdBJnXIqA35HI7oxCJXGKomLMofNfZlsXvKH0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:subject:content-type:content-transfer-encoding; b=NayyLSPvdIEc69Mo+1hz8a3wOQkM59D8ku3rKnKC/LxoJo0fMzeWOmrFyCOa+xBOd2 BUXeST8zVyaOI6/ZVhyEOKyfWymvSiCJYA+NbPmbB38HaP4bMmbX8BT3IkQiCnOeYK3I kShzSI49qk/uTrimPsFwl7g+GVbqGCqldG93s= Received: by 10.52.160.170 with SMTP id xl10mr6276946vdb.197.1298474601164; Wed, 23 Feb 2011 07:23:21 -0800 (PST) Received: from surutti.fandm.edu ([155.68.120.206]) by mx.google.com with ESMTPS id u4sm1166964vch.36.2011.02.23.07.23.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Feb 2011 07:23:20 -0800 (PST) Message-ID: <4D652667.1020105@fandm.edu> Date: Wed, 23 Feb 2011 10:23:19 -0500 From: Janardhan Iyengar Organization: Franklin & Marshall College User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mirja Kuehlewind , ledbat@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ledbat] max cwnd X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: janardhan.iyengar@fandm.edu List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 15:22:36 -0000 All, I hasten to add that there's only one piece that I've modified in the increase algorithm (pointed out below). The rest of it simply eliminates variables that MUST be 1. I am not opposed to leaving those variables (in particular, GAIN) in, but I wanted to provide a simpler and cleaner counterpoint. ------------- 1. Original increase algo (with Mirja's normalization of off_target): On an ack: ... off_target = TARGET - queuing_delay cwnd += GAIN * off_target / TARGET / cwnd # flight_size() is the amount of currently not acked data. max_allowed_cwnd = ALLOWED_INCREASE + TETHER*flight_size() cwnd = min(cwnd, max_allowed_cwnd) with - GAIN MUST be 1, - ALLOWED_INCREASE MUST be at least 1 packet and SHOULD NOT be more than 3 packets, - TETHER SHOULD be 1.5. The difficulty here is in tracking precisely how to utilize ALLOWED_INCREASE and TETHER to curb cwnd growth during data lulls, while ensuring that the growth must not be greater than standard TCP's. Note that as specified, this algorithm allows for faster increase than slow start during data lulls---ALLOWED_INCREASE and TETHER ought to be 1 for slow start like behavior. ------------- 2. My proposed simplification (changed off_target to cwnd_rate, eliminated GAIN, and replaced the cwnd curbing with an explicit if-else): On an ack: ... cwnd_rate = (TARGET - queuing_delay) / TARGET if flight_size()>= cwnd: cwnd += cwnd_rate / cwnd else: cwnd = flight_size() ------------- 3. If we want to retain GAIN and the other variables (someone needs to post justification here; I don't see much at this point): On an ack: ... cwnd_rate = GAIN * (TARGET - queuing_delay) / TARGET if flight_size()>= cwnd: cwnd += cwnd_rate / cwnd else: cwnd = ALLOWED_INCREASE + TETHER*flight_size() This form of the algo is (almost) the same as the form (1), with the minor difference that when there isn't a data lull, cwnd grows as we would expect (the body of the if clause). Constants are: - GAIN MUST be 1, - ALLOWED_INCREASE MUST be at least 1 packet and SHOULD NOT be more than 3 packets - TETHER SHOULD be 1. ------------ Thoughts? - jana On 2/23/11 9:48 AM, Janardhan Iyengar wrote: > Mirja, > > (I agree with you on normalizing off_target with TARGET. That part was fully broken in the original algorithm.) > >> there is another line in the pseudo code: >> >> max_allowed_cwnd = ALLOWED_INCREASE + TETHER*flight_size() >> >> The current spec says: >> "ALLOWED_INCREASE SHOULD be 1 packet; it MUST be at least 1 packet and SHOULD >> NOT be more than 3 packets. TETHER SHOULD be 1.5; it MUST be greater than >> 1. " > > So, after thinking about ALLOWED_INCREASE, TETHER, and GAIN, I'm increasingly leaning towards eliminating all of these variables in favor of simplicity. > >> This is the cwnd limitation when there are no enough data to fill the cwnd. >> As far as I can see the implementation in Linux would limit to >> >> max_allowed_cwnd = 3 + 1*flight_size(). > [...] > > This use of cwnd comes from TCP's definition of cwnd which conflates the sender's cwnd size with the actual send_window itself. In other words, TCP conflates *what* is outstanding with *how much* is outstanding. The cwnd ought to reflect *how much* and not *what*. > From RFC 5681, > CONGESTION WINDOW (cwnd): A TCP state variable that limits the amount > of data a TCP can send. At any given time, a TCP MUST NOT send > data with a sequence number higher than the sum of the highest > acknowledged sequence number and the minimum of cwnd and rwnd. > > TCP's cwnd is also its send_window. When there's no loss, this is fine, but when there's loss, the left edge of the send window is stuck to the last acknowledged byte. At the same time, duplicate acks received do not move the left edge of the send_window, but indicate to the sender that packets are leaving the wire. To compensate for this discrepancy, the window is allowed to artificially inflate until a new ack allows the left edge of the send_window (and cwnd) to move. > > I propose the following: > > First, a clean definition of cwnd is in order: > cwnd: A sender-side variable that limits the amount of data, regardless of sequence number, that the sender is allowed to have outstanding in the network. Note that the cwnd variable used in this document reflects and controls the amount of data that a sender is allowed to have outstanding, and is different from TCP's definition of cwnd [RFC5681] in not controlling the actual data being transmitted. This cwnd MAY be in bytes or packets; for ease of exposition, this document uses cwnd in packets. > > Then the modified increase algorithm: > On an ack: > ... > cwnd_rate = (TARGET - queuing_delay) / TARGET > if flight_size()>= cwnd: > cwnd += cwnd_rate / cwnd > else: > cwnd = flight_size() > > Thoughts? > - jana > From Rolf.Winter@neclab.eu Wed Feb 23 07:49:59 2011 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 19FA63A6845 for ; Wed, 23 Feb 2011 07:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.394 X-Spam-Level: X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, 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 x4yw7WjRavy8 for ; Wed, 23 Feb 2011 07:49:57 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A322F3A6835 for ; Wed, 23 Feb 2011 07:49:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 71DDA2C000203; Wed, 23 Feb 2011 16:51:30 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R87BW97t7RWe; Wed, 23 Feb 2011 16:51:30 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 4C6C12C0001DE; Wed, 23 Feb 2011 16:51:15 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Wed, 23 Feb 2011 16:50:28 +0100 From: Rolf Winter To: "Woundy, Richard" , Mirja Kuehlewind Thread-Topic: [ledbat] random input Thread-Index: AQHLzfTVRUh/ZVTYF0GQuzza1z8aVJQFtvyAgABIRwCAASAuAIAAQAcAgAADRoCAACoAAIAHucPQ Date: Wed, 23 Feb 2011 15:50:31 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DCB17C@DAPHNIS.office.hd> References: <201102161715.54959.mkuehle@ikr.uni-stuttgart.de> <201102181319.16627.mirja.kuehlewind@ikr.uni-stuttgart.de> <1CA25301D2219F40B3AA37201F0EACD1134122C8@PACDCEXMB05.cable.comcast.com> <201102181720.09659.mirja.kuehlewind@ikr.uni-stuttgart.de> <1CA25301D2219F40B3AA37201F0EACD1134125FD@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1134125FD@PACDCEXMB05.cable.comcast.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" Subject: Re: [ledbat] random input 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, 23 Feb 2011 15:49:59 -0000 Hi, this sounds we have a workable way forward? Are there other comments on the= issue of randomness? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Freitag, 18. Februar 2011 19:50 > To: Mirja Kuehlewind > Cc: Rolf Winter; ledbat@ietf.org > Subject: RE: [ledbat] random input >=20 > > I'm afraid that was not completely one of your three given options, > but does > this work for you? >=20 > Could you also add a comment somewhere within the algorithm in 3.4.2 > that says something to this effect? >=20 > # See section 5.3 for a discussion of how randomness is assumed in the > calculation above. >=20 > > If someone has some more experience on how much randomness can be > found in real systems, I would be happy about additional information or > even a piece of text as contribution for the draft! >=20 > Unfortunately I don't have personal knowledge. But the conversation > below (from the IETF76 minutes) among Murari Sridharan (Microsoft), > Stuart Cheshire (Apple) and Stanislav Shalunov (BitTorrent) seems > instructive -- that is, many environments have some amount of > 'randomness' due to operating system details (e.g. process/thread > scheduling and/or less precise timers) and/or the use of hard disk > drives (e.g. rotational delays at 'random' times). >=20 > Stuart points out that recent MacOS versions may not have these same > random side-effects, and that has caused throughput issues in the past. > Also, hard disk drives are being slowly replaced by solid state drives > without rotational delays (or moving parts in general). >=20 > > > [Stuart]: As world moves to flash disk, high-performance CPUs, > timers are > > > more and more precise. Cannot depend on the end system introducing > random > > > noise. > ... > > > Stuart: every network does NOT have randomness. Slav: every network > I > > > have TRIED has randomness, but not necessarily true for all > networks. > > > Stuart: MacOS 8.6 (?) had this problem; throughput cut in half. No > > > randomness, so everyone had the same collisions repeating. >=20 > I wonder if we'll get any more detailed guidance than that? >=20 > -- Rich >=20 > -----Original Message----- > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > Sent: Friday, February 18, 2011 11:20 AM > To: Woundy, Richard > Cc: Rolf Winter; ledbat@ietf.org > Subject: Re: [ledbat] random input >=20 > I want to delete random_input() from the pseudo code and add/extend an > section > (probably in 5.3 Fairness between LEDBAT flows) to say 'some amount of > randomness is believed to help' and 'there may be sufficient randomness > in > some environments'. >=20 > I'm afraid that was not completely one of your three given options, but > does > this work for you? >=20 > If someone has some more experience on how much randomness can be found > in > real systems, I would be happy about additional information or even a > piece > of text as contribution for the draft! >=20 >=20 > On Friday 18 February 2011 17:08:26 Woundy, Richard wrote: > > Mirja, > > > > The current text has: > > > > off_target =3D TARGET - queuing_delay + random_input() > > cwnd +=3D GAIN * off_target / cwnd > > > > and > > > > random_input() > > # random() is a PRNG between 0.0 and 1.0 > > # NB: RANDOMNESS_AMOUNT is normally 0 > > RANDOMNESS_AMOUNT * TARGET * ((random() - 0.5)*2) > > > > Are you suggesting to delete "random_input()" entirely? > > > > Or do you want to change the definition of random_input() to a set of > > comments that says 'some amount of randomness is believed to help' > and > > 'there may be sufficient randomness in some environments'? > > > > Or do you want to change the effect of GAIN on cwnd? > > > > -- Rich > > > > -----Original Message----- > > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > > Sent: Friday, February 18, 2011 7:19 AM > > To: Woundy, Richard > > Cc: Rolf Winter; ledbat@ietf.org > > Subject: Re: [ledbat] random input > > > > Those minutes show exactly the point. As Stas said "random > fluctuations in > > inter-packet transmission time" is needed. But the random factor in > the > > draft doesn't bring any randomness for the inter-packet transmission > times! > > > > On Thursday 17 February 2011 20:07:50 Woundy, Richard wrote: > > > > Again, BitTorrent input would be helpful on this point. > > > > > > Agreed. But I should point out that this topic has been raised > frequently > > > in past face to face meetings. > > > > > > Even if we remove the explicit random factor, can we at least > summarize > > > that at least some random fluctuation in base delay measurement is > > > assumed? > > > > > > Below are relevant minutes from the last three LEDBAT meetings. > > > > > > From http://www.ietf.org/proceedings/76/minutes/ledbat.txt: > > > > > > Late comer's (non)-advantage > > > ----- > > > > > > Lars: implementation depends on side effects on user's operating > system, > > > and looks like only might work by serendipity. It seems to be just > a hack > > > that might not work all the time. > > > > > > Slav: if your machine is so good, then you can introduce noise / > random > > > fluctuations in inter-packet transmission time. > > > > > > Stewart: As world moves to flash disk, high-performance CPUs, > timers are > > > more and more precise. Cannot depend on the end system introducing > random > > > noise. > > > > > > Murari: problem is non-existent on many systems. > > > > > > Rich: Assumption about a backoff time is random. Need to clearly > state > > > expectation that things back off with a random component. The > random > > > component is an implementation detail. (ACTION) > > > > > > Lars: Better to have something explicit in the document. > > > > > > Slav: Need to flush queue to figure out RTT on second stream to > really > > > know. > > > > > > Lars: That is too heavy weight (Slav clearly agrees) > > > > > > Bob Briscoe: Late-comer's advantage: please add it to the draft as > > > described on the list. Disadvantage: late-comer does not know base > > > delay. Advantage: if it does know base delay, other flows will not > > > necessarily get out of the way of the new flow. Draft says > randomness > > > fixes this, but that means randomness needs to be ensured (ACTION) > > > > > > Fairness > > > ----- > > > > > > Bob: Need to write down assumptions. Random walks with a lot of > flows > > > competing with each other; do not see how ones will a small amount > of > > > bandwidth will ever get large or vice versa. Need to state why > randomness > > > helps and importance of true randomness in the algorithm. (ACTION) > > > > > > Andrew: randomness protocol adds needs an estimator to know what > > > randomness is available so it knows how much randomness to add. > > > > > > Bob: May be we see randomness in networks because today's protocols > have > > > randomness built in. If on a ledbat-only network, no randomness. > E.g., > > > data center > > > > > > Slav: experience is randomness still there. > > > > > > Stuart: every network does NOT have randomness. Slav: every network > I > > > have TRIED has randomness, but not necessarily true for all > networks. > > > Stuart: MacOS 8.6 (?) had this problem; throughput cut in half. No > > > randomness, so everyone had the same collisions repeating. > > > > > > Bob: just need to note this in spec. > > > > > > From http://www.ietf.org/proceedings/77/minutes/ledbat.txt: > > > > > > Fairness > > > Lars: Measurements in Trilogy project is not enough, minutes may be > > > needed to determine baseline delay measurement. Explicit > randomization > > > should help. > > > > > > Rolf Winter NEC: An issue is one minute slots for base delay, with > > > history of ten minutes. A long delay in a one minute slot will not > be > > > aged out until ten minutes. > > > > > > Stanislav: Clarification, inserts small random (zero mean) values > to > > > delay which changes amount of capacity that is distributed to other > > > flows. Paramter should be related to the target. > > > > > > From http://www.ietf.org/proceedings/79/minutes/ledbat.txt: > > > > > > SC - we don't need to agonise too much about fairness - apps that > are > > > using this have already made a decision to play nice > > > > > > RoW - not sure I agree - competing apps in the same space may have > > > motivations to try to deliver better performance by increasing the > base > > > delay very slightly. this should be discussed in the draft. > > > > > > Random reshuffling for fairness slide > > > > > > RoW - have results that demonstrate latecomer advantage > > > > > > SC - Stas Shalunov (SS) asserted that OS scheduler would give > enough > > > randomness, I asked how much randomness was needed, didn't get a > > > response. Don't hold up the document for this, if we don't have a > firm > > > answer then leave text vague 'some amount of randomness is believed > to > > > help' > > > > > > LE - people implementing this should experiment with this. does > adding > > > more entropy improve behaviour they observe? this might be an > improvement > > > but we really don't know and we need someone to tell us. > > > > > > MS - don't know if BitTorrent do this in their implementation today > > > > > > SC - quite certain they don't as SS asserted that entropy of OS > > > scheduling would deal with this. But it won't if we're talking > about > > > MacOSX. > > > > > > MS - if you have few connections then the synch problem seems real, > but > > > we don't have data. > > > > > > -- Rich > > > > > > -----Original Message----- > > > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > Behalf > > > Of Rolf Winter Sent: Thursday, February 17, 2011 8:55 AM > > > To: Mirja K=FChlewind; ledbat@ietf.org > > > Subject: Re: [ledbat] random input > > > > > > Hi, > > > > > > > > > > > > I think that it might be OK to remove random factor, especially as > the > > > delay measurement should add sufficient randomness. The draft > currently > > > recommend a random value of 0 anyway. Regarding the point about not > being > > > able to measure the real base delay, I guess the hope is that other > > > (TCP/UDP) traffic will force all LEDBAT flows once in a while to > back off > > > completely, allowing all flows at some point to measure the true > base > > > delay. > > > > > > Again, BitTorrent input would be helpful on this point. > > > > > > 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 Mirja K=FChlewind > > > > Sent: Mittwoch, 16. Februar 2011 17:16 > > > > To: ledbat@ietf.org > > > > Subject: [ledbat] random input > > > > > > > > Hi, > > > > > > > > I would like to remove the part about the random input from the > draft. > > > > It > > > > might be helpful for LEDBAT if there actually is some variation > in > > > > delay on > > > > link as this could cause the bottleneck queue to empty from time > to > > > > time. If > > > > this would happen, all LEDBAT connections will be able to measure > the > > > > real > > > > base delay. But adding some random delay factor when calculation > the > > > > cwnd at > > > > the sender doesn't help to empty the queue at all. Is it okay to > remove > > > > the > > > > random input part or does anybody have different results? > > > > > > > > Actually, regarding the intra-protocol fairness issue. I wouldn't > care > > > > too > > > > much about multiple LEDBAT's which will not share the capacity > equally, > > > > as > > > > this was not one of the design goals (as already stated in the > previous > > > > mail). But the other problem is that a LEDBAT that will never > measure > > > > the > > > > true base delay, will add its own TARGET on top of the wrong base > > > > delay. In > > > > the worst case when the old LEDBAT connection is decreasing as > fast as > > > > the > > > > new one is increasing, the new LEDBAT will actually add double > the > > > > TARGET. > > > > Maybe this is a case for having a higher GAIN value for the > > > > decrease...? But > > > > what's the right value here? > > > > > > > > Mirja > > > > _______________________________________________ > > > > 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 >=20 >=20 > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- From Rolf.Winter@neclab.eu Thu Feb 24 07:46:36 2011 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 E0EDC3A63CA for ; Thu, 24 Feb 2011 07:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.453 X-Spam-Level: X-Spam-Status: No, score=-99.453 tagged_above=-999 required=5 tests=[AWL=-2.804, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, 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 TqtxxILPsRXH for ; Thu, 24 Feb 2011 07:46:36 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 9DD113A63C9 for ; Thu, 24 Feb 2011 07:46:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8D07E2800018B; Thu, 24 Feb 2011 16:48:41 +0100 (CET) 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 y6ooRh1rH4FP; Thu, 24 Feb 2011 16:48:41 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6E8A22800017B; Thu, 24 Feb 2011 16:48:26 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Thu, 24 Feb 2011 16:47:10 +0100 From: Rolf Winter To: "janardhan.iyengar@fandm.edu" , Mirja Kuehlewind , "ledbat@ietf.org" Thread-Topic: [ledbat] max cwnd Thread-Index: AQHL022ZGaZVa2RqckqnUCBdi0NTy5QQzERg Date: Thu, 24 Feb 2011 15:47:09 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DD65E3@DAPHNIS.office.hd> References: <4D652667.1020105@fandm.edu> In-Reply-To: <4D652667.1020105@fandm.edu> 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: Re: [ledbat] max cwnd 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, 24 Feb 2011 15:46:37 -0000 Hi, speaking not as chair. The current spec actually says that GAIN SHOULD be 1, which is wrong it sho= uld say MUST NOT be larger 1 in order to not ramp up faster than TCP. Havin= g a GAIN smaller than one, I am not sure how useful that would be given the= fact that we restrict LEDBAT to congestion avoidance and not slow start be= haviour. Speaking as chair: can we have more comments on this and come to a timely c= onclusion? 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 Janardhan Iyengar > Sent: Mittwoch, 23. Februar 2011 16:23 > To: Mirja Kuehlewind; ledbat@ietf.org > Subject: Re: [ledbat] max cwnd >=20 > All, >=20 > I hasten to add that there's only one piece that I've modified in the > increase algorithm (pointed out below). The rest of it simply > eliminates variables that MUST be 1. I am not opposed to leaving those > variables (in particular, GAIN) in, but I wanted to provide a simpler > and cleaner counterpoint. >=20 > ------------- > 1. Original increase algo (with Mirja's normalization of off_target): > On an ack: > ... > off_target =3D TARGET - queuing_delay > cwnd +=3D GAIN * off_target / TARGET / cwnd > # flight_size() is the amount of currently not acked data. > max_allowed_cwnd =3D ALLOWED_INCREASE + TETHER*flight_size() > cwnd =3D min(cwnd, max_allowed_cwnd) >=20 > with > - GAIN MUST be 1, > - ALLOWED_INCREASE MUST be at least 1 packet and SHOULD NOT be more > than 3 packets, > - TETHER SHOULD be 1.5. >=20 > The difficulty here is in tracking precisely how to utilize > ALLOWED_INCREASE and TETHER to curb cwnd growth during data lulls, > while ensuring that the growth must not be greater than standard TCP's. > Note that as specified, this algorithm allows for faster increase than > slow start during data lulls---ALLOWED_INCREASE and TETHER ought to be > 1 for slow start like behavior. >=20 > ------------- > 2. My proposed simplification (changed off_target to cwnd_rate, > eliminated GAIN, and replaced the cwnd curbing with an explicit if- > else): > On an ack: > ... > cwnd_rate =3D (TARGET - queuing_delay) / TARGET > if flight_size()>=3D cwnd: > cwnd +=3D cwnd_rate / cwnd > else: > cwnd =3D flight_size() >=20 > ------------- > 3. If we want to retain GAIN and the other variables (someone needs to > post justification here; I don't see much at this point): > On an ack: > ... > cwnd_rate =3D GAIN * (TARGET - queuing_delay) / TARGET > if flight_size()>=3D cwnd: > cwnd +=3D cwnd_rate / cwnd > else: > cwnd =3D ALLOWED_INCREASE + TETHER*flight_size() >=20 > This form of the algo is (almost) the same as the form (1), with the > minor difference that when there isn't a data lull, cwnd grows as we > would expect (the body of the if clause). Constants are: > - GAIN MUST be 1, > - ALLOWED_INCREASE MUST be at least 1 packet and SHOULD NOT be more > than 3 packets > - TETHER SHOULD be 1. >=20 > ------------ >=20 >=20 > Thoughts? > - jana >=20 >=20 > On 2/23/11 9:48 AM, Janardhan Iyengar wrote: > > Mirja, > > > > (I agree with you on normalizing off_target with TARGET. That part > was fully broken in the original algorithm.) > > > >> there is another line in the pseudo code: > >> > >> max_allowed_cwnd =3D ALLOWED_INCREASE + TETHER*flight_size() > >> > >> The current spec says: > >> "ALLOWED_INCREASE SHOULD be 1 packet; it MUST be at least 1 packet > and SHOULD > >> NOT be more than 3 packets. TETHER SHOULD be 1.5; it MUST be > greater than > >> 1. " > > > > So, after thinking about ALLOWED_INCREASE, TETHER, and GAIN, I'm > increasingly leaning towards eliminating all of these variables in > favor of simplicity. > > > >> This is the cwnd limitation when there are no enough data to fill > the cwnd. > >> As far as I can see the implementation in Linux would limit to > >> > >> max_allowed_cwnd =3D 3 + 1*flight_size(). > > [...] > > > > This use of cwnd comes from TCP's definition of cwnd which conflates > the sender's cwnd size with the actual send_window itself. In other > words, TCP conflates *what* is outstanding with *how much* is > outstanding. The cwnd ought to reflect *how much* and not *what*. > > From RFC 5681, > > CONGESTION WINDOW (cwnd): A TCP state variable that limits the > amount > > of data a TCP can send. At any given time, a TCP MUST NOT > send > > data with a sequence number higher than the sum of the highest > > acknowledged sequence number and the minimum of cwnd and rwnd. > > > > TCP's cwnd is also its send_window. When there's no loss, this is > fine, but when there's loss, the left edge of the send window is stuck > to the last acknowledged byte. At the same time, duplicate acks > received do not move the left edge of the send_window, but indicate to > the sender that packets are leaving the wire. To compensate for this > discrepancy, the window is allowed to artificially inflate until a new > ack allows the left edge of the send_window (and cwnd) to move. > > > > I propose the following: > > > > First, a clean definition of cwnd is in order: > > cwnd: A sender-side variable that limits the amount of data, > regardless of sequence number, that the sender is allowed to have > outstanding in the network. Note that the cwnd variable used in this > document reflects and controls the amount of data that a sender is > allowed to have outstanding, and is different from TCP's definition of > cwnd [RFC5681] in not controlling the actual data being transmitted. > This cwnd MAY be in bytes or packets; for ease of exposition, this > document uses cwnd in packets. > > > > Then the modified increase algorithm: > > On an ack: > > ... > > cwnd_rate =3D (TARGET - queuing_delay) / TARGET > > if flight_size()>=3D cwnd: > > cwnd +=3D cwnd_rate / cwnd > > else: > > cwnd =3D flight_size() > > > > Thoughts? > > - jana > > >=20 > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat