Re: [ssm] IPv6 Multicast Throughput problems in 802.11

Marshall Eubanks <marshall.eubanks@gmail.com> Tue, 15 November 2005 16:45 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec3wA-0007ha-LH; Tue, 15 Nov 2005 11:45:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec3w9-0007gt-6b for ssm@megatron.ietf.org; Tue, 15 Nov 2005 11:45:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06847 for <ssm@ietf.org>; Tue, 15 Nov 2005 11:45:03 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec4DM-0002DS-7u for ssm@ietf.org; Tue, 15 Nov 2005 12:03:24 -0500
Received: by zproxy.gmail.com with SMTP id 9so1009802nzo for <ssm@ietf.org>; Tue, 15 Nov 2005 08:45:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Hap+ncdV0xb9pnaxa7vkE8XDHp9s6jE5hFcRORgsRRLxSztQMvUfWUUyI6zIohshkZ35mZV80Fuuzpsl/dfMXTjMlK0GKg3k+xx1LApfuwDQsQpKLQZMNZi/rJBUTyhM8Rpc4lvR7Cbzy1JUXYxyPilFfpB1IMlg6+07Q/OfESo=
Received: by 10.37.18.77 with SMTP id v77mr5291514nzi; Tue, 15 Nov 2005 08:45:32 -0800 (PST)
Received: by 10.36.46.2 with HTTP; Tue, 15 Nov 2005 08:45:32 -0800 (PST)
Message-ID: <dcad22d80511150845ve96cd99q2fde1c27425468ac@mail.gmail.com>
Date: Tue, 15 Nov 2005 11:45:32 -0500
From: Marshall Eubanks <marshall.eubanks@gmail.com>
To: Tiago Sousa <tmas@dei.uc.pt>
Subject: Re: [ssm] IPv6 Multicast Throughput problems in 802.11
In-Reply-To: <200511151622.jAFGMoFE020867@smtp.dei.uc.pt>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <dcad22d80511150751ge3f0f27y68316f835e8276d5@mail.gmail.com> <200511151622.jAFGMoFE020867@smtp.dei.uc.pt>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
Content-Transfer-Encoding: quoted-printable
Cc: ssm@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
Sender: ssm-bounces@ietf.org
Errors-To: ssm-bounces@ietf.org

Hello;

On 11/15/05, Tiago Sousa <tmas@dei.uc.pt> wrote:
> Thanks for the reply.
>
> Well, one cool thing about 802.11 is that you can generally see every
> packet.
>
> Have you  used tcpdump to see if the packets get placed into the air ?
>
> Yes. I sniff the router outgoing interface where the AP is connect and I can
> see the packets flying to air.
>
> That should distinguish  between broken packets (they are there, but
> fragmented or
> have some  other problem) and some filtering happening in the access point
> or
> upstream.
>
> It is true. The majority of times I see fragmented packets in the outgoing
> interface. Do you think that AP is filtering this fragmented packets? Why?
>

That sounds bad. A lot of stuff will drop fragmented packets, or maybe
the router CPU will be overloaded by  them,  so IMHO they
should be avoided if at all possible. Now the question is, where are they
fragmented and why ?

Your AP might not forward fragmented packets at all, for example. It
sounds like it if
I am reading your comments correctly.

Possible reasons are

- an IPv6 tunnel (over IPv4 ?) - lots of times, people forget about the tunnel
overhead in doing static MTU calculations. Maybe it's going through a tunnel
within a tunnel. Maybe it's the extra size of the IPv6 headers.

- Something broken in configurations or ... .
If you look at packet sizes going into the router
and going  out of the router (or where-ever the fragmentation is occuring), you
should be able to figure out the _actual_ MTU. That may or may not
match the _configured_ MTU.

- Something broken, period. If all else fails, try a different NIC card.

If you can sniff upstream, you should be able to at least find out
where the packets are fragmented.

> If they aren't, you should be able to put a hub at the  AP or look on
> the AP LAN and see if they are _reaching_ the AP. (You can join the
> group on the AP LAN if it is not broadcasting multicast) If they are,
> then it's an AP problem. If I had to guess,
> I would suspect an AP problem, but it's good to know for sure.
>
> I will find another AP and try.
>

That sounds like a good idea, but you still need to make sure that

- packets are getting to the router unfragmented
- 98% of the packets are fragmented by the time they reach the AP (to get from
2 Mbps to 40 Kbps).
- the AP is dropping these.
- what box is actually doing the fragmentation. (For example, is there
a switch in the path ? A firewall ?)

I suspect you're pretty close to figuring this one out.

Regards
Marshall

> Thanks.
>
> Tiago Sousa
>
> Regards
> Marshall
>
> On 11/14/05, Tiago Sousa <tmas@dei.uc.pt> wrote:
> >
> >
> >
> > Hello to all
> >
> >
> >
> > I am testing the PIM-SSM daemon (both freebsd and linux) and mrd6 (another
> > IPv6 multicast routing daemon) in a wireless link.
> >
> > The problem I encountered with both pim6sd daemon and mrd6 is that I'm
> > sending multicast traffic at 4 Mbps and the throughput in the mobile node
> > (which is very near from de access point) rounds 40 kbps.
> >
> > I am using the mad-flute tool to send the multicast SSM traffic and the
> > tcpdump plus trpr to analyze the data. I have also used IxChariot and the
> > results are the same.
> >
> >
> >
> > Anyone knows why the throughput decreases so much in the wireless link?
> > (The multicast TTL is well defined, I have experimented with several
> > pci/pcmcia cards and drivers and several access points configurations
> > (different channels and rates (801.11b and 802.11g)). The results are
> remain
> > always the same).
> >
> >
> >
> > I would appreciate any help/hint that helps me to explain these results.
> >
> >
> >
> > Thanks.
> >
> >
> >
> > Tiago Sousa
> >
> >
> > _______________________________________________
> > ssm mailing list
> > ssm@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ssm
> >
> >
> >
>
> _______________________________________________
> ssm mailing list
> ssm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ssm
>
>

_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm