jak
----- Original Message -----
From: "Pars Mutaf" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>
Cc: "Erik Nordmark" <[EMAIL PROTECTED]>; <ipv6@ietf.org>
Sent: Wednesday, September 20, 2006 2:25 AM
Subject: Re: Proposal to change aspects of Neighbor Discovery
> On Mon, 2006-09-11 at 20:02 +0200, Pars Mutaf wrote:
>> Hello,
>>
>> The issue was raised again in 16ng, so I'm trying to help
>> moving forward on this issue. (I dropped out my dormant mode
>> reliability concerns for future work, but I hope this has
>> complemented the discussion.)
>>
>> I have a couple of comments on the signaling analysis made
>> by Erik and James:
>>
>> IMHO the comparison of RS/RA signaling vs unsolicited/periodic
>> RA is incomplete. At the IP layer, the cost RS/RA is clearly
>> twice the cost of unsolicited/periodic RA. I agree. This
>> doubles the load on the AR's interface (if I understand
>> correctly).
>>
>> However, at the link layer the situation is inversed
>> (especially on wireless links). Most of the unsolicited RAs
>> trigger paging (say 90% of them). This means that most of
>> the unsolicited/periodic RAs trigger N paging messages, plus
>> the paging protocol exchange messages, plus the RA. In addition,
>> the resource being consumed is the paging channel, which is
>> scarce. But I ignore the exact paging packet sizes.
>>
>> As for the RA filtering possibility:
>>
>> Filtering at the base stations may not be enough. Filtering should
>> be done at link-layer paging agents (I'm using the generic term).
>> Otherwise, the paging agent will unnecessarily generate N messages
>> (per RA), which will later be dropped by the base stations. Filtering
>> should also be made at the base stations. Because some of the RAs
>> will trigger paging, the others won't.
>
> hi,
>
> While talking with a colleague, we have realized that paging by
> the BS isn't possible in fact (I don't remember who proposed it,
> it looked like an anonymous magic solution).
> Because, when the BS receives a link-layer paging message, it
> cannot figure out whether:
>
> 1/ The paging message was triggered by an incoming session, or
> 2/ The paging message was triggered by a periodic RA.
>
> In conclusion, if filtering of the periodic RAs is considered as
> the best solution (not my argument), it should be done at the
> paging agent. This is not only more optimal (as I argued above),
> this is the only solution.
>
> The BS can of course filter the RA after paging, but it's too
> late. The host is woken up, the paging bandwidth is consumed.
>
> (UIMS, this point also applies to 16ng, and when paging agent = AR.)
>
> pars
>
>
>> In addition to other comments, my personal suggestion to the
>> authors would be: not only focusing on the energy cost but also
>> the paging cost, and resubmitting the draft. The solution is also
>> unclear. The RAs should be turned OFF, or the RA interval should
>> be increased? Which one? If they are not necessarily turned OFF,
>> they should be spread over time to avoid paging channel congestion.
>> This argument also applies to the current maximum period (30min).
>> But precisely how they are spread?
>>
>> My two cents.
>>
>> pars
>>
>> ps: On more point. If the proposal is made for 16ng, the number of
>> hosts in the subnet reported by Raj, which was several hundred
>> thousands (in the context of 3GPP) does not apply probably. In
>> 16ng, there will probably be only one paging area under the AR (not
>> sure yet). In this case, if filtering is considered as the best
>> solution, it can work at the BS. Because the AR is the paging agent.
>>
>>
>>
>> On Tue, 2006-09-05 at 12:54 -0700, James Kempf wrote:
>> > Erik,
>> >
>> > Couple points.
>> >
>> > Most cellular networks don't have more than one active last hop
>> > router,
>> > so
>> > the issue of multiple routers doesn't apply.
>> >
>> > Regarding the number of packets, the question is over what period of
>> > time
>> > are the packets sent. If the router needs to emulate multicast, then
>> > the M*N
>> > unicast RAs either need to be spread out over some period or you'd
>> > end
>> > up
>> > with congestion. It's true that the number of packets is more if
>> > explicit
>> > solicitation is done, but is that such an issue given the bandwidth
>> > available on modern wired and wireless links? Again also, the RS/RAs
>> > could
>> > be spread over a longer time period to reduce the possibility of
>> > congestion.
>> >
>> > Regarding filtering for dormant mode hosts, having the BS filter out
>> > the
>> > multicast RAs is certainly an option, since the BSs will know which
>> > hosts
>> > are in dormant mode. This would not require any special protocol to
>> > tell the
>> > last hop router which hosts are in dormant mode or not, if the BSs
>> > are
>> > IP
>> > devices. In current 3G networks, they aren't, but in Wimax they will
>> > be.
>> > However, at least one cellular SDO (3GPP2) has declined to specify
>> > beacon
>> > RAs for MIPv4 movement detection, I believe primarily because of
>> > dormant
>> > mode (Kuntal can correct me if I am wrong here). So I suspect if
>> > IETF
>> > does
>> > nothing on this, the cellular SDOs will simply ignore the IETF
>> > recommendation because it doesn't apply to their networks, and will
>> > specify
>> > that multicast RAs are not done, because most of the people active
>> > in
>> > Wimax
>> > Forum are 3GPP2 people so they are familiar with the way 3GPP2 does
>> > it.
>> > Of
>> > course, maybe IETF doesn't care in the end whether or not this gets
>> > deployed
>> > in cellular networks, in which case, leaving it as it is in RFC 2461
>> > and
>> > saying "if you feel this is an issue for dormant mode hosts, then
>> > have
>> > the
>> > BS filter" is fine.
>> >
>> > jak
>> >
>> > ----- Original Message -----
>> > From: "Erik Nordmark" <[EMAIL PROTECTED]>
>> > To: "James Kempf" <[EMAIL PROTECTED]>
>> > Cc: "Basavaraj Patil" <[EMAIL PROTECTED]>; <ipv6@ietf.org>;
>> > "ext
>> > Pars MUTAF" <[EMAIL PROTECTED]>
>> > Sent: Thursday, August 31, 2006 5:17 PM
>> > Subject: Re: Proposal to change aspects of Neighbor Discovery
>> >
>> >
>> > > James Kempf wrote:
>> > >
>> > >> I think the proposal was not to keep the router information until
>> > >> it
>> > >> was
>> > >> explicitly invalidated but rather that the host could
>> > >> individually
>> > >> solicit prior to the expiration of the lifetime. The router
>> > >> information
>> > >> state is still soft state, its just that the renewal is
>> > >> different.
>> > >> 2641
>> > >> explicitly prohibits solicitation except for 5 specific cases,
>> > >> and
>> > >> renewing a router table entry is not one of them.
>> > >>
>> > >> For some types of wireless links, multicast unsolicited router
>> > >> advertisements are not really that helpful in determining router
>> > >> reachability, because the host may be able to hear the router,
>> > >> but
>> > >> not
>> > >> transmit. If the host depends on a multicast unsolicited router
>> > >> advertisement, it could end up with a lengthy NUD procedure
>> > >> before
>> > >> it
>> > >> determined that it couldn't really use the router. That's one
>> > >> reason
>> > >> why
>> > >> an RS-RA exchange would be more useful. Another is the issue of
>> > >> dormant
>> > >> mode hosts, which is I think what prompted the original posting
>> > >> on
>> > >> this
>> > >> thread.
>> > >
>> > > But the cost of solicited advertisement in terms of load on the
>> > > network is
>> > > higher than unsolicited.
>> > >
>> > > Assume there are N routers on the link, and M hosts.
>> > >
>> > > With unsolicted multicast advertisements we get N multicast RAs
>> > > per
>> > > time
>> > > period. If we assume the the link layer emulates multicast with
>> > > repeated
>> > > unicast, that would end up bring M*N unicast RAs per time period.
>> > >
>> > > With solicited RAs, presumbly we'd want the RS to be unicast
>> > > instead
>> > > of
>> > > sent to all-routers, right? (Otherwise we'd have a ton of
>> > > multicast
>> > > RSs to
>> > > handle.)
>> > > Thus each host would need to unicast at least one RS per time
>> > > period.
>> > > But
>> > > with N routers providing potentially different information it
>> > > would
>> > > seem
>> > > each host needing to unicast an RS to each one each time period.
>> > > Thus
>> > > we'd
>> > > end up with N*M RSs plus N*M RAs in response; twice the number of
>> > > packets!
>> > >
>> > > Note that is addition to sending more packets, such an approach
>> > > can
>> > > not
>> > > robustly deal with a replacement of a router.
>> > > When a new router comes up it initially multicasts a few rapid
>> > > RAs.
>> > > But
>> > > all those could be lost. The fact that the new router (as well as
>> > > others)
>> > > keep on multicasting RAs periodically means that even if the
>> > > initial
>> > > RAs
>> > > were lost, the hosts would sooner or later receive an RA. Without
>> > > this, we
>> > > can easily get into states where the new router is introduced, and
>> > > a
>> > > day
>> > > later the old router is turned off, yet there might be hosts which
>> > > do
>> > > not
>> > > know there is a new router.
>> > > Thus you'd need to have the hosts fall back to sending *multicast*
>> > > RSs to
>> > > compensate for the lack of periodic RAs.
>> > >
>> > > To me the dormant host seems like a red herring.
>> > > For a dormant node there is a filter somewhere which determines
>> > > what
>> > > packets will make it wake up. I guess this filter could be either
>> > > in
>> > > the
>> > > NIC/radio on the host, or in the network. If it is in the network,
>> > > then a
>> > > match on the filter would make the network send the "wakeup"
>> > > signal
>> > > to the
>> > > host.
>> > >
>> > > Given this, we can get the desired behavior of not having the host
>> > > wakeup
>> > > due to periodic RAs if the wakeup filter blocks (doesn't wake up)
>> > > from a
>> > > RA.
>> > > This means that when the host wakes up it might find that its
>> > > default
>> > > routers and/or prefixes have timed out. But we need to deal with
>> > > that
>> > > in
>> > > the solicited RA case as well (presumably we don't want to have
>> > > the
>> > > host
>> > > wake up every time period to send the RS/RSs.)
>> > > And dealing with that case can be done by just invoking the DNA
>> > > procedures - send a unicast RS to a known router and wait for an
>> > > RA
>> > > in
>> > > response.
>> > >
>> > > Thus I don't see an alternative to periodic RAs that is more
>> > > attractive;
>> > > the alternative seems to cause more packets and be less robust.
>> > >
>> > > Erik
>> > >
>> >
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>