|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: audio/video again
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. -- ------ ___ --- Per G. Bilse, Mgr Network Operations Ctr ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since 1982 --- http://www.EU.net e-mail: [email protected] - - - - - - - - - - - - - - - - -
|