 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> All of the other *computer* network systems were designed for small
>> networks. Sheesh...
>
> Uh, no. Really, not. X.25. ATM. ISDN. SONET. They're all world-wide
> networks-of-networks, just like IP. Indeed, IP runs over top of all
> these networks once you get outside your own building. (Granted, X.25 is
> probably not much used any more, but it was basically what IP wound up
> replacing, and again was the substrate carrier for a lot of IP data
> before SONET got cheap enough to dedicate a fiber to something as
> trickling slow as IP traffic.)
Interesting. Because from what I've seen, all the earlier technologies
allow you to connect together maybe a few dozen nodes, and then stop
working after you try to scale much beyond that. They all use their own
perculiar addressing scheme, and there's no way of referring to a node
that isn't on the local network.
To me, it seems that the major contribution of IP is that it gives you
an addressing system which is independent of the underlying transport
technology, and has routable addresses (and definite rules for how to
use them). I haven't seen anything else that does that.
Oh, and then people whine that it doesn't map cleanly to the ISO/OSI
7-layer model. Oh well...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 May 2010 20:37:18 +0100, Orchid XP v8 wrote:
> I haven't seen anything else that does that.
IPX/SPX did that. DECNET, AFAIK, did that.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 May 2010 12:15:13 -0700, Darren New wrote:
> Jim Henderson wrote:
>> What do you mean by "2-way broadcast"?
>
> Well, FM radio would be a one-way broadcast. Coax ethernet would be a
> two-way broadcast.
OIC what you're saying, that the filtering is applied by the receiving
end (either filtered by software or hardware).
>> Yes, but from a standpoint of multicast, there again, you get some
>> savings (and increased scalability). I imagine (but don't know for
>> sure) that cable uses some sort of multicast scheme
>
> Well, look, there really isn't something that's a multicast physical
> layer.
Maybe Sirius radio? Dunno, you might be right on that.
> Either the bandwidth is scaled per user, or it isn't. If we're
> all talking at the same frequency on a coax cable (say like old
> ethernet) and I'm transmiting, it's a broadcast, regardless of the
> destination address.
>
> AFAIK, cable systems run fiber to a box in each neighborhood, and then
> have a tree of cables coming out from there, all carrying the same
> signal.
Would have to find someone who works for a cableco to confirm,
obviously. (Or a good article describing the technology)
>> all people who are watching channel 657 are likely part of a multicast
>> group of some sort,
>
> Sure. And all people watching channel 657 are also receiving channel
> 652. They're just not tuning it. Just like FM radio. (And I was talking
> about IP over cable, actually, not TV per se. :-)
That implies a pretty enormous total bandwidth on the coax cable coming
into your house, then. If you figure 40 SD channels and 40 HD channels,
for example, that several megabits of digital broadcast being sent out to
be filtered.
I was using cable TV as an example because it's data being sent over a
network. Data is data is data is data, after all. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 May 2010 11:58:34 -0700, Darren New wrote:
> Jim Henderson wrote:
>> I was simply pointing out that multicast (in particular) isn't
>> necessarily point-to-point from an IP standpoint.
>
> Sure. And it's not point-to-point from an ISDN or even POTS perspective
> either. Dialing into a conference bridge is the equivalent of putting
> the destination address as the multicast address in IP. It's lower-layer
> technology that actually does the multicasting, not IP itself.
Arguably, it would be a technology - not a protocol - implementation.
>>>>> 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.
>
> The transport layer isn't involved in multicast in IP, per se. Multicast
> transport layer is just UDP. The messages maintaining the spanning three
> modify things in the network layer.
I may need to read more on this.
>> and the network hardware understands which ports to send the multicast
>> data to,
>
> Then it's not broadcast, and the switch is duplicating the data once for
> each subscriber. That's what I'm saying. *If* there's any bandwidth
> savings (i.e., more than one NIC reads the same packet), it's because
> every NIC in the broadcast area is reading the same packet and some of
> them are throwing it away.
But that isn't the case, necessarily. The switch is allowing the packet
to get to those subscribers who've requested it. Whether that's
duplication or filtering is really just semantics.
>>> 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).
>
> It's duplicating it for each outward link the packet goes over. If you
> have a router with someone upstream sending a multicast session and
> three routers downstream receiving it, how much bandwidth, total, is
> that taking up?
That depends on a lot of different factors. If there's 10 stations at
the far end of the third router hop, the amount of bandwidth between
routers is still a constant 1:1; the initial sender isn't sending the
data 10 times, it's sending it once - and that doesn't matter if there's
10 targets at the end of the 3rd router, or 10 at the end of router 3, 50
between router 2&3, and 100 between router 1&2.
>>>> 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. ;-)
>
> I'm pretty sure IP says nothing about how you implement copying a packet
> from one NIC to another. :-)
That's because the switch provides the implementation details; the
protocol doesn't implement itself.
>> Yes, physical layer (or network layer), not transport layer. It feels
>> like you're conflating the two.
>
> No. I'm pointing out that talking about the bandwidth savings, or "point
> to point" ness of IP implicitly is talking about the network and
> physical layers. Multicast *is* point to point, *unless* you're on a
> physical broadcast network. Multicast is point-to-point between any two
> elements of the network where there's a non-broadcast cable between
> them.
I think that made sense to me.
>>> 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.
>
> Yes. And 858-102-1137 is a single multicast address that hosts a
> conference bridge. Is that not 1:many, if many phones call into that
> address?
It is, sure. Each phone is a "subscriber" to the bridge. The "data"
isn't sent to phones that aren't subscribers.
>> There again, though, mixing up physical/network layer with transport
>> layer.
>
> Only because I'm trying to understand in what possible sense IP is
> 1:many and ISDN isn't. Sure, if a conference bridge is 1:many then so is
> an IP multicast. But I don't think you can say an IP multicast is 1:many
> and an ISDN conference bridge is 1:1, because it's doing the identical
> thing in the identical way.
I don't think I was saying that. I haven't commented on ISDN, only on IP
multicast.
>>> 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.
>
> I said CDMA, not CSMA. I'm not sure what DSS is here, but in CDMA
> everyone talks at the same time, and in GSM (afaik) nobody talks at the
> same time, so there's no interference (of the type we're talking about)
> in either one.
Oh, right, I missed that (I'm used to talking strictly in terms of CSMA).
>> 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).
>
> If you're on a broadcast network, you have no choice but to receive it.
True, because you see everything, addressed to your or not. That's why
hubs are used for sniffing, generally.
> If you're on a network where each connection is 1:1, then it's the same
> as an ISDN conference bridge.
I think that's a matter of semantics.
>>> 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.
>
> I don't think so...
In which case the discussion has been an 'evolution'. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Mon, 17 May 2010 12:15:13 -0700, Darren New wrote:
>
>> Jim Henderson wrote:
>>> What do you mean by "2-way broadcast"?
>> Well, FM radio would be a one-way broadcast. Coax ethernet would be a
>> two-way broadcast.
>
> OIC what you're saying, that the filtering is applied by the receiving
> end (either filtered by software or hardware).
Right.
>> Well, look, there really isn't something that's a multicast physical
>> layer.
>
> Maybe Sirius radio? Dunno, you might be right on that.
Different frequencies, sure. I'd more likely call that lots of independent
networks.
> Would have to find someone who works for a cableco to confirm,
> obviously. (Or a good article describing the technology)
Yeah.
>>> all people who are watching channel 657 are likely part of a multicast
>>> group of some sort,
>> Sure. And all people watching channel 657 are also receiving channel
>> 652. They're just not tuning it. Just like FM radio. (And I was talking
>> about IP over cable, actually, not TV per se. :-)
>
> That implies a pretty enormous total bandwidth on the coax cable coming
> into your house, then. If you figure 40 SD channels and 40 HD channels,
> for example, that several megabits of digital broadcast being sent out to
> be filtered.
Yep. A cable can carry huge amounts of data, depending on its length. The
closer the fiber hubs out to the houses, the more channels you can carry.
> I was using cable TV as an example because it's data being sent over a
> network. Data is data is data is data, after all. :-)
Exactly.
--
Darren New, San Diego CA, USA (PST)
Ada - the programming language trying to avoid
you literally shooting yourself in the foot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Fri, 14 May 2010 15:36:09 -0700, Darren New wrote:
>
>> Jim Henderson wrote:
>>> Depends on how the router implements forwarding for multicast
>> Or, to phrase it differently, multicast is somewhat more point-to-point
>> than a telephone party line is.
>
> Not really, a party line is many-to-many, but multicast is one-to-many.
Nope. If you're on a party line and I'm not, and I call you, I have one
person on my end and you have every party on your end. Exactly like going
thru a router with one connection that's CAT5 and the other connection
that's coax ethernet. If you connect two party lines thru the switch, then
anyone on either side can hear everyone, just like having a switch with two
ports and a broadcast network on each side.
--
Darren New, San Diego CA, USA (PST)
Ada - the programming language trying to avoid
you literally shooting yourself in the foot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Interesting. Because from what I've seen, all the earlier technologies
> allow you to connect together maybe a few dozen nodes, and then stop
> working after you try to scale much beyond that.
Um, you *are* aware that we had a global telephone network *before* we had
computers, right?
> They all use their own
> perculiar addressing scheme, and there's no way of referring to a node
> that isn't on the local network.
Tell me. When you (or your boss) needs to talk to someone in America, how
do they do it? What steps do they follow?
> To me, it seems that the major contribution of IP is that it gives you
> an addressing system which is independent of the underlying transport
> technology, and has routable addresses (and definite rules for how to
> use them). I haven't seen anything else that does that.
You ... haven't picked up a phone lately?
> Oh, and then people whine that it doesn't map cleanly to the ISO/OSI
> 7-layer model. Oh well...
Exactly. It doesn't map cleanly to the global network that was already
around for decades before IP was even conceived. It is difficult to manage
and debug and route compared to the world-wide telephone network everyone
takes for granted. And they're running out of addresses (actually, probably
already ran out of addresses) long before every person has an address, let
alone every piece of communications equipment.
--
Darren New, San Diego CA, USA (PST)
Ada - the programming language trying to avoid
you literally shooting yourself in the foot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> Arguably, it would be a technology - not a protocol - implementation.
Yeah, basically.
> I may need to read more on this.
Yep. There's (IIRC) ICMP messages to control the routing (via expressing
interest), and just UDP with multicast destination addresses to deliver the
data.
> But that isn't the case, necessarily. The switch is allowing the packet
> to get to those subscribers who've requested it. Whether that's
> duplication or filtering is really just semantics.
Sure. As is "1:1" vs "1:many" when every pair of receivers had an
independent connection, which was my point. :-)
> That depends on a lot of different factors. If there's 10 stations at
> the far end of the third router hop, the amount of bandwidth between
> routers is still a constant 1:1;
Yep. And if there's 10 people on the conference call, my phone is only
sending my voice once. I completely agree with you. I'm simply stating that
ISDN and all those other network technologies work the same way, so IP
multicast isn't a distinguishing feature.
>>>> True, but now we're talking about something far below the level of IP.
>>> Not in a Layer3 switch we're not. ;-)
>> I'm pretty sure IP says nothing about how you implement copying a packet
>> from one NIC to another. :-)
>
> That's because the switch provides the implementation details; the
> protocol doesn't implement itself.
Hmmm. You seem to be disagreeing with yourself. Unless you were joking and
saying a layer 3 switch is only a little below IP and not far below.
> I think that made sense to me.
That's all I've been trying to express. IP multicast is equivalent to ISDN
conference bridge, where the bridge serves as the router doing the routing
to multiple outgoing segments.
>>> 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.
>> Yes. And 858-102-1137 is a single multicast address that hosts a
>> conference bridge. Is that not 1:many, if many phones call into that
>> address?
>
> It is, sure. Each phone is a "subscriber" to the bridge. The "data"
> isn't sent to phones that aren't subscribers.
OK. That was what I was trying to express. Saying IP multicast is 1:many and
ISDN conference bridge isn't is not a reasonable comparison.
> I don't think I was saying that. I haven't commented on ISDN, only on IP
> multicast.
Fair enough. That's where this came up, and why I'm talking about layers
below IP. Otherwise, I think we both understand how IP handles multicast.
>>> 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).
>> If you're on a broadcast network, you have no choice but to receive it.
>
> True, because you see everything, addressed to your or not. That's why
> hubs are used for sniffing, generally.
Exactly my point. That's why I said multicast in that case doesn't "save"
bandwidth.
>>> Well, quite possibly, unless he was talking about multicast as a
>>> reason.
>> I don't think so...
>
> In which case the discussion has been an 'evolution'. ;-)
From his other message, I think he doesn't realize that an ISDN connection
has an address at all, or something.
--
Darren New, San Diego CA, USA (PST)
Ada - the programming language trying to avoid
you literally shooting yourself in the foot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 May 2010 14:55:37 -0700, Darren New wrote:
> If you're on a party line and I'm not, and I call you
Then you get a busy signal. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 May 2010 15:05:04 -0700, Darren New wrote:
> Exactly my point. That's why I said multicast in that case doesn't
> "save" bandwidth.
Bottom line, we're both in violent agreement again without realising
it. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
