From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::22f]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A70C221F1EC for ; Mon, 18 May 2015 01:14:18 -0700 (PDT) Received: by vnbg7 with SMTP id g7so6887715vnb.12 for ; Mon, 18 May 2015 01:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gg0tR0a6r2DuvJBUqpjFVfdvoWriwCQGeS3IHYdgrbw=; b=nWm14OhDp8Yl7WswTSeqBa8Q9RIQBklR3zDO5s5J12q71jGtsU6YvZGUbxGa/4Lu1s Gh2AVsQTdSOUbgzuHYoXnzFl9rxThLSsay2Wn+XwuzVQlg1hBGq+yUBrHxkrRVg2Uv2O P0Nehv3uhdu3XGo5C6NHy6pyC9RxlAtlN7W83T9N4CVMCk9qqsh/QDHu0f/tOhnRACVF Say+AJUUETGWaVcMaBIkb2X6BhEhr9MV+eWbg8peCCvDhrzEPMHRkWINrKRKXXkpbeio 6bRInQfcTTBeWgII7cWBCClDbxyf17kewRGaRTfp0rHmyCAjJt6CIJ9TNg4c5yrUTJzw yiVA== MIME-Version: 1.0 X-Received: by 10.52.251.107 with SMTP id zj11mr19656649vdc.96.1431936796832; Mon, 18 May 2015 01:13:16 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Mon, 18 May 2015 01:13:16 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Mon, 18 May 2015 01:13:16 -0700 (PDT) In-Reply-To: <7B7986E7-49A1-4EE1-B8D0-B55A6C2660A1@gmx.de> References: <554F64E1.6000609@gmail.com> <554F9594.60808@gmail.com> <7B7986E7-49A1-4EE1-B8D0-B55A6C2660A1@gmx.de> Date: Mon, 18 May 2015 11:13:16 +0300 Message-ID: From: Jonathan Morton To: Sebastian Moeller Content-Type: multipart/alternative; boundary=001a1134d45e1db97f051656c463 Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] More overhead keywords X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 08:15:11 -0000 --001a1134d45e1db97f051656c463 Content-Type: text/plain; charset=UTF-8 Hmm. Looks like that document I found was really out of date, then. But it got me fairly close. For me, the overhead starts at the IP packet (so for your example, at the 1492 byte level), and excludes optional parts of the spec like FCS (since I have a separate flag for that). So I need to take the 8 bytes for PPPoE, the 14 for Ethernet and the 4 for PTM, total 26 - one less than my existing figure. Presumably the bridged version is also one byte smaller than my calculation, 18 rather than 19. Is there also a version which transmits IP without Ethernet framing? You would then specify "pppoe-ptm ether-vlan via-ethernet" to set your example connection up the friendly way, or just "overhead 16" for the terse way (and you can already do that in the current version). The 64/65 sync overhead is something we'll have to discover by experiment. Luckily, it's pretty easy to tell whether we're filling up a dumb FIFO or not. I've gone for the technical labels for three reasons. First, it reflects what's actually happening, which generally reduces confusion in the long run. Second, you might underestimate the number of ADSL ISPs worldwide, as well as the difficulty of keeping such a database up to date. Third, every DSL modem and ISP I know of has made it reasonably easy to discover at least the base encapsulations - autodetection of vcmux vs llc isn't absolutely reliable, for example. They might be less forthcoming about vlan and FCS, but one can make intelligent guesses here, based on whether it's a converged services ISP. Ideally, we could do with a tool (at dslreports?) which makes detecting the actual overhead easier. This would be doable using small packets to magnify the differences. And if the user really can't work it out, they can always throw up their hands and specify "conservative". - Jonathan Morton --001a1134d45e1db97f051656c463 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hmm. Looks like that document I found was really out of date= , then. But it got me fairly close.

For me, the overhead starts at the IP packet (so for your ex= ample, at the 1492 byte level), and excludes optional parts of the spec lik= e FCS (since I have a separate flag for that). So I need to take the 8 byte= s for PPPoE, the 14 for Ethernet and the 4 for PTM, total 26 - one less tha= n my existing figure.

Presumably the bridged version is also one byte smaller than= my calculation, 18 rather than 19. Is there also a version which transmits= IP without Ethernet framing?

You would then specify "pppoe-ptm ether-vlan via-ethern= et" to set your example connection up the friendly way, or just "= overhead 16" for the terse way (and you can already do that in the cur= rent version).

The 64/65 sync overhead is something we'll have to disco= ver by experiment. Luckily, it's pretty easy to tell whether we're = filling up a dumb FIFO or not.

I've gone for the technical labels for three reasons. Fi= rst, it reflects what's actually happening, which generally reduces con= fusion in the long run. Second, you might underestimate the number of ADSL = ISPs worldwide, as well as the difficulty of keeping such a database up to = date. Third, every DSL modem and ISP I know of has made it reasonably easy = to discover at least the base encapsulations - autodetection of vcmux vs ll= c isn't absolutely reliable, for example. They might be less forthcomin= g about vlan and FCS, but one can make intelligent guesses here, based on w= hether it's a converged services ISP.

Ideally, we could do with a tool (at dslreports?) which make= s detecting the actual overhead easier. This would be doable using small pa= ckets to magnify the differences.

And if the user really can't work it out, they can alway= s throw up their hands and specify "conservative".

- Jonathan Morton

--001a1134d45e1db97f051656c463--