RocketMan, Good to see you here. Some good, provocative stuff you've delivered. I had to read your post several times in order to put things into perspective for a reply. You certainly covered a lot of ground.
You cite the current ills of the 'net to be centered essentially on
(1) congestion and inordinate levels of latency and waiting times; and,
(2) uncertainty, where senders and recipients alike are unaware of the success or failure of their packet deliveries.
Can't argue with you there, although I could add a few things of my own, but let's work with what you've presented for the moment.
>>But then there are the larger issues of the IP routing and management paradigm that no doubt still lend themselves to the expertise and prowess that the Ciscos and Bays have mastered over the years.. do you really think that the Cisco/Bay expertise/prowess is what will lead us into the next generation of large-bandwidth near-real-time delivery of global audio and video?<<
They might, but not necessarily. Wellfleet (now Bay) and Cisco are among the leaders in the router field who were, let's not forget, the ones who broke a good bit of virgin ground, and are responsible in large part for getting us as far as we've gotten, so to speak. One could argue that their intellectual retention of the disciplines involved, alone, would give them an edge in the more comprehensive [but not necessarily, niche] Layer 3 issues. (I almost fell right into that one.)
Perhaps its time for a startup to do what some startups have been known to do so well, and that is to come in and leap-frog the incumbent dominant players, and establish a foothold in some new niche areas, and stem out from there.
But that wont be accomplished without a considerable fight. Or not at all, perhaps, since it seems that every time a startup appears to be gaining significant ground, especially with a breakthrough approach, they are acquired by one of the two companies mentioned above, namely, Cisco. And that's ok too... for the principals and stock-owning employees of the startup, that is.
>Even with ISDN, cable, xDSL, and all the alphabet soup you throw at the problem the basic clog at the access choke points may just grow to the point where the system collapses.<
Ad infinitum. Lump it up here, it vacuums there. Bend it hither, it squeaks yonder. Someone asked the other day what the impact on the network core would be in those areas of the country that are receiving heavy doses of xDSL and cable modem rollouts. In the case of the Internet, the 'core' translates to the network access points <NAPs> and other heavily trafficked peering nodes. Would the core "implode?", in other words?
I don't think that we will see that kind of traffic-ratio reversal in the near term, although this could happen in a regional or in a more localized sense, if the ISP offering the high speed links didn't adequately size their upstream pipes, router ports, and other routing resources, to accommodate the new loads. Are these, the latter elements I mentioned, the access choke points you referred to, or are you referring to the LEC's access ports on their switches?
In any event, both actually do exist. This implosion kind of action has actually happened in some cases where Cable Cos have offered 27 Mbps downstream transport capabilities via cable modems, only to have a fractional T-1 or several T-1s supporting the upstream connection from the head end. But I seem to be going the other way with this, aren't I? Your observations in this respect, IMO, are accurate, and they speak many truths, for, and by, themselves.
>>It's one thing to wait forever for a web page to load, quite another for a non-internet user to have to wait while his voice packets get there, with no assurance...if the answer may be not be in larger and larger centralized networks and switches, but in decentralized terabyte-sized caching systems fed by satellite or fiber systems... just wondering how we will eventually address the clogging problem, especially with the projected growth of VoIP traffic....Even if the caching systems have too much time delay for voice or video, they may relieve the major congestion, allowing better delivery of time- sensitive traffic.<<
As in medicine, each remedial prescription for a particular ailment must be studied for any of the ill side-effects it may cause, resulting from contraindicatives. Take your local caching solution, for example.
Caching would allow much faster downloads in the beginning, granted, if the caches were in, say, regional offices, as opposed to none at all, or in a national repository. But what would this do to other parts of the 'net? What would this do to the performance of the network edge? The edge would get swamped, if this model were to suddenly reach high levels of penetration, to the point of diminishing returns, and then none at all, because normal capacity sizing has rendered the edge to be capable of only that which it _currently_ must support. Kinda like natural selection. Of course, the edge could be bolstered, but whose responsibility is that?
In electric power company jargon, this displacement effect being caused by the caching action could be likened to 'load shedding' of power between neighboring generation plants or companies on the same grid, just before the breakers are set to blow. On the Internet, it could likewise be called load shedding, or, more appropriately, load "shifting." For, in the end, much greater amounts of traffic would then flow, not less, and although it might seem like there is an advantage gained, more traffic is then permitted to flow on the "backbones," perhaps sooner in time than otherwise, which in turn engenders more demanding forms of traffic to get through which cannot be cached. Namely, real time traffic. But how is this real time stuff going to get through to the limited edge resources, when the edge is busy coping with downloads from caches in regional offices?
The contraindicative? Now that the pipe is filled to the home to the point that it is bursting with that super-fast cache download of your favorite interactive game release (that still takes about a half hour to download, even under ideal conditions), where's the room for that UDP voice application going to come from on that limited feeding straw you call an access line? I've exaggerated to make a point.
Even if this were to work to everyone's favor, who would pay for the fat pipes needed between the local caching engines and the ISP's distribution nodes? Certainly, a single cache would render minimal effect for most ISPs' purposes, that is, for those with any appreciable geographic coverage; there would be a need for several-to-many of them.
How many caches would be required throughout the ISP's serving territories? The caching engines and the pipes would represent large incremental and recurring costs to already cash-strapped ISPs, who, in the main, are looking to cut costs, not increase them... The ISPs, in turn, would have to re-distribute the cost burden of acquisitions and upkeep to end users.
Are end users ready for this? Some are, most are not... because it runs counter to what the Internet is 'supposed' to be: Cheap. Uuhh, better make that, very inexpensive.
If we go back to the beginning and analyze the needs of users, all messages do not demand the same levels of immediacy in their receipt. Some emails, many LAN messages, some database updates, some voice-mail trickles, etc., can wait. This, however, is not the case today, since the fairness rules on the 'net do not distinguish between an email message and r-t voice, at least not in the favor of voice packets...
In fact, email gets the priority, since VoIP is using UDP packets which lack the guaranteed delivery mechanisms that TCP allows in the transport layer for applications such as Email and http. And while email is subject to TCP windowing delays, and restarts, it does in fact enjoy the guarantees that TCP avails itself to, since sooner or later that email does get through, ordinarily in one piece. Kinda like a backwards set of priorities, wouldn't you say?
[[ But, to clarify, and so as to not make this entirely one-sided, the effects of the lost UDPs in the VoIP model are mitigated to some extent by several factors. First, UDP packets are like cockroaches, they sneak through cracks in the wall, because, in fact, they are 'not' subjected to windowing algorithms. In a way, they are like free agents, not bound by the ordinary rules of the transmission control protocol, or TCP. Secondly, when one does happen to get stepped on, squished, it goes into the bucket, and the message will still make sense, thanks to predictive algorithms which fill gaps, and some other nifty band-aid fixes which makes everything feel better in the end. ]]
In the portfolio of traditional public carrier offerings, i.e., those offered by the incumbent IXCs and xLECs, there are a disparate and seemingly unending number of different network types and makeups. POTS, 800, ISDN, Frame Relay, ATM, DDS, X.25, SMDS, to name the more popular ones.
There begins to seem like there is no rhyme or reason as to why so many different network forms should exist. They exist, for the most part, to satisfy the different levels of expectations that users have on the basis of what types of traffic it is that they are sending, and the urgency they place on that traffic's delivery. And it works very well, almost without fail. There are a lot of substantiable 9's to back that up.
What we're trying to do with the IP protocol, in turn, is to mimic the capabilities of all of these network forms, and in such a way as to create a single serum to treat all ailments. It can be done, but not before more ailments are first created, and it's going to take a lot of time. And in the end, for it to succeed it will be largely dependent on a major fiber push into the edge, and to the user.
Consider that the 'push' component of the core network is getting far greater (the amount of indexed content and the capacity of the network core as demonstrated by DWDM buildouts and new fiber carrier deployments), while the relative 'pull' capabilities in the loop are diminishing rapidly (for most users). This means that it is going to get a lot worse for them before it gets better... for those who are not fortunate enough to be the recipients of next generation access technologies. This may not seem to be the case, but wait until streaming video and real time video conferencing becomes commonplace in some locales, while not in others. This could mark the beginnings of a further taxonomical delineation of haves and have nots, right within the framework of the former 'haves,' itself!
I see xDSL and CM deployments in a limited set of areas being able to fill some of the bottleneck problems. But this wont be pervasive for quite some time. Some will be satisfied through new wireless local loop alternatives, but again, not enough. Satellite download capabilities? Don't want that, because I telecommute often, and my requirements are two way. No way am I going to pay for two or three different methods of access from my home. From the office, I may have no choice, but not from my home. Yet.
Getting back to the problems you cited, there are some good things happening that will allow for prioritization and the mapping of CoS/QoS markers in IP, and vice versa, with ATM, that should settle some of these issues, where queuing and buffering will permit. But not in all forms of IP deployments, rather, in VPN scenarios, and in other controlled networking environments. Quality, over time, will be tiered according to user demands and will carry pricing levels to match.
Well, as you can see, I don't have many of the answers. I would venture to state, however, that those answers which were slated for deployment at one point are probably outdated by now, with more hopes gradually being placed on the brute force of the core (more fiber, greater DWDM factors), than on smarts, and there is little recourse for those at the edge, and in the home, who are still relegated to using POTS/56k/ISDN.
Regards, Frank Coluccio |
