On Fri, Jun 21, 2013 at 8:28 AM, Juliusz Chroboczek <
[email protected]> wrote:

> > if it turns out to be multicast specific it could go in 3.5.1.
> > if there are more general issues to consider then perhaps a new
> sub-section?
>
> No, I think it's more general.  What about something like the following:
>
>   Homenets tend to grow organically over many years, and a homenet
>   will typically be built over link-layer technologies from different
>   generations.  Current homenets typically use links ranging from
>   1Mbit/s up to 1Gbit/s, which is a three orders of magnitude speed
>   discrepancy.  We expect this discrepancy to get worse as both
>   high-speed and low-power technogies are deployed.
>
>   Homenet protocols should be designed to deal well with
>   interconnecting links of very different speeds.  In particular,
>   flows local to a link should not be flooded throughout the homenet,
>   even when sent over multicast, and, whenever possible, the homenet
>   protocols should be able to choose the faster links and avoid the
>   slower ones.
>
> If you wish, I can add a sentence saying "This implies that a link-state
> protocol must be used in the homenet" ;-)
>

I'll stay out of the routing discussion....

But I'd like to point out that the problems we're already facing are not
just multicast, as Dave Taht has educated me recently  The scarcest
resource can often now be "transmit-opportunities", or txopts; certainly
this is true for WiFi (you get around 1000/second, and that's it...).

So anything that causes packets to require their own txopt for
transmission makes them very expensive.  So, for example, whether it is
even wise to use the hardware priority queues WiFi nominally has (even if
they work correctly) at all is questionable; under a loaded network,
bundling your voip traffic into the first available transmit opportunity
along with other traffic you have queued is clearly better than having to
burn an extra txopt to use the "feature" of the hardware queue, if no
further delay will be incurred by doing so.

Multicast is evil not only due to its inefficient use of the available
bandwidth, but because it forces use of a separate txopt for transmission.

The real point is we have several technological drivers toward wanting to
avoid the network being "chatty", and liking protocols that allow for
aggregation of packets when transmissions do occur.

I'm not sure I can easily express this in RFCese, however.
                                              - Jim


> -- Juliusz
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet
>
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to