From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D745821F9C6 for ; Wed, 30 Sep 2015 05:11:36 -0700 (PDT) Received: from u-089-d066.biologie.uni-tuebingen.de ([134.2.89.66]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LeuUB-1aRcvV3uGN-00qipV; Wed, 30 Sep 2015 14:11:30 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <560BBF0D.2080802@darbyshire-bryant.me.uk> Date: Wed, 30 Sep 2015 14:11:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <80D43A22-F0B2-4C00-989A-AA3433BB39E2@gmx.de> References: <560BBF0D.2080802@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:B7SCt70GzU51WbscWhIOTOpMfNURtDagNZT9VywdCLJqYAvCelO hJT9+XeJmZQTLCzY+L3sz6Uo1C72yFxLhJgdEgUzJ68l62So1s87gmV2MxDoe9IPlkz6rd0 BxxqVJ8xIpBM2hA7BiuyfhbAXSWvsaB0AZRJyqbyQyncqapQQmBHdah89cgV3ADu7pxvigM DH5Wl5ACEVa//CLr5C+pw== X-UI-Out-Filterresults: notjunk:1;V01:K0:SeHF7YBZm/Y=:krjuMGa2ptFmr8pckzbqCR oavlDrK0/Ce10fqzWaEdK4IGD0goY3NlRW9a3Wtiv52eZw06qLC6C06ZLga4WYrRQV2+pvoT5 UEMgYEteJorZTtpfVcjBKhlypfn58MSOLLGah4FquktC5oJ7mY0I8V/yPl/ypzQBiusGD1RTD JKRLTk7rTH9SpPehT1cbJ7n5ZiyXn0Tis3iIql+HiAid2ukBdsz+S7LE9FQ3fKRvkrHlOevTG QbSeNdj3ynEdoY2Zv5OH7XqKj+7juAZwIGgvTPPxj/AbKqDu3oJ0zPEU+I5uYIL4qFaPzXu/l KRft5EW4PwPn+fnf0IXwg9O6nRG29WMdJV3MWb24YwuYlXjRvjrwh2uOSEUeY9LObOADMaxYK xLnrAF6C4oEKiXwhCi19vDKZXNxxwcS10wxrlzUgF+JCLXMS/cG+cB9TWm+NsNOq6j9maeeLT gk7tgcQvClGP/KF3Yik82vsWeUN5l/IibNb/uEL+eKwTPAOunKHdeO2FpfFu0lJQOsdvP88Br cRaIWRKiLFaUBv+E2gcDfUGmzBKAePa7V2r/vwpJ+0B5xk5BTNCzUNAHlldM3xeO6A5UAPYg4 GLPftbQqvU5znoBf6wGVAf5C+zrUXalj/aSklN+WRj+crFpojlQrsm0K/JHNCEJeqAaUdOTyJ 3l8JvX26rVdKXsEq+YIWRYaJPuCrYW2BwfPSwABS0VdR3GhIL2lFA61w0+OimC3oni3ksd1+t T3mFhtYXbSD2DCgI0dPgeq12yhRavIZ+HrTyG25c08HnnM/c02WAO/x6YwC/7uWT3je18326I O5wDM66 Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Ethernet frame overheads 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: Wed, 30 Sep 2015 12:11:59 -0000 Hi list, On Sep 30, 2015, at 12:53 , Kevin Darbyshire-Bryant = wrote: > Greetings fellow cake eaters :-) >=20 > Sebastian raised a little flag in the brain cell yesterday in his > questioning/discussion of cake stats & kernel accounted for overheads.=20= > As he stated the kernel considers the overhead of an ethernet packet = to > be 14 bytes but forgets about the 4 byte frame check sequence and > pre/post ambles which in the end make a packet on the wire worth 1538 > bytes (must use octets, must use octets) >=20 > Jonathan pointed out that cake's overhead parameter/s are used for > timing purposes, which to me makes it all the more important that > overheads are got right. >=20 > As much as I'm loath to suggest yet another option to cake, should it > not by default assume ethernet 'on-the-wire' framing overheads > (preamble& start of frame=3D8, FCS=3D4, interpacket gap=3D12) = totalling 24 > octets, not forgetting VLAN tag/s at 4 octets each and the already > accounted for 14 octets of MAC source,dest & frame type/length for > timing purposes? Ref: https://en.wikipedia.org/wiki/Ethernet_frame At least we could come up with a nice symbolic option = =93ether-layer1=94 or =93ether-phy=94 or some-such that adds the missing = preamble and inter-frame gap (IFG), we already have "ether-fcs=94, = maybe, since this is just tc that needs modification we can go wild and = do =93ether-all=94 to include IFG, preamble, MAC-header, and FCS=85 for = people wanting to shape an ethernet link... >=20 > For ethernet links this is going to be important. For other links > 'transporting' ethernet at slower rates (I'm thinking VDSL2 modems & = the > like) I suspect their overheads and pure slowness of link swamp the > timing discrepancy. A lot of the link types used by ISPs actually contain an = ethernet MAC header as part of the transferred data (I believe of the = common ones only IPoA and PPPoA avoided that basically useless 14 = bytes=85), so those 14 bytes truly are relevant on-the-wire overhead for = those links, while the layer1 stuff does not seem to be transferred and = FCS being potentially/likely used in VDSL2. The real ethernet overhead = commes into play the moment one tries to shape a VDSL2 link to 100Mbps = on a modem connected vie 100Mbps ethernet=85 (best solution, don=92t do = that then use a 1Gbps link to the modem ;) ) Too many details: # this is just from the standards, I have never seen a VDSL1 link in = real life: VDSL1 (see G.993.1 Annex H): 2 Byte PPP + 6 Byte PPPoE + 4 Byte VLAN + 1 = Byte Opening Flag Sequence (OFS), 1 Byte Address Field (AF), 1 Byte = Control Field (CF), 2 Byte TC-CRC (PTM-FCS), 1 Byte Closing Flag = Sequence (CFS) (CFS might be unused for back-2-back PTM frames?(*)) =3D = 18 byte, or 17 byte (if CFS is unused, it seems the CFS is essentially = free as it will be omitted if there is back2back data to send). This all = seems to be HDLC encoded, which statistically costs 1/128 if I = understood Jonathan correctly, but with tailored nasty packet payloads = might be much larger if I understand the HDLC typed used correctly. # my ISP uses PPPoE and a VLAN that is terminated by the MODEM PPPOE-VLAN-VDSL2 (IEEE 802.3-2012 61.3 relevant for VDSL2): 2 Byte PPP + = 6 Byte PPPoE + 4 Byte VLAN + 1 Byte Start of Frame (S), 1 Byte End of = Frame (Ck), 2 Byte TC-CRC (PTM-FCS), =3D 16 Byte FAST-ETHERNET: 7 Byte Preamble + 1 Byte start of frame delimiter (SFD) + = 12 Byte inter frame gap (IFG) =3D 20 Byte (see G.992.3 Annex N N.1 note 4 neither Preamble und nor SFD are = transferred over VDSL, the IFG does not even consist out of bytes that = could be transferred it is simply a temporal break taking the same time = as a transfer of 12 bytes would take) COMMON for pppoe-VDSL2 and fast-ethernel: 4 Byte Frame Check Sequence = (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) =3D 18 byte Now let=92s see what happens if we try to feed a VLAN and PPPoE = terminating modem-router via fast-ethernet: max Paket size 1492 Byte (due to 8 Byte PPP/PPPoE Overhead between Modem = and BRAS) FE: Payload 1492: (no VLANs no PPPoE encapsulation) Layer 1+: (1492 (Payload =3D pMTU) + 6 (dest MAC) + 6 (src MAC) + 2 = (ethertype) + 4 (FCS) + 7 (preamble) + 1 (start of frame delimiter) + 12 = (interframe gap)) =3D 1492+6+6+2+4+7+1+12 =3D 1530 payload-factor: (1492/1530) =3D 0.975163398693 payload rate: 100 * payload-factor =3D 100 * (1492/1530) =3D = 97.5163398693 Mbps VDLS2: 109.341 Mbps =93link rate=94 theoretisches VDSL100 (ohne G.INP) mit exakt 100Mbps "link rate"=20 Layer1+: (1492 (Nutzlast =3D pMTU) + 6 (dest MAC) + 6 (src MAC) + 2 = (ethertype) + 4 FCS + 2 (PPP), + 6 (PPPoE) + 4 VLAN + 5 (PTM Framing) =3D = 1492+6+6+2+4+2+6+4+5 =3D 1527=20 payload-factor: (1492/1527) =3D 0.977079240341 encapsulation-factor (for PTM)(***): 64/65 =3D 0.984615384615 payload rate: 109.341 * payload-factor * encapsulation-factor =3D = 109.341 * (1492/1527) * (64/65) =3D 105.191208584 Mbps Loss of VDSL2-rate caused by FE-Bottleneck: (100* 105.191208584/97.5163398693)-100 =3D 7.9% Starting at around 100Mbps fast-ethernet turns into a bottleneck for = VDSL2-links, so in that situation a downlink shaper needs to account for = that by shaping to a lower speed; an upload shaper however could be = replaced by BQL, assuming BQL works well enough=85 The example = calculation is not the worst case as the overhead on the VDSL2 link = could be lower and on the FE link it could be larger, but at least the = values match what a large european ISP uses in its home market... Best Regards Sebastian >=20 > 'ethernet' & 'ethernetotw' flags? >=20 > What don't I understand properly here? >=20 > Kevin >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake