Yoav, Erik, Thanks! This makes sense.
Guess I have to skim 4861 again :-! - Anders > -----Original Message----- > From: Yoav Ben-Yehezkel [mailto:[email protected]] > Sent: Friday, October 29, 2010 07:10 > To: Erik Nordmark; Anders Brandt > Cc: [email protected] > Subject: [!! SPAM] RE: [6lowpan] ND: Sending NS+ARO message > for the first time > > Hi, > > I have expressed a similar concern in the past. > Find below the correspondence. > > Best regards, > Yoav > > ------------------------- > Start of correspondence > ------------------------- > Thanks Colin, > > Your points below indeed cover my concerns. > > Regards, > Yoav > > > From: Colin O'Flynn [mailto:[email protected]] > Sent: Sunday, September 26, 2010 6:00 PM > To: 'Yoav Ben-Yehezkel'; [email protected] > Cc: '6lowpan' > Subject: RE: [6lowpan] congestion of responses to multicast > RS query from an ND host > > 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 > > 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 > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Erik Nordmark > Sent: Friday, October 29, 2010 12:14 AM > To: Anders Brandt > Cc: [email protected] > Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time > > On 10/28/10 01:53 AM, Anders Brandt wrote: > > OK, thanks. > > > >> You discover the possible routers by performing an RS/RA exchange. > >> The RS is typically sent to the IPv6 all-routers multicast address > >> (see Section 5.3). > > > > But then we are back to my first question: > > > >>> In that case, what happens if this message reaches 50 > different 6LRs > > within direct range? > >>> I suppose something prevents me from getting flooding? > > > > IOW: Do I have do some random arbitration of Router > Advertisements in > > response to multicasted Router Solicitations in a lowPan? > > RFC 4861 specifies some random delay for the RAs. If I don't > misremember it is random between zero and .5 seconds. > > Erik > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
