Re: [ledbat] LEDBAT doesn't help sharing network beyond home gateway

Rolf Winter <Rolf.Winter@neclab.eu> Thu, 28 July 2011 23:30 UTC

Return-Path: <Rolf.Winter@neclab.eu>
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F18C11E80C8; Thu, 28 Jul 2011 16:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.389
X-Spam-Level:
X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id av11jIyuQEmc; Thu, 28 Jul 2011 16:30:13 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C746211E80A2; Thu, 28 Jul 2011 16:30:12 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8C5C828000329; Fri, 29 Jul 2011 01:30:11 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqFgvU4MLIuo; Fri, 29 Jul 2011 01:30:11 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 66BF628000198; Fri, 29 Jul 2011 01:29:51 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.20]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 01:29:30 +0200
From: Rolf Winter <Rolf.Winter@neclab.eu>
To: Bob Briscoe <bob.briscoe@bt.com>, Janardhan Iyengar <jana.iyengar@gmail.com>
Thread-Topic: [ledbat] LEDBAT doesn't help sharing network beyond home gateway
Thread-Index: AQHMTXzjahdOl9p7WUmuqzdg87JclZUCYPrg
Date: Thu, 28 Jul 2011 23:29:29 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D1D034AF5@DAPHNIS.office.hd>
References: <201107282319.p6SNJd8F022546@bagheera.jungle.bt.co.uk>
In-Reply-To: <201107282319.p6SNJd8F022546@bagheera.jungle.bt.co.uk>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.7.0.197]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ledbat@ietf.org" <ledbat@ietf.org>, tsv-area IETF list <tsv-area@ietf.org>
Subject: Re: [ledbat] LEDBAT doesn't help sharing network beyond home gateway
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG <ledbat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ledbat>, <mailto:ledbat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ledbat>
List-Post: <mailto:ledbat@ietf.org>
List-Help: <mailto:ledbat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ledbat>, <mailto:ledbat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2011 23:30:14 -0000

One clarification. The target is 100ms, can be less, but not more. The "can be less" part is to cater for the future. The cannot be more is to make sure you cannot be unfair unless you chose to be non-standards compliant.

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 Bob Briscoe
> Sent: Donnerstag, 28. Juli 2011 17:24
> To: Janardhan Iyengar
> Cc: ledbat@ietf.org; tsv-area IETF list
> Subject: [ledbat] LEDBAT doesn't help sharing network beyond home
> gateway
> 
> Jana,
> 
> You asked the basis of what I just said in TSVAREA. I said in a
> residential network, LEDBAT won't yield to traffic sharing any queue
> upstream of your own home gateway queue.
> 
> LEDBAT's target delay is 150ms.
> 
> A typical shared link in such a network will be 1Gb/s.
> 
> 150ms of queuing into a 1Gb/s link is 12,500 packets of queue (if
> 1500B per pkt).
> 
> The buffer will not be this big (unless there's more bloat than
> anyone would expect)! Therefore LEDBAT will drive the queue off the
> end of its tail, just like TCP does. Therefore LEDAT is not designed
> to yield to others in such a queue into a higher speed link.
> 
> The root cause is the fixed 150ms target delay.
> 
> Nonetheless, I believe this design choice makes sense for LEDBAT
> _today_: you only yield to others in your own home. You don't yield
> to others in other homes.
> 
> If LEDBAT yielded to others, users would reject it. Evidence is on
> the Bittorrent community postings when uTP was 'imposed' on
> BitTorrent users - it was only accepted because it was shown that
> performance didn't suffer unless it was yielding to self.
> 
> We could design a LEDBAT-like protocol that yields to others in any
> queue. But no-one would want it (yet). Incidentally, a goal of ConEx
> is to incentivise deployment of LEDBAT-like protocols. The suffix
> '-like' means that they would benefit from yielding to anyone, not
> just your family in your home.
> 
> 
> Bob
> 
> 
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design
> 
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat