Subject: RE: [Mip4] HoA=0.0.0.0 question

From: "Avi Lior" <[email-masked]>
Date: Wed, 6 Jul 2005 20:51:52 -0400

Sorry, this is a bit late but I wanted to wrap up this discussion about
the billing example.

I belive in the example I gave is that if the operator sees a new
request coming in while there seemingly is one already active that the
operator will use other hints to determine when the last activity was
conducted.  For example, the operator can look at the ip flows etc....
So theft from the user by doing what you or Kent suggest is not
possible.  I don't think I said to roll back the transaction to the last
registration.

Second, from the point of the user, the amount gained would be in the
order of minutes or perhaps hours (depends on the livetime).  So the
gain would be minimal.  Abuses by the user would also be detectable and
can be reported.

However an operator that has millions of users each potentially with a
revenue leak can be a huge problem for an operator.  They may be
overcharging millions of dollars a year or undercharging millions of
dollars a year -- both creates a problem for them.

I know this based on some reports we have been seeing from operators
concerned about accuracy of over accounting or under accounting flows in
the order of octets.

> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]] 
> Sent: Monday, June 20, 2005 10:36 AM
> To: Avi Lior
> Cc: Charles E.Perkins; Chowdhury, Kuntal; [email-masked]; 
> Henrik Levkowetz
> Subject: RE: [Mip4] HoA=0.0.0.0 question
> 
> 
> 
> Avi,
> 
> One comment below:
> 
> Avi Lior writes:
>  > Charlie and All,
>  > 
>  > Here is an example of the problem (as I understand it) 
> Kuntal or others may  > correct me or add to this.  > 
>  > Consider the case where customers are billed based on time.  > 
>  > Now consider what happens when a mobile deregisters but 
> the  deregistration  > is lost; the binding cache in the HA 
> will become stale.  In order not to  > overbill the user, the 
> HA -- everytime a binding update goes stale could  > then 
> attempt to determine when the session actually terminated by 
> looking at  > other indicators to determine the last activity 
> time.  Note this operation  > is expensive but it is 
> important for accurate billing of customers and hence  > 
> important to operators.  > 
>  > If however, the same mobile preforms a new registration 
> before the lifetime  > of the previous registration expires, 
> then the HA will see this new  > registration as a 
> re-registration.  The HA will then NOT attempt to  > 
> re-compute the real session time and the user will be billed 
> for that time.  > 
>  > In some environments such as wirelss this could happen 
> relatively frequently  > and operators are concerned about 
> these issues and want to make sure that  > they do everything 
> possible to bill appropriately.  > 
>  > One solution to this problem is as Kuntal suggested.  In 
> his particular case  > where the HOA is allocated by the home 
> network then if the mobile always  > sends an HOA with 
> 0.0.0.0 in new registration then we can then deferentiate  > 
> between new registration and a re-registration.  > 
>  > However, when the MN is assigned a static HOA then that 
> "hint" is no longer  > available. We need something else.  
> What that something else is I am not  > sure.  But it seems 
> to me that we should have explicitly indicated whether a  > 
> registration is a new registration or a re-registration. This 
> would make the  > protcol more robust.
> 
> Let's say we add a flag to indicate a "new registration" and 
> then users won't be billed for time between the last 
> registration and a "new registration".  What is to prevent me 
> from setting this flag in every single registration?  Let's 
> say the MN is set up to be a seldom-used server so you can't 
> really tell from traffic flow whether the MN is still out 
> there listening.  Then I won't be billed for any time at all, 
> but the MN is still available to receive packets from the HA 
> at any time.
> 
> I think we do need a more detailed case analysis of the 
> address assignment implications when the HoA = 0.0.0.0 and 
> this should be in a 2794 bis document.  This is planned to be 
> completed by the working group.  However, we need to consider 
> carefully whether this kind of a billing requirement needs to 
> be addressed.
> 
>  > Another solution is to reduce the lifetime of a 
> registration.  This may be  > workable in fixed wireline 
> mobile ip application but it is not a good idea  > for 
> wireless mobile ip applications due to the expensive over the 
> air  > resources.
> 
> As long as there is a binding in the HA the MN is getting 
> some kind of service from the HA (the HA is available to 
> forward packets).
> 
> -Pete
> 
>  > Perhaps I should ask this question from those who know 
> this subject far  > better than me, is there a reliable way 
> for the HA to reliably deferentiate  > between a 
> Re-registration, a new Re-gistration?  > 
>  > > -----Original Message-----
>  > > From: Charles E.Perkins [mailto:[email-masked]] 
>  > > Sent: Thursday, June 16, 2005 6:43 PM
>  > > To: Chowdhury, Kuntal
>  > > Cc: [email-masked]; Henrik Levkowetz
>  > > Subject: Re: [Mip4] HoA=0.0.0.0 question
>  > > 
>  > > 
>  > > 
>  > > Hello Kuntal,
>  > > 
>  > > "Chowdhury, Kuntal" wrote:
>  > > 
>  > > > What I understand from your responses is that HoA=0 should 
>  > > be treated 
>  > > > by the HA as a new registration request (since an HoA 
> assignment is 
>  > > > involved here). Is this a correct understanding?
>  > > 
>  > > I'd rather not modify the specification about how the
>  > > home agent might distinguish this as a new Request.
>  > > Just from memory, without perusing the document,
>  > > I believe that the concept of "new registration"
>  > > in the base specification is tied closely to the
>  > > use of the same "Identification" field within the
>  > > Registration Request, and I would not want to disturb
>  > > the meaning of that term.
>  > > 
>  > > Moreover, I don't yet fully understand the need, even
>  > > in the context of AAA protocols.
>  > > 
>  > > Regards,
>  > > Charlie P.
>  > > 
>  > > -- 
>  > > Mip4 mailing list: [email-masked]
>  > >     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>  > >      Charter page: 
> http://www.ietf.org/html.charters/mip4-charter.html
>  > > Supplemental site: http://www.mip4.org/
>  > > 
>  > 
>  > -- 
>  > Mip4 mailing list: [email-masked]
>  >     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>  >      Charter page: 
> http://www.ietf.org/html.charters/mip4-charter.html
>  > Supplemental site: http://www.mip4.org/
> 
> 

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Pete McCann <[email-masked]>
Date: Mon, 18 Jul 2005 09:43:51 -0500

Avi,

I think our point was that there might not be any flows, the MN might
just be a server waiting for connections.  As long as there is a
registration in the HA the MN is getting some kind of service even
though no packets are flowing.  Charges should be applied
appropriately.

The registration revocation mechanism can be used to garbage collect a
stale registration once it has been detected that the MN is no longer
in the coverage area of a given FA.  However, given that we don't send
any messages between RRQs that are scheduled near Lifetime expiration,
there is no way to tell securely that a MN has been out of coverage
during that period of time.

-Pete