No problem. I’m glad to answer. To answer the specific question at the end of your email, cable modem service rate is configured using the “Maximum Sustained Traffic Rate” parameter (Section C.2.2.7.2 in http://www.cablelabs.com/specification/docsis-3-0-mac-and-upper-layer-protocols-interface-specification/). That rate includes all MAC Frame data bytes sent in the Service Flow, which means the DOCSIS MAC Header, Ethernet Header, Ethernet PDU and CRC of each MAC Frame are included. Depending on how the service is configured, the Service Flow may or may not be carrying a very small amount of network management traffic to/from the IP stack in the modem and/or a very small amount of “MAC Management” traffic to/from the modem MAC-layer, in addition to the user traffic. It is common that cable operators set the Maximum Sustained Traffic Rate to be a value 10%-20% greater than the rate that they advertise to the customer (presumably to both account for the overhead, and to compensate for the occasional congestion events that can happen during peak hours). There is, unfortunately, no way for the user to directly find out what values of Max Sustained Traffic Rate are configured for their service.
In terms of the MAC Header size that factors into the above rate shaping calculation, 240 bytes is the absolute maximum total bytes for all EHDRs that the DOCSIS MAC frame format could support, but in fact there is no way that you’d ever get anywhere close to that. For downstream packets, the DOCSIS MAC header consists of the standard 6-byte MAC Header, plus 6 bytes for the DS EHDR and 5 bytes for the Downstream Privacy EH Element. So, 17+14+4=35 bytes of per-packet overhead for a downstream DOCSIS MAC Frame. For upstream packets, there will typically be only the 6-byte MAC Header, plus the 4 byte Upstream Privacy EH version 2 Element, so 10+14+4=28 bytes of per-packet overhead for an Upstream DOCSIS MAC Frame. If you are concerned about the overall shared channel capacity, and what the other overheads are there, things get more complicated than I want to get into, but for downstream, you could look at Sections 7.1, 7.2 and 7.5 in http://www.cablelabs.com/specification/downstream-rf-interface-specification/ as a start. -Greg On 6/23/16, 9:59 AM, "Moeller, Sebastian" <moel...@caltech.edu> wrote: >Hi Greg, > >I hope you do not mind being contacted directly, but you seem to be one of the >few persons with the “intimate" knowledge about docsis low-level details. We >had a discussion recently in the cake list, IIRC, about the appropriate >per-packet overhead in DOCSIS networks, which lead me to do some research, but >now I am fully confused. > > To me it seems that DOCSIS adds at least 6 Bytes worth of DOCSIS > headers and includes otherwise ethernet frames including the frame-check > sequence is that correct? So this would mean 6+14+4 = 24 bytes of > per-paket-overhead. But what about the data link security EHDR according to > Data-Over-Cable Service Interface Specifications DOCSIS 3.0 that can be up to > 240 bytes per encapsulated ethernet frame? Is this typically used and what > size is this typically 240 bytes seems exessive, no? > > Now for DSL (where I have more experience and data) I know what we need > is a “raw” bandwidth number and the to be subtracted per packet overhead (or > packet independent overhead from say 64/65 encoding or maybe the MPEG 184/188 > encoding). But for DOCSIS I am really at a loss, since cable ISPs do not > communicate the exact values for bandwidth and overhead that are applicable… > Could you maybe shad some light on what overhead typically is accounted > already in the user- reported bandwidths and what overhead still needs to be > accounted for? (I realize that this most likely be only relevant in an > otherwise “silent” DOCSIS segment where there is no contention, but currently > I have no clue for even that rather simple condition). > >Many Thanks in advance > Sebastian _______________________________________________ Codel mailing list Codel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/codel
