[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DNA] Scope of solutions discussion document



Hi Sathya,

Sathya Narayanan wrote:
> 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.

Well, I'll see what I can do to see if there's more results i can
produce.

It's not likely that I'll make a separate presentation, but may
have some slides (graphics) to show.  The test scenario was quite
limited, so the applicability may not be wide.

> 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.

Actually, I think hysteresis on hint actiosn is likely to be useful,
rather than induced delay in the event of our own handover.
Certainly on some media it may be useful to keep the delays in some
form, but I hope not to have delays in general.

> 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.

I think I see your point.

In some cases, I think the packets were queued at MAC for a while,
and can't be recalled.  Those packets will go out anyway.

The random delay does help in this case, but the host knows nothing 
about the network.

RS affects (hoepfully, if multicast snoop filters work on base-stations)
only a single cell, whereas an RA consumes bandwidth on all cells in the 
link uniformly (and may wake sleeping nodes).

for multi-cell environments, it's probably better to control things from
the router side.

Just my ideas at the moment.

Greg