Ken,
Disclaimer: It would be prudent and proper to mention at this point that there is no universally administered policy in place among all ILECs and DLECs/CLECs relating to how they will or should treat this issue. We are likely to see a great deviation in philosophical treatment here, just as we do from ISP to ISP, and even from NAP to NAP, in the precepts which drive their network architectures. But it is somewhat entertaining, and at the same time, instructive, to examine the possibilities, IMO.
I would agree that in large part you are correct, because the TCP/IP model takes these factors into account, and takes care of its own, so to speak.
But I would not presuppose that the provider -the ILEC, in this case- would simply go with what they previously had in place, not making allowances for increased capacity demands and differentiated grades of services, even tacitly.
Nor do I think that they would ignore the need to be more responsive to the higher paying client, nor leaving it entirely to chance that the previous supply of bandwidth and routing resources were sufficient to accommodate the greater loads.
In retrospect, I would have to assume, consistent with the disclaimer above, that in some instances they do this. And in these instances they are simply gauging uptake before making load adjustments on a just-in-time, or after-the-fact basis. I really don't know how one would gather the type of information across the board that would clarify this. Such an approach as the latter, however, would find it difficult to pass Quality Assurance criteria in any enterprises which did their homework properly using predictive modeling techniques, I should add.
Unless, of course, the anticipated uptake of the higher speed services was very low, and they deferred to a judgement call predicated on "wait and see what happens." This, I should add, is to a large extent actually consistent with many other Internet related architectural practices.
And to that extent, maybe you are even more correct in your assumptions than I am, where I have taken the structured and proactive approach.
ILECs have not been known, historically, for this kind of non-determinism, however. Because of their deterministic "rigidness," in fact, they have actually been accused up until now of "not getting it." Is this about to change? Or is it simply that the IP model is so loose and wieldy that they will attempt to get by with what they have and defer to the vaguaries of the 'net, when congestion and bottlenecking levels rise?
Also, TCP/IP sessions are not as serially administered at the router level as your (granted, over-simplified) explanation suggests. Behind every access mux, or DSLAM, or MAX-TNT dial in modem pool, there resides an Ethernet, or an FDDI, or an ATM Fabric [haven't seen any Token rings yet (g)], which allow for sharing and interleaving to the upstream router and link resources in the edge.
Secondly, routers accommodate multiple TCP sessions simultaneously, effectively performing much of the arbitration you alluded to, through windowing algorithms and flow controls. These, in turn, are dependent to a great extent on the variable factors I alluded to in my previous post: prioritization (tos/qos), buffer administration (queuing), partitioning, link-sizing, etc.
I think that we overlap more closely in our views than one would conclude from reading your post. The difference is that I believe that special attention has been paid to bolstering the abilities of the higher speed services in some deliberate way, however modest it may be, whereas you do not. And that's okay, too. I could be wrong in many instances, depending on local decisions reached by the particular ILEC, and then again, in other situations I may be correct.
I think we also have to take into account the other DSLs which are now coming on line whose primary providers (who are reselling ILEC facilities) are not the ILECs themselves. Rather, they comprise the new family of data CLECs, and they actually do negotiate with the incumbent LECs and with the Tier One and Two backbone providers for service level guarantees for edge and core services. Thus, potentially affecting the overall edge composition in other ways which may, in turn, have secondary effects on dial in users.
I'd be interested in hearing more of your views, along with those of others, on this topic.
Regards, Frank Coluccio |
