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. > > 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. > 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 > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
