Somebody in the office pointed out that what's needed in this area is
effectively an Applications Requirements RFC, similar to the Router
and Host Requirements RFCs. In the good (but somewhat boring) old
days, there wasn't really a lot of applications outside the normal
UNIX and TCP-based environment, with multicasting being the exception
(and this one carefully tunneled and monitored), so Router and
Host Requirements were all that was needed.
To what extent such an RFC actually would be useful, I don't know. You
mention CU-SeeMe, which we got hit by very badly, starting almost a
couple of years ago. That was with the earlier version, where a user
could request up to 640kbps of UDP data to be sent to him,
irrespective of his own bandwidth and whatever else might want to run
over the same lines. It only takes 2-3 users of an application like
that to hog a T1 or an E1. We had a longish discussion/battle on the
mbone list about this a year or something ago (hi Jon), and found it
very difficult (at least to start with) to get even the Internet R&D
community to understand the problems. In the end I think I can say
we won the day, and the CU-SeeMe developers have since then put in
congestion control, which actually works pretty OK; the application
still eats a lot of continuous bandwidth, but it's limited roughly to
the thinnest pipe along the path, and since most Kool Cyber Dudes are
on dial-up, no real/immediate damage is being done.
But getting the attention of developers of Kool Cyber Applications
won't necessarily be easy, not least because many of them really
don't have too much idea about background, engineering, whatever.
Was it Vocaltec that circulated this ad "Talk for FREE over the
Internet"? I think so, but it doesn't matter anyway; I have seen
other people dabble in "TCP accelerators", which is a "more powerful"
TCP implementation in a proxy setting, adding "thrust" to "weaker"
TCP implementations on hosts behind it, getting more throughput on
congested lines.
In the end all of this is just an arms race and there is a risk that
it will gradually lower network service quality if shared capacities
aren't kept up to meet demand (polite and considerate applications
and protocols are much better at coexistence; aggressive dittos will
end up wasting large amounts of resources). This in turn costs more
money, which the users of the applications don't particularly want to
part with (after all, they're supposed to be able to do whatever for
free, that's what the vendor said).
There is clearly scope for enlightened members of the press to try to
prevent Internet application developers from repeating the success of
50s and 60s car makers. That would actually be a valuable contribution
to a healthier Internet industry.