Forum Discussion

legacy1's avatar
legacy1
Alessandro Volta
3 months ago

Reverse engineering and start implementing how the upstream works

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😋 

  • 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's avatar
    legacy1
    Alessandro Volta

    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.

  • 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's avatar
    legacy1
    Alessandro Volta

    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.

  • All I can say is LLD is evolving within the industry, but it will not be bandwidth driven.  

  • Anonymous's avatar
    Anonymous

    Increased latency caused by congestion or bufferbloat? Scheduling has no impact on the latter.

  • Anonymous's avatar
    Anonymous

    About asking for bandwidth in DOCSIS: Contention requests (asking permission to transmit) can collide with requests from other modems. The request will be lost and must be retransmitted = increased latency.

    When congestion occur, the likelihood of collissions will increase. The CMTS may even decrease the number of slots that the modems can use for these requests = even higher risk of collision.

    If the rate of packets is high enough, the modem will piggyback the request: It will add it to an existing grant (cannot collide), avoiding the need to use a contention request. This is the most efficient way to request bandwidth. Requesting bandwidth to reply back to the bandwidth monitor does not use this method (the rate is too slow).

    Sending grants to the modems without prior requests is another way to do it. Such a scheduling service is defined for LLD (optional).

  • Exactly !!     No need to "reverse engineer" how it works.   LLD will eventually give Legacy1 what is required, although only for certain traffic types.   Service flows will eventually be allocated accordingly.  

  • Anonymous's avatar
    Anonymous

    There has been a lot of talk on the internet about L4S, an upcoming method to give you low queueing delays. VM must deploy LLD in order to support that. PGS (the new scheduling scheme) is not required. PGS can add overhead to the upstream, so we will see what VM will do. 🙂

  • Anonymous's avatar
    Anonymous

    Cannot edit. I forgot to write: L4S is about high speed and low queueing delay at the same time.