On 2/12/14, 10:37 PM, "Mikael Abrahamsson" <[email protected]> wrote:
>On Wed, 12 Feb 2014, Greg White wrote: > >> Certainly, more complex models can be built to look into nuances of >> specific situations, and perhaps this is an area for other researchers >> to explore. But, at that point, I think you have to move away from >> simple synthetic usage models like we've been discussing in this thread >> (5 users simultaneously go immediately dark or simultaneously >> immediately saturate their link). TCP sessions (and other traffic >> loads) come and go across the user base asynchronously, so the >>available >> capacity fluctuates over time in a more random manner than we've used >>in >> this example. Similarly within each modem the traffic loads and TCP >> sessions will come and go and be in various states of congestion >> avoidance (hence differing amounts of queue), so the availability of a >> 500ms or 10ms of queued traffic isn't guaranteed in the FIFO vs >>FQ_CODEL >> cases. > >How quickly does the CMTS react to customer demand, is this done >continously (basically down to millisecond)? I don't know how cable >works, >I just know how LTE works for instance, where it actually takes a little >while to adapt to changes in customer rate requirements. If cable does >this is more or less round robin fairness between users then I agree with >you that the current model is sufficient. It is done continuously. There is about a 6ms lag between the CM sending a request for a transmission opportunity (e.g. "I currently have 3742 bytes in queue ready to transmit") and the actual transmission opportunity occurring (e.g. "Ok you can transmit 1768 bytes starting at time X"), but essentially* every data transmission is handled via this request-grant mechanism, i.e. the CMTS doesn't grant a tx opportunity for a CM unless it is explicitly requested for. *there are some special cases (not relevant here) that differ from this > >-- >Mikael Abrahamsson email: [email protected] _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
