Hi, This is the first of a series of related posts. I figured it best to make sure the groundwork is in place, first... On any *wired* network (save the wireless complications for later) using a star *physical* topology beyond 10BaseT, there is a potential for multicast packets to NOT arrive at all nodes coincidentally (i.e., ignoring "speed of light" propagation down the wire). Presumably, switches enqueue incoming multicast packets on *all* outbound ports. Since there is no way of knowing what's already queued on a particular port, the storage time in the switch can vary from port to port. Also, the switch can't know a priori if multicast traffic might *originate* on all ports simultaneously. (Consider this in light of the previous assertion). So, first question: how do switches handle incoming multicast traffic (in terms of a real algorithm, not just an approximate "hand waving" explanation)? This then clears the way for the second question: how to determine the maximum latency presented by a switch? And, the third question: how is the above mentioned pathological case handled (i.e., you can create more traffic than you have bandwidth to process!)? Or, do switch vendors avoid this with arbitrary restrictions on their application? (e.g., akin to segmented hubs in days gone by) I could see how a switch could conceivably monitor IGMP traffic to "eavesdrop" on the virtual connections desired. But, IGMP is only required when routers come into play (or is this a misunderstanding on my part?). [I should just set up a few multicast hosts and watch where the bytes go... :-/ ]
Multicasting and Switches
Started by ●November 8, 2010
Reply by ●November 8, 20102010-11-08
D Yuniskis wrote:> Presumably, switches enqueue incoming multicast packets > on *all* outbound ports.I'm not sure, but I believe that some switches can snoop on IGMP so they know where to send multicast traffic, and so minimize broadcasts. Sorry I can't point you at a reference though.> So, first question: how do switches handle incoming > multicast traffic (in terms of a real algorithm, not > just an approximate "hand waving" explanation)?Same way they handle all traffic; buffer it if possible, drop it if not.> This then clears the way for the second question: how > to determine the maximum latency presented by a switch?That would depend on the buffer size, but typically that's not very big.> And, the third question: how is the above mentioned > pathological case handled (i.e., you can create more > traffic than you have bandwidth to process!)?Drop packets. If you google for reliable multicast protocols, as I did when I studied this stuff several years ago, you'll get a lot more insight into the hardware behaviours that must be handled by the software protocols. Ack-fan-in is a big problem, replacing the fan-out problem of point-to-point connections. Clifford Heath.
Reply by ●November 8, 20102010-11-08
D Yuniskis wrote:> Hi, > > This is the first of a series of related posts. > I figured it best to make sure the groundwork is in > place, first... > > On any *wired* network (save the wireless complications > for later) using a star *physical* topology beyond > 10BaseT, there is a potential for multicast packets > to NOT arrive at all nodes coincidentally (i.e., > ignoring "speed of light" propagation down the wire).By a star topology, I assume you mean one and only one switch. Correct?> Presumably, switches enqueue incoming multicast packets > on *all* outbound ports. Since there is no way of knowing > what's already queued on a particular port, the storage > time in the switch can vary from port to port. > > Also, the switch can't know a priori if multicast traffic > might *originate* on all ports simultaneously. (Consider > this in light of the previous assertion). > > So, first question: how do switches handle incoming > multicast traffic (in terms of a real algorithm, not > just an approximate "hand waving" explanation)?Ask the switch vendor. How would you expect anyone in this group to have anything but a educated guess for that question?> This then clears the way for the second question: how > to determine the maximum latency presented by a switch?Falling back to the educated guess disclaimer, I'd say the maximum latency is indeterminate. It seems that by definition, that if the multicast packet collides with another packet, the latency will be indeterminate. Presumably you will argue that this is a purpose- built network and the possibility of a collision is small to non-existent. I would reply that in addition to coordinating the host and client stacks and packets to avoid collisions, you also have to consider that the switch might be sending spanning tree packets at unknown intervals.> And, the third question: how is the above mentioned > pathological case handled (i.e., you can create more > traffic than you have bandwidth to process!)? > > Or, do switch vendors avoid this with arbitrary > restrictions on their application? (e.g., akin to > segmented hubs in days gone by) > > I could see how a switch could conceivably monitor > IGMP traffic to "eavesdrop" on the virtual connections > desired. But, IGMP is only required when routers > come into play (or is this a misunderstanding on my part?). > > [I should just set up a few multicast hosts and watch > where the bytes go... :-/ ]
Reply by ●November 8, 20102010-11-08
On Mon, 08 Nov 2010 14:35:07 -0700, D Yuniskis <not.going.to.be@seen.com> wrote:>Hi, > >This is the first of a series of related posts. >I figured it best to make sure the groundwork is in >place, first... > >On any *wired* network (save the wireless complications >for later) using a star *physical* topology beyond >10BaseT, there is a potential for multicast packets >to NOT arrive at all nodes coincidentally (i.e., >ignoring "speed of light" propagation down the wire). > >Presumably, switches enqueue incoming multicast packets >on *all* outbound ports. Since there is no way of knowing >what's already queued on a particular port, the storage >time in the switch can vary from port to port.Use a dumb hub. For exactly those reasons, some industrial ethernet protocols require that hubs (not switches) are used. Expect to pay a lot for a primitive hub due to "industrial" and possibly some certification markings :-).
Reply by ●November 9, 20102010-11-09
Hi Clifford, Clifford Heath wrote:> D Yuniskis wrote: >> Presumably, switches enqueue incoming multicast packets >> on *all* outbound ports. > > I'm not sure, but I believe that some switches can snoop > on IGMP so they know where to send multicast traffic, > and so minimize broadcasts.But I don't (?) need to support IGMP if I am not trying to route the multicasts. I.e., a switch should (?) be able to handle multicast traffic on a single LAN segment.> Sorry I can't point you at a reference though. > >> So, first question: how do switches handle incoming >> multicast traffic (in terms of a real algorithm, not >> just an approximate "hand waving" explanation)? > > Same way they handle all traffic; buffer it if possible, > drop it if not.But, does the switch *effectively* treat the multicast packet AS IF it was a unicast packet *destined* for the host(s) serviced by this port? In one conceptual model, the packet is *copied* to each destination port; in another conceptual model, the packet is "cached" and "a flag set" in each port telling each destination port "pass the cached multicast packet, also" (when all flags have been cleared, the multicast packet has been effectively copied to each port; etc. Note that the details of how the packet is handled influence how multiple packets are handled as well as the maximum throughput (even with "few" destination ports) for the multicast traffic (e.g., a "cached" implementation would affect *all* multicast streams going through the switch)>> This then clears the way for the second question: how >> to determine the maximum latency presented by a switch? > > That would depend on the buffer size, but typically that's > not very big. > >> And, the third question: how is the above mentioned >> pathological case handled (i.e., you can create more >> traffic than you have bandwidth to process!)? > > Drop packets.Of course -- no free lunch. But, does the switch do so "fairly" or with some bias (towards or against the multicast traffic)?> If you google for reliable multicast protocols, as I did > when I studied this stuff several years ago, you'll get a > lot more insight into the hardware behaviours that must > be handled by the software protocols. Ack-fan-in is a big > problem, replacing the fan-out problem of point-to-point > connections.Cisco has some detailed information on their switches. But, I was hoping for some more general conclusions that would apply to *all* product offerings. E.g., if you drag your mind along the evolution of the technology, you can see multicast traffic was originally limited by the bandwidth of the cable segment. E.g., one multicast host could conceivably generate every packet the wire was capable of carrying. Now you introduce a hub (10BaseT). The same limitation applies -- one host could still use all of the bandwidth. Two hosts could split/share it, etc. Once you introduce switches, packet amplification becomes a problem. I.e., the very same attribute of the switch that makes it so attractive (vs. a hub) -- getting something for nothing -- comes back to bite you when you multicast. I was hoping some standards "task force" or "working group" would have codified the minimum behavior to be expected of a switch... i.e., can a switch NOT pass multicast traffic AT ALL and still be called a switch?
Reply by ●November 9, 20102010-11-09
Hi Jim, Jim Stewart wrote:> D Yuniskis wrote: > >> On any *wired* network (save the wireless complications >> for later) using a star *physical* topology beyond >> 10BaseT, there is a potential for multicast packets >> to NOT arrive at all nodes coincidentally (i.e., >> ignoring "speed of light" propagation down the wire). > > By a star topology, I assume you mean one and only > one switch. Correct?No, I meant "not a physical BUS" (multicasting on a physical bus is a lot easier to characterize).>> Presumably, switches enqueue incoming multicast packets >> on *all* outbound ports. Since there is no way of knowing >> what's already queued on a particular port, the storage >> time in the switch can vary from port to port. >> >> Also, the switch can't know a priori if multicast traffic >> might *originate* on all ports simultaneously. (Consider >> this in light of the previous assertion). >> >> So, first question: how do switches handle incoming >> multicast traffic (in terms of a real algorithm, not >> just an approximate "hand waving" explanation)? > > Ask the switch vendor. How would you expect > anyone in this group to have anything but a > educated guess for that question?Because I assume *I* am not the only person designing products that employ multicasting. I am assuming/hoping that others may have gone down this road before (why do people ask specific questions about MCU's here instead of "asking the MCU vendor"?). This seems especially true given the move towards "whatever-over-IP" implementations (e.g., where are the folks designing the AVB products -- in alt.knitting?)>> This then clears the way for the second question: how >> to determine the maximum latency presented by a switch? > > Falling back to the educated guess disclaimer, > I'd say the maximum latency is indeterminate. > > It seems that by definition, that if the multicast > packet collides with another packet, the latency > will be indeterminate.That depends on the buffering in the switch. And, how the multicast packet is treated *by* the switch.> Presumably you will argue that this is a purpose- > built network and the possibility of a collision > is small to non-existent. I would reply that in > addition to coordinating the host and client stacks > and packets to avoid collisions, you also have to > consider that the switch might be sending spanning > tree packets at unknown intervals.No, I'm wanting to know how *you* and your *neighbor* and your *friends* are going to be deploying network fabric in your house in the next 5-10 years to handle the shift to the X-over-IP distribution systems that are in the pipeline TODAY. Will you have to buy new "AV" switches? Will those switches take pride in advertising themselves: "New and improved! Now supports *3* multicast streams!!" Or, will folks just be complaining that their video spontaneously pixelates, etc.? Or, will you have to design the network fabric into the house at the time of construction (retrofit being impossible), etc.>> And, the third question: how is the above mentioned >> pathological case handled (i.e., you can create more >> traffic than you have bandwidth to process!)? >> >> Or, do switch vendors avoid this with arbitrary >> restrictions on their application? (e.g., akin to >> segmented hubs in days gone by) >> >> I could see how a switch could conceivably monitor >> IGMP traffic to "eavesdrop" on the virtual connections >> desired. But, IGMP is only required when routers >> come into play (or is this a misunderstanding on my part?). >> >> [I should just set up a few multicast hosts and watch >> where the bytes go... :-/ ]
Reply by ●November 9, 20102010-11-09
Hi Paul, Paul Keinanen wrote:> On Mon, 08 Nov 2010 14:35:07 -0700, D Yuniskis > <not.going.to.be@seen.com> wrote: > >> On any *wired* network (save the wireless complications >> for later) using a star *physical* topology beyond >> 10BaseT, there is a potential for multicast packets >> to NOT arrive at all nodes coincidentally (i.e., >> ignoring "speed of light" propagation down the wire). >> >> Presumably, switches enqueue incoming multicast packets >> on *all* outbound ports. Since there is no way of knowing >> what's already queued on a particular port, the storage >> time in the switch can vary from port to port. > > Use a dumb hub.Ha! I guess that's a solution! Do they make GB hubs? It seems like this problem will only be getting more significant in the coming years... especially in the SOHO market. Perhaps this suggests running *two* networks -- one that uses hubs ("bus" topology) that is friendly to multicast traffic and the other using switches for unicast traffic?> For exactly those reasons, some industrial ethernet protocols require > that hubs (not switches) are used. > > Expect to pay a lot for a primitive hub due to "industrial" and > possibly some certification markings :-).
Reply by ●November 9, 20102010-11-09
On Nov 9, 9:41=A0pm, D Yuniskis <not.going.to...@seen.com> wrote:> Hi Paul, > > > > Paul Keinanen wrote: > > On Mon, 08 Nov 2010 14:35:07 -0700, D Yuniskis > > <not.going.to...@seen.com> wrote: > > >> On any *wired* network (save the wireless complications > >> for later) using a star *physical* topology beyond > >> 10BaseT, there is a potential for multicast packets > >> to NOT arrive at all nodes coincidentally (i.e., > >> ignoring "speed of light" propagation down the wire). > > >> Presumably, switches enqueue incoming multicast packets > >> on *all* outbound ports. =A0Since there is no way of knowing > >> what's already queued on a particular port, the storage > >> time in the switch can vary from port to port. > > > Use a dumb hub. > > Ha! =A0I guess that's a solution! =A0Do they make GB hubs? > It seems like this problem will only be getting more > significant in the coming years... especially in the > SOHO market. > > Perhaps this suggests running *two* networks -- one > that uses hubs ("bus" topology) that is friendly to > multicast traffic and the other using switches for > unicast traffic? > > > For exactly those reasons, some industrial ethernet protocols require > > that hubs (not switches) are used. > > > Expect to pay a lot for a primitive hub due to "industrial" and > > possibly some certification markings :-). > >I have only seen dumb hubs up to 10 MbpS, it would be quite a piece of hardware to do the hub work at 100MbpS+ without buffering/ transmitting. But then I have not been looking for such a thing. Yet I believe you are looking into a non-issue. The switches (I have dealt in more detail with only one chip, though) broadcast all data to all ports until they can identify the destination MAC address - which they do when that MAC address sends something. And since I don't think any data will be sent with a multicast source address, the multicast data will be always just broadcast (I assume). OTOH, if you want to route it some particular way, sending a packet from a "multicast" source address may do the job and the switch will likely route everything to that port (everything to that multicast address, that is). The switch chip I have been dealing with does not have the word "multicast" at all in its datasheet/manual, so I guess it treats multicast addresses like any other non-broadcast address. If this guess is wrong, all of the above is also probably wrong :-). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Reply by ●November 9, 20102010-11-09
Forgot to mention that in my previous post, the switch chip that I know has a "broadcast storm protection" facility. Just drops packets above certain count IIRC. Dimiter
Reply by ●November 9, 20102010-11-09
D Yuniskis wrote:> Hi Jim, > > Jim Stewart wrote: >> D Yuniskis wrote:> No, I'm wanting to know how *you* and your *neighbor* > and your *friends* are going to be deploying network fabric > in your house in the next 5-10 years to handle the shift > to the X-over-IP distribution systems that are in the > pipeline TODAY. Will you have to buy new "AV" switches? > Will those switches take pride in advertising themselves: > "New and improved! Now supports *3* multicast streams!!" > Or, will folks just be complaining that their video > spontaneously pixelates, etc.?Now we are getting somewhere. I happen to have ATT U-verse in my house, running 3 SD video streams and 3mbit internet. It is running quite happily over the existing 10/100 ethernet installation using generic netgear switches. Of the 3 ATT "cable boxes", 2 are at least 2 switches downstream from the U-verse router. Note that I do have 3 concurrent video streams running 24-7. Normally the ATT settop box times out and drops the stream if the channel doesn't change in 4 or so hours. Since we use Tivos downstream of the settop boxes, I had to program each tivo to switch channels periodically so that the stream wouldn't drop and the Tivo wouldn't record the "Press OK" screen the settop box puts up when the stream drops. BTW, U-verse also has the option of running its digital link over existing 75 ohm antenna coax. I haven't tried it. Haven't seen any spontaneous pixelations. There's other occasional digital weirdness, but not so much as I saw coming in on Comcast analog cable, presumably from their headend issues.