On Mon, 17 May 2010 10:07:52 -0700, Darren New wrote:

> Jim Henderson wrote:
>> On Sat, 15 May 2010 13:02:58 -0700, Darren New wrote:
>> 
>>> Jim Henderson wrote:
>>>>> If you have one cable coming into the university campus, and a
>>>>> network for each building, the router is going to have to send the
>>>>> packets to each building, duplicating the packets, regardless of how
>>>>> "aware" anyone is.
>>>> Yes, but that's not a 1:1 transmission (compared to the receiving
>>>> clients).
>>> I don't know what you mean.
>> 
>> It's not one sender to one receiver.  It's one sender to many
>> receivers.
> 
> Right. The question isn't how many senders and receivers there are. The
> question is whether you're duplicating packets.

Yes, and you would duplicate packets when repeating to a different 
subnet, sure.  That doesn't mean the bandwidth savings disappear when you 
introduce a router to the picture.

>>> For one thing, modern ethernet (the kind that goes over CAT5 instead
>>> of coax) is indeed 1:1 on every part of the network. Nothing I send
>>> from my computer to yours does not go through the router.
>> 
>> Not necessarily true if it's a local subnet.
> 
> Uh, yes. There's nothing that's going to go over this cat5 wire that
> doesn't go to the other end of the wire. If your PC is plugged into your
> router/switch, and your other PC is plugged into your router/switch,
> then talking between the PCs goes thru the router/switch.

Yes, true.

> The only difference would be if you have (a) only two PCs on the
> network, at which point multicast is irrelevant, or (b) you have a hub,
> at which point the hub is still duplicating packets for every wire,
> except it's doing it indiscriminately.

True in both cases.

>> But even if it is across
>> routers, so what?  The router is just setting up a multicast domain for
>> the downstream network, which may include another router that does the
>> same thing.
> 
> I think at this point you may have forgotten why we're discussing this.

Perhaps, or perhaps the discussion mutated. :-)

> The contention was that things like ATM and ISDN are "point to point"
> while IP somehow isn't. My contention is that any network physically
> wired anything close to what ATM and ISDN does is also point to point,
> and that most IP networks other than wireless are of the same sort of
> topology as ATM and ISDN. (And maybe wireless, too. I don't know enough
> to know whether one node can send to the other without the AP repeating
> it.)

I was simply pointing out that multicast (in particular) isn't 
necessarily point-to-point from an IP standpoint.  I think you may be 
talking at a lower level in the OSI stack than IP that it is, and I 
couldn't disagree with that, certainly.

>>> You need to duplicate the packets at least once per physical wire.
>>> Same as any network. IP doesn't force you to duplicate anything less.
>> 
>> True.
> 
> That's my point. IP is still point-to-point, by necessity, when you
> don't have a broadcast network.

This is where I think you're talking at the physical or network layer, 
not the transport layer.

> When you *do* have a broadcast network, unless you do something really
> funky (unlike, say, coax ethernet), all the nodes can be conceptually
> treated as one node, because they can't talk at the same time, they all
> see the same data, they don't get all the bandwidth to themselves, etc.
> And that hasn't anything to do with IP. IP multicast doesn't route
> packets to a specific machine. It routes them to a specific broadcast
> subnet, if there is one. If I'm on a segment with someone receiving
> multicast, I have no way *not* to receive that, and it can saturate my
> bandwidth even tho I'm uninterested.

That's not how multicast works, to my understanding.  You subscribe to 
the multicast - unless the switch (a) isn't a switch, or (b) isn't 
multicast aware, you're right; but if you are on a segment with someone 
who receives a multicast and the network hardware understands which ports 
to send the multicast data to, then no, you don't see the packets because 
you're not subscribed to the multicast.

> When I'm on a conference call via ISDN, I'm only sending one copy of
> each byte. I'm not the one doing the duplication. 

Right.

> The ISDN router (known
> as the conference bridge) is doing the duplication, just like in IP.

Depends on whether you're talking unicast to *each* destination node or 
multicast IP.  Therein lies the difference (and the bandwidth savings).  
In a multicast scenario, at the transport layer, the switch isn't 
"duplicating" the packet, it's forwarding it (which may be a semantic 
debate).

