[GRLUG] Two topics...multicast and traffic shaping.

[Michael Mol]

On Tue, Jul 19, 2011 at 7:02 AM, Adam Tauno Williams
<awilliam at whitemice.org> wrote:
> On Tue, 2011-07-12 at 13:57 -0400, Michael Mol wrote:
>> The first is traffic shaping. With my current connection, I don't
>> really face noticeable bandwidth limitations, but it's still something
>> I'd like to get straight.
>> My thought is, the majority of latency-sensitive traffic is going to
>> be on UDP (VOIP, etc),
>
> Define "latency-sensitive".  Multimedia is going to be almost entirely
> UDP [for Voip it will probably be RTP].

Anything requiring rapid human perception or interaction, such as VOIP
or SSH/terminal sessions.

>
>>  or is going to be on TCP with small packets
>> (ssh sessions and the like).
>
> You'll notice latency with these, but latency won't 'break' anything.

True enough, but noticing latency on them, particularly with as much
time as I spend in them, is a significant degradation in quality of
experience.

>> My firewall logs currently show that I'm
>> dropping packets with multicast destination IPs, so I know I have some
>> fixes to do, there. However, I don't expect that my router is
>> currently routing multicast traffic through to my internal network.
>
> I assume we are talking about IPv4 multicast;  the odds you'll
> successfully get it across a NAT are low [you can't really NAT multicast
> traffic].  You should be able to bring multicast traffic into the
> network without much issue, but outbound multicast traffic will have a
> source address of the private network [connection tracking doesn't work
> for multicast traffic, so the typically awesome stateful-NAT provided by
> iptables isn't effective - at least this *WAS* true a few years ago.]

I'll ask around in #netfilter, but I'm not terribly worried about it.
I'm still uncertain how one actually sends custom multicast traffic.
Especially traffic that doesn't necessarily have an existing defined
multicast address. I know it's just opening a udp socket socket to
write to the multicast address, but I don't know what addresses or
ports are safe to use. (I'd like to send multicast flows across the
open web)

>
> Getting around the NAT issue is the purpose of the
> mrouted/pimd/igmpproxy service.

OK. I'd heard of mrouted (it was mentioned in the O'Reilly books I'd
read...which are apparently very dated by now), but only stumbled
across pimd late last week. Hadn't heard of igmpproxy, but by the name
I can make a solid guess of what it does.

>
> You can see the state of the multicast routing and established streams
> in /proc/net
> awilliam at linux-yu4c:/proc/net> cat ip_mr_cache
> Group    Origin   Iif     Pkts    Bytes    Wrong Oifs
> awilliam at linux-yu4c:/proc/net> cat ip_mr_cache
> Group    Origin   Iif     Pkts    Bytes    Wrong Oifs
> awilliam at linux-yu4c:/proc/net>
>
> Also watch the TTL of multicast packets since many services set this to
> "1".  This means the 'range' of the packet is pretty much limited to the
> LAN or immediately adjacent networks.
>
> Also make sure multicast forwarding is even enabled.
>  --- /proc/sys/net/ipv4/conf/all/mc_forwarding ---

Good to know. This was one of the hardest things to identify and set
for getting *IPv6* traffic working...

>
>> Does anyone have any experience with enabling multicast on a Debian
>> system? I thought I just needed to install mrouted, but there isn't
>> even a package for it.
>
> I haven't played with multicast in awhile but I think mrouted was
> obseleted by pimd.   If I recall correctly mrouted was a DVMRP service
> not IGMP [but my notes are old].

Sounds right for what I've read.

>
> Do you have any specific applications you want to use with multicast?
> In general *local* multicast "just-works".  Avahi / Bonjour / ZeroConf
> use multicast DNS to accomplish their thing.  Routed multicast is
> another [rabid] animal entirely; it is yet another reason NAT is *EVIL*
> and IPv4 must die.

The most specific application I have relates to Rosetta Code.
MediaWiki supports streaming its changelog as UDP datagrams, and I'd
love to target that at a multicast address so some of my more
technically apt users can consume it. It won't do me much good unless
I can test it, though. RC sits on a VPS on the public Internet.

As a more experimental application, I'd like to play with text, voice
and video conferencing using multicast streams.

-- 
:wq

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.