On 8/11/2015 2:44 PM, Pat (Patricia) Thaler wrote: > RE: RFC3819 > >> The assumption is that L2 will do a reasonably good and efficient job of >> multicast/broadcast - certainly better than L3 or other layers would. > > What I think Juliuz is trying to point out is that the RFC doesn't > talk about how good the performance of L2 multicast needs to be - > for instance in terms of BER/packet loss. It does talk about the > impact of BER on TCP throughput, but not on multicast.
Agreed. > How good an error rate do the IPv6 related multicasts need? I would expect that depends on the use, e.g., DAD would be different than streaming multimedia. > Adrian summarized the causes of packet loss: > "1. The basic "packet error rate" (before Ack) designed to is 10% in the > case of unicast. This is a very broad statement and almost so > simplistic as to be misleading. Errors are composed of 1) collisions, 2) > interference, 3) rate/MCS adaptation > errors, 4) sudden changes in the radio environment such as shadowing. The > residual error for unicast is less because of the retry mechanism. > > 2. Multicast is generally sent at a low "basic" (one intended to be > receivable by all STAs in the AP's network) rate. This improves reliability > in some of the error causes cited above, but not all. > ...." > > If it takes two missed RAs to decide that you aren't connected to > the router any more, that has about a 1% chance of happening with a 10% > packet error rate (though the multicast error rate is probably > somewhat better since it is sent at the lower rate). This assumes that > the error probability for the two RAs is independent; they occur far > enough apart in time that this doesn't seem unreasonable. > > Why does it take two lost RAs rather than one? Presumably because > the protocol assumes that sometimes an RA is lost, just not with as > high a probability as 10%. > > 1% seems high - how good does it need to be for acceptable behavior? > One could improve the behavior by adjusting parameters so that more > than2 had to be lost. Of course there is a tension between bandwidth > formulticast heartbeats, wanting to detect reasonably quickly that > thedevice is no longer on the subnet (e.g. because it is mobile), and > notlosing the context unnecessarily. > > Without guidance on how good the multicast packet loss rate should > be, it is difficult to define the best solution . While I agree with your conclusion, what's the alternative if there is no L2 multicast? 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. Joe _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