>> the switches also typically have logic so they don't have to fill their
>> buffers with multiple copies of the same data (for those that have a
>> buffer).
> 
> True, but now we're talking about something far below the level of IP.

Not in a Layer3 switch we're not. ;-)

>>> Firstly, if your subnet isn't broadcast, it doesn't save you any
>>> bandwidth. The router still needs to duplicate all the packets. If
>>> your subnet *does* support broadcast (like coax ethernet, or alohanet,
>>> or something like that) then sure, you can broadcast to everyone, but
>>> that's because *any* transmission goes to everyone, taking up your
>>> bandwidth even if it's not addressed to you.
>> 
>> I think there may be a conflation of "broadcast" and "multicast" here.
> 
> Nope. I'm saying there are two physical networking possibilities:
> broadcast, and unicast. Either everyone gets the signal on a broadcast
> network, or only one person gets the signal on a unicast network.  Coax
> ethernet is broadcast. CAT5 ethernet is unicast.

Yes, physical layer (or network layer), not transport layer.  It feels 
like you're conflating the two.

> The only place that multicast saves bandwidth is on a unicast network
> (like between routers) where nobody downstream of the receiver wants to
> receive the data. If you have a separate wire to each PC with bandwidth
> dedicated to that PC, multicast is 1:1 on any given segment of the
> network.

The destination "1" is a single multicast address that the specific 
targets subscribe to - that's what makes it not 1:1, but 1:many.

>>> Broadcast networks tend to be very small, and they tend to not allow
>>> two conversations at once. You're not saving bandwidth by
>>> broadcasting. You're just using it more efficiently. A targeted
>>> communication on a broadcast network still takes up everyone's
>>> bandwidth. They just ignore it. Multicast on a broadcast network isn't
>>> saving bandwidth as much as it's not wasting bandwidth.
>> 
>> Small relative to the size of the Internet, sure.  Small relative to
>> the size of a given network, maybe not so much.
>> 
>> That last sentence is just semantics, though.
> 
> By that I mean that multicast on a broadcast network doesn't needlessly
> send the same packet multiple times. But neither does something like ATM
> or ISDN.

There again, though, mixing up physical/network layer with transport 
layer.

>>> Wireless is about the only common broadcast IP-based network still
>>> around, tho, exactly because it's so bandwidth-inefficient and
>>> impossible to squelch when something goes wrong.
>> 
>> I assume you're talking about 802.11 networks;
> 
> Yes, the kind that carry IP via broadcast. Something like IP over CDMA
> or GSM is much closer to having a wired connection than a broadcast
> connection, since nearby nodes aren't listening to you.

Well, if it's DSS then that's true, but otherwise, the other nodes can 
cause interference with you, so if they're doing CSMA-CD, then they are 
listening to you, if only to see if the channel is clear to transmit.

>> some wireless networking
>> technologies implement CSMA-CA while others do CSMA-CD; the latter is
>> much more efficient but requires hardware that is capable of listening;
>> in a spread-spectrum implementation (which most 802.11 networks are),
>> CSMA-CA is more common but the DSS implementations mean that there's
>> much less chance of a collision (that's part of the point of that type
>> of implementation).
> 
> Sure. But if I have a 10Mbps coax, or a 54Mbps 802.11g, I'm sharing that
> with everyone else on that network. If I can hear everything coming out
> of the router and I have to wait for everyone else to stop transmitting
> before I can, then having multicast not transmit duplicates isn't
> "saving" bandwidth. It's taking up my bandwidth whether I'm listening to
> it or not. If I have a 9Mbps stream coming in, my coax ethernet network
> is going to be slow whether I'm watching video or not. What it *does* do
> is not send it twice when everyone interested has already heard it.
> That's what I was talking about.

Not with multicast IP; again, if you don't subscribe to it, you don't 
receive it, at least that's my understanding (http://
www.multicasttech.com/faq/ provides a good explanation).

> However, I strongly suspect that none of this discussion has anything to
> do with whatever Andrew meant when he said IP isn't 1:1 like ISDN is.

Well, quite possibly, unless he was talking about multicast as a reason.

Jim

Post a reply to this message