Hi Yoav,
This depends greatly on the L2 characteristics. As the RA is sent unicast you could rely on L2 delivery, for example 802.15.4 ACKs. For the 6lowpan-ND you don't need to receive every reply anyway though. You just need one router that connects to the prefix you want, so in a dense network you may have more collisions, but you should also have enough successes that it doesn't matter. Note that in 6lowpan-nd-13 MAX_RA_DELAY_TIME is redefined to 2 seconds by default, which in terms of most link layers a very long time! I think it's best to leave the random delay granularity as define in RFC4861: something implementation defined. There is an unknown processing delay between receiving the RS and internally generating/queuing the RA. Thus even if you use a random granularity that matches the L2 packet length, you could still have collisions. And if two nodes have both sent a RA this again all goes out the window. And I don't think anything would stop an extension of 6lowpan-ND being added in the future using for example something like the trickle timer for sending RA's, where if nodes see a lot of other routers advertising it doesn't send its own RA. Or adjusting power of sending RS to solicit fewer responses, etc. But I think these should remain optimizations that can be explored only if required in dense networks, and keep 6lowpan-nd as simple as possible. Regards, -Colin From: [email protected] [mailto:[email protected]] On Behalf Of Yoav Ben-Yehezkel Sent: September 26, 2010 5:32 PM To: [email protected] Cc: 6lowpan Subject: Re: [6lowpan] congestion of responses to multicast RS query from an ND host Thanks Robert, I am guessing you are referring to the MAX_RA_DELAY_TIME .5 seconds? The problem I am thinking about goes a little beyond this randomization. The way I see it, in LLNs hidden nodes are a common case, so if two responding routers are not within direct connectivity, their packets will collide if randomization resolution is too small. Unless the randomization resolution is not in the order of magnitude of L2 frame transmissions (including overheads such as preambles, backoffs, etc.) their packets are very likely to collide. This is why I am concerned with the value of 0.5 seconds being a little small, and also wonder whether defining the resolution of the randomization is important for 6LoWPAN-ND. Trying to illustrate below. Consider the following topology: R1 --> H <-- R2 +----+ Query: | RS | +----+ +--------+ R1 Resp: | RA1 | +--------+ +---------+ R2 Resp: | RA2 | +---------+ ---------------------------------->t Above you see the responses collide, even though R1 and R2 randomized a different value, because their L2 could not separate their transmissions (as they cannot hear each other). Had the randomization was using resolution at least the size of the response packet and R1 and R2 randomized two different values, the collision would have been avoided. Of course in realistic large and dense networks, you're likely to see more than two routers respond, which may escalate the problem. I hope this better clarifies my concern. Thanks, Yoav From: Robert Cragie [mailto:[email protected]] Sent: Sunday, September 26, 2010 4:45 PM To: Yoav Ben-Yehezkel Cc: 6lowpan Subject: Re: [6lowpan] congestion of responses to multicast RS query from an ND host Hi Yoav, There is already a mechanism specified in rfc4861 to randomize the transmission of RAs - see section 6.2.6. This would apply to 6lowpan-nd as well. The downside of this approach is the lengthening of the whole RS/RA procedure. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com <http://www.gridmerge.com/> On 26/09/2010 1:32 PM, Yoav Ben-Yehezkel wrote: Hi, I have a question on 6LoWPAN-ND. I tried looking for this issue in the mailing list, but couldn't find anything on this. Does the WG see a need for some kind of regulation of RA responses to host multicast of a RS query in 6LoWPAN-ND? Unless regulated, in a large and dense networks, this could cause excessive traffic for a meaningful period of time. Best regards, Yoav _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
