[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DUB107-W43809186CF94F192981E9FED6E0@phx.gbl>
Date: Tue, 23 Jul 2013 00:06:31 +0200
From: Lukas Tribus <luky-37@...mail.com>
To: Benjamin LaHaise <bcrl@...ck.org>,
William Manley <william.manley@...view.com>,
"hannes@...essinduktion.org" <hannes@...essinduktion.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: IGMP Unsolicited Report Interval too long for IGMPv3?
> Date: Mon, 22 Jul 2013 17:18:55 -0400
>> I would guess that this 10s has come from IGMPv2 RFC2236, which was
>> reduced to 1s in IGMPv3 RFC3376.
>
> Reducing the timeout does not solve the problem you are encountering, as
> any packet loss will still result in a 1 second delay.
Packet loss will always result in a delay and I think William is well aware
of that.
off-topic: 1 second is not a problem in IPTV, 10 seconds are ([1]).
> The correct approach is to queue the IGMP multicast join with a higher
> priority than other traffic in the system so that the requests are not
> lost due to congestion of a single queue.
While this certainly makes sense, congestion is not the only reason for
packet loss. There is no way to fix packet loss in lower network layers,
like ADSL, satellite links or IPoAC.
Improving retransmission by making it more predictable, bringing it closer
to RFC proposals and real life problems makes a lot of sense, imho. This
includes setting TC_PRIO_CONTROL, but I'm not sure it will fix Williams use
case.
lukas
[1] http://en.wikipedia.org/wiki/Zap_time --
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists