Re: Melting the Internet?

Per Gregers Bilse (
Sun, 7 May 1995 22:37:57 +0200

It's been a very interesting discussion to watch and it's good to
see that a number of people take the issues of bandwidth hogging
and network behaviour seriously.

There are a couple of issues I'd like to address:

On May 2, 23:59, Michael Sattler <> wrote:
> >what Rutkowski said -- there is not an army of friendly Telcos lined
> >up with cheap bandwidth, just because a number of people think that
> >would be nice.
> Hmmm, there sure is in my neck of the woods. Access keeps on getting
> cheaper and cheaper, restrictions keep on getting lifted. If businesses

Try to think in more global terms. Bandwidth is always cheap
domestically and locally; 2Mbit in Amsterdam costs on the order of
1-2% of 2Mbit across the Atlantic.

> every month. Sure, I pay less than my Australian counterparts, and I'm
> guessing I pay less than you do, but I pay. I pay US$12.50/month for
> unrestricted 28.8 kbps access, and US$200/month for unrestricted 128 kbps
> access.

If you actually use that bandwidth, somebody else is paying for you.
This isn't even a question about overselling -- how do you imagine
any ISP being able to sell global bandwidth at a price of
USD200/month for 128kbit? Nobody can sell bandwidth at less than
what they themselves are paying.

> >As has been said before, "The Internet isn't free, it just looks like
> >that because somebody else is paying". What is it that makes people
> >believe that an N kbit Internet connection allows them to use N kbit
> >on a continuous basis?
> I'm guessing they believe this because they haven't been educated; because
> there are folks out there who believe that hiding information from them is
> better than inundating the masses with examples of responsible bandwidth
> use.

Do you consider CU-SeeMe as a good example of responsible bandwidth use?

> I don't see the difference; I buy bandwidth at the free-market price. It

No, you don't.

> sounds like you're not distributing your costs across your users. I must
> admit I don't understand how things are done "over there". Pray educate
> me.

Most people pay flat rate or per minute charge; only in few cases is
an outright volume charge applied (tastes vary). But either way, it
doesn't make any difference. Here's why (grossly simplified):

80-200kbit 9.6-28.8k
Source ->---------->- terminal server ->-------->- Destination

In the terminal server you have on the order of 80% packet loss.
There is no way the user can be billed for the full international
bandwidth, both technically and contractually. But somebody has
to pay.

On May 3, 18:05, Richard Cogger <> wrote:
> >Q. TCP is bad since it does packet retransmission (if necessary), and
> > why retransmit old data?
> >
> >A. If TCP has to resort to retransmission then it is because the
> > network dropped the packet (or acknowledgement), which means that
> > the net can't support your packet rate at this time. The net
> Correct. However, you should be aware that tcp keeps sending faster and
> faster until a packet is lost. It then retransmits that one, slows down,
> and starts speeding up again, repeating indefinitely as long as there is
> data to send. Since (almost) all tcp's do this, they are all continuously

In general, it doesn't. There may well be some really crummy
implementations that do, but that's a different story (and you
don't find them in UNIX, which is where reflectors tend to run).

In the absence of other constraints, TCP keeps pushing -- it sends
every packet slightly earlier than it "should have done" (but not
earlier than what was the case for the previous packet). It doesn't
carry on increasing the transmission rate until it loses a packet; as
a matter of fact, it doesn't even increase the rate until it starts
receiving acks quicker than before. Likewise for congestion
avoidance: at the onset of congestion packets get queued up in one of
the routers between the source and destination. TCP senses the
increased RTT and slows down. This doesn't mean that the amount of
data transmitted fluctuates, it actually comes out as a very steady
stream, perfectly matched to the available bandwidth.

TCP also slows down (very drastically) if it loses a packet, but
packet loss is not TCPs primary congestion control mechanism. This
is where there is a gross mismatch between the behaviour of
CU-SeeMe/UDP (which uses packet loss as a measure of available
bandwidth) and TCP; and this is why CU-SeeMe outright kills TCP
traffic until it has the bandwidth it wants.

As for the "TCP unsuitable for real time" myth, this is a cranky old
idea that goes back to the days when a PDP-11 was a roaring monster.
The experiments done by Sean Foderaro <jkf@frisky.Franz.COM> (many
thanks) speak for themselves. Considering in particular CU-SeeMe
over modem connections, most people use compression on their modems.
This easily adds 50ms to the RTT, which compares very favourably to
the maybe 1-2ms extra delay if TCP was used insted of UDP.

On May 4, 18:20, <> wrote:
> At 8:13 AM 5/4/95 -0700, Sean Foderaro wrote:
> > I also wanted to gently chastise CU for releasing CU-SeeMe in its
> >current form to the masses. Its default behavior is to be a
> >bandwidth hog. It didn't have to be that way: it could have come up
> >in 'demo' mode (1fps cap) and one could set it higher for
> But, we were not interested in producing a "demo." Nor was it our main
> objective to be "friendly to The Internet." We were interested in

This is sort of outrageous. I'll bet anything that a lot of the
folks at Cornell and on the Net in general are very concerned about
the environment, ozone-layer, pollution, endangered species, you name
it -- ecology. And yet, you quite cheerfully go ahead and ignore
Internet ecology. Why is that?

You also maintain that responsibility lies with the users. That's
fine, but what have you done to educate the users? You're giving
them a loaded gun, with no training, no licence, nothing -- "Here,
just push that button". Except only very few (like Boerre) realize
what actually happens when they do that; in general, they can't see
what they're doing, they can't see the results of their actions.
This is entirely your responsibility.

> When you find something on the net and try to employ it for general
> use, *you* really have to think about using its responsibly. Final
> responsibility lies with the end user. E.g., statistics here consistently
> show that the most popular Usenet groups are devoted to pictures of naked
> people. I would guess that 100's of megabits of that material criss-cross
> the Internet daily. Should the creators of Usenet software be held
> responsible by those who consider this a waste of bandwidth? Should they
> have withheld distribution of the software pending development of features
> to automatically detect and delete such material when bandwidth was
> limited?

This comparison is completely bogus. The bandwidth consumed by the
binary groups is on the order of 15kbits for a full feed; ie, less
than 20% of the default bandwidth for a single CU-SeeMe user.
Moreover, news is transported using TCP.

> Finally, the only way we are going to see increases in bandwidth
> capacity is if we use what's there. This is a bit of a simplification, but
> the folks that own the fiber plant just want to get there $100,000/month.
> If they think we'll use 1 Mbit, they'll charge $100,000/Mbit....if they
> think we'll use 100 Mbit, they'll charge $1000/Mbit. In the era of fiber

There's a fair amount of truth in this but it doesn't solve
anything. Prices may come down as much as they want, long-haul
international bandwidth will always be much more expensive than local
bandwidth. So if people who develop applications base their design
on the cost of local bandwidth, we're back to square one. And this
is not in the interest of the global Internet.

===    ___                        === Per G. Bilse, Sr. Network Engineer
===   /     /  /   __   ___  _/_  === EUnet Communications Services B.V.
===  /---  /  /  /  /  /__/  /    === Singel 540, 1017 AZ Amsterdam, Holland
=== /___  /__/  /  /  /__   /     === tel: +31 20 6233803, fax: +31 20 6224657
===                               === 24hr emergency number: +31 20 592 5165
=== Connecting Europe since 1982  ===; e-mail: