OK, I will bite. What is wrong with this comparison of UDP with TCP? As
far as I can see the only error is that it implies incorrectly that UDP
traffic is not affected by congestion. But it is quite valid in the
statement that UDP will tend to crowd out TCP. (Except for short TCP
transmissions for which congestion control does not have time to take
effect.) Per megabyte of traffic, UDP will tend to cause more delay to
other traffic stream than will TCP. What am I overlooking?
UDP will also crowd out itself in ways such that things like
DNS quits working, not to mention the streaming UDP protocols.
Protocols that don't have congesition limiting built in,
and which stream, and which are real time, will not be long
lived. My longer lived TCP streams will get my data through
eventually, where the CUSeeMe stream may choke a link or to,
it won't really be able to provide any real service due to multiple
aggreesive protocols condending for the bandwidth.
So to a large extent these effects are self limiting in the long
term. However it is sever lack of clue that some of these
software designers are specificly designing to use UDP for two
reasons: A. Its harder for people to filter them out, and B.
they don't want congestion control to slow them down.
A. is solved with a larger stick (or hammer), and B is self limiting
due to the popularity of the protocols.
Its only a matter of time before DNS gets considered a "bad" protocol
because it users UDP.
There are a handful of people that do have some very good ideas
about how the Net will evolve and scaling issues will be solved,
and quite a few are in places to do things about it, but
you don't see any popular coverage of "peering for pay", "strict peering"
v. "loose peering", parital tranasit, capture effects of low
priced dialup acounts as they might be compared to the magazine subscrition
business, etc.
However, I can assure one and all, that:
You WILL.
And it won't be brought to you by AT&T or Infoworld for that
matter.