[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Scope of solutions discussion document
Greg -
I am not sure I understood the data itself. But, I get your point. It may a good idea for you to make a short presentation on this in MN meeting. ;-) We could try to come to conclusion on the issue of 'serialization of RS messages' - becos our next step is likely to be very different based on our decision.
Its good that 2461bis is already relaxing the MAX_RTR_SOLICITATION_DELAY constraint. May be its better to reduce the value from 1 second to say 10 or 20 milli-sec rather than completely getting rid of it.
On a related point, as part of the solutions - do we plan on keeping the RA response as unicast response. We could possibly avoid multiple RS messages being sent on the the link by using multicast RA response. Hosts that were random-delaying for the RS message could cancel the RS message if it receives the required information in a multicast-RA message.
thanks & regards,
Sathya
----- Original Message -----
From: Greg Daley <greg.daley@eng.monash.edu.au>
Date: Thursday, February 24, 2005 8:07 pm
Subject: Re: [DNA] Scope of solutions discussion document
> Hi Sathya,
>
>
> RFC2461bis seems to indicate that in the furture it
> may be possible to ignore MAX_RTR_SOLICITATION_DELAY.
> It's really our task to guess or show if/where it can be done.
>
> Sathya Narayanan wrote:
> > Hello Brett -
> >
> > I agree - they are all 'SHOULDs' - but some information on the
> > implementations will be useful?
> >
> > The problem with RTR_SOLICITATION_INTERVAL is not only when a
> node is
> > moving rapidly between links, it will also cause problems when
> there is
> > packet loss. If the packet loss probability is p, then the prob
> of a 4
> > second delay being added will be (p + p^NR) where NR is the
> number of
> > routers on the link that can respond. If NR is 1, the prob is
> 2p. I
> > don't know if this is acceptable, so we can ignore this. My gut
> feeling
> > is that we can not. We must be a bit more resilient to packet
> loss
> > problems, 4 seconds is too much. I think it will be useful to
> > differentiate the delay between re-transmission of RS becasue RA
> was not
> > received, from delay between RS with a corresponding RA and
> another
> > following RS due to link trigger. In the later case, 4 second
> delay
> > could avoid too many RS message due to fluctuating wireless link
> signal.>
> > And, I agree, MAX_RTR_SOLICITATION_DELAY is the trickier one.
>
>
> Here's the text (page 3: draft-ietf-ipv6-2461bis-02.txt):
>
> "...
>
> In some cases, the random delay MAY be omitted if necessary. For
> instance, a mobile node, using [MIPv6], moving to a new link would
> need to discover such movement as soon as possible to minimize the
> amount of packet losses resulting from the change in its
> topological movement. Router Solicitations provide a useful
> tool for movement
> detection in Mobile IPv6 as they allow mobile nodes to determine
> movement to new links. Hence, if a mobile node received link layer
> information indicating that movement might have taken place,
> it MAY
> send a Router Solicitation immediately, without random delays. The
> strength of such indications should be assessed by the mobile
> node's implementation depending on the level of certainty of
> the link layer
> hints and is outside the scope of this specification. Note
> that using
> this mechanism inappropriately (e.g. based on weak or transient
> indications) may result in Router Solicitation storms.
> Furthermore, simultaneous mobility of a large number of mobile
> nodes that use this
> mechanism can result in a large number of solicitations sent
> simultaneously.
>
> ..."
>
>
> So there has to be management of link-layer indication->RS requirement
> within the host, and potential application of delays on certain link
> layers.
>
> Below is a rough overview of some work I did a while ago using a
> locallycreated OMNeT++ 802.11 simulation (the simulation has since
> beenpublished, but doesn't have the test scenario).
>
> I have to apologise that I've left this on the side for a while and
> don't have published results to display.
>
> From my experience with simulations of up to 30 alike MNs
> simultaneouslychanging cell (hard handover threshold, super-
> imposed hosts receiving
> an 802.11 beacon below the threshold), there were MAC collision bands
> for RS's sent to the network.
>
> In a lot of these cases, there were L2 probing collisions when
> scanningchannels, which meant that some of the MNs didn't know
> about the base
> station's presence because they were unaware of the collision (the
> probeis a multicast frame, with no ACK).
>
> These devices found the same base station (since no other valid
> one was
> nearby) on the second probe pass. This meant that there were
> tiers of
> successful probe responses, and subsequent authentication and
> association.It is notable that probe responses weren't being
> snooped regardless of
> MAC address. This would have tightened things up considerably.
>
> Across all the tiers, there was a lot of contention in the MAC and
> delay was experienced in responses to the RS's. Each bridged RS
> received a unicast RA.
>
> Mostly the cause of the delay in RA responses through the AP was the
> nodes still attempting to get onto the link through 802.11 procedures.
> This caused a queue backlog issue to arise so that around 20ms delay
> was experienced for the RTT for the RS/RA pairs.
>
> The spread in delays of hosts changing cells increased fairly steadily
> until 30 nodes.
>
> Here's the 30 hosts incidence plot for the delay after RS that an RA
> was received using one millisecond buckets. The incidences were
> summed over the simulation runs. Please be aware that the values
> are for
> the middle of the millisecond range (so it works for box plots).
>
> The actual delay for beginning to probe until the reception of the RA
> was much more spread out. I can send similar data to individuals
> in order to get an impression, but I'd prefer not to send larger
> attachments.
>
> As you can see, this data is not really ready for publication,
> but may give an indication of what occurs on one of the
> interesting
> link-layers.
>
> There's a lot more to actually test (for example the effect on other
> hosts within a cell).
>
> The (rough) impression I got was that there wasn't much harm in having
> no additional RS serialization delay in 802.11b.
>
> Greg
>
>
>
> RS/RA exchange delay
> -------------------
> 0.004500 1
> 0.005500 2
> 0.006500 2
> 0.007500 2
> 0.014500 1
> 0.015500 12
> 0.016500 2
> 0.017500 3
> 0.018500 153
> 0.019500 855
>