Selon Basavaraj Patil <[EMAIL PROTECTED]>:
>
> Inline:
>
>
> On 8/10/06 8:52 AM, "ext Pars Mutaf" <[EMAIL PROTECTED]> wrote:
>
> >
> > Hello,
> >
> > I'm still trying to understand the problem :-)
> > Unless I missed an episode, the context is
> > connection-oriented cellular networks under IP
> > (whatever that means)
> >
> > You say that the RA packets (unicasted) will wake up
> > 90% of hosts in the subnet. Because roughly %90 of
> > hosts are dormant, in general.
> >
> > I still believe that 30 minutes is longtime. Thus
> > the problem is not energy consumption perhaps
> > (without justification).
>
> 30 minutes is a long time. But if you have to go through the process of
> waking a host to simply deliver an RA, which in most instances has no value
> for the host, it is a waste of resources which include power, radio and
> possibly causing congestion as well.
> From a power consumption perspective:
> The host will wake up when paged and have to establish a traffic channel
> which requires it to request allocation of resources from the network. There
> is power that is consumed. Now if you argue that doing this every 30 minutes
> is not a problem...... I cant really argue against that. But my point is
> that why do you need to do this every 30 minutes in networks where you know
> that the host is not going to change the AR and the RA has no value to the
> host.
>
> >
> > But there is a problem if you link-layer page
> > many many hosts simultaneously to deliver an
> > RA. The paging channels may be saturated. From L2
> > perspective, this would be similar to a situation
> > where many many cellular users are called
> > simultaneously, resulting in call setup delays.
> > Personally, I suspect that this may be a much more
> > serious problem than energy consumption.
>
> True. Paging a large number of dormant hosts simultaneously will be a
> serious issue for operators and people who do network planning don't like
> such broadcasts. So I agree that congesting the paging channel may be a more
> serious concern than power consumed by the host.
> Additionally you have to note that in order to deliver the RA you have to
> establish a traffic channel in most cases. Establishing this for a large
> number of hosts every 30 minutes just to deliver an RA is an overhead and
> waste of resources.
>
> >
> > But, firstly, your draft doesn't make it clear,
> > and secondly, I couldn't see how your draft solved
> > this problem.
>
> Solution is fairly simple as stated in the I-D:
> 1. Transmission of periodic RAs should be optional - It is a configurable
> parameter and the RA will indicate this to the host when it first attaches
> or solicits an RA.
> 2. Interval between periodic RAs should be flexible, i.e > 1800 secs. It is
> up to the deployment to determine what is an optimal interval. 1800 secs is
> just as random a value as 600 seconds or 5400 secs.
>
> And if a host needs an RA for some reason, it can always solicit it from the
> AR.
This is the only point that needs clarification IMveryHO:
Are the periodic RAs useless for those cellular hosts?
A periodic RA can periodically show me that the paging
subsystem still works, for example. I can sleep better.
This makes sense in your context? (I'm not a
connection-oriented specialist).
> >
> > The real solution, imho, is to distribute the
> > unicast RAs over time. For example, if there are
> > 5 hosts in the subnet and the RA period is 5 minutes,
>
> Staggered tranmission of RAs is one solution. There are others as well.
I'm curious what are the others? (if/when you have time)
Thanks!
pars
>
> > then
> >
> > start:
> > Min1 - send the 1st RA
> > Min2 - send the 2nd RA
> > ...
> > Min5 - send the 5th RA
> >
> > and goto start.
> >
> > This makes sense? Sorry if this is already specified
> > somewhere.
> >
> > Otherwise, you may want to filter the RAs at
> > the paging agent.
>
> Thanks for your comment.
>
> -Raj
>
> >
> > pars
> >
> >
> >
>
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
