Just how big a load are UDP broadcasts?
I run a small network of small sites, including a couple in the Adirondacks with 56k feeds. When a user of one of these sites uses one of the UDP audio or video services it drives the 56k to 100% saturation (load 255/255) and makes the site unusable for everyone else. Recently I "solved" this problem by blocking this traffic at the entry port for my T1 feed. To my surprise, both the average and peak traffic on the T1 dropped by a factor of 3, although less than 2% of my users complained. Traffic on my T1 wasn't the issue, but this has me wondering: how much of the Internet congestion my users do complain about is due to UDP audio/video services? In my very limited view of the world, UDP is a very poor network citizen among protocols. Am I wrong in that view? -- Dick St.Peters, Gatekeeper, Pearly Gateway, Ballston Spa, NY stpeters@NetHeaven.com Owner, NetHeaven 518-885-1295/800-910-6671 Internet for Albany/Saratoga, Glens Falls, North Creek, & Lake Placid First Internet service based in the 518 area code
I run a small network of small sites, including a couple in the Adirondacks with 56k feeds. When a user of one of these sites uses one of the UDP audio or video services it drives the 56k to 100% saturation (load 255/255) and makes the site unusable for everyone else.
Recently I "solved" this problem by blocking this traffic at the entry port for my T1 feed. To my surprise, both the average and peak traffic on the T1 dropped by a factor of 3, although less than 2% of my users complained.
Traffic on my T1 wasn't the issue, but this has me wondering: how much of the Internet congestion my users do complain about is due to UDP audio/video services?
In my very limited view of the world, UDP is a very poor network citizen among protocols. Am I wrong in that view?
no not really. udp unlike tcp has no form of inherent rate control and must rely on the application, unlike tcp which performs rate control (congestion control). for sake of discussion we can roughly equate net citizen ship with how fairly it uses the network, in otherwords it's cc. this being the case udp is not really a citizen, (since it has no cc) like tcp is, rather the bad citizen is the application or the user. :)
-- Dick St.Peters, Gatekeeper, Pearly Gateway, Ballston Spa, NY stpeters@NetHeaven.com Owner, NetHeaven 518-885-1295/800-910-6671 Internet for Albany/Saratoga, Glens Falls, North Creek, & Lake Placid First Internet service based in the 518 area code
-- - rusty eddy@isi.edu
Does nobody else even care that dialup users can request streams of far more packets than can go down their dialup lines? If not, I might as well let my own users do this too - join the merry party, burn bandwith across the net with traffic you can't receive ... -- Dick St.Peters, Gatekeeper, Pearly Gateway, Ballston Spa, NY stpeters@NetHeaven.com Owner, NetHeaven 518-885-1295/800-910-6671 Internet for Albany/Saratoga, Glens Falls, North Creek, & Lake Placid First Internet service based in the 518 area code
On Fri, 2 Aug 1996, Dick St.Peters wrote:
Does nobody else even care that dialup users can request streams of far more packets than can go down their dialup lines?
Is this a case of 14.4k users requesting 28.8k audio UDP streams or is the problem more widespread? The feedback loop for this branch of the software industry is strange because the network providers need to be the ones pushing for the software publishers to minimize bandwidth usage, yet the customers/end-users of these companies don't give a direct hoot. It might be time for something like a "Bandwidth Conservation Society" which serves as a watchdog group that pressures software publishers and bandwidth users in general, to use the net wisely. A BCS logo could be given to those that pass certain criteria and customers/end-users could be taught to look for such a logo. Chris Caputo President, Altopia Corporation
On Sun, 4 Aug 1996, Chris Caputo wrote:
It might be time for something like a "Bandwidth Conservation Society" which serves as a watchdog group that pressures software publishers and bandwidth users in general, to use the net wisely. A BCS logo could be given to those that pass certain criteria and customers/end-users could be taught to look for such a logo.
It's all their already. http://www.bcs.org All you have to do is get them to add wasteful use of UDP to their agenda. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
On Sun, 4 Aug 1996, Michael Dillon wrote:
On Sun, 4 Aug 1996, Chris Caputo wrote:
It might be time for something like a "Bandwidth Conservation Society" which serves as a watchdog group that pressures software publishers and bandwidth users in general, to use the net wisely. A BCS logo could be given to those that pass certain criteria and customers/end-users could be taught to look for such a logo.
It's all their already.
I can't believe I just posted that. Let's try again... It's all there already. http://www.infohiway.com/way/faster/ All you have to do is get them to add wasteful use of UDP to their agenda. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
Does nobody else even care that dialup users can request streams of far more packets than can go down their dialup lines?
Is this a case of 14.4k users requesting 28.8k audio UDP streams or is the problem more widespread?
The case where I first ran into this was CU-SeeMe between a univerity student, apparently on at least a T1, and a 14.4 dialup. I don't have a precise measure of the traffic, but it was around 30% of capacity of what was then a 384 incoming feed. Not much of it fit down the dialup, but it all went through Pennsauken.
It might be time for something like a "Bandwidth Conservation Society"
I think "conservation" is not the right concept. The bandwidth is there to be used, and people ought not to be discouraged from using it. I don't think flooding a destination with traffic it can't receive counts as "use". Sending no more than will actually arrive is only a minimal requirement, not a sufficient standard. Having observed streaming UDP push TCP completely aside on a 56k, I imagine much the same thing happens on any congested link: TCP will yield bandwidth until UDP has all it needs to get the entire UDP flow through. Sending no more that it's "fair" even to try to get through the most congested portion of a route would be a much more stringent standard, one that TCP meets according to my admittedly not very deep understanding of how things actually work. Of course, if simplistically applied, such a standard would completely kill any realtime-ish applications on today's Internet, and I don't want to do that. Maybe an answer could lie in the definition of "fair" involving a longer time scale - like it's ok to use UDP to bulldoze your "realtime" flow though a congested link when competing with lots of TCP flows if you don't expand to use more than your "long term share" when not competing with many TCP flows (where the assumption is that what's important for most TCP flows is the total duration, not intra-flow speed variations). Now that I've completely wandered off the deep end, I'd really like to have some people who know what they're talking about say something. All I really know for sure is that a lot of audio/video traffic crosses the net only to not be able to go down the last phone line. I think it's likely to get worse real fast: 28.8 --> 14.4 ISDN --> 28.8, 14.4 -- Dick St.Peters, Gatekeeper, Pearly Gateway, Ballston Spa, NY stpeters@NetHeaven.com Owner, NetHeaven 518-885-1295/800-910-6671 Internet for Albany/Saratoga, Glens Falls, North Creek, & Lake Placid First Internet service based in the 518 area code
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: bilse@EU.net
Per G. Bilse wrote:
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
Yesterday I watch a "cyber-TV-program" on US TV. They showed a "cool screensaver" that was continuously displaying new stock quotes it was getting over the net. And another screensaver that displayed video pictures of the Olympic Games. What worries me here is that people are developing applications that use (lots of) bandwidth, even when people are not even using their computers. Henk.
On Mon, 5 Aug 1996, Henk Smit wrote:
What worries me here is that people are developing applications that use (lots of) bandwidth, even when people are not even using their computers.
I agree. This will get worse and worse as more and more companies build products and test them on a LAN or with a local ISP at the other end of their T1 line. It would help a lot if there was an RFC because even though many developpers can be clueless when designing and implementing these products, they *DO* listen when someone points them to a standards authority like IETF. You and I may know that IETF is just a bunch of plain folks who understand networks and try to figure out the best way to build them. But it is much much easier to tell a developper that their product violates RFC2001 than it is to try to convince them that they are wrong based just on engineering grounds. The developper and their managers will dispute engineering reasons much sooner than they will dispute an official Internet standard from the IETF. Maybe we could get an RFC that requires screensaver type applications to have a standalone mode that works with stored data and require user overrides in order to initiate video or other data feeds. Maybe it could also require that video and data feeds automatically shut down if there is no user interaction within a specified time period. Kind of a higher level view of the smae kind of timing specs that make TCP work. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
But it is much much easier to tell a developper that their product violates RFC2001 than it is to try to convince them that they are wrong based just on engineering grounds. The developper and their managers will dispute engineering reasons much sooner than they will dispute an official Internet standard from the IETF.
An RFC would also make it a lot easier to justify restraints on what users can do. RFC compliance could even be turned into a marketing advantage, which would put pressure on other networks to comply as well. I much prefer pressuring developers than pressuring users, but I think anyone who runs a "retail" network or is aware of mailbombing software, spamming software, or cracking software knows that being part policeman and part parent comes with the territory. "Bad" applications will be written no matter what the RFC says. -- Dick St.Peters, Gatekeeper, Pearly Gateway, Ballston Spa, NY stpeters@NetHeaven.com Owner, NetHeaven 518-885-1295/800-910-6671 Internet for Albany/Saratoga, Glens Falls, North Creek, & Lake Placid First Internet service based in the 518 area code
Dick, you wrote: ...
RFC compliance could even be turned into a marketing advantage, which would put pressure on other networks to comply as well.
RFCs form Internet guidelines, notes, and standards. They are not marketing advantages, brochure fillers, reasons, pressure-points, or massage techniques. You've shown usual lack of understanding of bandwidth usage, conservation, and reservation, despite many comments from Michael and others.
I much prefer pressuring developers than pressuring users, but I think anyone who runs a "retail" network or is aware of mailbombing software, spamming software, or cracking software knows that being part policeman and part parent comes with the territory. "Bad" applications will be written no matter what the RFC says.
RFCs don't pressure developers or users, and has nothing to do with your seriously messed-up religious viewpoints on "retail networks" or whatever else you were typing while your prozac wore off. Please don't make it any worse by calling for an RFC ''so marketing can force'' some solution you don't understand to a problem you can't define on a network you don't run or ever will grok.
-- Dick St.Peters, Gatekeeper, Pearly Gateway, Ballston Spa, NY stpeters@NetHeaven.com Owner, NetHeaven 518-885-1295/800-910-6671 Internet for Albany/Saratoga, Glens Falls, North Creek, & Lake Placid First Internet service based in the 518 area code
-- Ehud Net.signature less than 5 lines, including -- First Internet service based in XXX where the owner isn't a moron
Ehud Gavron writes:
You've shown usual lack of understanding of bandwidth usage, conservation, and reservation, despite many comments from Michael and others.
RFCs don't pressure developers or users, and has nothing to do with your seriously messed-up religious viewpoints on "retail networks" or whatever else you were typing while your prozac wore off.
Please don't make it any worse by calling for an RFC ''so marketing can force'' some solution you don't understand to a problem you can't define on a network you don't run or ever will grok.
-- Ehud Net.signature less than 5 lines, including -- First Internet service based in XXX where the owner isn't a moron
Ehud, I'm sorry I'm so stupid. I guess Per Bilse should fire that other stupid person in his office for suggesting an RFC - but Per's own .sig is 7 lines, so I guess he must be an outcast already also. Luckily for Michael, he owns his own network, so nobody can fire him for stupidly suggesting that an RFC could be used to pressure developers. For everyone else: I'm not sure what triggers these outbursts at me by Ehud, but the first one appeared to be some kind of religious fanaticism directed at my choice of name for my network. Most people who get it (there are people who don't) find the choice amusing, and I have more than my share of religious organizations as clients because of it. -- Dick St.Peters, Gatekeeper and moron, Pearly Gateway, Ballston Spa, NY stpeters@NetHeaven.com Owner, NetHeaven 518-885-1295/800-910-6671 Internet for Albany/Saratoga, Glens Falls, North Creek, & Lake Placid First Internet service based in the 518 area code
On Mon, 5 Aug 96 16:41:48 PDT Henk Smit wrote:
Yesterday I watch a "cyber-TV-program" on US TV. They showed a "cool screensaver" that was continuously displaying new stock quotes it was getting over the net. And another screensaver that displayed video pictures of the Olympic Games. What worries me here is that people are developing applications that use (lots of) bandwidth, even when people are not even using their computers.
Shouldn't be a problem if people have to pay for their traffic. Assuming that there would be a way to listen to foreign radio stations per telephone, how many people would make long distance calls to feed their 'radio'? geert jan
participants (8)
-
Chris Caputo -
Dick St.Peters -
eddy＠isi.edu -
Ehud Gavron -
Geert Jan de Groot -
Henk Smit -
Michael Dillon -
Per Gregers Bilse