On 8/11/2015 3:32 PM, Pat (Patricia) Thaler wrote:
> Joe,
>
> I'm mainly concerned in this discussion on what error rate is needed
> for acceptable performance of the protocols that support IPv6 - e.g.
> DAD, RA. Streaming multimedia is a separate discussion since different
> solutions might apply to it.
Sure.
>> While I agree with your conclusion, what's the alternative if there is
>> no L2 multicast?
>
> 802.11 does have L2 multicast. It just doesn't provide for L2 ack
> and retry for L2 multicast (at least in its basic form, there is a
> recent optional extension for that) so the packet loss can be higher
> than that for unicast.
Understood, but again, what's the alternative?
>> I think you're arguing for more specific guidance on acceptable packet
>> loss rates for various uses of multicast, but that might be out of scope
>> for RFC3819 (even as a -bis). I gave it a quick scan, and as I checked
>> (and recall) RFC3819 doesn't make specific recommendations on BER for
>> unicast either. It says that the BER needed depends on the use, and that
>> can affect the efficiency of L3. The same is true for multicast, but
>> that doc is not the place for a specific recommendation.
>
> I don't think advice on that would be out of place as "Advice for
> Internet Subnetwork Designers" if it is what is needed to make IPv6 work
> well. People here have expressed consternation that 802.11 doesn't have
> good enough performance for that, but how can you expect subnets to
> provide that performance when the need hasn't been included in the advice.
That's true, but specific protocol behaviors do address this issue
already, e.g., RFC 7559 uses exponential backoffs for soliciting RAs.
DAD is a "negative information" protocol, i.e., a lossy link can give a
false positive. This issue is already addressed Sec 4.4 of RFC 4429: the
effect of L2 losses can be mitigated by recommending a different value
for DupAddrDetectTransmits. RFC 4862 Sec 5.1 already notes that this
parameter might need to be defaulted to a different value for particular
link types, and such might need to be the case for 802.11.
> Even if the number doesn't get put into an RFC3819-bis, it would be
> useful to have a number so that solutions can be examined.
For this protocol mechanism, the numbers are a relationship:
L2 mcast loss rate vs. DupAddrDetectTransmits value
IMO, it'd be a lot easier to increase DupAddrDetectTransmits than to
assume 802.11 would lower the L2 mcast loss rate.
Joe
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
