On 8/20/2011 2:45, Orchid XP v8 wrote:
>>> OK. Is that for legacy reasons, or because ATM is actually good at
>>> something?
>>
>> ATM is a lot less legacy than IP is. Yes, of course it's actually good
>> at something.
>
> Well, you know, RS232 is a pretty sucky design. But it's still here. That
> *isn't* because it's good at anything. It's because it's widely implemented,
> i.e. legacy.
>
>>> "Yeah, IP really sucks, except for being really flexible." Yes, because
>>> flexibility is a really sucky thing to have.
>>
>> I didn't say that. I said it sacrifices other things in preference to
>> being flexible. There's no resource allocation. There's no way to force
>> a particular route thru the network (well, there is, but nobody actually
>> implemented it in their switches), the addressing sucks for large
>> networks, the address space (in IPv4 at least) is exceedingly limited,
>> remote management of hardware is extremely limited, there's no access
>> control, admission control, or decent rate regulation other than
>> actually dropping packets, etc etc etc.
>
> Most of this sounds like "IP is sucky for managing network hardware". Well,
> no, that's not what IP is for. It's deliberately hardware-neutral.

Well, yes, that's what I said. IP really sucks, except for being 
hardware-neutral. You didn't seem to understand what I was saying before I 
gave the list of many things IP sucks at.

Oh, and it also sucks at things like bandwidth allocation, sophisticated 
routing, and isochronous connections, so it's not just the management part 
that sucks.

 > The idea
> is that you have some infrastructure for controlling your hardware, and then
> run IP on the top. IP is for moving data from A to B.

IP is for moving data from one port on your network to the next port on your 
network, as long as you don't care how long that takes or how quickly it 
gets there.

There's no reservation, no connection control, no access control, and no 
routing control. Even if the hardware fails, you have no way of determining 
how to route around that failure efficiently and promptly.

> If you asked me what was "sucky" about IP, the one I'd probably pick is that
> the entire design philosophy fundamentally assumes that everybody will
> follow the rules.

That too. But tell me how you tell whether the reason you lost your 
connection is whether the remote machine went down, or just some router in 
the middle is rebooting? Tell me how to ask, in IP, whether there's enough 
bandwidth to carry your 64Kbps conversation in each direction with a maximum 
of 85ms delay in each direction. OK, I'm going to start displaying a digital 
movie from the producer to a theater for the next two hours seven minutes: 
How do I pick a route that guarantees me enough bandwidth that the audience 
doesn't see stutters?

You're looking at the things IP does well, and saying "well, it's a bit 
limited here and there." You're not even looking at the stuff that ATM or 
SONET does that IP is never even asked to do.

>> Heck, it doesn't even do roaming, which cell phones have been managing
>> for 10 years.
>
> Cell phones do that by being controlled by a single central authority.

If they were controlled by a single central authority, you wouldn't need 
roaming agreements, now would you?

>> See above. Every packet has the full source and destination address, and
>> there's no information anywhere about the physical network.
>
> Ooo, 64 bits, bit deal.

Well, yes, when you're transporting voice packets a couple dozen bytes long, 
96+ bits of routing information is indeed a big deal.

> It sounds like you're basically complaining that IP isn't
> connection-oriented.

That's one of its failings, yes.

 > You know, if what you're trying to do isn't
> connection-oriented, that's an advantage, right?

Yep. How much of your networking isn't connection oriented? Here's a hint: 
all networking is connection oriented. IP layers non-connection-oriented 
networking on top of that, and then layers TCP to turn it back into 
connection-oriented, poorly. If IP wasn't connection oriented, you wouldn't 
need routing tables on each machine.

> I'm unfamiliar with the data protocols that enable this to be possible. (I
> was under the impression that everybody runs their voice data over IP now
> anyway, so they only need to maintain one big IP network for their voice
> services *and* their broadband offerings...)

In the last mile, that might be true. I'm fairly sure it isn't IP that's 
running on the undersea fibers or bouncing off satellites.  Know how I know? 
There aren't enough IP addresses.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message