re: lets not forget the other classes of service that must coexist
Jay,
One of the areas we're not taking into account here is the need for sufficient class of service provisioning, and QoS, for other applications requiring of isochronous treatment, such as time critical voice and video. If there is sufficient bandwidth, these are sometimes satisfied by brute force dynamics. The more crowded the pipe gets, however, as I think I've demonstrated is plausible (at least) here, the more these parameters become important.
While it may be statistically feasible, from a desktop application user perspective, to fill up the pipes all the way with data apps which are non-isochronous, between the cracks, so to speak (read: to fill the pipe to near 100% utilization), yielding only some minor latency penalties to those apps, the same cannot be said about the effects of unsynchronized latency and its resulting jitter on VoIP and v-c applications.
In other words, filling up the pipe to the extreme may be alright for data applications only (although there's no guarantees that this is sustainable with scaling), but some additional "head room" or spare capacity would always be needed to allow for the more demanding time critical applications such as voice over IP. Unless, of course, these are sacrificed for those which are non- time-critical.
The way that these requirements scale with varying degrees of backbone and feeder sizing is interesting. In the very large pipes such a SP backbones of say, 600 Mb/s or 2.5 Gb/s, voice UDPs (datagrams) are able to negotiate very nicely and get in and out of tight spaces like cockroaches among the larger data-centric flows. As the size of the pipe decreases, however, a disproportionate level of increased difficulty is encountered when attempting to achieve the same end. It's not linear, in other words.
When a cablemodem segment is being shared by hundreds of users, the problem could become very acute for VoIP talkers and those doing video conferencing, especially if head end routers are not optimized for CoS, QoS and other parameters which have to do with fair queuing, as the number of other m-m applications scale up on the same segment, at the same time.
These are still other pieces of the tradeoff analyses which need to be taken into account, and probably the reason why those programmers and systems analysts you mentioned are very likely earning their keep.
I wonder if Curtis Bemis is looking in here. Curtis? We could use some help on this topic. Are you there? |
