Reverse engineering and start implementing how the upstream works

[legacy1]

So this is just me thinking why is the upstream so bad and without knowing how Docsis works make it better.

So we have downstream which the modem can not Tx unless Rx tells it can and lets also assume that the timing of when the CMTS tells the modem to Tx to the ns to not cause problems when other modem Tx for interfering.

So lets say every 250ms the CMTS tells the modem to Tx a set burst to Tx so first problem is every 250ms means that you have high jitter and latency.

So what if we change that to every 10ms for the modem to Tx a set burst to Tx then the problem is you waste bandwidth should that modem has noting more to Tx

Then the other problem is set burst to Tx maybe the burst is to big or too small

meaning we need some thing dynamic so we could have the CMTS tells the modem to Tx every 250ms but a small burst but the modem when sending the burst to tell the CMTS that I have more to Tx so the CMTS can schedule the modem to Tx before the next 250ms gap and how big of a burst to max or less in modems buffer to Tx.

One small problem with this is you might be waiting for the next 250ms if you did have something to send then don't then do.

So every 50ms or less for a small burst to see if you have something to Tx?

To me this system should work with many modems and the CMTS scheduling everyone fair bandwidth.

Yet VM system don't do this and so scheduling stacks up without doing fair bandwidth just the one asking I got more to Tx at the max burst till it hits the modem user upto limit.

PS sorry for any misstakes blame VM for no Edit option😋 

[pete_at_home]

It's usually more frequent than 250mS.   The CMTS is typically configured with MAP interval around 2mS-5mS, so the modem(s) have plenty of opportunity to send "requests" for upstream slots.   Once the CMTS "grants" the modem slots, it can then transmit up to the allowed bandwidth in those slots (although this is shared with all other modems in the serving area).

[legacy1]

Ok so why is the scheduling so bad with current CMTS? Its like the CMTS knowns it can schedule so must where by the scheduling can be placed ahead of time for given modems to be fair to everyone in 1000ms but the upstream seem to extends this try to fulfil everything and stacks the over 1000ms for the next 1000ms causing latency spikes.

[pete_at_home]

Because it also depends on the number of modems in a serving area.   There's a fixed number of US slots, so if a large number of modems are doing requests, then they will get spread out.    You cannot see the background messaging to the modem, because it's in an underlying Docsis layer between the CMTS & modem.

If VM reduce the MAP interval, then in theory there's more upstream opportunities sooner, however the means the modem has to process these & respond faster.  Also more MAP messages uses up bandwidth that's no longer available for data packets.   There's always a trade-off. 

It's all in the Docsis specs.

[legacy1]

Ok but even so I think the scheduling can be handled better at the CMTS side so that greed modems are slotted far ahead and less greed modems are slotted to close to real time so that lower bandwidth usage = low latency with sooner slots. So if you do 20Mb upload you can still get low latency but when 10 modems try to upload 100Mb each vs one under less then 1Mb then that modem has low latency with everything going on.