Re Network Bandwidth

Brian D Williams (talon57@well.com)
Fri, 24 Sep 1999 11:44:18 -0700 (PDT)

From: "Robert J. Bradbury" <bradbury@www.aeiveos.com>

>> There is a third link, the Internet itself, which in a tragedy
>>of the commons situation lacks sufficient bandwidth.

>This is a good point, but in my experience on the net (since
>its inception pretty much), the situation got much better once
>we had high capacity (fiber) intercity lines carrying much of
>the traffic. When everyone jumped on the bandwagon (1995+)
>things got bottlenecked for a while, but people seem to have
>adjusted now to the "continual growth" model and have plans
>in place for increasing the capacity as requried.

Yes things are better, those of us in the trenches build new routers, new ATM facilities, and new SONET bays everyday, and we work alot of overtime..... ;)

I just finished the link between Ameritech and our soon to be new bosses SBC.

>> We use WDM now, there isn't sufficient fiber in ground, or
>> equipment installed, to begin to handle the bandwidth everyones
>> talking about, and the BIG point is that it's currently to
>> expensive to install.

>Well, it depends who is "talking". I think there is a *lot*
>of marketing hype about everyone wanting T1 speeds. If I
>can do a net-meeting or family conf. call on an ADSL line
>then that is fine for my requirements. I've got a satellite
>dish that gets 500+ channels and I don't use it. At one
>point I thought I would use it for downstream datacomm but
>that was before ADSL came along. I believe in general
>surveys show a gradual migration from TV watching to
>net surfing. E-mail messages (low bandwidth) are replacing
>telephone calls (high bandwidth); [Scientific American, pg 112,
>October 1999].

You know your stuff, last year was the first time data traffic exceded telephone traffic on our networks.

>Humans are bandwidth limited, I can't watch 500 channels, I
>can only watch 1 and the compression techniques keep putting
>that channel into smaller bandwidth requirements (MPEG3->MPEG4).
>So, I think the bandwidth problem is overemphasized. However,
>I agree with the "tragedy of the commons" problem, and that seems
>to require a software/hardware solution so all message are not
>treated as being equal. I'm not sure however that it requires
>going so far as to price all content. The people who really
>require the dedicated bandwidth always have the option of buying
>it.

Once again your right on, if e-mail was all we needed we're all set, the problem is people who want to run studio digital video (45MBS) to their friends.....

Oh, and the Internet telephone people........ (ip telephony... on ethernet?) TANSTAAFL.

>> All optical is the way to go, unfortunately no ones willing to
>> build it. (too expensive).

>It looks like fiber to multiplexed low-power GHz radio on the
>telephone poles may get us there.

George Gilder did a piece a few years ago on digital radios, very cool. The only problem with the GHZ radios is getting a standard ( the nice thing about standards? there's so many to choose from... ;) ) and the cost of infrastructure installation (I'm easy but I'm not cheap)

>> Don't confuse pinging trace-routes with bandwidth availability,
>>try running traffic at say T-1 speed 1.536 MBS (framed) and
>>you'll see what I mean...

>For my uses, and most users, I suspect, ping/traceroutes *do*
>tell you where the bottlenecks are, and they *aren't* in the
>backbones.

You are definitely in the upper 1% of users

When I started on the Internet the link to Japan had just been installed.... 9.6K a few months later 56K.

> I would say that this is because the telecommunications
>professionals (Ameritech, MCI, Sprint, etc.) *have* figured out
>how to manage their bandwidth growth requirements, while the
>suppliers and end-users (the non-professionals) for the most part
>have not.

I have the calluses to prove it....

>Almost all of the stuff I do on internet is browsing.
>I don't need T-1 speeds -- humans cannot drink at those speeds
>(going back to the tidal wave analogy). The only people who
>*think* I need those speeds are the people who want to stream me
>video (but I've got a satellite for that!) or who want to throw me
>a megabyte of Java code in 1/10th of a second that makes my
>computer bark like a dog.

Thats why I think ADSL switches are the next step till we go 100% fiber. If you can establish point to point connections, you don't need pentabyte/exabyte backbones.....

>> I can't agree, the inter NAP trunks often run at 100% bandwidth,
>> and everything slows down. There just isn't anywhere near the
>> backbone to support millions of connections running at ADSL
>> bandwidth.

>It depends on whether that bandwidth is continually utilized.
>I probably use 0.0001% of my ADSL total bandwidth. I think that
>would be true for most users (going back to the basic limits we
>have on processing information). What I want is fast page load
>times (the average page takes me much longer to process than
>it does to load). I was actually pretty stunned when I tried
>Netscape's new Gecko browser recently. The page load times
>improved quite dramatically. Though it isn't ready for prime
>time (it took me about 5 minutes to crash it), it does point
>out how better software engineering can significantly improve
>the perception of how slow the net is.

Good points again, the problem is we have to build networks that can take maximum load even if it's only once a year (Mothers day!) We hear about it if anybody's connection is even slightly slow....

Hell, we get thousands of calls that they can't connect at 56K despite the fact the telephone system isn't even tariffed for data , much less than at that rate...

>While the trunks may be heavily loaded, it seems that the growth
>is well managed at this point. Better engineering of the
>upstream and downstream ends is where the emphasis really
>needs to be.

I agree, Bandwidth costs $$$.

Brian

Member, Extropy Institute, www.extropy.org Life Extension Foundation, www.lef.org
National Rifle Association, www.nra.org, 1.800.672.3888 Mars Society, www.marssociety.org
Ameritech Data Center Chicago, IL, Local 134 I.B.E.W