On Sun, Dec 3, 2017 at 12:14 PM, Sebastian Moeller <moell...@gmx.de> wrote: > > > On December 3, 2017 8:54:40 PM GMT+01:00, Juliusz Chroboczek <j...@irif.fr> > wrote: >>> Many would kill for a 10:1 DOCSIS connection. 50:1 is not rare, and I >>> have personally been subscribed to a near 100:1 service. >> >>Some people should not be allowed to design networks.
The upstream/downstream problem over long distances has been problematic for dsl (phone line) and cable (coax) deployments. The head-ends have much greater control over the signal strengths than the (usually much cheaper) Gpon fiber is also commonly sold in 1Gbit/100Mbit modes. Testing on a GPON network showed about 80ms worth of buffering in the ONT - which we can get rid of entirely, in cake. >>> The DOCSIS shaper deals with ethernet frames so 58 / 1518 bytes. >> >>Could you please point me to details of the DOCSIS shaper? > > the relevant section from the Docsis standard > (http://www.cablelabs.com/specification/docsis-3-0-mac-and-upper-layer-protocols-interface-specification/): > > "C.2.2.7.2 Maximum Sustained Traffic Rate 632 This parameter is the rate > parameter R of a token-bucket-based rate limit for packets. R is expressed in > bits per second, and MUST take into account all MAC frame data PDU of the > Service Flow from the byte following the MAC header HCS to the end of the > CRC, including every PDU in the case of a Concatenated MAC Frame. This > parameter is applied after Payload Header Suppression; it does not include > the bytes suppressed for PHS. The number of bytes forwarded (in bytes) is > limited during any time interval T by Max(T), as described in the expression: > Max(T) = T * (R / 8) + B, (1) where the parameter B (in bytes) is the Maximum > Traffic Burst Configuration Setting (refer to Annex C.2.2.7.3). NOTE: This > parameter does not limit the instantaneous rate of the Service Flow. The > specific algorithm for enforcing this parameter is not mandated here. Any > implementation which satisfies the above equation is conformant. In > particular, the granularity of enforcement and the minimum implemented value > of this parameter are vendor specific. The CMTS SHOULD support a granularity > of at most 100 kbps. The CM SHOULD support a granularity of at most 100 kbps. > NOTE: If this parameter is omitted or set to zero, then there is no > explicitly-enforced traffic rate maximum. This field specifies only a bound, > not a guarantee that this rate is available." > > So in essence DOCSIS users need to only account for 18 Bytes of ethernet > overhead in both ingress and egress directions under non-congested conditions. Also, cake, as a deficit mode shaper, it is the opposite of how htb functions in terms of bursts. TB tries to make up for bandwidth you should have, verses cake which gives you the bandwidth you have "right now". This lets us set the shaper much closer (seemingly exact in the case of docsis, atleast) to the actual configured TB rate (with better fq/aqm queue management) I just submitted an initial patch for cake to net-next after a huge round of testing. > > > >> >>-- Juliusz >>_______________________________________________ >>Bloat mailing list >>Bloat@lists.bufferbloat.net >>https://lists.bufferbloat.net/listinfo/bloat > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat