Subject: [netlmm] timestamp vs seqno redux

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 Sep 2007 11:00:55 +0200

I've recently became aware that much nonsense discussion is happening
around the timestamp vs seqno.  People keep saying that seqno method is
a possible alternative to timestamp but at the same time they mandate
in the document the timestamp method.  This is complete nonsense.

I don't want the timestamp method to be mandatory.

Anybody else wants the timestamp method to be a mandatory method?

Anybody else wants the timestamp method to be an alternative method?

Alex
PS: mandatory excerpts:
"This document _requires_ the use of Timestamp Option"
"An implementation MUST support Timestamp option."

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 6 Sep 2007 12:58:06 -0700

Please comment on this issue raised by Alex about mandating
Timestamp option. Alex is right, when we discussed this issue,
the conclusion was to use Timestamp based approach, but we
did not discuss if that was supposed to be mandatory to 
implement.

Now, w.r.t the issue, what are we mandating ?

- The ability for the LMA to generate a Timestamp and return
  the timestamp option. The timestamp in relation to a specific
  reference point. IMO, this is one system call on most OS's and
  a delta addition if the timestamp generated is elapsed time past
  some other reference point. We are talking about 5 to 8 lines
  of code. I will be happy to publish this code for all standard
  OS's.

- We are NOT mandating the nodes in the domain to sync up to
  a clock source. 

How does it impact, if some deployment wants to use Seq Number
approach ?

-  No impact. The option need to be supported. Implies those 10
   lines of extra code.

Why this should be mandatory ?

Base draft does not support Context Transfers. Given that the draft
will be incomplete, if we dont mandate the support. By mandating
the support, the LMA can always return its timestamp and the MAG
can use that timestamp and register. This need to be done just
once whenever the LMA/MAG clocks are out of sync and just for one
registration. One extra round trip for the 1st registration between
LMA/MAG pair.

But, if the LMA falls back to the seq number based approach and if
there are no context transfers, there is always an extra round trip
for each MN registration (at handoff). 

So, I prefer the mandatory approach, its more efficient. But, as I
had it in the initial suggested text, I'm ok not mandating this and
defining an error code "Timestamp option not supported". 

Please comment. I want to close this issue. 

Implementation MUST support Timestamp option: [Yes/No]

Thanks
Sri

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Thursday, September 06, 2007 2:01 AM
> To: netlmm
> Subject: [netlmm] timestamp vs seqno redux
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 Sep 2007 23:59:43 +0200

Sri Gundavelli wrote:
> Please comment on this issue raised by Alex about mandating Timestamp
>  option. Alex is right, when we discussed this issue, the conclusion
>  was to use Timestamp based approach, but we did not discuss if that
>  was supposed to be mandatory to implement.
> 
> - The ability for the LMA to generate a Timestamp and return the 
> timestamp option. The timestamp in relation to a specific reference 
> point. IMO, this is one system call on most OS's and a delta addition
>  if the timestamp generated is elapsed time past some other reference
>  point. We are talking about 5 to 8 lines of code. I will be happy to
>  publish this code for all standard OS's.

I agree it's not much code to call an API to obtain current time.  What
is more is to encode the message format of that time into the Mobile
IPv6 implementation.

> - We are NOT mandating the nodes in the domain to sync up to a clock
>  source.

Thanks, that is good.

> -  No impact. The option need to be supported. Implies those 10 lines
>  of extra code.
> 
> 
> Base draft does not support Context Transfers.

Ok.

> Given that the draft will be incomplete, if we dont mandate the 
> support.

I don't think it will be incomplete.

The spec can very easily say that in order for the P-BUs to be correctly
ordered at the HA then the HA should provide the correct seqno to the
MAG, as part of the 'profile' related to MN, or as part of some other
assumed and non-specified mechanism.  When MAG sends a P-BU to MAG it
will just send the seqno it received in the unspecified mechanism, and
increment it plus one.

Or maybe as part of an enhanced DHCP procedure, or AAA, or link-layer
authentication procedure.

The LMA is supposed to provide MN's home prefix already to the MAG, thus
it can provide the right seqno to it as well.

> By mandating the support, the LMA can always return its timestamp and
>  the MAG can use that timestamp and register. This need to be done 
> just once whenever the LMA/MAG clocks are out of sync and just for 
> one registration. One extra round trip for the 1st registration 
> between LMA/MAG pair.

But this can be achieved with the seqnos as well, not necessarily to
send the timestamp.

> for each MN registration (at handoff).

No, not always an extra round trip necessary.  (For our audience: in
private I've discussed with Ahmad and Sri at least three possible ways
to sync these seqnos and two of them assumed extra round trips.)

I think that if the right seqno is provided by LMA to MAG as part of
that 'profile' then MAG can simply increment it and send the proper
seqno to LMA.  This involves no additional roundtrip.

> defining an error code "Timestamp option not supported".

I'm happy you already agreed not to mandate timestamp, thanks for that.

For error "Timestamp option not supported" then one would have to define
"seqno option not supported" too, right?

> Implementation MUST support Timestamp option: [Yes/No]

No, it's not necessary to say that implementation MUST support timestamp
option.

An alternative is just an alternative.

Alex

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 7 Sep 2007 11:03:49 +0200

Hi Sri,

I haven't had time to catch up yet with the new draft, so I apologize if any of my comments below has already been addresed

Sri> ... what are we mandating? The ability for the LMA to generate a Timestamp and return the timestamp option ...
I'm trying to understand the motivation for this mandate

I understand the need in the LMA to identify the sequence of BUs in order to avoid race conditions when more than one MAG can send a BU for the same user
The minimum requirement from LMA point of view is that the ID carried in the BU represents a free-running counter that increases monotonically
It follows that the requirement for the MAGs is to synchronize the values used in the BU-ID
Let me stress that these "minimum requirements" are only for synchronization between MAGs, i.e. not including LMA

Timestamps is a valid solution for filling in the ID when there's time synchronization (with sufficient accuracy) between MAGs
Let me stress that the precondition for using timestamps should only be synchronization between MAGs, i.e. not including LMA
By including LMA in the equation, it seems that we're trying to correct deviations in the time synchronization of MAGs via PMIP
That is, the LMA becomes some kind of synch Master. Honestly, I don't think it is right to extend PMIP scope in such way

Let me cite your answers to Alper (from another email):
Sri> ... It is important to highlight the fact that we need this entire synchronization logic to avoid one scenario, where the LMA ends up processing a PBU that was sent by pMAG and the LMA received that much later due to network out of order deliverly ...
[FDJ] This problem statement seems wrong. Unordered delivery because of nw congestion does not make any difference
What matters is the relationship between the ID sent by the pMAG and the one sent by the nMAG
The only requirement that we can make is that pMAG and nMAG must synchronize this ID
There's no way the LMA can't tell in which order these 2 BUus were sent if the IDs are not-synchronized

Sri> ... If a deployment does not enable NTP kind of protocols and if the LMA receives a packet with PBU from a MAG with a invalid timestamp, the LMA can return its own timestamp and the MAG can use the same in the requests to avoid this special race condition ...
[FDJ] If the deployment does not enable NTP, all PBUs will have a wrong ID. Or do you expect the MAG to synch to the same timebase as the LMA when the LMA returns the timestamp option?
Furthermore, I fail to understand the solution you propose: how can the LMA declare that the ID (timestamp) is invalid?
Use case:
   - pMAG send BU at 10 AM
   - nMAG sends BU at 11 AM
   - LMA receives BU from nMAG at 11:15 AM. Will it return timestamp to nMAG, so that the BU can be resent?
   - LMA receives BU from pMAG at 11:30 AM. Will it retun timestamp to pMAG, so that BU can be resent? Or maybe the proposal is that LMA will decide that pMAG BU was sent earlier than nMAG BU and therefore discard it. The latter makes sense but it means that the LMA has to assume that pMAG and nMAG are in synch. And then we're back to the minimum requirement

In summary, in my opinion:
   1- The LMA MAY be able to generate timestamps (but should not be required to)
   2- The LMA MAY know that the source used for the ID is a timestamp (but should not be required to)
   3- If the LMA is not timestamp aware, the MAG MAY use timestamps (but should not be required to)
   4- If the LMA is timestamp aware, the MAG MAY use timestamps (but should not be required to)
If any of the 4 statements would reduce the usability of PMIP in any way, I would appreciate to have a more clear problem statement
Thus: Implementation MUST support Timestamp option: No
And I would even push it further: if the previous 4 statements can be agreed to, then the logical conclusion is that timestamps can be left out of the specification (at most an informative note would do)

A couple of collateral comments:
   - I understand that CT (Context Transfer) is already acknowledged as a valid alternative solution
   For some reason, CT is left out of scope. Fine for me, but I don't think it's a fair consequence to mandate timestamps
   The fact that "context transfer is out of scope" doesn't equate to "there is no context transfer"
   Is it the working assumption that a solution without CT is simpler than a solution with CT? This would be a wrong assumption
   If we have to choose between specifying timestamps or specifying CT, then I prefer the latter. It's clear that it will require more work but it will be more useful

   - If a nMAG sends a BU for a given user without synchronization with pMAG it may be useful to have the option to indicate it to the LMA
   In other words, I propose a flag "OOS ID" (Out of Synch ID) sent by the MAG, so that the LMA can reset the sequencing algorithm for a given MN

   - I have read in other emails that timestamps are already a proven concept in MIP4
   I fail to understand how this argument makes a difference, since the original problem statement is that the MIP client (the one generating BUs) in case of PMIP (i.e. the MAG) may change during the lifetime of a MIP session. The problem addressed in MIP4 is a different one (replay protection). It's off-topic, but I find this area of MIP4 overspecified when compared to approaches in other protocols (e.g. IEEE 802.16). A monotonically increasing counter is sufficient for replay protection

Regards

federico

-----Message d'origine-----
De : Sri Gundavelli [mailto:[email-masked]] 
Envoyé : jeudi 6 septembre 2007 21:58
À : 'Alexandru Petrescu'; 'netlmm'
Objet : RE: [netlmm] timestamp vs seqno redux

Please comment on this issue raised by Alex about mandating Timestamp option. Alex is right, when we discussed this issue, the conclusion was to use Timestamp based approach, but we did not discuss if that was supposed to be mandatory to implement.

How does it impact, if some deployment wants to use Seq Number approach ?

Base draft does not support Context Transfers. Given that the draft will be incomplete, if we dont mandate the support. By mandating the support, the LMA can always return its timestamp and the MAG can use that timestamp and register. This need to be done just once whenever the LMA/MAG clocks are out of sync and just for one registration. One extra round trip for the 1st registration between LMA/MAG pair.

But, if the LMA falls back to the seq number based approach and if there are no context transfers, there is always an extra round trip for each MN registration (at handoff). 

So, I prefer the mandatory approach, its more efficient. But, as I had it in the initial suggested text, I'm ok not mandating this and defining an error code "Timestamp option not supported". 

Thanks
Sri

> around the timestamp vs seqno.  People keep saying that seqno method 
> is a possible alternative to timestamp but at the same time they 
> mandate in the document the timestamp method.  This is complete 
> nonsense.
>

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 7 Sep 2007 11:09:01 +0200

Hi Sri, 

> - We are NOT mandating the nodes in the domain to sync up to

Hmm, so far I assumed that the proposal is to mandate the MAGs to sync
up to an external clock source such as NTP server.

> registration. One extra round trip for the 1st registration between

So the proposal is to allow the use of the timestamp option in the
absence of any external time synchronization like NTP and to mandate a
mechanism to synchronize clocks between MAGs and LMA (and hence between
all MAGs) using the timestamp option in PBU/PBA only (i.e., without
utilizing NTP or an external clock source)? Is my understanding correct?

If so, can you please give some more details how the LMA can detect that
the clocks are out of sync? Is it based on a certain difference of
timestamp in the received PBU and the current LMA's time? 

And how to differentiate the out of sync case from the out-of-order
delivery case (i.e., a PBU is delayed and overtaken by another PBU from
another MAG)? For instance, if the LMA receives a PBU with timestamp
equal to "current time of LMA - X" and X > threshold, how does the LMA
know whether the 
1. the MAG clock is synchronized, but the PBU got delayed by X or
2. the PBU is not delayed, but the MAG's clock is out of sync by X?
Ideally, in case 1 the LMA should just ignore the PBU, in case 2 it
should accept it and sync clocks.

If the idea is to always reject a PBU with X > threshold and include a
current timestamp in the PBA, then I guess the same could be done with
sequence numbers instead of timestamps, right?

BR,

Kilian

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: Julien Laganier <[email-masked]>
Date: Fri, 7 Sep 2007 14:19:23 +0200

> Implementation MUST support Timestamp option: [Yes/No]

YES.

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 7 Sep 2007 08:18:25 -0500

Hi Alex,

Please see comments inline.

> Timestamp  
> I agree it's not much code to call an API to obtain current 
> time.  What is more is to encode the message format of that 
> time into the Mobile
> IPv6 implementation.
> 
> The spec can very easily say that in order for the P-BUs to 
> be correctly ordered at the HA then the HA should provide the 
> correct seqno to the MAG, as part of the 'profile' related to 
> MN, or as part of some other assumed and non-specified 
> mechanism.  When MAG sends a P-BU to MAG it will just send 
> the seqno it received in the unspecified mechanism, and 
> increment it plus one.
> 
> Or maybe as part of an enhanced DHCP procedure, or AAA, or 
> link-layer authentication procedure.
> 
> The LMA is supposed to provide MN's home prefix already to 
> the MAG, thus it can provide the right seqno to it as well.
> 
> > the MAG can use that timestamp and register. This need to 
> be done just 
> But this can be achieved with the seqnos as well, not 
> necessarily to send the timestamp.
> 
> No, not always an extra round trip necessary.  (For our 
> audience: in private I've discussed with Ahmad and Sri at 
> least three possible ways to sync these seqnos and two of 
> them assumed extra round trips.)

{Ahmad]
Alex, the fact that we did not continue the offline discussion is
because you preferred to bring this to the mailing list which is
absolutely fine with me. It does not mean that I agreed with any of your
proposals. 

You keep saying that the SQN can be provided by the LMA via a profile. I
want you to be specific here, tell me how that would work. In details.

My understudying that profile comes from a policy server or whatever.
The SQN is a per-MN dynamically always changing. In your response please
consider how the LMA will always update the profile with the last SQN.

Thanks.

> 
> I think that if the right seqno is provided by LMA to MAG as 
> part of that 'profile' then MAG can simply increment it and 
> send the proper seqno to LMA.  This involves no additional roundtrip.

[Ahmad]
I disagree, The only feasible and meaningful way to provide the SQN
without extra outstanding effort is Context Transfer and the draft
acknowledged that. Please see the above comment.

> 
> > So, I prefer the mandatory approach, its more efficient. 
> But, as I had 
> > it in the initial suggested text, I'm ok not mandating this and 
> For error "Timestamp option not supported" then one would 
> have to define "seqno option not supported" too, right?

[Ahmad]
Not right.
PMIPv6 is based on RFC3775 and we agreed long time ago, LMA supports SQN
either way. It is part of the Mobility header. Right? How the LMA would
survive all of this without supporting SQN, unless you are proposing
deprecating it?

> No, it's not necessary to say that implementation MUST 
> support timestamp option.

[Ahmad]
Ok, I guess you meant to say, that it is not necessary for
implementation to support the use of timestamp for P-BU/P-BA ordering.
In all conditions, implementation MUST support the timestamp option but
not necessarily the use of it. Because, in order to reject timestamp
option, implementation MUST understand the option itself. Right?

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 7 Sep 2007 08:24:51 -0500

Hi Sri,

Regards,
Ahmad

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Thursday, September 06, 2007 2:58 PM
> To: 'Alexandru Petrescu'; 'netlmm'
> Subject: RE: [netlmm] timestamp vs seqno redux
> 
> 
> Timestamp option. Alex is right, when we discussed this 
> issue, the conclusion was to use Timestamp based approach, 
> but we did not discuss if that was supposed to be mandatory 
> to implement.
> 
> Base draft does not support Context Transfers. Given that the 
> draft will be incomplete, if we dont mandate the support. By 
> mandating the support, the LMA can always return its 
> timestamp and the MAG can use that timestamp and register. 
> This need to be done just once whenever the LMA/MAG clocks 
> are out of sync and just for one registration. One extra 
> round trip for the 1st registration between LMA/MAG pair.

[Ahmad]
I agree.
> 
> But, if the LMA falls back to the seq number based approach 
> and if there are no context transfers, there is always an 
> extra round trip for each MN registration (at handoff).

[Ahmad]
TRUE. 
Unless there is a mechanism to communicate the last SQN the pMAG used
for the MN to the nMAG, it is almost always requires 2 round trips.. 
> 
> So, I prefer the mandatory approach, its more efficient. But, 
> as I had it in the initial suggested text, I'm ok not 
> mandating this and defining an error code "Timestamp option 
> not supported". 

[Ahmad]
As my initial suggestion was, I believe this is the best approach. I
support that.
> Implementation MUST support Timestamp option: [Yes/No]

[Ahmad]
Let me rephrase this question, as I mentioned in my response to Alex
earlier.

Implementation Must support timestamp option however, the mechanism to
use timestamp for ordering P-BU/P-BA is optional.
In that case, I support this approach.

As I said earlier, in order for the MAG to send "timestamp mechanism NOT
supported", it needs to understand the timestamp option.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2007 15:33:53 +0200

Ahmad Muhanna wrote:
[...]
>>> But, if the LMA falls back to the seq number based approach and 
>>> if there are no context transfers, there is always an extra round
>>>  trip for each MN registration (at handoff).
>> No, not always an extra round trip necessary.  (For our audience: 
>> in private I've discussed with Ahmad and Sri at least three 
>> possible ways to sync these seqnos and two of them assumed extra 
>> round trips.)
> 
> {Ahmad] Alex, the fact that we did not continue the offline 
> discussion is because you preferred to bring this to the mailing list
>  which is absolutely fine with me. It does not mean that I agreed
> with any of your proposals.

Right, I know, you didn't agree, and I didn't imply you agreed.  I agree
with you on this.

> You keep saying that the SQN can be provided by the LMA via a 
> profile. I want you to be specific here, tell me how that would work.
>  In details.
> 
>  The SQN is a per-MN dynamically always changing. In your response 
> please consider how the LMA will always update the profile with the 
> last SQN.

Ahmad, when first the 'profile' is delivered by the 'policy server' or
whatever to the MAG then the LMA inserts the current seqno in that
profile.  It is not necessary to insert every time, just the first time
the MN authenticates.  This is the same  time when the home prefix (the
one that has to be put in the RA) is delivered in that same profile.

Don't you think this can work?  Why not?  Why can the LMA send to MAG
the home network prefix of the MN but not its current seqno?

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 7 Sep 2007 08:45:04 -0500

Hi Alex,
Please find comments inline.

Regards,
Ahmad

> Subject: Re: [netlmm] timestamp vs seqno redux
> 
> Ahmad Muhanna wrote:
> [...]
> >> in private I've discussed with Ahmad and Sri at least 
> three possible 
> >> ways to sync these seqnos and two of them assumed extra 
> round trips.)
> > 
> discussion 
> > is because you preferred to bring this to the mailing list  
> which is 
> > absolutely fine with me. It does not mean that I agreed with any of 
> > your proposals.
> 
> Right, I know, you didn't agree, and I didn't imply you 
> agreed.  I agree with you on this.
> 
> > You keep saying that the SQN can be provided by the LMA via 
> a profile. 
> > I want you to be specific here, tell me how that would work.
> >  In details.
> > 
> Ahmad, when first the 'profile' is delivered by the 'policy 
> server' or whatever to the MAG then the LMA inserts the 
> current seqno in that profile.  

{Ahmad]
I do not understand this sentence, can you elaborate. I understand the
portion of how the policy server may deliver the profile to the MAG.
Now, how the LMA then will insert the current SQN in that profile which
already in the hand of the MAG.?
Am I missing something?

> It is not necessary to insert 
> every time, just the first time the MN authenticates.  

[Ahmad]
What does this mean Alex. Are you assuming that there is no
re-registration possibility here?

> This 
> is the same  time when the home prefix (the one that has to 
> be put in the RA) is delivered in that same profile.

[Ahmad]
I am truly confused here. May be if you give a call flow or a step by
step mechanism, I would be able to understand what you mean.
> 
> Don't you think this can work? Why not?

{Ahmad]
It is not clear to me what is the proposal yet to give a verdict here.

> Why can the LMA 
> send to MAG the home network prefix of the MN but not its 
> current seqno?

[Ahmad]
This I understand, but the current RFC3775 mechanism is BROKEN and needs
to be fixed. 
We need to have a new option "Last Successful SQN" it currently does not
exist.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2007 16:18:38 +0200

Ahmad Muhanna wrote:
[...]
>>>  please consider how the LMA will always update the profile with
>>>  the last SQN.
>> Ahmad, when first the 'profile' is delivered by the 'policy server'
>>  or whatever to the MAG then the LMA inserts the current seqno in 
>> that profile.
> 
> {Ahmad] I do not understand this sentence, can you elaborate. I 
> understand the portion of how the policy server may deliver the 
> profile to the MAG.

(btw this is the part that _I_ don't understand can you please
  elaborate: how does the 'policy server' deliver the profile to MAG?).

> Now, how the LMA then will insert the current SQN in that profile 
> which already in the hand of the MAG.? Am I missing something?

In the same way that it sends the home prefix to the MAG.

>> It is not necessary to insert every time, just the first time the 
>> MN authenticates.
> 
> [Ahmad] What does this mean Alex. Are you assuming that there is no 

Once a seqno is sent to the MAG then MAG knows from where to send its
increments.  And yes, there is re-registration possible.

Each time a MAG obtains a home prefix to send in RS to the MN it also 
obtains the current seqno that LMA keeps with respect to that MN.

Both the home prefix and the seqno are managed on a per-MN basis.

>> This is the same  time when the home prefix (the one that has to be
>>  put in the RA) is delivered in that same profile.
> 
> [Ahmad] I am truly confused here. May be if you give a call flow or a
>  step by step mechanism, I would be able to understand what you mean.

HEre is topology and message exchange diagram, is this more clear?

    ----      -----            -----
   | MN |----| MAG |----------| LMA |
    ----      -----            -----
                                 |
                               ---------------
                              |'Policy Server'|
                               ---------------

   MN        MAG        LMA       'Policy Server'
   | L2 trig |          |         |
   |-------->|  'Profile|Req'     |
   |         |----------o-------->|
   |         |  'Profile|Ack'     |
   |         |<---------o---------|(Home Prefix and seqno)
   |         |   P-BU   |         |
   |         |--------->|         |(inc'ed seqno)
   |         |   P-BAck |         |
   |   RA    |<---------|         |
   |<------- |          |         |
   |         |          |         |

> {Ahmad] It is not clear to me what is the proposal yet to give a 
> verdict here.

Please let me know how can I clarify more.

>> Why can the LMA send to MAG the home network prefix of the MN but 
>> not its current seqno?
> 
> [Ahmad] This I understand, but the current RFC3775 mechanism is 
> BROKEN and needs to be fixed. We need to have a new option "Last 
> Successful SQN" it currently does not exist.

(Errr... so MIP6-3775 has an issue with the way it deals with sequence
  numbers, right?   The issue is listed here:
  http://www.mip4.org/issues/tracker/mip6/issue101

  In there you propose a solution: communicate the last valid seqno by HA
  to MN.

  Do you want to discuss that issue in MIP6 WG?  It doesn't warrant the
  introduction of timestamps in P-MIPv6 IMHO.)

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 7 Sep 2007 09:40:15 -0500

> Cc: Sri Gundavelli; netlmm

[Ahmad]
There are more than one way for that delivery right. Offline Via AAA for
example. Please see more below.

> In the same way that it sends the home prefix to the MAG.

[Ahmad]
Ok, let us continue.
> 
> >> It is not necessary to insert every time, just the first 
> time the MN 
> >> authenticates.
> > 
> Once a seqno is sent to the MAG then MAG knows from where to 
> send its increments.  And yes, there is re-registration possible.
> 
> Each time a MAG obtains a home prefix to send in RS to the MN 
> it also obtains the current seqno that LMA keeps with respect 
> to that MN.
> 

[Ahmad]
You have the following assumptions here:

1. The delivery of the MN/User profile always goes through the LMA. 
2. MAG always know what LMA the MN is attached to. I am not sure how
this would happen without context transfer or during access
authentication.
3. LMA is able to update the policy reply back to the MAG and inserts
the last SQN used in the user profile or,
3.1. LMA always updates the policy server of the latest successful SQN
for that user.

Are those valid assumptions here or you have a problem with any?

> HEre is topology and message exchange diagram, is this more clear?

[Ahmad]
Please see the assumptions listed above and let me know if you
agree/disagree with any of them in order to comment further.
> 
> >> Why can the LMA send to MAG the home network prefix of the 
> MN but not 
> >> its current seqno?
> > 
> > [Ahmad] This I understand, but the current RFC3775 
> mechanism is BROKEN 
> > and needs to be fixed. We need to have a new option "Last 
> Successful 

[Ahmad]
If we need to discuss this issue it must be on MIPv6 mailing list. 
Second, I am not saying that the reason behind introducing timestamp. I
never said that SQN can not be made to work. As a matter of fact that
what the spec reflects. However, there are more than one way to make SQN
works and that is beyond the scope of PMIPv6 base protocol spec.

That's all here. However, I still believe that RFC3775 issue needs to be
fixed. But that is a different animal.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 7 Sep 2007 09:54:43 -0500

Hi Kilian,

Regards,
Ahmad

> Hmm, so far I assumed that the proposal is to mandate the 
> MAGs to sync up to an external clock source such as NTP server.

[Ahmad]
May be the spec can specify if timestamp mechanism is used, then MAGs
needs to sync up to an external clock source, e.g. NTP server. That
should not be a problem, I think.

> > will be incomplete, if we dont mandate the support. By 
> mandating the 
> > support, the LMA can always return its timestamp and the 
> MAG can use 
> > that timestamp and register. This need to be done just once 
> whenever 
> > the LMA/MAG clocks are out of sync and just for one 
> registration. One 
> > extra round trip for the 1st registration between LMA/MAG pair.
> 
> So the proposal is to allow the use of the timestamp option 
> in the absence of any external time synchronization like NTP 
> and to mandate a mechanism to synchronize clocks between MAGs 
> and LMA (and hence between all MAGs) using the timestamp 
> option in PBU/PBA only (i.e., without utilizing NTP or an 
> external clock source)? Is my understanding correct?

[Ahmad]
That is NOT my understanding here. The mandate is for the use of
timestamp mechanism in ordering P-BU/P-BA. In case timestamp is used,
the best approach is to have the MAGs synchronizes their timestamp via
an external server, e.g. NTP.
> 
> If so, can you please give some more details how the LMA can 
> detect that the clocks are out of sync? Is it based on a 
> certain difference of timestamp in the received PBU and the 
> current LMA's time? 

[Ahmad]
That is possible. Why not?

> 
> And how to differentiate the out of sync case from the 
> out-of-order delivery case (i.e., a PBU is delayed and 
> overtaken by another PBU from another MAG)? For instance, if 
> the LMA receives a PBU with timestamp equal to "current time 
> of LMA - X" and X > threshold, how does the LMA know whether 
> the 1. the MAG clock is synchronized, but the PBU got delayed 
> by X or 2. the PBU is not delayed, but the MAG's clock is out 
> of sync by X?
> Ideally, in case 1 the LMA should just ignore the PBU, in 
> case 2 it should accept it and sync clocks.
> 
> If the idea is to always reject a PBU with X > threshold and 
> include a current timestamp in the PBA, then I guess the same 
> could be done with sequence numbers instead of timestamps, right?

[Ahmad]
No. They are not the same here.
The possibility of the timestamp to go out of synch over the threshold
every handoff registration does not exit. The MAG needs to track a
global time delta per a peer LMA. MAG can update the global option every
time a P-BA with code 135 arrives.

On the other hand, in the absence of a mechanism to communicate the SQN,
every handoff registration warrants a 2 round trip. Right?

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2007 16:55:32 +0200

> 1. The delivery of the MN/User profile always goes through the LMA. 

I'm talking about the home network prefix of the MN.  That will always 
go through LMA, because LMA is in charge, topologically correct, of that 
prefix.  You can't have any other entity to send the home prefix of MN 
to MN without letting LMA know about that.

> this would happen without context transfer or during access

I don't know either.  How do you assume the current P-MIPv6 MAG to send 
the P-BU to what LMA?

> the last SQN used in the user profile or,

Right, I assumed that.

> 3.1. LMA always updates the policy server of the latest successful SQN

I didn't assume that.

The LMA maintains that seqno and it doesn't communicate it to anybody 
else but to MAG.

If you want to have the 'policy server' to maintain the home network 
prefix of each MN then this server has to work in synch with the HA somehow.

Because a 'policy server' can not be in charge of any prefix.

> Are those valid assumptions here or you have a problem with any?

I think I don't have any problem with any.
> fixed. But that is a different animal.

Ok, so let's discuss the 3775isssue of seqnos in MIP6.

And discuss here how seqnos can work ok with P-MIPv6.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 7 Sep 2007 10:28:51 -0500

> I'm talking about the home network prefix of the MN.  That 
> will always go through LMA, because LMA is in charge, 
> topologically correct, of that prefix.  You can't have any 
> other entity to send the home prefix of MN to MN without 
> letting LMA know about that.

[Ahmad]
Alex,

I understand that LMA in charge of the maintenance of its network
topology, whatever, you would like to call it. Including the HNP. Okay.

Let us focus here on the HNP first and SQN becomes redundant.
Now, It seems we have different opinions on how the HNP is communicated
back to the MAG.

somehow you believe that the HNP will always be communicated back to the
MAG via LMA.
I have a problem with this assumption, as follows:

My understanding is that there are two options that have been discussed:

1. MAG receive the HNP before establishing P-MIP session, i.e. before
sending P-BU/P-BA.
1.1. In this mechanism it does not make any sense for this mechanism to
be done through the LMA.
1.2. MAG request the profile from the Policy server which maintains the
HNP of the user. I do not think this a huge issue here and it can be
done, is that the best option, that is a different discussion.
1.3. Policy server delivers the user profile (Assuming that the LMA and
Policy server are in sync) In other words, yes, LMA supports the HNP
configured in the policy server and it is available.
1.4. When the MAG receives the user profile from the policy server, MAG
finds the following information: 
1.4.1. User NAI 
1.4.2. LMA IP address
1.4.3. IP address Configuration

Optionally:
1.4.4. HNP (this was made optional because there is another mechanism
which I will list in a second)

1.5. After the MAG receives the user profile, MAG sends a P-BU to the
LMA and include the HNP.

** Optionally MAG may start advertising the HNP to the MN via RA  or
wait after successful P-BA arrives **
1.6. LMA send a successful P-BA only if the HNP is correct and all other
stuff.
1.7. MAG receives P-BA and user is registered.

In this scenario, tell me where the LMA can update the user profile by
the last successful SQN. It is only possible if the LMA always goes back
to the Policy Server and update the policy server with the last
successful SQN per-MN. I guess that probably a killing!

2. MAG receive the HNP in the P-BA after inserting an All-ZERO in the
HNP/HoA option in the P-BU:
This mechanism is exactly the same as per option 1 until (1.3) for this
one let us say 2.3.

2.4. MAG will receive the profile BUT there is no HNP.
2.5. After the MAG receives the user profile, MAG sends a P-BU to the
LMA and include an all-ZEROS in the HNP option.
2.6. LMA send a successful P-BA with a valid HNP/HoA IP address if all
other validations are correct.
2.7. MAG receives P-BA and ONLY then advertise the HNP to the MN.

NOW: In this scenario, tell me where the LMA can update the user profile
by the last successful per-MN SQN. 

> I don't know either.  How do you assume the current P-MIPv6 
> MAG to send the P-BU to what LMA?

[Ahmad]
Please see above. It is only arrives after the MAG already consulted the
policy server.

> > 3.1. LMA always updates the policy server of the latest 

[Ahmad]
Please check above and tell me how your proposal would work without this
assumption.

> 
> The LMA maintains that seqno and it doesn't communicate it to 
> anybody else but to MAG.

How? In P-BA, it is too late and that is what is called 2 round trips.
Right?

> 
> If you want to have the 'policy server' to maintain the home 
> network prefix of each MN then this server has to work in 
> synch with the HA somehow.
[Ahmad]
That is not my option but that is one of the options that is already
documented in the spec. I assume that is also a valid assumption.

> Because a 'policy server' can not be in charge of any prefix.

[Ahmad]
I am not sure why, but that is irrelevant here.

> I think I don't have any problem with any.

[Ahmad]
Actually you had a problem with one which is part of 3.1. Please see
comments above.

> >>   In there you propose a solution: communicate the last 
> valid seqno 
> >> by HA
> >>   to MN.
> >>
> >>   Do you want to discuss that issue in MIP6 WG?  It 
> doesn't warrant 
> >> the
> > Second, I am not saying that the reason behind introducing 
> timestamp. 
> > I never said that SQN can not be made to work. As a matter of fact 
> > that what the spec reflects. However, there are more than 
> one way to 
> > make SQN works and that is beyond the scope of PMIPv6 base 
> protocol spec.
> > 
> > That's all here. However, I still believe that RFC3775 
> issue needs to 
> > be fixed. But that is a different animal.
> 

[Ahmad]
Agreed.
> And discuss here how seqnos can work ok with P-MIPv6.
[Ahmad]
Agreed.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2007 17:55:09 +0200

Ahmad Muhanna wrote:
>>> [Ahmad] You have the following assumptions here:
>>> 
>> I'm talking about the home network prefix of the MN.  That will
>> always go through LMA, because LMA is in charge, topologically
>> correct, of that prefix.  You can't have any other entity to send
>> the home prefix of MN to MN without letting LMA know about that.
> 
> [Ahmad] Alex,
> 
> Let us focus here on the HNP first and SQN becomes redundant. Now, It
> seems we have different opinions on how the HNP is communicated back
> to the MAG.
> 
> somehow you believe that the HNP will always be communicated back to
> the MAG via LMA. I have a problem with this assumption, as follows:
> 

Right... that's what I've assumed.

> 1.1. In this mechanism it does not make any sense for this mechanism
> to be done through the LMA. 1.2. MAG request the profile from the
> Policy server which maintains the HNP of the user. I do not think
> this a huge issue here and it can be done, is that the best option,
> that is a different discussion.

How?  Which protocol?

> 1.3. Policy server delivers the user profile (Assuming that the LMA
> and Policy server are in sync) In other words, yes, LMA supports the
> HNP configured in the policy server and it is available. 1.4. When
> the MAG receives the user profile from the policy server, MAG finds
> the following information: 1.4.1. User NAI 1.4.2. LMA IP address 

How does the 'policy server' know the IP address configuration of MN?
It's the LMA who communicated it to 'policy server', right?

> Optionally: 1.4.4. HNP (this was made optional because there is
> another mechanism which I will list in a second)
> 
> wait after successful P-BA arrives ** 1.6. LMA send a successful P-BA
> only if the HNP is correct and all other stuff. 1.7. MAG receives
> P-BA and user is registered.
> 
> In this scenario, tell me where the LMA can update the user profile
> by the last successful SQN.

In step 1.4.3: how does the 'policy server' know the 'IP address
configuration' to send to MAG?  The only way it could know it is to
learn it from LMA.  At that learning point the LMA sends the last
successful seqno as well.

> It is only possible if the LMA always goes back to the Policy Server
> and update the policy server with the last successful SQN per-MN. I
> guess that probably a killing!

We can have the 'policy server' to always request the LMA before sending 
IP address information to MAG.  This happens only at first MN attaching 
to MAG.

If you talk about overkill, I think the whole reliance on a 'policy 
server' is overkill.

>  HNP/HoA option in the P-BU: This mechanism is exactly the same as
> per option 1 until (1.3) for this one let us say 2.3.

Right... in this case, in addition to HNP All-ZERO, the MAG will put a 
seqno equal All-ZERO and the LMA will reply back the current seqno.

> 2.4. MAG will receive the profile BUT there is no HNP. 2.5. After the
> MAG receives the user profile, MAG sends a P-BU to the LMA and
> include an all-ZEROS in the HNP option. 2.6. LMA send a successful
> P-BA with a valid HNP/HoA IP address if all other validations are
> correct. 2.7. MAG receives P-BA and ONLY then advertise the HNP to
> the MN.
> 
> NOW: In this scenario, tell me where the LMA can update the user
> profile by the last successful per-MN SQN.

In this last scenario 2, you don't have a 'policy server', so only the 
LMA is involved.  The 'policy profiler machine' will not update the user 
profile.

Could you please picture a message exchange with what you think the 
first steps are and then I'll paste into these first steps where the 
seqno fits.

> How? In P-BA, it is too late and that is what is called 2 round
> trips. Right?

Well, if you put 00 instead of a home address in the P-BU then you can 
put a 00 in the place of the seqno as well.  There will only be one 
pbu/pback initially.  The LMA will just not increment its seqno when it 
receives a seqno 00.

The LMA can not receive two P-BUs with seqno 00 from two different MAGs. 
   BEcause MAG can not be attached to two MAGs simultaneously.

Alex

>> network prefix of each MN then this server has to work in synch
>> with the HA somehow.
> [Ahmad] That is not my option but that is one of the options that is
> already documented in the spec. I assume that is also a valid
> assumption.
> 
> [Ahmad] I am not sure why, but that is irrelevant here.

> [Ahmad] Actually you had a problem with one which is part of 3.1.
> Please see comments above.
> 
>>> 
>>>> ----      -----            ----- | MN |----| MAG |----------|
>>>> LMA | ----      -----            ----- | --------------- 
>>>> |'Policy Server'| ---------------
>>>> 
>>>> 
>>>> MN        MAG        LMA       'Policy Server' | L2 trig |
>>>> |         | |-------->|  'Profile|Req'     | |
>>>> |----------o-------->| |         |  'Profile|Ack'     | |
>>>> |<---------o---------|(Home Prefix and seqno) |         |
>>>> P-BU   |         | |         |--------->|         |(inc'ed
>>>> seqno) |         |   P-BAck |         | |   RA    |<---------|
>>>> | |<------- |          |         | |         |          |
>>>> |
>>>> 
>>>>> {Ahmad] It is not clear to me what is the proposal yet to
>>>>> give a verdict here.
>>> [Ahmad] Please see the assumptions listed above and let me know
>>> if you agree/disagree with any of them in order to comment
>>> further.
>>>> by HA to MN.
>>>> the introduction of timestamps in P-MIPv6 IMHO.)
>>> [Ahmad] If we need to discuss this issue it must be on MIPv6
>>> mailing list. Second, I am not saying that the reason behind
>>> introducing
>> timestamp.
>>> I never said that SQN can not be made to work. As a matter of
>>> fact that what the spec reflects. However, there are more than
>> one way to
> [Ahmad] Agreed.
> [Ahmad] Agreed.
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit 
>> http://www.messagelabs.com/email

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 7 Sep 2007 11:30:13 -0500

Hi Alex,

Regards,
Ahmad

> >> correct, of that prefix.  You can't have any other entity 
> to send the 
> >> home prefix of MN to MN without letting LMA know about that.
> > 
> > [Ahmad] Alex,
> > 

[Ahmad]
But how that can be done through the LMA before exchanging P-BU/P-BA?

> > Policy server which maintains the HNP of the user. I do not 
> think this 
> > a huge issue here and it can be done, is that the best 
> option, that is 
> > a different discussion.
> 
> How?  Which protocol?
> 
> > HNP configured in the policy server and it is available. 
> 1.4. When the 
> > MAG receives the user profile from the policy server, MAG finds the 
> > following information: 1.4.1. User NAI 1.4.2. LMA IP 
> address 1.4.3. IP 
> > address Configuration
> 

[Ahmad]
Alex, 
we are not talking about the MN IP address, it is the whole HNP. 
Regardless. Now, how the Policy server know which HNP is out-of-scope of
this discussion and the PMIPv6 spec.

> > only if the HNP is correct and all other stuff. 1.7. MAG 
> receives P-BA 
> > and user is registered.
> > 
> > the last successful SQN.
> In step 1.4.3: how does the 'policy server' know the 'IP 
> address configuration' to send to MAG?  The only way it could 
> know it is to learn it from LMA.  At that learning point the 
> LMA sends the last successful seqno as well.

{Ahmad]
Step 1.4.3. Is not a step in the call flow, I am just listing what are
the things saved in the user profile!
How to get these information into the user profile can be achieved via
many other ways and out-of-scope here and irrelevant. If you think that
is done dynamically by the LMA while establishing a PMIP session for the
user, I can tell you that is NOT correct. IMO.

> We can have the 'policy server' to always request the LMA 
> before sending IP address information to MAG.  This happens 
> only at first MN attaching to MAG.

{Ahmad]
No problem, you can suggest whatever you want, however, that is
out-of-scope of the PMIP spec. IMO, it is not the best option!

> 
> If you talk about overkill, I think the whole reliance on a 
> 'policy server' is overkill.

[Ahmad]
May be. However, to dynamically update the policy server with the latest
SQN in order to solve your issue here is not an overkill, it is a little
more:-)

> > HNP/HoA option in the P-BU: This mechanism is exactly the 
> same as per 
> > option 1 until (1.3) for this one let us say 2.3.
> 
> Right... in this case, in addition to HNP All-ZERO, the MAG 
> will put a seqno equal All-ZERO and the LMA will reply back 
> the current seqno.

[Ahmad]
Good suggestion, Do you expect the LMA to send a successful P-BA or a
P-BA with code 135?
1. If you expect LMA to send 135 and the latest SQN, that is 2 round
trip!
2. If you expects the LMA to accept the P-BU and sends a successful P-BA
with latest SQN, that is a horrible thing. The least to say.
3. Also, you are creating a problem in matching the P-BA with the
outstanding P-BU for nothing.

> > MAG receives the user profile, MAG sends a P-BU to the LMA 
> and include 
> > an all-ZEROS in the HNP option. 2.6. LMA send a successful 
> P-BA with a 
> > valid HNP/HoA IP address if all other validations are correct. 2.7. 
> > MAG receives P-BA and ONLY then advertise the HNP to the MN.
> > 
> In this last scenario 2, you don't have a 'policy server', so 
> only the LMA is involved.  The 'policy profiler machine' will 
> not update the user profile.

[Ahmad]
Alex, Please go back and read it one more time.

> 
> Could you please picture a message exchange with what you 
> think the first steps are and then I'll paste into these 
> first steps where the seqno fits.
> 

[Ahmad]
Sincerely, I do not have the time to do it and I apologize for not being
able to deliver on your request.

> Well, if you put 00 instead of a home address in the P-BU 
> then you can put a 00 in the place of the seqno as well.  
> There will only be one pbu/pback initially.  The LMA will 
> just not increment its seqno when it receives a seqno 00.
> 

[Ahmad]

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 7 Sep 2007 09:47:47 -0700

Hi Kilian,

> From: Kilian Weniger [mailto:[email-masked]] 
> Sent: Friday, September 07, 2007 2:09 AM
> To: Sri Gundavelli
> Cc: [email-masked]

For the timestamp option to work, we RECOMMEND the use of NTP for
synchronizing the clocks in the domain. However, we do not want to
mandate on a specific mechanism. 

> utilizing NTP or an external clock source)? Is my 

No. For this to work, we require the clocks to be in sync.
How its achieved, it could be based on NTP or some other protocols.
But, why should we mandate this.

> detect that

For what ever reasons if the LMA and MAG clocks are out of sync, the
LMA can return its timestamp and the MAG can always apply that delta
in all the registration it sends. This is done just once, when ever
the clocks are off. But, with seq number scheme, this needs to be done
for each MN registration. Its as per the 3775 per MN seq number.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 7 Sep 2007 10:01:50 -0700

Hi Federico,
 
Please see inline ..

> From: DE JUAN HUARTE FEDERICO 
> [mailto:[email-masked]] 
> Sent: Friday, September 07, 2007 2:04 AM
> To: Sri Gundavelli
> Cc: netlmm
> I haven't had time to catch up yet with the new draft, so I 
> apologize if any of my comments below has already been addresed
> 
> Sri> ... what are we mandating? The ability for the LMA to 
> generate a Timestamp and return the timestamp option ...
> I understand the need in the LMA to identify the sequence of 
> BUs in order to avoid race conditions when more than one MAG 
> can send a BU for the same user
> The minimum requirement from LMA point of view is that the ID 
> carried in the BU represents a free-running counter that 
> increases monotonically
> Let me stress that these "minimum requirements" are only for 
> synchronization between MAGs, i.e. not including LMA
> 
> Timestamps is a valid solution for filling in the ID when 
> there's time synchronization (with sufficient accuracy) between MAGs
> Let me stress that the precondition for using timestamps 
> should only be synchronization between MAGs, i.e. not including LMA
> By including LMA in the equation, it seems that we're trying 
> to correct deviations in the time synchronization of MAGs via PMIP
> That is, the LMA becomes some kind of synch Master. Honestly, 
> I don't think it is right to extend PMIP scope in such way
> 

No, that is not true. We are not trying to sync clocks
using PMIP. Allowing LMA to return its own timestamp, essentially
establishes one node in that domain to dictate some order, in
the absence of NTP snchronization. In a network with multiple
nodes, we need a global scale such as a timestamp. We either
depend on NTP to synchronize all the clocks in the node or
let LMA always returns its timestamp, so as for the MAG to
use that timestamp (delta) in the subsequent requests. Otherwise,
every MAG in the network may be sending different timestamps and
the LMA would not know, which one to accept.

> Sri> ... It is important to highlight the fact that we need 
> this entire synchronization logic to avoid one scenario, 
> where the LMA ends up processing a PBU that was sent by pMAG 
> and the LMA received that much later due to network out of 
> order deliverly ...
> [FDJ] This problem statement seems wrong. Unordered delivery 
> because of nw congestion does not make any difference
> There's no way the LMA can't tell in which order these 2 BUus 
> were sent if the IDs are not-synchronized
> 

It does. The race condition would not be an issue, if LMA 
receives packets in the order in which they were generated
by different MAG's. The LMA may potentially delete a valid 
current binding, because it received a stale binding from
the prev MAG. 

If pMAG and nMAG can synchronize the id's, the whole issue
is mute. That is the alternative approach to timestamp based
scheme that the draft supports. MAG can certainly send the
seq number of the MN that it obtained as part of handoff using
CT. No need for timestamps there.

> Sri> ... If a deployment does not enable NTP kind of 
> protocols and if the LMA receives a packet with PBU from a 
> MAG with a invalid timestamp, the LMA can return its own 
> timestamp and the MAG can use the same in the requests to 
> avoid this special race condition ...
> [FDJ] If the deployment does not enable NTP, all PBUs will 
> have a wrong ID. Or do you expect the MAG to synch to the 
> same timebase as the LMA when the LMA returns the timestamp option?
> Furthermore, I fail to understand the solution you propose: 
> how can the LMA declare that the ID (timestamp) is invalid?
> Use case:
>    - pMAG send BU at 10 AM
>    - nMAG sends BU at 11 AM
>    - LMA receives BU from nMAG at 11:15 AM. Will it return 
> timestamp to nMAG, so that the BU can be resent?

The LMA returns its timestamp if it detects that the clocks
are out of sync. 

>    - LMA receives BU from pMAG at 11:30 AM. Will it retun 
> timestamp to pMAG, so that BU can be resent? Or maybe the 
> proposal is that LMA will decide that pMAG BU was sent 
> earlier than nMAG BU and therefore discard it.

Yes. The LMA will discard it. You should read the Timestamp
section.

 The latter 
> makes sense but it means that the LMA has to assume that pMAG 
> and nMAG are in synch. And then we're back to the minimum requirement
> 
>    2- The LMA MAY know that the source used for the ID is a 
> timestamp (but should not be required to)
>    3- If the LMA is not timestamp aware, the MAG MAY use 
> timestamps (but should not be required to)
>    4- If the LMA is timestamp aware, the MAG MAY use 
> timestamps (but should not be required to)
> If any of the 4 statements would reduce the usability of PMIP 
> in any way, I would appreciate to have a more clear problem statement

Ok.

> And I would even push it further: if the previous 4 
> statements can be agreed to, then the logical conclusion is 
> that timestamps can be left out of the specification (at most 
> an informative note would do)
> 
>    - I understand that CT (Context Transfer) is already 
> acknowledged as a valid alternative solution
>    For some reason, CT is left out of scope. Fine for me, but 
> I don't think it's a fair consequence to mandate timestamps

But, the base draft has to be complete. We should allow deployments
to happen just based on this spec. If we dont support Timestamp
and if there is no CT, how will registrations happen ? The LMA
will always reject the first request for each MN. 

>    Is it the working assumption that a solution without CT is 
> simpler than a solution with CT? This would be a wrong assumption
>    If we have to choose between specifying timestamps or 
> specifying CT, then I prefer the latter. It's clear that it 
> will require more work but it will be more useful
> 
>    - If a nMAG sends a BU for a given user without 
> synchronization with pMAG it may be useful to have the option 
> to indicate it to the LMA
>    In other words, I propose a flag "OOS ID" (Out of Synch 
> ID) sent by the MAG, so that the LMA can reset the sequencing 
> algorithm for a given MN
> 
>    I fail to understand how this argument makes a difference, 
> since the original problem statement is that the MIP client 
> (the one generating BUs) in case of PMIP (i.e. the MAG) may 
> change during the lifetime of a MIP session. The problem 
> addressed in MIP4 is a different one (replay protection). 
> It's off-topic, but I find this area of MIP4 overspecified 
> when compared to approaches in other protocols (e.g. IEEE 
> 802.16). A monotonically increasing counter is sufficient for 
> replay protection
> 

Agree, the purpose is different. But, replay protection has a
relation to time window. Timestamp provides the validity for
the same message. Its the same thing here, just that the window
is small.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2007 20:33:05 +0200

Ahmad, both you and me have exposed our reasons.

I think both of us make some assumptions in order for our preferred 
method to work (seqno vs timestamp).

But as you can see, me and you are not the only one expressing opinions 
on this topic.

I would call for Chair judgment.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 7 Sep 2007 15:25:19 -0500

Hi Alex,

I am not sure what is the best approach for moving forward. 
But that should not be a problem.

Cheers.

Regards,
Ahmad

> Sent: Friday, September 07, 2007 1:33 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> I think both of us make some assumptions in order for our 
> preferred method to work (seqno vs timestamp).
> 
> But as you can see, me and you are not the only one 
> expressing opinions on this topic.
> 
> > Regardless. Now, how the Policy server know which HNP is 
> out-of-scope 
> > of this discussion and the PMIPv6 spec.
> > 
> > 
> > many other ways and out-of-scope here and irrelevant. If you think 
> > that is done dynamically by the LMA while establishing a 
> PMIP session 
> > for the user, I can tell you that is NOT correct. IMO.
> > 
> >>
> >> We can have the 'policy server' to always request the LMA before 
> >> sending IP address information to MAG.  This happens only 
> at first MN 
> >> attaching to MAG.
> > 
> > {Ahmad]
> > May be. However, to dynamically update the policy server with the 
> > latest SQN in order to solve your issue here is not an 
> overkill, it is 
> > a little
> > more:-)
> > 
> >> Right... in this case, in addition to HNP All-ZERO, the 
> MAG will put 
> >> a seqno equal All-ZERO and the LMA will reply back the 
> current seqno.
> > 
> > [Ahmad]
> > 2. If you expects the LMA to accept the P-BU and sends a successful 
> > P-BA with latest SQN, that is a horrible thing. The least to say.
> >> In this last scenario 2, you don't have a 'policy server', so only 
> >> the LMA is involved.  The 'policy profiler machine' will 
> not update 
> >> the user profile.
> > 
> > [Ahmad]
> think the 
> > Sincerely, I do not have the time to do it and I apologize for not 
> > being able to deliver on your request.
> > 
> >> Well, if you put 00 instead of a home address in the P-BU then you 
> >> can put a 00 in the place of the seqno as well.
> >> There will only be one pbu/pback initially.  The LMA will just not 
> >> increment its seqno when it receives a seqno 00.
> >>

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Mon, 10 Sep 2007 19:44:28 +0200

Hi Sri,

thanks for your answer
I've taken some time to process your answer and what is written in the draft (v3)

>From your email answer:
Sri> ... Allowing LMA to return its own timestamp, essentially establishes one node in that domain to dictate some order, in the absence of NTP snchronization ...
Sri> ... We either depend on NTP to synchronize all the clocks in the node or let LMA always returns its timestamp, ...

I understand now that there's a case that I had not taken into account:
   1- The MAGs may be syncronized by context transfer => SeqNum in BU
   2- The MAGs may be synchronized by a common time reference => SeqNum (carrying a timestamp) in BU
   3- The MAGs may be not-synchronized at all => timestamp option
Can you confirm that the timestamp option is only to cover case #3?
By the way the draft is written (section 5.4), it's not clear to me if you also expect the MAGs to use the timestamp option in case #2 (connected to a common time reference). I think in case #2 the LMA should not interfere with the explicit mechanism used to synchronize clocks (e.g. NTP)

In case #3, (MAGs not connected to a common time reference), I still perceive that the draft expects the LMA to become a sort of Time Reference Master

In general, I can't see how the timestamp option can provide a deterministic behavior and therefore I don't think that the draft should RECOMMEND it, unless the following points are addressed:
   - for the timestamp option to work, the rate of BUs between a given MAG and a given LMA should not allow for time deviations larger than the threshold to declare a timestamp as invalid
   - A factor to take into account is RTDs (RoundTrip Delays) between MAGs and LMA: if the pMAG-LMA RTD is larger than the nMAG-LMA RTD then the pMAG "clock" will be delayed with respect to the one of the nMAG
   - Unclear what the effects of congestion will be: if the link between the LMA and the pMAG is more congested than the link between the LMA and the nMAG, the previous effect will be even worse
   - Something that needs to be considered in this discussion is how/when resources will be released by the pMAG. If there's no communication between pMAG and nMAG, there will need to be a timeout or a revocation message from the LMA. In any case, there's a period of time between the nMAG sending the BU and the pMAG releasing its own binding. During this period of time the pMAG may send a BU, thereby creating a race condition. In the extreme case, both the pMAG and the nMAG may send the BU with the same time (virtually)
   - When connected to multiple LMAs (e.g. roaming), MAGs have to maintain multiple timers (one per LMA). Doable but complex
Can you please tell me if the following concerns have been raised before and if yes how are they addressed?

In my opinion, NETLMM should RECOMMEND the MAGs to be synchronized (case #1 or case #2) and not the timestamp option (as in section 5.4)
In these conditions, a non-synchronized MAG is an error case (thus infrequent): #1) context transfer didn't take place or #2) lost synchronization with the time reference.
In order to address such error case it is enough to let the MAG indicate it explicitly to the LMA, so that the LMA can (exceptionally) ignore the sequencing.
I don't see much added value in a solution like #3 (LMA as Time Reference Master), but I'm not against describing it in the spec as long as it is not REQUIRED or RECOMENDED

A couple side reactions:
Sri> But, the base draft has to be complete. We should allow deployments to happen just based on this spec. If we dont support Timestamp and if there is no CT, how will registrations happen ? The LMA will always reject the first request for each MN. 
MAGs need to be synchronized (CT or common time ref). The first BU of all will need to carry a "Reset-Synch" flag
Any MAG that is not synched (no CT or no connectivity to time ref) SHOULD also assert the "Reset-Synch" flag

Sri> ...replay protection has a relation to time window. Timestamp provides the validity for the same message. Its the same thing here, just that the window is small.
We have very different opinions here, but as long as replay protection is not an argument for the timestamp option, no need to discuss it

Regards

federico

-----Message d'origine-----
De : Sri Gundavelli [mailto:[email-masked]] 
Envoyé : vendredi 7 septembre 2007 19:02
À : DE JUAN HUARTE FEDERICO
Cc : 'netlmm'
Objet : RE: [netlmm] timestamp vs seqno redux

Hi Federico,
 
Please see inline ..

> I haven't had time to catch up yet with the new draft, so I apologize 
> if any of my comments below has already been addresed
> 
> I understand the need in the LMA to identify the sequence of BUs in 
> order to avoid race conditions when more than one MAG can send a BU 
> for the same user The minimum requirement from LMA point of view is 
> that the ID carried in the BU represents a free-running counter that 
> increases monotonically It follows that the requirement for the MAGs 
> is to synchronize the values used in the BU-ID Let me stress that 
> these "minimum requirements" are only for synchronization between 
> MAGs, i.e. not including LMA
> 
> Timestamps is a valid solution for filling in the ID when there's time 
> synchronization (with sufficient accuracy) between MAGs Let me stress 
> that the precondition for using timestamps should only be 
> synchronization between MAGs, i.e. not including LMA By including LMA 
> in the equation, it seems that we're trying to correct deviations in 
> the time synchronization of MAGs via PMIP That is, the LMA becomes 
> some kind of synch Master. Honestly, I don't think it is right to 
> extend PMIP scope in such way
> 

No, that is not true. We are not trying to sync clocks using PMIP. Allowing LMA to return its own timestamp, essentially establishes one node in that domain to dictate some order, in the absence of NTP snchronization. In a network with multiple nodes, we need a global scale such as a timestamp. We either depend on NTP to synchronize all the clocks in the node or let LMA always returns its timestamp, so as for the MAG to use that timestamp (delta) in the subsequent requests. Otherwise, every MAG in the network may be sending different timestamps and the LMA would not know, which one to accept.

> this entire synchronization logic to avoid one scenario, where the LMA 
> ends up processing a PBU that was sent by pMAG and the LMA received 
> that much later due to network out of order deliverly ...
> [FDJ] This problem statement seems wrong. Unordered delivery because 
> of nw congestion does not make any difference What matters is the 
> relationship between the ID sent by the pMAG and the one sent by the 
> nMAG The only requirement that we can make is that pMAG and nMAG must 
> synchronize this ID There's no way the LMA can't tell in which order 
> these 2 BUus were sent if the IDs are not-synchronized
> 

It does. The race condition would not be an issue, if LMA receives packets in the order in which they were generated by different MAG's. The LMA may potentially delete a valid current binding, because it received a stale binding from the prev MAG. 

If pMAG and nMAG can synchronize the id's, the whole issue is mute. That is the alternative approach to timestamp based scheme that the draft supports. MAG can certainly send the seq number of the MN that it obtained as part of handoff using CT. No need for timestamps there.

> protocols and if the LMA receives a packet with PBU from a MAG with a 
> invalid timestamp, the LMA can return its own timestamp and the MAG 
> can use the same in the requests to avoid this special race condition 
> ...
> [FDJ] If the deployment does not enable NTP, all PBUs will have a 
> wrong ID. Or do you expect the MAG to synch to the same timebase as 
> the LMA when the LMA returns the timestamp option?

The LMA returns its timestamp if it detects that the clocks are out of sync. 

>    - LMA receives BU from pMAG at 11:30 AM. Will it retun timestamp to 
> pMAG, so that BU can be resent? Or maybe the proposal is that LMA will 
> decide that pMAG BU was sent earlier than nMAG BU and therefore 
> discard it.

Yes. The LMA will discard it. You should read the Timestamp section.

 The latter 
> makes sense but it means that the LMA has to assume that pMAG and nMAG 
> are in synch. And then we're back to the minimum requirement
> 
>    4- If the LMA is timestamp aware, the MAG MAY use timestamps (but 
> should not be required to) If any of the 4 statements would reduce the 
> usability of PMIP in any way, I would appreciate to have a more clear 
> problem statement

Ok.

> And I would even push it further: if the previous 4 statements can be 
> agreed to, then the logical conclusion is that timestamps can be left 
> out of the specification (at most an informative note would do)
> 
>    For some reason, CT is left out of scope. Fine for me, but I don't 
> think it's a fair consequence to mandate timestamps

But, the base draft has to be complete. We should allow deployments to happen just based on this spec. If we dont support Timestamp and if there is no CT, how will registrations happen ? The LMA will always reject the first request for each MN. 

>    Is it the working assumption that a solution without CT is simpler 
> than a solution with CT? This would be a wrong assumption
>    If we have to choose between specifying timestamps or specifying 
> CT, then I prefer the latter. It's clear that it will require more 
> work but it will be more useful
> 
>    - If a nMAG sends a BU for a given user without synchronization 
> with pMAG it may be useful to have the option to indicate it to the 
> LMA
>    I fail to understand how this argument makes a difference, since 
> the original problem statement is that the MIP client (the one 
> generating BUs) in case of PMIP (i.e. the MAG) may change during the 
> lifetime of a MIP session. The problem addressed in MIP4 is a 
> different one (replay protection).
> It's off-topic, but I find this area of MIP4 overspecified when 
> compared to approaches in other protocols (e.g. IEEE 802.16). A 
> monotonically increasing counter is sufficient for replay protection
> 

Agree, the purpose is different. But, replay protection has a relation to time window. Timestamp provides the validity for the same message. Its the same thing here, just that the window is small.

Sri

> De : Sri Gundavelli [mailto:[email-masked]] Envoyé : jeudi 6 
> septembre 2007 21:58 À : 'Alexandru Petrescu'; 'netlmm'
> will be incomplete, if we dont mandate the support. By mandating the 
> support, the LMA can always return its timestamp and the MAG can use 
> that timestamp and register.
> This need to be done just once whenever the LMA/MAG clocks are out of 
> sync and just for one registration. One extra round trip for the 1st 
> registration between LMA/MAG pair.
> 
> So, I prefer the mandatory approach, its more efficient. But, as I had

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 10 Sep 2007 10:52:09 -0700

Hi Federico,

Two quick comments. I will respond to your other comments
later.

Sri

> Sent: Monday, September 10, 2007 10:44 AM
> To: Sri Gundavelli
> Cc: netlmm
> Sri> ... Allowing LMA to return its own timestamp, 
> essentially establishes one node in that domain to dictate 
> some order, in the absence of NTP snchronization ...
> Sri> ... We either depend on NTP to synchronize all the 
> clocks in the node or let LMA always returns its timestamp, ...
> 
> By the way the draft is written (section 5.4), it's not clear 
> to me if you also expect the MAGs to use the timestamp option 
> in case #2 (connected to a common time reference). I think in 
> case #2 the LMA should not interfere with the explicit 
> mechanism used to synchronize clocks (e.g. NTP)
> 
> In case #3, (MAGs not connected to a common time reference), 
> I still perceive that the draft expects the LMA to become a 
> sort of Time Reference Master
>

This is required. If we dont keep LMA timestamp in the loop, there
will be one issue. If MN starts at MAG1 and for what ever reasons
the timstamp of that MAG is bad (running 8 hours ahead) and if
LMA accepts the BU without using its own time as a reference or
for sanity check, any subsequent registrations from other MAG's
for that MN will not go thru. As the time stamp will be older
timestamp.

Also, the timestamp text section was reviewed by the WG and there
is consensus on this text. Unless, we failed to understand all
the issues.

Sri

> In general, I can't see how the timestamp option can provide 
> a deterministic behavior and therefore I don't think that the 
> draft should RECOMMEND it, unless the following points are addressed:
>    - for the timestamp option to work, the rate of BUs 
> between a given MAG and a given LMA should not allow for time 
> deviations larger than the threshold to declare a timestamp as invalid
>    - A factor to take into account is RTDs (RoundTrip Delays) 
> between MAGs and LMA: if the pMAG-LMA RTD is larger than the 
> nMAG-LMA RTD then the pMAG "clock" will be delayed with 
> respect to the one of the nMAG
>    - Unclear what the effects of congestion will be: if the 
> link between the LMA and the pMAG is more congested than the 
> link between the LMA and the nMAG, the previous effect will 
> be even worse
>    - Something that needs to be considered in this discussion 
> is how/when resources will be released by the pMAG. If 
> there's no communication between pMAG and nMAG, there will 
> need to be a timeout or a revocation message from the LMA. In 
> any case, there's a period of time between the nMAG sending 
> the BU and the pMAG releasing its own binding. During this 
> period of time the pMAG may send a BU, thereby creating a 
> race condition. In the extreme case, both the pMAG and the 
> nMAG may send the BU with the same time (virtually)
>    - When connected to multiple LMAs (e.g. roaming), MAGs 
> have to maintain multiple timers (one per LMA). Doable but complex
> Can you please tell me if the following concerns have been 
> raised before and if yes how are they addressed?
> 
> In my opinion, NETLMM should RECOMMEND the MAGs to be 
> synchronized (case #1 or case #2) and not the timestamp 
> option (as in section 5.4)
> In these conditions, a non-synchronized MAG is an error case 
> (thus infrequent): #1) context transfer didn't take place or 
> #2) lost synchronization with the time reference.
> In order to address such error case it is enough to let the 
> MAG indicate it explicitly to the LMA, so that the LMA can 
> (exceptionally) ignore the sequencing.
> I don't see much added value in a solution like #3 (LMA as 
> Time Reference Master), but I'm not against describing it in 
> the spec as long as it is not REQUIRED or RECOMENDED
> 
> A couple side reactions:
> Sri> But, the base draft has to be complete. We should allow 
> deployments to happen just based on this spec. If we dont 
> support Timestamp and if there is no CT, how will 
> registrations happen ? The LMA will always reject the first 
> request for each MN. 
> MAGs need to be synchronized (CT or common time ref). The 
> first BU of all will need to carry a "Reset-Synch" flag
> Any MAG that is not synched (no CT or no connectivity to time 
> ref) SHOULD also assert the "Reset-Synch" flag
> 
> Sri> ...replay protection has a relation to time window. 
> Timestamp provides the validity for the same message. Its the 
> same thing here, just that the window is small.
> We have very different opinions here, but as long as replay 
> protection is not an argument for the timestamp option, no 
> need to discuss it
> 
> Regards
> 
> federico
> 
> apologize 
> there's time 
> No, that is not true. We are not trying to sync clocks using 
> PMIP. Allowing LMA to return its own timestamp, essentially 
> use that timestamp (delta) in the subsequent requests. 
> Otherwise, every MAG in the network may be sending different 
> timestamps and the LMA would not know, which one to accept.
> 
> 
> where the LMA 
> receives packets in the order in which they were generated by 
> different MAG's. The LMA may potentially delete a valid 
> current binding, because it received a stale binding from the 
> prev MAG. 
> 
> If pMAG and nMAG can synchronize the id's, the whole issue is 
> mute. That is the alternative approach to timestamp based 
> seq number of the MN that it obtained as part of handoff 
> using CT. No need for timestamps there.
> 
> 
> MAG with a 
> timestamp to 
> timestamps (but 
> statements can be 
> >    The fact that "context transfer is out of scope" doesn't 
> equate to 
> > "there is no context transfer"
> 
> But, the base draft has to be complete. We should allow 
> deployments to happen just based on this spec. If we dont 
> support Timestamp and if there is no CT, how will 
> registrations happen ? The LMA will always reject the first 
> request for each MN. 
> 
> >    - I have read in other emails that timestamps are 
> already a proven 
> > concept in MIP4
> the same message. Its the same thing here, just that the 
> window is small.
> 
> Sri
> 
> 
> 
> > Regards
> > 
> > federico
> > 
> > 
> > 
> > 
> are out of

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 10 Sep 2007 13:33:58 -0500

Hi Federico,

I just would like to make one comment quickly here and we can go over other issues later.
Timestamp option still needs to be used in Case No. 2 as you specified below. Otherwise, how the whole sequencing would work? Right?

Regards,
Ahmad

> Sent: Monday, September 10, 2007 12:44 PM
> To: Sri Gundavelli
> Cc: netlmm
>    3- The MAGs may be not-synchronized at all => timestamp 
> option Can you confirm that the timestamp option is only to 
> cover case #3?

[Ahmad]
Timestamp option is used in case 2 and case 3.

> have to maintain multiple timers (one per LMA). Doable but 
> complex Can you please tell me if the following concerns have 
> been raised before and if yes how are they addressed?
> 
> option (as in section 5.4) In these conditions, a 
> non-synchronized MAG is an error case (thus infrequent): #1) 
> context transfer didn't take place or #2) lost 
> synchronization with the time reference.
> first BU of all will need to carry a "Reset-Synch" flag Any 
> MAG that is not synched (no CT or no connectivity to time 
> De : Sri Gundavelli [mailto:[email-masked]] Envoyé : 
> vendredi 7 septembre 2007 19:02 À : DE JUAN HUARTE FEDERICO 
> Cc : 'netlmm'

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 10 Sep 2007 13:39:42 -0500

Hi Federico,
It seems that I did not read the whole case No. 2.

You are proposing a new mechanism/field to use timestamp. 
I agree with Sri, That has been discussed and agreed upon. 

Regards,
Ahmad

> From: Muhanna, Ahmad (RICH1:2H10) 
> Sent: Monday, September 10, 2007 1:34 PM
> To: 'DE JUAN HUARTE FEDERICO'; 'Sri Gundavelli'
> Cc: 'netlmm'
> Timestamp option still needs to be used in Case No. 2 as you 
> specified below. Otherwise, how the whole sequencing would 
> work? Right?
> 
> 
> Regards,
> Ahmad
>  
> 
> > I've taken some time to process your answer and what is 
> written in the 
> > draft (v3)
> > 
> > >From your email answer:
> option Can 
> > you confirm that the timestamp option is only to cover case #3?
> 
> [Ahmad]
> > By the way the draft is written (section 5.4), it's not 
> clear to me if 
> > you also expect the MAGs to use the timestamp option in case #2 
> > (connected to a common time reference). I think in case #2 the LMA 
> > should not interfere with the explicit mechanism used to 
> synchronize 
> > clocks (e.g. NTP)
> > 
> > In case #3, (MAGs not connected to a common time 
> reference), I still 
> > perceive that the draft expects the LMA to become a sort of Time 
> > Reference Master
> > 
> > In general, I can't see how the timestamp option can provide a 
> > deterministic behavior and therefore I don't think that the draft 
> > should RECOMMEND it, unless the following points are addressed:
> between a given 
> > MAG and a given LMA should not allow for time deviations 
> larger than 
> > the threshold to declare a timestamp as invalid
> >    - A factor to take into account is RTDs (RoundTrip 
> Delays) between 
> > MAGs and LMA: if the pMAG-LMA RTD is larger than the 
> nMAG-LMA RTD then 
> > the pMAG "clock" will be delayed with respect to the one of the nMAG
> >    - Unclear what the effects of congestion will be: if the link 
> > between the LMA and the pMAG is more congested than the 
> link between 
> > the LMA and the nMAG, the previous effect will be even worse
> >    - Something that needs to be considered in this discussion is 
> > how/when resources will be released by the pMAG. If there's no 
> > communication between pMAG and nMAG, there will need to be 
> a timeout 
> > or a revocation message from the LMA. In any case, there's 
> a period of 
> > time between the nMAG sending the BU and the pMAG releasing its own 
> > binding. During this period of time the pMAG may send a BU, thereby 
> > creating a race condition. In the extreme case, both the 
> pMAG and the 
> >    - When connected to multiple LMAs (e.g. roaming), MAGs have to 
> > maintain multiple timers (one per LMA). Doable but complex Can you 
> > please tell me if the following concerns have been raised 
> before and 
> > if yes how are they addressed?
> > 
> > In my opinion, NETLMM should RECOMMEND the MAGs to be synchronized 
> > (case #1 or case #2) and not the timestamp option (as in 
> section 5.4) 
> > In these conditions, a non-synchronized MAG is an error case (thus 
> > infrequent): #1) context transfer didn't take place or #2) lost 
> > In order to address such error case it is enough to let the MAG 
> > indicate it explicitly to the LMA, so that the LMA can
> > I don't see much added value in a solution like #3 (LMA as Time 
> > Reference Master), but I'm not against describing it in the spec as 
> > long as it is not REQUIRED or RECOMENDED
> > 
> > A couple side reactions:
> > deployments to happen just based on this spec. If we dont support 
> > Timestamp and if there is no CT, how will registrations 
> happen ? The 
> > LMA will always reject the first request for each MN.
> first BU of 
> > all will need to carry a "Reset-Synch" flag Any MAG that is not 
> > synched (no CT or no connectivity to time
> > Timestamp provides the validity for the same message. Its the same 
> > thing here, just that the window is small.
> protection 
> > is not an argument for the timestamp option, no need to discuss it
> > 
> > Regards
> > 
> > federico
> > 
> > vendredi 7 septembre 2007 19:02 À : DE JUAN HUARTE FEDERICO Cc : 
> > 'netlmm'
> > No, that is not true. We are not trying to sync clocks using PMIP. 
> > Allowing LMA to return its own timestamp, essentially 
> establishes one 
> > node in that domain to dictate some order, in the absence of NTP 
> > snchronization. In a network with multiple nodes, we need a global 
> > scale such as a timestamp. We either depend on NTP to 
> synchronize all 
> > the clocks in the node or let LMA always returns its 
> timestamp, so as 
> > for the MAG to use that timestamp (delta) in the subsequent 
> requests.
> > It does. The race condition would not be an issue, if LMA receives 
> > packets in the order in which they were generated by 
> different MAG's. 
> > The LMA may potentially delete a valid current binding, because it 
> > received a stale binding from the prev MAG.
> > 
> > If pMAG and nMAG can synchronize the id's, the whole issue is mute. 
> > That is the alternative approach to timestamp based scheme that the 
> > draft supports. MAG can certainly send the seq number of 
> the MN that 
> > it obtained as part of handoff using CT. No need for 
> timestamps there.
> > 
> > 
> > >    1- The LMA MAY be able to generate timestamps (but 
> should not be 
> > > required to)
> specifying 
> synchronization

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 11 Sep 2007 15:33:01 +0200

Hi Sri,

my point is that NOT mandating synchronization to an external clock
source for the timestamp option implies that sending PBU msgs with
timestamp option is allowed even when MAGs are not (yet) synchronized.
I.e., it would be allowed that a deployment uses only the returned
timestamps in PBA msgs to synchronize the MAG clocks. I think the draft
should not allow this for the following reasons:

1. If a MAG's clock is out of sync (i.e., not yet synced by receiving a
PBA with timestamp) AND PBUs sent by this MAG are delayed, the out of
sync situation may not be detectable by the LMA and old PBUs may be
accepted by the LMA. 

Consider the following example: MN attaches to MAG1 and shortly
thereafter hands over to MAG2. MAG2's clock is in sync with LMA's clock,
but MAG1's clock is out of sync and is ahead of LMA's clock by 5
seconds. MAG1-LMA link is highly congested. When MN attaches to MAG1,
MAG1 sends PBU1 msg to LMA. This happens 3 seconds before the MN hands
over to MAG2. The PBU1 msg is delayed by 5 seconds due to the congestion
and hence arrives at LMA 2 seconds after handover. Despite of the delay,
PBU1 has a valid timestamp from LMA's point of view due to the wrong
clock of MAG1. MAG2 sends a PBU2 msg 1 second after handover. PBU2 is
not significantly delayed and arrives at LMA ~1 seconds after handover
with valid timestamp. In this scenario, the LMA will wrongly accept PBU1
arriving after PBU2, since both have a valid timestamp. Consequently,
the LMA forwards packets to the wrong MAG (MAG1) and will not notice the
out of sync of MAG1, which also means that the LMA doesn't return a
timestamp in the PBA and MAG1's clock keeps to be out of sync.

2. When packets on the link between MAG and LMA experience high (and
varying) packet delays (e.g., due to congestion), the timestamp in the
PBA returned by the LMA may already be outdated at the time it arrives
at the MAG. So exactly in the situation where a re-ordering of PBUs is
needed, the synchronization mechanism may fail.

My two cents.

BR,

Kilian

> Sent: Freitag, 7. September 2007 18:48
> To: 'Kilian Weniger'
> Cc: [email-masked]
> MAGs to sync

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Tue, 11 Sep 2007 17:14:34 +0200

Hi Ahmad,

I don't see why do you consider that sending the timestamp in the SeqNum is a new mechanism
IMO, it's something that can already be done with any MIP implementation

The difference between sending timestamp in SeqNum or sending it in TS option is that in the former case the LMA would not need to worry about sending the TS option back
In other words, I see a difference between:
   1- Sending timestamp in SeqNum => only MAGs need to be time synched
   2- Sending timestamp in TS option => all MAGs and LMAs should be time synched
Choosing between the 2 options is probably deployment dependent
In the first case (LMA is not synched with the MAGs) what is the added value of using the TS option instead of carrying the timestamp in SeqNum?

Ahmad> I agree with Sri, That has been discussed and agreed upon. 
Was it agreed to use time synchronization (thus #1 falls in the agreement) or to use the timestamp option (only #2 can be considered)?
Anyway, I understood from Sri call for inputs that he was pushing the TS option beyond what had been agreed, so I presume that there's (some) room for closing this issue properly

Regards

federico

PS: I'm discussing with Sri offline, so given that you have an opinion I'll add you in CC

-----Message d'origine-----
De : Ahmad Muhanna [mailto:[email-masked]] 
Envoyé : lundi 10 septembre 2007 20:40
À : Ahmad Muhanna; DE JUAN HUARTE FEDERICO; Sri Gundavelli
Cc : netlmm
Objet : RE: [netlmm] timestamp vs seqno redux

Hi Federico,

Regards,
Ahmad

> Timestamp option still needs to be used in Case No. 2 as you specified 
> below. Otherwise, how the whole sequencing would work? Right?
> 
> 
> Regards,
> Ahmad
>  
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 11 Sep 2007 10:19:55 -0500

Hi Federico,

Please see one clarification inline.

Regards,
Ahmad

> I don't see why do you consider that sending the timestamp in 
> the SeqNum is a new mechanism IMO, it's something that can 
> already be done with any MIP implementation

[Ahmad]
Are you suggesting that the timestamp will be inserted in the already defined SQN field of the P-BU/P-BA?
I just wanted to understand this point to make sure that we are on the same page.

Thanks.
> 
> The difference between sending timestamp in SeqNum or sending 
> it in TS option is that in the former case the LMA would not 
> need to worry about sending the TS option back In other 
> words, I see a difference between:
>    2- Sending timestamp in TS option => all MAGs and LMAs 
> should be time synched Choosing between the 2 options is 
> probably deployment dependent In the first case (LMA is not 
> synched with the MAGs) what is the added value of using the 
> TS option instead of carrying the timestamp in SeqNum?
> 
> Was it agreed to use time synchronization (thus #1 falls in 
> the agreement) or to use the timestamp option (only #2 can be 
> considered)?
> Anyway, I understood from Sri call for inputs that he was 
> pushing the TS option beyond what had been agreed, so I 
> presume that there's (some) room for closing this issue properly
> 
> Regards
> 
> federico
> 
> De : Ahmad Muhanna [mailto:[email-masked]] Envoyé : 
> lundi 10 septembre 2007 20:40 À : Ahmad Muhanna; DE JUAN 
> HUARTE FEDERICO; Sri Gundavelli Cc : netlmm Objet : RE: 
> [netlmm] timestamp vs seqno redux
> 
> 
> Hi Federico,
> > I just would like to make one comment quickly here and we 
> can go over 
> > other issues later.
> synchronized 
> using PMIP. 
> receives

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 11 Sep 2007 23:14:09 -0700

Hi Kilian/Federico,

> Sent: Tuesday, September 11, 2007 6:33 AM
> To: Sri Gundavelli
> Cc: [email-masked]

The stated assumption for the timestamp based approach to work,
is the requirement for the MAG's to have synchronized clocks.
That is a requirement. Now, if a given MAG sends a PBU with an
incorrect timestamp, its an error and as you and Federico pointed
out, there are cases where the LMA will not be able to determine
the sending order of the received packets. This is an error
condition, as the requirement is not met.

Now, should the draft state that the time synchronization is a
requirement and additionally mandate a method of time synchronization,
say by NTP ? But, the later has a system wide impact and additionally,
a given architecture where this protocol is applied, can achieve the
time synchronization through other non NTP means. IMO, we may not
be able dictate that. Also, we want implementations to support the
timestamp based scheme by default. Now, mandating the NTP usage will
create some restrictions for some deployments. So, that is the
reasoning behind not mandating the method of time synchronization.

W.r.t this below scenario, the reason for LMA to return its timestamp,
solves two purposes. 1.) Diagnostics (especially useful when the LMA
and MAG are in different admin domains) 2.) The MAG can detect that
its clock is not in sync and take the necessary actions. I guess,
Frederico has an issue with the second part. But, if you look at
the recommendation from the draft on handling this error case,
MAG signaling considerations, 

      "If the received Proxy Binding Acknowledgement message has the
      Status field value set to TIMESTAMP_MISMATCH (Invalid Timestamp),
      the mobile access gateway SHOULD try to register again only after
      it synchronized its clock with the local mobility anchor's system
      clock or to a common time source that is used by all mobility
      entities in that domain for their clock synchronization."

So, we are not really using the LMA as the time source. Now, with the
given assumptions, do you see an issue if we dont say NTP is a MUST,
but we say clock synch is a requirement, how they do it, draft does
not say. If this requirement is not met, its an incorrect usage of
the protocol and the PBU ordering will fail in that special rare
reordering scenario (IMO, its not a practical issue).

The second question to this discussion, is Alex's point of not
mandating Timestamp option as a MUST implement. For this, as I stated
before, this is few lines of code for supporting this option and if seq
number scheme is in use, this need not be used at all. We need to mandate
this as there is no CT in the base spec. But, this is not a big issue
either way. If others agree, I'm fine not mandating this. But, I really
believe, implementations can support this option, at the least cost.

One last comment on the trust on LMA's clock for the sanity check, is
because its an anchor point and its typically well managed, compared
to MAG's, where they are scattered out. So, its reasonable to expect
the clock on the LMA to be in sync, else all registrations will fail
and will generate the traps.

So, let me know your comments on how we can move forward.

Sri

> out-of-order

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 12 Sep 2007 10:07:29 +0200

Hi Sri, 

please see my comments inline.

> Sent: Mittwoch, 12. September 2007 08:14
> To: 'Kilian Weniger'
> Cc: [email-masked]

Right, sending a PBU with timestamp option requires that the MAG's clock
is synchronized. Hence, I don't see why the draft should specify a
mechanism to synchronize a MAG's clock using a received PBA. Also, I
think this mechanism has issues in some scenario (see my previous mail).

The clock synchronization is the job of some PMIP-independent
synchronization method like NTP and out of sync clocks can only occur if
there is a problem with this PMIP-independent synchronization method.
Hence, it is a non-recoverable error case from PMIP point of view IMHO. 

> reasoning behind not mandating the method of time synchronization.

I'm not sure if the draft can say "a MAG's clock MUST be synchronized
for this protocol to work, but how this is done is out of scope of the
draft". I guess the draft has to mandate the implementation of one
"default" synchronization protocol such as NTP to achieve
interoperability. However, as long as the use of NTP is not mandated
(e.g., just say "SHOULD use"), deployments can still use other methods.
So I don't see restrictions for deployments in this case. 

>       entities in that domain for their clock synchronization."

I think it is good if the LMA informs the MAG about detected out of sync
clocks for the purpose of diagnostics and as a trigger for re-sync. But
why do we need the timestamp option in the PBA? The TIMESTAMP_MISMATCH
value in the status field is enough for the purpose of diagnostics and
as a trigger for re-sync. 

> reordering scenario (IMO, its not a practical issue).

see above

BR,

Kilian

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 12 Sep 2007 09:58:33 -0500

Hi Kilian/Federico and All,

There has been a lot of email exchange that the timestamp
synchronization using the PMIPv6 signaling does not work. On the other
hand, I have not seen any in detail analysis which proves that it does
not work. I would like to share in details my thoughts on how this
SHOULD work and please comment as necessary. 

The following are a list of assumptions:
========================================

1. The time that the P-BU takes from MAG to LMA equals the time the P-BA
takes from LMA to MAG.
2. LMA Timestamp included in the P-BA is the LMA timestamp when
comparing timestamp in P-BU and LMA current timestamp.
3. MAG use the difference between the P-BU timestamp and P-BA timestamp
for calculating the delta!
4. MAG and LMA maintains the same out of sync delta during the
re-synchronization process.

				 MAG
LMA
                     ----------
----------
1. Current Timestamp 	MAG.t1
LMA.t1 = MAG.t1 +d1
2. Timestamp in P-BU    MAG.t1                        LMA timestamp:
LMA.t1
3. MAG sends P-BU	      ============>>>>>>> P-BU(MAG.t1)
4. P-BU arrives at LMA     ....................... ===============>>>>
P-BU(MAG.t1)
5. Arrival Timestamp    MAG.t1 + d2
LMA.t1 + d2

6. delta based on P-BU timestamp                              (LMA.t1 +
d2) - (MAG.t1)
                                                                       =
 
((MAG.t1+d1)+d2) - MAG.t1	
                                                                       =
 
delta.P-BU = d2+d1

7. Real delta
delta.real = d1

8. Timestamp in P-BA    MAG.t2                               LMA.t2 =
(LMA.t1 + d2)
 
P-BA(LMA.t2)<<<<<<<<<<<=====================
9. P-BA arrives @ MAG   MAG.t2 + d2                             LMA.t2 +
d2
10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in corresponding
P-BU)
                              =
                       (LMA.t1 + d2) - MAG.t1
                              =
                       ((MAG.t1 +d1)+d2) -MAG.t1
                        
                      delta = d1+d2

11. Real delta        delta.real = d1

What is the problem here? Or am I missing something?

Let us examine a re-registration or a P-BU/PA exchange based on the
above synchronization:
========================================================================
==================

MN- Resynchronization/Re-registration:
=======================================

12. Current timestamp    MAG.t3                                 LMA.t3 =
MAG.t3 + d1
13. Timestamp in P-BU    MAG.t3 + (d1+d2)                       LMA.t3
14. MAG sends P-BU       ============>>>>>>> P-BU(MAG.t3 + (d2+d1))
15. P-BU arrives at LMA  .......................===============>>>>
P-BU(MAG.t3 + (d1+d2))
16. Arrival Timestamp    MAG.t3 + d2                            LMA.t3 +
d2

17. delta based on P-BU                                     (LMA.t3 +
d2) - (MAG.t3 + (d2+d1))
                                                                       =
                                                        ((MAG.t3+d1)+
d2) - (MAG.t3 + (d2+d1))
                                                                       =
                                                             delta.P-BU
= ZERO

18. Real delta                                               delta.real
= ZERO                                      

Please let me know what I am missing.

If nothing, I hope we can put an end to this debate and MOVE ON.

Regards,
Ahmad

> Sent: Wednesday, September 12, 2007 3:07 AM
> To: Sri Gundavelli
> Cc: [email-masked]
> > > timestamps in PBA msgs to synchronize the MAG clocks. I think the 
> > > draft should not allow this for the following reasons:
> > > 
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Sep 2007 17:23:37 +0200

Ahmad Muhanna wrote:
> synchronization using the PMIPv6 signaling does not work.

It can work.  Implementing it can work in a lab.

But relying on timestamps and correct time keeping is too much reliance 
and too many assumptions on machines keeping correct time.

> On the other

Wrong assumption, lots of links are asymmetric.  This includes ADSL, 
which is a very good candidate for linking the LMA to MAG, by existing 
commercial deployments of WiFi hotspots.

> re-synchronization process.

Could you please send diagrams that are more beautifully spaced, so the 
eye doesn't reject it instinctively... thanks.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 12 Sep 2007 10:25:11 -0500

I am working on reformatting it. Sorry for that.

Regards,
Ahmad

> Sent: Wednesday, September 12, 2007 10:24 AM
> Cc: Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE FEDERICO; 
> [email-masked]
> But relying on timestamps and correct time keeping is too 
> much reliance and too many assumptions on machines keeping 
> correct time.
> 
> > On the other
> > 1. The time that the P-BU takes from MAG to LMA equals the time the 
> > P-BA takes from LMA to MAG.
> 
> Wrong assumption, lots of links are asymmetric.  This 
> includes ADSL, which is a very good candidate for linking the 
> LMA to MAG, by existing commercial deployments of WiFi hotspots.
> 
> > 3. MAG use the difference between the P-BU timestamp and P-BA 
> > timestamp for calculating the delta!
> Could you please send diagrams that are more beautifully 
> spaced, so the eye doesn't reject it instinctively... thanks.
> 
> Alex
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 12 Sep 2007 10:40:58 -0500

Resending hopefully with the correct format.

+++++

                       MAG                                       LMA
                     ----------                             ----------
1. Current Timestamp    MAG.t1                    LMA.t1 = MAG.t1 +d1
2. Timestamp in P-BU    MAG.t1                 LMA timestamp: LMA.t1
3. MAG sends P-BU             ============>>>>>>> P-BU(MAG.t1)

4. P-BU arrives at LMA  .............. ===============>>>> P-BU(MAG.t1)

5. Arrival Timestamp    MAG.t1 + d2                   LMA.t1 + d2
6. delta based on P-BU timestamp                (LMA.t1 + d2)-(MAG.t1)
                                                            =
                                              ((MAG.t1+d1)+d2) - MAG.t1
                                                            =
                                                 delta.P-BU = d2+d1

7. Real delta                                     delta.real = d1

8. Timestamp in P-BA    MAG.t2                  LMA.t2 = (LMA.t1 + d2)
                P-BA(LMA.t2)<<<<<<<<<<<==============
9. P-BA arrives @ MAG   MAG.t2 + d2                LMA.t2 + d2
10. Delta based on P-BA LMA.t2-MAG.t1 (timestamp in corresponding P-BU)
                              =
                       (LMA.t1 + d2) - MAG.t1
                              =
                       ((MAG.t1 +d1)+d2) -MAG.t1

                          delta = d1+d2

12. Current timestamp    MAG.t3                   LMA.t3 = MAG.t3 + d1
13. Timestamp in P-BU    MAG.t3 + (d1+d2)         LMA.t3
14. MAG sends P-BU       ============>>>>>>> P-BU(MAG.t3 + (d2+d1))

15. P-BU arrives at LMA  .......============>>>> P-BU(MAG.t3+(d1+d2))
16. Arrival Timestamp    MAG.t3 + d2                  LMA.t3 + d2
17. delta based on P-BU                     (LMA.t3+d2)-(MAG.t3+(d2+d1))
                                                            =
                                       ((MAG.t3+d1)+d2)-(MAG.t3+(d2+d1))
                                                            =

                                                 delta.P-BU = ZERO
18. Real delta                                   delta.real = ZERO

Regards,
Ahmad

> Sent: Wednesday, September 12, 2007 9:59 AM
> To: 'Kilian Weniger'; 'Sri Gundavelli'; 'DE JUAN HUARTE FEDERICO'
> Cc: [email-masked]'
> synchronization using the PMIPv6 signaling does not work. On 
> the other hand, I have not seen any in detail analysis which 
> proves that it does not work. I would like to share in 
> details my thoughts on how this SHOULD work and please 
> comment as necessary. 
> 
> 1. The time that the P-BU takes from MAG to LMA equals the 
> time the P-BA takes from LMA to MAG.
> 2. LMA Timestamp included in the P-BA is the LMA timestamp 
> when comparing timestamp in P-BU and LMA current timestamp.
> 4. MAG and LMA maintains the same out of sync delta during 
> the re-synchronization process.
> 
> 
> 
> 				 MAG                            
>                LMA
>                      ----------                               
>      ----------
> 2. Timestamp in P-BU    MAG.t1                        LMA 
> timestamp: LMA.t1
> 4. P-BU arrives at LMA     ....................... 
> ===============>>>> P-BU(MAG.t1)
> 6. delta based on P-BU timestamp                              
> (LMA.t1 + d2) - (MAG.t1)
>                                                               
>          =
>                                                               
> 8. Timestamp in P-BA    MAG.t2                               
> LMA.t2 = (LMA.t1 + d2)
>                                     
> 9. P-BA arrives @ MAG   MAG.t2 + d2                           
>   LMA.t2 + d2
> 10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in 
> corresponding P-BU)
>                               =
>                        (LMA.t1 + d2) - MAG.t1
>                               =
> Let us examine a re-registration or a P-BU/PA exchange based 
> on the above synchronization:
> ==============================================================
> ============================
> 
> 12. Current timestamp    MAG.t3                               
>   LMA.t3 = MAG.t3 + d1
> 15. P-BU arrives at LMA  
> .......................===============>>>> P-BU(MAG.t3 + (d1+d2))
> 16. Arrival Timestamp    MAG.t3 + d2                          
>   LMA.t3 + d2
> 
> 17. delta based on P-BU                                     
> (LMA.t3 + d2) - (MAG.t3 + (d2+d1))
>                                                               
>          =
>                                                         
> ((MAG.t3+d1)+ d2) - (MAG.t3 + (d2+d1))
>                                                               
>          =
>                                                              
> delta.P-BU = ZERO
> 
> 18. Real delta                                               
> delta.real = ZERO                                      
> 
> > > The stated assumption for the timestamp based approach to 
> work, is 
> > > the requirement for the MAG's to have synchronized clocks.
> > > out, there are cases where the LMA will not be able to 
> determine the 
> > > sending order of the received packets. This is an error 
> condition, 
> > Right, sending a PBU with timestamp option requires that the MAG's 
> > clock is synchronized. Hence, I don't see why the draft 
> should specify 
> > a mechanism to synchronize a MAG's clock using a received 
> PBA. Also, I 
> > synchronization method like NTP and out of sync clocks can 
> only occur 
> > if there is a problem with this PMIP-independent synchronization 
> > method.
> > > time synchronization through other non NTP means. IMO, we 
> may not be 
> > > able dictate that. Also, we want implementations to support the 
> > > Frederico has an issue with the second part. But, if you 
> look at the 
> > > recommendation from the draft on handling this error case, MAG 
> > > signaling considerations,
> > > 
> > I think it is good if the LMA informs the MAG about detected out of 
> > sync clocks for the purpose of diagnostics and as a trigger for 
> > re-sync. But why do we need the timestamp option in the PBA? The 
> > TIMESTAMP_MISMATCH value in the status field is enough for 
> the purpose 
> > of diagnostics and as a trigger for re-sync.
> > 
> > > before, this is few lines of code for supporting this 
> option and if 
> > > seq number scheme is in use, this need not be used at 
> all. We need 
> > > to mandate this as there is no CT in the base spec. But, 
> this is not 
> > > a
> > big issue
> > > > 1. If a MAG's clock is out of sync (i.e., not yet synced by 
> > > > receiving a PBA with timestamp) AND PBUs sent by this MAG are 
> > > > delayed,
> > > the out of
> > > > thereafter hands over to MAG2. MAG2's clock is in sync 
> with LMA's 
> > > > clock, but MAG1's clock is out of sync and is ahead of 
> LMA's clock 
> > > > by 5 seconds. MAG1-LMA link is highly congested. When MN
> > > attaches to MAG1,
> > > > over to MAG2. The PBU1 msg is delayed by 5 seconds due to the 
> > > > congestion and hence arrives at LMA 2 seconds after handover. 
> > > > Despite of the delay,
> > > > with valid timestamp. In this scenario, the LMA will wrongly 
> > > > accept PBU1 arriving after PBU2, since both have a valid 
> > > > timestamp.
> > > Consequently,
> > > > the LMA forwards packets to the wrong MAG (MAG1) and will not 
> > > > notice the out of sync of MAG1, which also means that the LMA
> > doesn't return a
> > > > > > mechanism to synchronize clocks between MAGs and LMA (and 
> > > > > > hence between all MAGs) using the timestamp option 
> in PBU/PBA 
> > > > > > only
> > > > (i.e., without
> > > > > > certain
> > > difference of
> > > > > > delivery case (i.e., a PBU is delayed and overtaken 
> by another 
> > > > > > PBU from another MAG)? For instance, if the LMA 
> receives a PBU
> > > > with timestamp
> > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing 
> Director: Thomas 
> > > > > > Micke
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas 
> > > > Micke
> > > 
> > > 
> > 
> >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 12 Sep 2007 10:53:13 -0500

Hi Sri,

I completely agree. There are several options for timestamp
synchronization and any deployment can choose any of these mechanism.
Nothing is mandated in the draft and that is good. On the other hand, if
a deployment wants to use SQN, it is absolutely fine too.

1. If a deployment does not mind to have 2 round trips during initial
attach or inter-MAG handoff, then straight forward use of the per-MN SQN
is a possibility.

2. If a deployment would like to avoid two round trips during initial
attach or inter-MAG handoff, then they need to synchronize per-MN SQN
across MAGs. How, that is out-of-scope.

I do not see any problem with the drafts options and I believe we have
spent a lot of time debating this issue. IMO, The draft is good as far
as this issue is concerned and the issue should be closed.

Regards,
Ahmad

> Sent: Wednesday, September 12, 2007 1:14 AM
> To: 'Kilian Weniger'
> Cc: [email-masked]
> work, is the requirement for the MAG's to have synchronized clocks.
> That is a requirement. Now, if a given MAG sends a PBU with 
> an incorrect timestamp, its an error and as you and Federico 
> pointed out, there are cases where the LMA will not be able 
> to determine the sending order of the received packets. This 
> is an error condition, as the requirement is not met.
> 
> Now, should the draft state that the time synchronization is 
> a requirement and additionally mandate a method of time 
> synchronization, say by NTP ? But, the later has a system 
> wide impact and additionally, a given architecture where this 
> protocol is applied, can achieve the time synchronization 
> through other non NTP means. IMO, we may not be able dictate 
> that. Also, we want implementations to support the timestamp 
> based scheme by default. Now, mandating the NTP usage will 
> create some restrictions for some deployments. So, that is 
> the reasoning behind not mandating the method of time synchronization.
> 
> W.r.t this below scenario, the reason for LMA to return its 
> timestamp, solves two purposes. 1.) Diagnostics (especially 
> useful when the LMA and MAG are in different admin domains) 
> 2.) The MAG can detect that its clock is not in sync and take 
> the necessary actions. I guess, Frederico has an issue with 
> the second part. But, if you look at the recommendation from 
> the draft on handling this error case, MAG signaling considerations, 
> 
> So, we are not really using the LMA as the time source. Now, 
> with the given assumptions, do you see an issue if we dont 
> say NTP is a MUST, but we say clock synch is a requirement, 
> how they do it, draft does not say. If this requirement is 
> not met, its an incorrect usage of the protocol and the PBU 
> ordering will fail in that special rare reordering scenario 
> (IMO, its not a practical issue).
> 
> The second question to this discussion, is Alex's point of 
> not mandating Timestamp option as a MUST implement. For this, 
> as I stated before, this is few lines of code for supporting 
> this option and if seq number scheme is in use, this need not 
> be used at all. We need to mandate this as there is no CT in 
> the base spec. But, this is not a big issue either way. If 
> others agree, I'm fine not mandating this. But, I really 
> One last comment on the trust on LMA's clock for the sanity 
> check, is because its an anchor point and its typically well 
> managed, compared to MAG's, where they are scattered out. So, 
> its reasonable to expect the clock on the LMA to be in sync, 
> else all registrations will fail and will generate the traps.
> 
> receiving 
> > a PBA with timestamp) AND PBUs sent by this MAG are 
> delayed, the out 
> > of sync situation may not be detectable by the LMA and old 
> PBUs may be 
> > accepted by the LMA.
> > 
> > thereafter hands over to MAG2. MAG2's clock is in sync with LMA's 
> LMA's clock by 
> > 5 seconds. MAG1-LMA link is highly congested. When MN attaches to 
> > MAG1,
> > congestion and hence arrives at LMA 2 seconds after 
> handover. Despite 
> > of the delay,
> > with valid timestamp. In this scenario, the LMA will wrongly accept 
> > PBU1 arriving after PBU2, since both have a valid timestamp. 
> > Consequently, the LMA forwards packets to the wrong MAG (MAG1) and 
> > will not notice the out of sync of MAG1, which also means 
> that the LMA 
> > doesn't return a timestamp in the PBA and MAG1's clock 
> keeps to be out 
> > of sync.
> > 
> > > > > - We are NOT mandating the nodes in the domain to 
> sync up to a 
> > > > > clock source.
> > > > 
> > > > mechanism to synchronize clocks between MAGs and LMA (and hence 
> > > > between all MAGs) using the timestamp option in PBU/PBA only
> > (i.e., without
> > > > detect that the clocks are out of sync? Is it based on 
> a certain 
> > > > difference of timestamp in the received PBU and the 
> current LMA's 
> > > > time?
> > > > 
> > > > delivery case (i.e., a PBU is delayed and overtaken by 
> another PBU 
> > > > from another MAG)? For instance, if the LMA receives a PBU
> > with timestamp

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 12 Sep 2007 18:03:47 +0200

Hi Ahmad, 

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Mittwoch, 12. September 2007 16:59
> To: Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE FEDERICO
> Cc: [email-masked]

In one of my previous emails I described an example scenarios where it
fails, at least according to my understanding of the sync method (which
is not yet described anywhere in detail AFAIK). The point is that the
LMA only sees a delta time consisting of two parts: 1.) transmission
delay of PBU (d2 in your example) and 2.) clock difference (d1 in your
example). The problem is that the LMA doesn't know d1 and d2 itself, it
only knows d1+d2. If d2=~-d1, i.e., MAG's clock is ahead of LMA's clock
by a value that is roughly equal to the transmission delay, then
d1+d2=~0, i.e., the LMA doesn't see any delta and assumes that the MAG's
clock is in sync (which is not true). Hence, no re-sync happens and the
LMA may accept outdated PBUs.

> The following are a list of assumptions:

What is behind this assumption? Why not introduce another variable d3
for PBA delay (in addition to d2 for PBU delay).

I'll wait for your reformatted diagrams before I comment on those. 

BR,

Kilian

> (LMA.t1 +
>   LMA.t2 +
>   LMA.t3 =
>   LMA.t3 +
> delta.real
> > timestamp,
> > check, is
> sync up to

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 12 Sep 2007 18:03:15 +0200

Hi Ahmad,

> Sent: Mittwoch, 12. September 2007 17:41
> To: Ahmad Muhanna; Kilian Weniger; Sri Gundavelli; DE JUAN 
> HUARTE FEDERICO
> Cc: [email-masked]

thanks for re-sending. Much better to read now ;)

In one of my previous emails I described an example scenarios where it
fails, at least according to my understanding of the sync method.
According to my understanding, the LMA only sees a delta time consisting
of two parts: 1.) transmission delay of PBU (d2 in your example) and 2.)
clock difference (d1 in your example). The problem is that the LMA
doesn't know d1 and d2 itself, it only knows d1+d2. If d2=~-d1, i.e.,
MAG's clock is ahead of LMA's clock by a value that is roughly equal to
the transmission delay, then d1+d2=~0, i.e., the LMA doesn't see any
delta and assumes that the MAG's clock is in sync (which is not true).
Hence, no re-sync happens and the LMA may accept outdated PBUs (see my
previous email).

Please see some more comments inline.

> re-synchronization process.

right, d2+d1 is the delta that the LMA measures.

> 7. Real delta                                     delta.real = d1

How is the real delta d1 known by the LMA? 

>                 P-BA(LMA.t2)<<<<<<<<<<<==============

How does the LMA know d2? IMO, LMA only knows delta.P-BU = d2+d1. 
Hence, P-BA can only contain LMA.t2 = (LMA.t1 + delta.P-BU) = (LMA.t1 +
d1 + d2)

>                        ((MAG.t1 +d1)+d2) -MAG.t1

delta should be d1+2*d2

> 11. Real delta           delta.real = d1

How does the LMA know the real delta?

BR,

Kilian

> (LMA.t3+d2)-(MAG.t3+(d2+d1))
>                                                             =
>                                        
> > > >       the mobile access gateway SHOULD try to register 
> again only 
> > > > after
> > > >       it synchronized its clock with the local mobility 
> anchor's 
> > > > system
> Given that
> > > > > > the draft

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 12 Sep 2007 15:19:48 -0500

Hi Kilian,

Regards,
Ahmad
 
> > To: Ahmad Muhanna; Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE 
> > FEDERICO
> > Cc: [email-masked]
> In one of my previous emails I described an example scenarios 
> where it fails, at least according to my understanding of the 
> sync method.
> According to my understanding, the LMA only sees a delta time 
> consisting of two parts: 1.) transmission delay of PBU (d2 in 
> your example) and 2.) clock difference (d1 in your example). 
> The problem is that the LMA doesn't know d1 and d2 itself, it 
> only knows d1+d2. If d2=~-d1, i.e., MAG's clock is ahead of 
> LMA's clock by a value that is roughly equal to the 
> transmission delay, then d1+d2=~0, i.e., the LMA doesn't see 
> any delta and assumes that the MAG's clock is in sync (which 
> is not true).
> Hence, no re-sync happens and the LMA may accept outdated 
> PBUs (see my previous email).

[Ahmad]
Kilian,

This is the same race condition that we have discussed too many times
and people do not like to accept the unpopular solution :-) I have no
problem with that. But let us exactly identify all conditions related to
the scenario:

1. A race condition scenario which happens during handoff.

2. It assumes that the MAGs are not properly synchronized with each
other using an outside mechanism. We are here talking here about the
MAGs not the (LMA and MAGs). In other words, if the MAGs in the same
local domain are synchronized this issue will never happen.

3. It assumes that the pMAG sent a P-BU as a re-registration in a race
condition as the MN moves from pMAG (previous MAG) to nMAG (next MAG).

4. Due to some network conditions, the P-BU of the pMAG arrives at the
LMA after the P-BU of the nMAG.

5. It also assumes that not only pMAG and nMAG is out of sync, but also
nMAG is slower than pMAG by almost double the delta between any of them
and the LMA.

6. Not only that but also, the nMAG is slower enough to the degree that
when the P-BU arrives at the LMA it is within the threshold.

Finally,
--------
I am not saying that the possibility of this scenario to happen is ZERO.
No. There is a possibility that it MAY happen but , at the same time, it
is very very slim. Not only that, I think according to the PMIPv6 draft,
MAG needs to make sure that the MN is currently attached before sending
a re-registration P-BU. If the MAG is not sure, then MAG does not send
the P-BU.

NOW: what can we do about it:
-----------------------------

1. The very famous but un-popular solution that we mentioned several
time. In case of handoff, i.e. when the LMA receives the P-BU from nMAG,
LMA considers this as a case of handoff. When LMA receives a P-BU from
the pMAG, LMA drops or rejects it with a code MN-in-handoff, for
example. Since it is a race condition, that will take care of it.

2. LMA needs to track the delta for each MAG. Then after the P-BU passes
the LMA timestamp check and in case of handoff, LMA can always make sure
that the adjusted timestamp of the received P-BU is always larger than
the adjusted timestamp of the last received P-BU which is already saved
as part of the MN BCE.

I hope that this will take care of this issue and we can finally move
on.

Best Regards,
Ahmad

BTW: please see more comments below.

> What is behind this assumption? Why not introduce another 
> variable d3 for PBA delay (in addition to d2 for PBU delay).

[Ahmad]
Actually d3 is irrelevant in this regard. Because the timestamp delta
that the MAG is tracking does not depend on d3, because, MAG considers
the timestamp delta as the difference between the LMA-timestamp in P-BA
(which is independent of d3) and the MAG-timestamp in the corresponding
P-BU (which is again independent of d3). 

This means that regardless of the delay in the downlink direction, only
the delay in the uplink direction has an impact and that impact is
already factored IN and does not influence synchronization scheme.

> d2)-(MAG.t1)

[Ahmad]
Correct. Measured from the MAG timestamp. Right?

> How is the real delta d1 known by the LMA?

[Ahmad]
LMA does not need to know it. As long as the scheme works to
resynchronize the MAG with the LMA, no need for LMA to know it. Right?
 
> How does the LMA know d2? IMO, LMA only knows delta.P-BU = d2+d1. 

[Ahmad]
Absolutely. LMA does not know what d2 and does not need to. This is used
for proving the scheme. 

> Hence, P-BA can only contain LMA.t2 = (LMA.t1 + delta.P-BU) = 

[Ahmad]
I am afraid that is not correct. You probably meant to say: LMA.t2 =
(MAG.t1 + (d1+d2)). Right?
Otherwise, LMA.t2 in terms of LMA.t1 is as follows: LMA.t2 = LMA.t1 +
d2. NO?

> >                        ((MAG.t1 +d1)+d2) -MAG.t1

[Ahmad]
No. That is not correct. Delta = d1+d2. Please see above comment.

> How does the LMA know the real delta?

[Ahmad]
It does not need to know. ONLY MAG needs to track a delta with the LMA.
Well, we can make both track each other deltas but that will be too much
for the LMA and , honestly, it is not needed.
 
> > > synchronization using the PMIPv6 signaling does not work. On the 
> > > other hand, I have not seen any in detail analysis which 
> proves that 
> > > it does not work. I would like to share in details my thoughts on 
> > > how this SHOULD work and please comment as necessary.
> > > 
> corresponding 
> > > > think this mechanism has issues in some scenario (see 
> my previous 
> > > > mail).
> > > > 
> > > > 
> > > > Hence, it is a non-recoverable error case from PMIP 
> point of view 
> > > > IMHO.
> > > > 
> > > > > 
> handover.
> > > > > > > > absence of any external time synchronization 
> like NTP and
> > > > > > > to mandate a
> > > > > > > > equal to "current time of LMA - X" and X > 
> threshold, how
> > > > > > > does the LMA
> > > > > > > > know whether the
> > > > > > > > current timestamp in the PBA, then I guess the 
> same could
> > > > > > > be done with
> > > > > > > the clocks are off. But, with seq number scheme, 
> this needs
> > > > > > to be done

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 12 Sep 2007 18:14:27 -0700

Hi Kilian,

> Sent: Wednesday, September 12, 2007 1:07 AM
> To: Sri Gundavelli
> Cc: [email-masked]

The draft is not mandating on MAG to sync with the LMA clock. Its
really upto the MAG on what do do. Its requiring the MAG to sync up
to a clock source. I can slightly modify the below text suggesting
it to sync up to LMAs clock.

> only occur if

Sure.

> So I don't see restrictions for deployments in this case. 

I'm not sure, if we should mandate on NTP. The protocol has a requirement
and I think, how deployments achieve that is not our issue. For ex, we
need Routing between LMA and MAG. That's the assumption, we dont say 
there MUST be OSPF enabled between them. I really think, we should just
state the requirement strongly and make a note that the mechanism will
not work, if the requirement is not met. It is sufficient, IMHO.

> > anchor's system

Returning just an error code is not sufficient. It will be very hard to
run any diagnostics. I suggest we leave this. I'm ok on not stating
that the MAG should not sync up to the LMA's clock and should use a 
common clock source. The returned timestamp is also used for matching
request to response. So, we can leave this there.

Sri

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 13 Sep 2007 09:17:37 +0200

Hi Sri,

the simple method of using the timestamp in the PBA sent by the LMA to
sync MAG's clock has issues in some scenarios IMO. As explained in the
previous emails of this thread, these issues can lead to unsuccessful
clock sync and wrong BCEs, which in turn may result in significant
packet loss. Do you agree that this can happen? 

If so, my suggestion is to disallow the synchronization of MAG's clock
using the timestamp in the PBA as specified in the draft currently. At
least there should be some text in the draft explaining the issues to
the reader, so that an implementor is aware of them.

Please note that I'm only talking about *synchronization of MAG's clock
using the timestamp in the PBA*. Using the timestamp in PBUs to re-order
PBUs is not related to that and ok (under the assumption that the MAGs'
clocks are synchronized using some PMIP-independent mechanism like NTP)

BR,

Kilian

> Sent: Donnerstag, 13. September 2007 03:14
> To: 'Kilian Weniger'
> Cc: [email-masked]

If this is really sufficient for standards track, I'm fine with not
mandating any time sync protocol.

> common clock source. The returned timestamp is also used for matching

You mean "stating" or "not stating"? 

I'm not against syncing up to the LMA's clock per se. The point is that
the timestamp in the PBA should not be used to do that. Instead, a
dedicated sync protocol like NTP (which also considers packet delay)
should be used to sync up to LMA's clock.

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 13 Sep 2007 11:36:45 +0200

Hi Ahmad,

the issue only occurs when d2=~-d1 (PBU delay =~ amount that MAG's clock
is ahead of LMA's clock). Then the LMA doesn't send a PBA with
timestamp_mismatch status code and MAG doesn't compute a delta. I agree
that the probability that this situation will occur may be low, but the
consequences can be serious: Wrong BCE and packet loss till the next
PBU. Is this acceptable? I'm not sure. 

Furthermore, I don't really understand why we can't rely on an outside
mechanism like NTP. Is there any scenario where NTP fails, but the
PBA-based time sync does not fail?

Please see my email to Sri for suggestions to move on.

Some more comments inline. 

BR,

Kilian

> Sent: Mittwoch, 12. September 2007 22:20

When did we discuss the scenario where d2=~-d1 before? Can you please
give me a pointer?

> local domain are synchronized this issue will never happen.

If you assume that the clocks of all MAGs are always properly
synchronized using an outside mechanism, why do you want to specify a
mechanism to synchronize the MAG's clock using timestamps in PBAs?

> is very very slim. Not only that, I think according to the 

Maybe the probability that it happens is quite low, but the consequences
can be serious: Wrong BCE and packet loss till the next PBU.

> PMIPv6 draft,

Why is this related to the scenario in discussion? The MAG does not send
a PBU if the MN is not attached.

> NOW: what can we do about it:

As you said this was already discussed and there was no consensus for it
AFAIK.

I don't understand why we cannot just rely on the outside time sync
mechnanism like NTP? What is the problem with using a protocol like NTP,
which was specifically designed to sync time? Why do we need a second
time sync mechanism based on PBAs?

> resynchronize the MAG with the LMA, no need for LMA to know it. Right?

ok

> Absolutely. LMA does not know what d2 and does not need to. 

ok

> Otherwise, LMA.t2 in terms of LMA.t1 is as follows: LMA.t2 = LMA.t1 +

right, P-BA contains current timestamp of LMA, which is LMA.t2 = LMA.t1
+ d2.

> No. That is not correct. Delta = d1+d2. Please see above comment.

right, delta is d1+d2.

> > > 18. Real delta                                   delta.real = ZERO

right. 

The issue only occurs when d2=~-d1, because then the LMA doesn't send a
PBA with timestamp_mismatch status code and MAG doesn't compute a delta.
This scenario is not shown in your diagrams...

BR,

Kilian

> > > > > (e.g., just say "SHOULD use"), deployments can still 
> use other 
> > > > > methods.
> > > > > > > PBA returned by the LMA may already be outdated 
> at the time
> > > > > > it arrives
> > > > > > > at the MAG. So exactly in the situation where a 
> re-ordering
> > > > > > of PBUs is
> > > > > > > > > 2. the PBU is not delayed, but the MAG's 
> clock is out of
> > > > > > > sync by X?
> > > > > > > > > If the idea is to always reject a PBU with X 
> > threshold
> > > > > > > > and include a
> > > > > > > > LMA can return its timestamp and the MAG can 
> always apply
> > > > > > that delta
> > > > > > > > in all the registration it sends. This is done 
> just once,
> > > > > > when ever

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Thu, 13 Sep 2007 12:57:01 +0200

Hi Ahmad,

I understand now that you're not proposing to resynch the clock in the MAG, but only to keep a delta

Nonetheless, it's still not clear to me what is the benefit of your proposal
In simple words:
   - MAG sends BU with TS=X
   - LMA returns BAck with error and TS=Y
   - (second roundtrip) MAG resends BU with TS=Y and deduces that delta(d)=Y-X

My comments:
   - I don't see the usefulness of the 2 roundtrip to set the binding: you can achieve the same with only 1 roundtrip
   - Are you assuming that you can reuse the same delta for the following BU? If yes, this (intentionally?) ignores the variablity of delta due to clock deviation (d1) and congestion (d2). The delta will change with every BU and each BU could (potentially) require 2 roundtrips (I guess we can give up the 2nd roundtrip)
I guess you assume that the variablity of the delta can be dealt with by fine-tuning the thresholds in the LMA to declare a TIMESTAMP-MISMATCH. Fine
The final result is that we have all MAGs maintaining a delta (d) per LMA, which changes now and then
What's the added value of this delta?
   - It is not useful to synchronize the MAG clock and the LMA clock (for this synchronization you would need to be able to tell d1, not d)
   - It is not useful to solve the race condition problem

>From your answer, it seems to me that we don't have the same understanding of the race condition problem, let me describe it again
The race condition problem occurs when more than 1 MAG (e.g. MAG1 and MAG2) send a BU at the same time. Note that MAG1 and MAG2 maybe perfectly synchronized in time
The problem is that the LMA can not tell which is the right sequence of the Bus. Typical use case:
   - MN moves from pMAG to nMAG (both perfectly synchronized). nMAG sends BU with timestamp X
   - the lifetime of the binding in pMAG expires. pMAG sends BU with timestamp Y (Y>X)
When LMA receives the BU from nMAG (timestamp X) it updates the BCE
When LMA receives the BU from pMAG (timestamp Y) it also updates the BCE (because Y>X, thus correct)
The final result is that the binding in the LMA points to the pMAG, but the MN is attached to the nMAG
There are other use cases but I find this one as the most clear

Does this make sense or is it me that I'm missing something?
Regards

federico

-----Message d'origine-----
De : Ahmad Muhanna [mailto:[email-masked]] 
Envoyé : mercredi 12 septembre 2007 22:20
À : Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE FEDERICO
Cc : [email-masked]
Objet : RE: [netlmm] timestamp vs seqno redux

Hi Kilian,

Regards,
Ahmad
 
> consisting of two parts: 1.) transmission delay of PBU (d2 in your 
> example) and 2.) clock difference (d1 in your example).
> The problem is that the LMA doesn't know d1 and d2 itself, it only 
> knows d1+d2. If d2=~-d1, i.e., MAG's clock is ahead of LMA's clock by 
> a value that is roughly equal to the transmission delay, then 
> d1+d2=~0, i.e., the LMA doesn't see any delta and assumes that the 
> MAG's clock is in sync (which is not true).

[Ahmad]
Kilian,

This is the same race condition that we have discussed too many times and people do not like to accept the unpopular solution :-) I have no problem with that. But let us exactly identify all conditions related to the scenario:

2. It assumes that the MAGs are not properly synchronized with each other using an outside mechanism. We are here talking here about the MAGs not the (LMA and MAGs). In other words, if the MAGs in the same local domain are synchronized this issue will never happen.

3. It assumes that the pMAG sent a P-BU as a re-registration in a race condition as the MN moves from pMAG (previous MAG) to nMAG (next MAG).

4. Due to some network conditions, the P-BU of the pMAG arrives at the LMA after the P-BU of the nMAG.

5. It also assumes that not only pMAG and nMAG is out of sync, but also nMAG is slower than pMAG by almost double the delta between any of them and the LMA.

6. Not only that but also, the nMAG is slower enough to the degree that when the P-BU arrives at the LMA it is within the threshold.

Finally,
--------
I am not saying that the possibility of this scenario to happen is ZERO.
No. There is a possibility that it MAY happen but , at the same time, it is very very slim. Not only that, I think according to the PMIPv6 draft, MAG needs to make sure that the MN is currently attached before sending a re-registration P-BU. If the MAG is not sure, then MAG does not send the P-BU.

1. The very famous but un-popular solution that we mentioned several time. In case of handoff, i.e. when the LMA receives the P-BU from nMAG, LMA considers this as a case of handoff. When LMA receives a P-BU from the pMAG, LMA drops or rejects it with a code MN-in-handoff, for example. Since it is a race condition, that will take care of it.

2. LMA needs to track the delta for each MAG. Then after the P-BU passes the LMA timestamp check and in case of handoff, LMA can always make sure that the adjusted timestamp of the received P-BU is always larger than the adjusted timestamp of the last received P-BU which is already saved as part of the MN BCE.

I hope that this will take care of this issue and we can finally move on.

Best Regards,
Ahmad

> for PBA delay (in addition to d2 for PBU delay).

[Ahmad]
Actually d3 is irrelevant in this regard. Because the timestamp delta that the MAG is tracking does not depend on d3, because, MAG considers the timestamp delta as the difference between the LMA-timestamp in P-BA (which is independent of d3) and the MAG-timestamp in the corresponding P-BU (which is again independent of d3). 

This means that regardless of the delay in the downlink direction, only the delay in the uplink direction has an impact and that impact is already factored IN and does not influence synchronization scheme.

[Ahmad]

> How is the real delta d1 known by the LMA?

[Ahmad]
LMA does not need to know it. As long as the scheme works to resynchronize the MAG with the LMA, no need for LMA to know it. Right?
 
> How does the LMA know d2? IMO, LMA only knows delta.P-BU = d2+d1. 

[Ahmad]
Absolutely. LMA does not know what d2 and does not need to. This is used for proving the scheme. 

[Ahmad]
I am afraid that is not correct. You probably meant to say: LMA.t2 =
(MAG.t1 + (d1+d2)). Right?
Otherwise, LMA.t2 in terms of LMA.t1 is as follows: LMA.t2 = LMA.t1 + d2. NO?

[Ahmad]

[Ahmad]
It does not need to know. ONLY MAG needs to track a delta with the LMA.
Well, we can make both track each other deltas but that will be too much for the LMA and , honestly, it is not needed.

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Thu, 13 Sep 2007 12:57:15 +0200

Hi Ahmad,

why would there be 2 roundtrips during initial attach when using SQN? (by definition there's no context transfer in initial attach)

I also want to clarify something about using SQNs in inter-MAG handoff as I believe the current text can be improved
I see 2 scenarios: 
   - SQN-error: the LMA receives a SQN that is out of order (smaller than current SQN) => then LMA should return an error
   - SQN-reset: the LMA can tell from the BU that it has to reset the SQN algorithm. This is useful in the following use cases:
     * The deployment doesn't support context transfer nor timestamps
     * The deployment supports context transfer but the context transfer failed (for whatever the reason)
     * The deployment supports context transfer and the context transfer was succeful, but the LMA returns SQN-error (for whatever the reason). Then the MAG can initiate a second BU (with SQN-reset this time)
     * Optionally, also in initial attach (not neecessary)

The SQN-reset concept could be conveyed explicitly (new flag) or implicitly (SQN=0)
I don't have an opinion one way or the other but I think that it would be useful if the specification supported this concept
I wonder if basic MIP has built-in something similar (for some sort of fast-reset)

Regards

federico

-----Message d'origine-----
De : Ahmad Muhanna [mailto:[email-masked]] 
Envoyé : mercredi 12 septembre 2007 17:53
À : Sri Gundavelli; Kilian Weniger
Cc : [email-masked]
Objet : RE: [netlmm] timestamp vs seqno redux

Hi Sri,

I completely agree. There are several options for timestamp synchronization and any deployment can choose any of these mechanism.
Nothing is mandated in the draft and that is good. On the other hand, if a deployment wants to use SQN, it is absolutely fine too.

1. If a deployment does not mind to have 2 round trips during initial attach or inter-MAG handoff, then straight forward use of the per-MN SQN is a possibility.

2. If a deployment would like to avoid two round trips during initial attach or inter-MAG handoff, then they need to synchronize per-MN SQN across MAGs. How, that is out-of-scope.

I do not see any problem with the drafts options and I believe we have spent a lot of time debating this issue. IMO, The draft is good as far as this issue is concerned and the issue should be closed.

Regards,
Ahmad

> The stated assumption for the timestamp based approach to work, is the 
> requirement for the MAG's to have synchronized clocks.
> incorrect timestamp, its an error and as you and Federico pointed out, 
> there are cases where the LMA will not be able to determine the 
> sending order of the received packets. This is an error condition, as 
> the requirement is not met.
> 
> time synchronization through other non NTP means. IMO, we may not be 
> and MAG are in different admin domains)
> 2.) The MAG can detect that its clock is not in sync and take the 
> necessary actions. I guess, Frederico has an issue with the second 
> part. But, if you look at the recommendation from the draft on 
> handling this error case, MAG signaling considerations,
> 
> not say. If this requirement is not met, its an incorrect usage of the 
> protocol and the PBU ordering will fail in that special rare 
> before, this is few lines of code for supporting this option and if 
> seq number scheme is in use, this need not be used at all. We need to 
> mandate this as there is no CT in the base spec. But, this is not a 
> big issue either way. If others agree, I'm fine not mandating this. 
> But, I really believe, implementations can support this option, at the 
> least cost.
> 
> > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 13:57:58 +0200

> synchronization and any deployment can choose any of these mechanism.

Right.

> Nothing is mandated in the draft and that is good.

I don't agree: the draft uses the word 'RECOMMENDED' for timestamp,
which is equivalent to 'SHOULD'.

draft proxymip6-04:
> For solving this [determining sending order] problem, this 
> specification RECOMMENDS the use of Timestamp option [Section 8.4].

What does 'RECOMMENDS' mean?  RFC2119 and Errata:
> 3. SHOULD   This word, or the adjective "RECOMMENDED", means that 
> there may exist valid reasons in particular circumstances to ignore a
>  particular item, but the full implications must be understood and 
> carefully weighed before choosing a different course.

Putting it all together, a standards reader and implementer thinks
like this: "I better implement timestamp option until I demonstrate the
particular circumstances where the implications of not using timestamps
and using seqnos are understood".

I think that up to now I have showed that there are particular
circumstances and implications of using timestamps, that may lead to
non-working protocol.

I think the seqnos method should be default and, if people understand
the full implications of using timestamps then timestamps should be 
weighed before choosing a different course.

> On the other hand, if a deployment wants to use SQN, it is absolutely
> fine too.
> 
>  attach or inter-MAG handoff, then straight forward use of the per-MN
>  SQN is a possibility.

This is not true.

It is possible to have the seqno method with only one roundtrip, not 
two.  As I described earlier, one can take advantage of the exchange 
where the MNP is learned by MAG to also learn the seqno.

Thus, a deployment doesn't have to have 2 round trips in order to 
support per-MN SQN.

>  attach or inter-MAG handoff, then they need to synchronize per-MN 
> SQN across MAGs. How, that is out-of-scope.

It is as much out-of-scope as learning the MNP at MAG is.

> I do not see any problem with the drafts options and I believe we 
> have spent a lot of time debating this issue. IMO, The draft is good
>  as far as this issue is concerned and the issue should be closed.

I think it should be closed, yes, but not with the resolution you propose.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 14:11:20 +0200

Thanks.

> other hand, I have not seen any in detail analysis which proves that
> it does not work. I would like to share in details my thoughts on how
> this SHOULD work and please comment as necessary.
> 

Ahmad, this is a wrong assumption.  As I said earlier, the links between
LMA and MAG can easily be asymmetric.  One hotspot public deployment 
uses this ADSL link between the DHCP Server and DHCP Relay; ADSL stands 
for assymmetric DSL, with a asymmetry of like 25%.  This means that the 
time P-BA takes is like 3 times shorter than the P-BU.

Does this affect your calculations?

Otherwise, do you assume that always the MAG-LMA link is symmetric?
Which link-layer technology?

Thanks,

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 07:20:49 -0500

Hi Alex,

No it does not have an effect on the calculation.

Actually the MAG always calculate the timestamp delta based on two
things:

1. The timestamp of the P-BA (which is independent from the time the
P-BA takes to arrive at the MAG) and 
2. The timestamp of the corresponding P-BU (Which also independent of
downlink delay)

Here is the delta:

"

"

Please see my reply to Kilian for more information.

Regards,
Ahmad

> Sent: Thursday, September 13, 2007 7:11 AM
> Ahmad, this is a wrong assumption.  As I said earlier, the 
> links between LMA and MAG can easily be asymmetric.  One 
> hotspot public deployment uses this ADSL link between the 
> DHCP Server and DHCP Relay; ADSL stands for assymmetric DSL, 
> with a asymmetry of like 25%.  This means that the time P-BA 
> takes is like 3 times shorter than the P-BU.
>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Sep 2007 14:21:05 +0200

On Thursday 13 September 2007, Alexandru Petrescu wrote:
> Ahmad, this is a wrong assumption.  As I said earlier, the links
> between LMA and MAG can easily be asymmetric.  One hotspot public
> deployment uses this ADSL link between the DHCP Server and DHCP
> Relay; ADSL stands for assymmetric DSL, with a asymmetry of like 25%.
>  This means that the time P-BA takes is like 3 times shorter than the
> P-BU.

FWIW the asymmetry in ADSL is w.r.t. bandwidth, not end-to-end delivery 
delay as you indicate above.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 14:22:59 +0200

> delay as you indicate above.

What do you mean Julien?

Bandwidth is directly related to end to end delivery delay isn't it?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 14:36:27 +0200

> No it does not have an effect on the calculation.

So why do you mention it as an assumption?

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 07:38:09 -0500

> So why do you mention it as an assumption?

[Ahmad]
It is an over sight on my part. Sorry for the confusion.

> > P-BA takes to arrive at the MAG) and 2. The timestamp of the 
> > corresponding P-BU (Which also independent of downlink delay)
> > 
> > Here is the delta:
> > 
> > "
> _____________________________________________________________________
> >> _ This email has been scanned by the MessageLabs Email Security 
> >> System.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 07:44:14 -0500

Hi Alex,

Regards,
Ahmad

> I don't agree: the draft uses the word 'RECOMMENDED' for 
> timestamp, which is equivalent to 'SHOULD'.

[Ahmad]
I agree with the draft recommendation for the following reason:
Timestamp with a synchronization mechanism (where the choice is not
mandated) successfully address all P-BU/P-BA ordering including
inter-MAG handoff in a single round trip. If PMIPv6 signaling is used
for synchronization there is a very slim chance that it may require 2
round trips.

On the other hand, the use of SQN without an out-of-scope mechanism to
synchronize the SQN across MAGs will always require 2 round trips. The
fact that the synchronization mechanism of SQN across MAGs is currently
undefined, I support the draft recommendation.

There has to be a defined default working mechanism in the draft which
does not depend on any undefined mechanism.

> Putting it all together, a standards reader and implementer 
> thinks like this: "I better implement timestamp option until 
> I demonstrate the particular circumstances where the 
> implications of not using timestamps and using seqnos are understood".

[Ahmad]
We can check the draft text, I believe it requires the SQN
synchronization across MAGs. In there the draft also can mention if no
SQN synchronization is available, an initial attach and inter-MAG
handoff requires 2 round trips. 

> 
> I think that up to now I have showed that there are 
> particular circumstances and implications of using 
> timestamps, that may lead to non-working protocol.

[Ahmad]
I am sorry, that is not true and I have not seen that proof.

> 
> I think the seqnos method should be default and, if people 
> understand the full implications of using timestamps then 
> timestamps should be weighed before choosing a different course.

[Ahmad]
IMO, That is backward.

> It is possible to have the seqno method with only one 
> roundtrip, not two.  As I described earlier, one can take 
> advantage of the exchange where the MNP is learned by MAG to 
> also learn the seqno.
> 
> Thus, a deployment doesn't have to have 2 round trips in 
> order to support per-MN SQN.

[Ahmad]
Alex, you failed to address all concerns about your proposal and at the
end you decided to not address the latest concerns saying that the
Co-chairs need to make a decision. IMO, before asking the chairs to
decide on a technical issue, we need to answer all questions raised in
order for anyone to make a good judgment of the proposal.

So far, I disagree that you have presented a working mechanism.

> It is as much out-of-scope as learning the MNP at MAG is.

[Ahmad]
Alex,
Please, That is not true. We can go over this again. If you would like.

> > spent a lot of time debating this issue. IMO, The draft is good  as 
> > far as this issue is concerned and the issue should be closed.
> 

[Ahmad]
Unless you point a valid reason not to close it, otherwise, it should be
closed, IMO.

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Thu, 13 Sep 2007 14:44:54 +0200

Hi Sri,

in my opinion, from deployment point of view:
   - In order to use the timestamp option MAGs need to have their clock synchronized. This should be a conditional requirement (only applicable if deployment chooses to use timestamps)
   - The LMAs may also be synchronized to the same time source (e.g. to use timestamp in Back for diagnostics). But it's enough as a recommendation (thus not a requirement)
   - The means used to synchronize MAGs (and potentially LMAs) should be a deployment decision

And from implementation point of view:
   - The MAG capability to add the timestamp option in the BU should be a recommendation rather than a requirement
   - The LMA capability to process the timestamp option in the BU should be a requirement (otherwise MAGs would not be able to use it)
   - The LMA capability to add timestamp in Back should be a recommendation (thus not a requirement)
   - The MAG capability to process the timestamp in Back should be a recommendation (thus not a requirement)
   - The MAG capability to re-synch its own clock with the timestamp in Back should be a recommendation (thus not a requirement) at most. Depending on the result of the discussion with Ahmad, I would even prefer to not mention it

Other aspects:
   - The proposal from Julien (preferably in generalized format) to use information from the MN (when available) should be a recommendation
   - It would be good to mention the race condition problem when using timestamps: 2 MAGs may send BU very close in time. The result of a race condition may be that the MN is connected to MAG2, but the the binding in the LMA is to MAG1, so it should not be neglected

When I say recommendation, I don't have a strong opinion between SHOULD or MAY
Regards

federico

-----Message d'origine-----
De : Kilian Weniger [mailto:[email-masked]] 
Envoyé : jeudi 13 septembre 2007 09:18
À : Sri Gundavelli
Cc : [email-masked]
Objet : RE: [netlmm] timestamp vs seqno redux

Hi Sri,

the simple method of using the timestamp in the PBA sent by the LMA to sync MAG's clock has issues in some scenarios IMO. As explained in the previous emails of this thread, these issues can lead to unsuccessful clock sync and wrong BCEs, which in turn may result in significant packet loss. Do you agree that this can happen? 

If so, my suggestion is to disallow the synchronization of MAG's clock using the timestamp in the PBA as specified in the draft currently. At least there should be some text in the draft explaining the issues to the reader, so that an implementor is aware of them.

Please note that I'm only talking about *synchronization of MAG's clock using the timestamp in the PBA*. Using the timestamp in PBUs to re-order PBUs is not related to that and ok (under the assumption that the MAGs'
clocks are synchronized using some PMIP-independent mechanism like NTP)

BR,

Kilian

> > > > timestamps in PBA msgs to synchronize the MAG clocks. I think 
> > > > the draft should not allow this for the following reasons:
> > > > 
> > > 
> > > The stated assumption for the timestamp based approach to work, is 
> > clock is synchronized. Hence, I don't see why the draft should 
> > specify a mechanism to synchronize a MAG's clock using a received 
> > PBA. Also, I think this mechanism has issues in some scenario (see 
> > my previous mail).
> > 
> 
> really upto the MAG on what do do. Its requiring the MAG to sync up to 
> a clock source. I can slightly modify the below text suggesting it to 
> sync up to LMAs clock.
> 
> "If the received Proxy Binding Acknowledgement message has the Status 
> field value set to TIMESTAMP_MISMATCH (Invalid Timestamp), the mobile 
> access gateway SHOULD try to register again only after it synchronized 
> its clock with the local mobility anchor's system clock or to a common 
> time source that is used by all mobility entities in that domain for 
> their clock synchronization."
>  
> 
> 
> > 
> > synchronization method like NTP and out of sync clocks can only 
> > occur if there is a problem with this PMIP-independent
> synchronization method.
> I'm not sure, if we should mandate on NTP. The protocol has a 
> requirement and I think, how deployments achieve that is not our 
> issue. For ex, we need Routing between LMA and MAG. That's the 
> assumption, we dont say there MUST be OSPF enabled between them. I 
> really think, we should just state the requirement strongly and make a 
> note that the mechanism will not work, if the requirement is not met. 
> It is sufficient, IMHO.

If this is really sufficient for standards track, I'm fine with not mandating any time sync protocol.

> > > the recommendation from the draft on handling this error case, MAG 
> TIMESTAMP_MISMATCH
> Returning just an error code is not sufficient. It will be very hard 
> to run any diagnostics. I suggest we leave this. I'm ok on not stating 

I'm not against syncing up to the LMA's clock per se. The point is that the timestamp in the PBA should not be used to do that. Instead, a dedicated sync protocol like NTP (which also considers packet delay) should be used to sync up to LMA's clock.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 14:49:10 +0200

> It is an over sight on my part. Sorry for the confusion.

Ahmad, I think any assumption on a constant delay of the network is 
wrong, be it symmetric or asymmetric.  You do a measurement now and ten 
minutes later the delays are different because somebody else loads the 
network.

You do 10 measurements in a burst and you get different times, 
eventually with a Gaussian distribution.  That's the first experience 
with ping.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 14:52:35 +0200

> The following are a list of assumptions:

Ahmad, you should also list the implicit assumption you make that MAG 
and LMA will keep time ok, once synchronized.

Or, that assumption can sometimes be not true.

An LMA or MAG's LiIon BIOS battery can dry out and reset the clocks on 
an arbitrary basis.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 07:58:25 -0500

> Ahmad, I think any assumption on a constant delay of the 
> network is wrong, be it symmetric or asymmetric.  You do a 
> measurement now and ten minutes later the delays are 
> different because somebody else loads the network.
> 
> You do 10 measurements in a burst and you get different 
> times, eventually with a Gaussian distribution.  That's the 
> first experience with ping.

[Ahmad]
Alex, There is no assumption about a constant delay?
This is just used for a snap shot analysis to prove the concept is
valid. That is all.

If the network condition changes, the concept still valid and should
adjust itself and work. NO?

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 13 Sep 2007 14:59:14 +0200

> eventually with a Gaussian distribution.  That's the first experience 

Right, that's why NTP requires several packet exchanges with
sophisticated statistical calculations. From
http://www.ntp.org/ntpfaq/NTP-s-algo.htm:

"Time is not believed until several packet exchanges have taken place,
each passing a set of sanity checks. Only if the replies from a server
satisfy the conditions defined in the protocol specification, the server
is considered valid. Time cannot be synchronized from a server that is
considered invalid by the protocol. Some essential values are put into
multi-stage filters for statistical purposes to improve and estimate the
quality of the samples from each server."

BR,

Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 13 Sep 2007 14:59:02 +0200

Hi Ahmad, 
 
> does not depend on any undefined mechanism.

I discussed this with Sri and according to his understanding this is not
true. From his recent email:

> The protocol has a requirement

Furthermore, this is no argument for specifying a PMIP-based time sync
mechanism. One could mandate, e.g., NTP instead.

BR,

Kilian

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 15:04:10 +0200

> This is just used for a snap shot analysis to prove the concept is

What makes you think that the situation is the same when you make your 
snapshot and 10minutes later?

> adjust itself and work. NO?

Don't you assume that when network conditions change a new measurement 
is necessary?  How do you know when network conditions change?

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 08:13:38 -0500

Hi Kilian,

Regards,
Ahmad

> the issue only occurs when d2=~-d1 (PBU delay =~ amount that 
> MAG's clock is ahead of LMA's clock). Then the LMA doesn't 
> send a PBA with timestamp_mismatch status code and MAG 
> doesn't compute a delta. I agree that the probability that 
> this situation will occur may be low, but the consequences 
> Is this acceptable? I'm not sure. 

[Ahmad]
I do not understand what is the problem here. Are we talking about the
race condition here or about synchronization.
If you are talking about the race condition, then there are a couple of
options to address it and the choice is yours.

On the other hand, if we are talking about this synchronization issue,
IMO, as long as ordering P-BU/P-BA works and that MAG continuously
monitor the LMA timestamp through all P-BU and P-BA, then I do not see a
great impact here.

> 
> Furthermore, I don't really understand why we can't rely on 
> an outside mechanism like NTP. Is there any scenario where 
> NTP fails, but the PBA-based time sync does not fail?

[Ahmad]
Kilian,
I have no problem with that requirement. Life will be good for
everyone:-)
The point here is that some people on the list do not want to mandate
the use of NTP server. I personally, respect that choice. It is valid
and hence, we should not mandate it. Again, personally, I have no
problem.
> Please see my email to Sri for suggestions to move on.

<snip-from Sri email. It is difficult to trace!>
<snip>

[Ahmad]
Kilian,

Using the PMIPv6 signaling does not have the objective of synchronizing
timestamp in an accuracy as NTP server. That is a whole protocol by
itself. However, what we are talking about is the use of timestamp in
ordering the P-BU/P-PA. And using PMIPv6 signaling as an alternative
mechanism should work.

> > > In one of my previous emails I described an example 
> scenarios where 
> > > it fails, at least according to my understanding of the 
> sync method.
> > > knows d1+d2. If d2=~-d1, i.e., MAG's clock is ahead of 
> LMA's clock 
> When did we discuss the scenario where d2=~-d1 before? Can 
> you please give me a pointer?
> 
> > problem with that. But let us exactly identify all 
> conditions related 
> > to the scenario:
> > 
> synchronized using an outside mechanism, why do you want to 
> specify a mechanism to synchronize the MAG's clock using 
> timestamps in PBAs?
> 
> 
> > 
> > 5. It also assumes that not only pMAG and nMAG is out of sync, but 
> > also nMAG is slower than pMAG by almost double the delta 
> between any 
> > of them and the LMA.
> > 
> > 6. Not only that but also, the nMAG is slower enough to the degree 
> > that when the P-BU arrives at the LMA it is within the threshold.
> > 
> > 
> > Finally,
> > --------
> > No. There is a possibility that it MAY happen but , at the 
> same time, 
> > it is very very slim. Not only that, I think according to the
> 
> Maybe the probability that it happens is quite low, but the 
> consequences can be serious: Wrong BCE and packet loss till 
> the next PBU.
> 
> > PMIPv6 draft,
> > MAG needs to make sure that the MN is currently attached before 
> > sending a re-registration P-BU. If the MAG is not sure, 
> then MAG does 
> > not send the P-BU.
> 
> Why is this related to the scenario in discussion? The MAG 
> does not send a PBU if the MN is not attached.
> 
> > 
> > time. In case of handoff, i.e. when the LMA receives the P-BU from 
> > nMAG, LMA considers this as a case of handoff. When LMA receives a 
> > P-BU from the pMAG, LMA drops or rejects it with a code 
> MN-in-handoff, 
> > for example. Since it is a race condition, that will take 
> care of it.
> > 
> > 2. LMA needs to track the delta for each MAG. Then after the P-BU 
> > passes the LMA timestamp check and in case of handoff, LMA 
> can always 
> > make sure that the adjusted timestamp of the received P-BU 
> is always 
> > larger than the adjusted timestamp of the last received 
> P-BU which is 
> > already saved as part of the MN BCE.
> 
> As you said this was already discussed and there was no 
> consensus for it AFAIK.
> 
> I don't understand why we cannot just rely on the outside 
> time sync mechnanism like NTP? What is the problem with using 
> a protocol like NTP, which was specifically designed to sync 
> time? Why do we need a second time sync mechanism based on PBAs?
> 
> > 
> variable 
> > > d3 for PBA delay (in addition to d2 for PBU delay).
> > 
> > [Ahmad]
> > the timestamp delta as the difference between the LMA-timestamp in 
> > P-BA (which is independent of d3) and the MAG-timestamp in the 
> > corresponding P-BU (which is again independent of d3).
> > 
> > This means that regardless of the delay in the downlink direction, 
> > only the delay in the uplink direction has an impact and 
> that impact 
> > is already factored IN and does not influence 
> synchronization scheme.
> > 
> > > 
> > > 
> > > > 10. Delta based on P-BA LMA.t2-MAG.t1 (timestamp in 
> corresponding
> > > > P-BU)
> > > >                               =
> > > >                        (LMA.t1 + d2) - MAG.t1
> > > >                               =
> > Well, we can make both track each other deltas but that will be too 
> > much for the LMA and , honestly, it is not needed.
> >  
> > > 
> > > BR,
> > > 
> > > Kilian
> > > 
> > > 
> > > > 
> > > > 
> The issue only occurs when d2=~-d1, because then the LMA 
> doesn't send a PBA with timestamp_mismatch status code and 
> MAG doesn't compute a delta.
> > > > > > > > I.e., it would be allowed that a deployment 
> uses only the
> > > > > > returned
> > > > > > >       Status field value set to 
> TIMESTAMP_MISMATCH (Invalid 
> > > > > > > Timestamp),
> > > > > > > > MAG1 sends PBU1 msg to LMA. This happens 3 
> seconds before
> > > > > > > the MN hands
> > > > > > > > > > > will be incomplete, if we dont mandate 
> the support. 
> > > > > > > By mandating
> > > > > > > > > > > the support, the LMA can always return 
> its timestamp
> > > > > > > and the MAG
> > > > > > > > > > > once whenever the LMA/MAG clocks are out 
> of sync and
> > > > > > > > just for one
> > > > > > > > > How its achieved, it could be based on NTP or 
> some other
> > > > > > > protocols.
> > > > > > > > > For what ever reasons if the LMA and MAG 
> clocks are out
> > > > > > > of sync, the

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 15:20:18 +0200

Let's try to see whether we can formulate some questions to the group.

-do we want or don't want to require that MAG and LMA are time
  synchronized.

-do we want or don't want to use NTP for that.

-do we want or don't want to use PBU/PBAck to sync times.

-do we want or don't want to use timestamps at all.

-do we want or don't want to use sequence numbers.

Feel free to reformulate as you wish.

Alex
PS: I didn't describe the problem because the problem is described in 
the draft:

draft proxymip6-04:
>    Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding
>    registration messages as a way for the home agent to process the
>    binding updates in the order they were sent by a mobile node.  The
>    home agent and the mobile node are required to manage this counter
>    over the lifetime of a binding.  However, in Proxy Mobile IPv6, as
>    the mobile node moves from one mobile access gateway to another and
>    in the absence of context transfer mechanism, the serving mobile
>    access gateway will be unable to determine the sequence number that
>    it needs to use in the signaling messages.  Hence, the sequence
>    number scheme as specified in [RFC-3775], will be insufficient for
>    Proxy Mobile IPv6.
> 
>    If the local mobility anchor cannot determine the sending order of
>    the received binding registration messages, it may potentially
>    process an older message sent by a mobile access gateway, where the
>    mobile node was previously anchored, resulting in an incorrect
>    Binding Cache entry.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 08:34:24 -0500

Okay,

Then you assume that the MAG will not send any other P-BU for any other
MN in 10 minutes. That is possible. However, reality is a little
different than that. On the other hand, let us argue to the extreme that
you are right. MAG is not sending any other P-BU for 10 minutes and the
network state has changed. What the consequences. 2 round trips right?

The idea here, how often that should happen? 

Regards,
Ahmad

> Sent: Thursday, September 13, 2007 8:04 AM
> Cc: Alexandru Petrescu; Kilian Weniger; Sri Gundavelli; DE 
> JUAN HUARTE FEDERICO; [email-masked]
> network is 
> >> wrong, be it symmetric or asymmetric.  You do a 
> measurement now and 
> >> ten minutes later the delays are different because somebody else 
> >> loads the network.
> >>
> What makes you think that the situation is the same when you 
> make your snapshot and 10minutes later?
> 
> Don't you assume that when network conditions change a new 
> measurement is necessary?  How do you know when network 
> conditions change?
> 
> Alex
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 08:43:58 -0500

Hello Alex,
Please see inline.

Regards,
Ahmad
 
> Ahmad, you should also list the implicit assumption you make 
> that MAG and LMA will keep time ok, once synchronized.

[Ahmad]
The assumption is that it is synchronized during the synchronization
process. If you see another assumption, please come forward and identify
and qualify it and we will discuss it.

> An LMA or MAG's LiIon BIOS battery can dry out and reset the 
> clocks on an arbitrary basis.

[Ahmad]
Another bad luck, but what is the consequence? Does the concept work or
NOT? That is what important?
> >>>>>>> between all MAGs) using the timestamp option
> >> in PBU/PBA
> >>>>>>> only
> >>>>> (i.e., without
> >>>>>>> utilizing NTP or an external clock source)? Is my 
> understanding 
> >>>>>>> correct?
> >>>>>>>
> >>>>>>> detect that the clocks are out of sync? Is it based 
> on a certain
> >>>> difference of

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 15:51:42 +0200

> The idea here, how often that should happen?

Ahmad, thanks for assuming that idea along my own thoughts, and agreeing 
  that it might lead to something undesirable.

It's true that if it requires 2 round trips every 10minutes then it's 
not much an overload.

I've used the same argumentation previously for saying that maybe 2 
round trips now and then for seqno at first attachment is not that much 
an overload.

Let's say that the requirement is to ensure ordering of P-BUs at LMA 
_without_ extraneous P-BU/P-BAck roundtrips.  Then we can only do this: 
(1) do seqno stuff at the shadowy AAA phase xor (2) rely on NTP/GPS/GSM 
for time synchronizaion.

I think doing only timestamps without NTP/GSM/GPS synchronization 
doesn't save us the risk of extraneous roundtrips.  I also think doing 
both timestamps+seqnos doesn't save us the same risk.  I also think 
reusing the timestamps from DNA/SeND doesn't save us the risk of 
sometimes running two round trips.

Alex
PS: if we change the requirement to allow for a three-way handshake
     (still forbid 2 round trips) then the solutions change again.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 08:52:53 -0500

Hi Kilian,

Please see inline.

Regards,
Ahmad

> > wrong, be it symmetric or asymmetric.  You do a measurement now and 
> > ten minutes later the delays are different because somebody 
> else loads 
> > the network.
> > 

[Ahmad]
And that why NTP needs a whole different protocol and different
equipment and everything else in between. And let me say some $$$$ CASH.
Right? Please let us take this in prospective. If the group agree to
mandate NTP time synchronization, we do not need to go through all of
this and we could have save plenty of man hours for all of us. Reality
is a little different and timestamp is used per other signaling
protocols in other IETF standards. Nothing new here.

> "Time is not believed until several packet exchanges have 
> taken place, each passing a set of sanity checks. Only if the 
> replies from a server satisfy the conditions defined in the 
> protocol specification, the server is considered valid. Time 
> cannot be synchronized from a server that is considered 
> invalid by the protocol. Some essential values are put into 
> multi-stage filters for statistical purposes to improve and 
> estimate the quality of the samples from each server."

[Ahmad]
As long as the proposed mechanism works for ordering P-BU/P-BA, then
that should be fine.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 16:33:45 +0200

> protocols in other IETF standards. Nothing new here.

Which ones other than SEND and MIP4?  In both it's used for replay 
protection, not ordered delivery of messages.

Take other routing protocols OSPF and BGP and there's no timestamps 
transmitted in messages.

I think there's no other IETF protocol that uses timestamps in messages 
in order to ensure ordered delivery of messages.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 09:34:55 -0500

> > Then you assume that the MAG will not send any other P-BU for any 
> > other MN in 10 minutes. That is possible. However, reality 
> is a little 
> > different than that. On the other hand, let us argue to the extreme 
> > that you are right. MAG is not sending any other P-BU for 
> 10 minutes 
> > and the network state has changed. What the consequences. 2 
> round trips right?
> > 
> It's true that if it requires 2 round trips every 10minutes 
> then it's not much an overload.
> 
> I've used the same argumentation previously for saying that 
> maybe 2 round trips now and then for seqno at first 
> attachment is not that much an overload.
> 
> Let's say that the requirement is to ensure ordering of P-BUs 
> at LMA _without_ extraneous P-BU/P-BAck roundtrips.  Then we 
> can only do this: 
> (1) do seqno stuff at the shadowy AAA phase xor (2) rely on 
> NTP/GPS/GSM for time synchronizaion.

[Ahmad]
I am not sure about the shadowy AAA phase does. Without understanding
the details this for me is undefined.

> 
> I think doing only timestamps without NTP/GSM/GPS 
> synchronization doesn't save us the risk of extraneous 
> roundtrips.
  
[Ahmad]
True. However, I do not believe that it is as bad as using SQN without
synchronization. I hope you agree. 

> I also think doing both timestamps+seqnos 
> doesn't save us the same risk.  I also think reusing the 
> timestamps from DNA/SeND doesn't save us the risk of 

[Ahmad]
I do not think there is currently a mechanism to enable this three-way
handshake in MIPv6 or PMIPv6. 

> >> Cc: Alexandru Petrescu; Kilian Weniger; Sri Gundavelli; DE JUAN 
> >> HUARTE FEDERICO; [email-masked]
> >> What makes you think that the situation is the same when you make 
> >> your snapshot and 10minutes later?
> >>
> >> measurement is necessary?  How do you know when network conditions 
> >> change?
> >>
> >> Alex
> >>
> >>
> >> 
> >> _

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 09:50:08 -0500

> Which ones other than SEND and MIP4?  In both it's used for 
> replay protection, not ordered delivery of messages.

[Ahmad]
Let us talk about MIPv4. I understand that MIPv4 use timestamp for
replay protection, but you are saying that does not guarantee ordering?
In other words, are you saying that the HA will accept an out of order
packets?
For example: RRQ(t1-d1) can be accepted if HA already has already
accepted another RRQ with timestamp (t1)?

> 
> Take other routing protocols OSPF and BGP and there's no 
> timestamps transmitted in messages.
> 
> I think there's no other IETF protocol that uses timestamps 
> in messages in order to ensure ordered delivery of messages.
> 
> Alex
> 
> >> "Time is not believed until several packet exchanges have taken 
> >> place, each passing a set of sanity checks. Only if the 
> replies from 
> >> a server satisfy the conditions defined in the protocol 
> >> specification, the server is considered valid. Time cannot be 
> >> synchronized from a server that is considered invalid by the 
> >> protocol. Some essential values are put into multi-stage 
> filters for 
> >> statistical purposes to improve and estimate the quality of the 
> >> samples from each server."
> > 
> > [Ahmad]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 16:56:37 +0200

Ahmad Muhanna wrote:
>>> different than that. On the other hand, let us argue to the
>>> extreme that you are right. MAG is not sending any other P-BU for
>>> 
>> 10 minutes
>> Ahmad, thanks for assuming that idea along my own thoughts, and
>> agreeing that it might lead to something undesirable.
>> 
>> It's true that if it requires 2 round trips every 10minutes then
>> it's not much an overload.
>> 
>> round trips now and then for seqno at first attachment is not that
>> much an overload.
>> 
>> Let's say that the requirement is to ensure ordering of P-BUs at
>> LMA _without_ extraneous P-BU/P-BAck roundtrips.  Then we can only
>> do this: (1) do seqno stuff at the shadowy AAA phase xor (2) rely
>> on NTP/GPS/GSM for time synchronizaion.
> 
> [Ahmad] I am not sure about the shadowy AAA phase does. Without
> understanding the details this for me is undefined.

I am not sure either.

However, without it the MAG can not send the P-BUs on behalf of MN.

If I knew what it does and how it works then I could say how it
distributes the seqno as well.

>> doesn't save us the risk of extraneous roundtrips.
> 
> [Ahmad] True. However, I do not believe that it is as bad as using
> SQN without synchronization. I hope you agree.

No :-)

>> I also think doing both timestamps+seqnos doesn't save us the same
>> risk.  I also think reusing the timestamps from DNA/SeND doesn't
>> save us the risk of sometimes running two round trips.
>> 
>> Alex PS: if we change the requirement to allow for a three-way
>> handshake (still forbid 2 round trips) then the solutions change
>> again.
> 
> [Ahmad] I do not think there is currently a mechanism to enable this
> three-way handshake in MIPv6 or PMIPv6.

Right, there isn't.  And there are many things in PMIPv6 that aren't in 
MIP6 either: reliance on timestamps and timesync, HNP in PBack, reliance 
on AAA, reliance on prefix-per-MN - to name a few.

You were talking about money and dollars: how much does it cost to 
upgrade the MIP6 HA software to PMIPv6?  how much does it cost to have 
all entities time synchronized?

I'm sure one could reuse much more of MIP6 than that.

Alex

> 
>>> Regards, Ahmad
>>> 
>>> 
>>>> -----Original Message----- From: Alexandru Petrescu
>>>> [mailto:[email-masked]] Sent: Thursday, September
>>>> 13, 2007 8:04 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: Alexandru
>>>> Petrescu; Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE
>>>> FEDERICO; [email-masked] Subject: Re: [netlmm] timestamp vs
>>>> seqno redux
>>>> 
>>>> Ahmad Muhanna wrote:
>>>>>>> [Ahmad] It is an over sight on my part. Sorry for the
>>>>>>> confusion.
>>>>>> else loads the network.
>>>>>> first
>>>> experience
>>>>> [Ahmad] Alex, There is no assumption about a constant delay?

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 17:01:28 +0200

> replay protection, but you are saying that does not guarantee ordering?

Good question.

I can say that my mip4 implementation doesn't rely on MN and HA be time 
synched and MIP4 messages are ordered.  But it's prototype.

(it's not "my" implementation, it has its open source origins as you may
  be aware).

> In other words, are you saying that the HA will accept an out of order

In extreme conditions, my implementation - yes.  Its problem is not 
packets being disordered, but security: another MN sending RegReq for 
the victim MN's Home Address.  And I plan to solve security by using 
IPsec encapsulated UDP.

> accepted another RRQ with timestamp (t1)?

YEs, it can.  And it has problems - security problems, not ordering 
problems.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 10:08:32 -0500

Alex,

You can call it security or whatever, it is part of the MIP4 replay
protection which guarantees ordering. If you would like to use IPsec
with MIP4 that is fine, but, then you may as well forget about MIPv4
replay protection because that is supposedly handled by IPsec too.

Regards,
Ahmad

> Sent: Thursday, September 13, 2007 10:01 AM
> I can say that my mip4 implementation doesn't rely on MN and 
> HA be time synched and MIP4 messages are ordered.  But it's prototype.
> 
> In extreme conditions, my implementation - yes.  Its problem 
> is not packets being disordered, but security: another MN 
> sending RegReq for the victim MN's Home Address.  And I plan 
> to solve security by using IPsec encapsulated UDP.
> 
> YEs, it can.  And it has problems - security problems, not 
> ordering problems.
> 
> Alex
> 
> >> I think there's no other IETF protocol that uses timestamps in 
> >> messages in order to ensure ordered delivery of messages.
> >>
> >> Alex
> >>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 10:17:24 -0500

Alex,

We are going in circle. This is my last response. 
Unfortunately or fortunately, I have other tasks that I need to work on
too.

Please see comments below.

Best Regards,
Ahmad

> >> _without_ extraneous P-BU/P-BAck roundtrips.  Then we can only do 
> >> this: (1) do seqno stuff at the shadowy AAA phase xor (2) rely on 

[Ahmad]
The functionality of the use of AAA in MN access authentication and
possible assignment of HNP, other MN information is well known concept.
However, what you are proposing is the use of keeping AAA always updated
with the last used SQN per-MN. I am not sure how realistic that approach
but at least , IMO, it is undefined.

> 
> If I knew what it does and how it works then I could say how 
> it distributes the seqno as well.
> 
> > [Ahmad] True. However, I do not believe that it is as bad 
> as using SQN 
> > without synchronization. I hope you agree.
> 
> No :-)

[Ahmad]
That is fine. I am not trying to change your mind:-)

> >> risk.  I also think reusing the timestamps from DNA/SeND 
> doesn't save 
> >> us the risk of sometimes running two round trips.
> >> 
> MIP6 either: reliance on timestamps and timesync, HNP in 
> PBack, reliance on AAA, reliance on prefix-per-MN - to name a few.
> 
> You were talking about money and dollars: how much does it 
> cost to upgrade the MIP6 HA software to PMIPv6?  how much 
> does it cost to have all entities time synchronized?
> 

[Ahmad]
That is also a cool thing! :-)
> >>>> [mailto:[email-masked]] Sent: Thursday, 
> September 13, 
> >>>> 2007 8:04 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: Alexandru 
> FEDERICO; 
> >>>> [email-masked] Subject: Re: [netlmm] timestamp vs seqno redux
> >>>> 
> >>>> Ahmad Muhanna wrote:
> conditions

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 18:21:52 +0200

> replay protection because that is supposedly handled by IPsec too.

And that is a good thing.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Sep 2007 11:50:27 -0500

[Ahmad]
Hi Alex,

I could not resist this one.:-) 

Distorting MIPv4 replay protection to prove a point that MIP4 replay
protection (based on timestamp) does not guarantee ordering and then you
suggest using IPsec to fix the distortion and finally calling that a
good thing. :-)

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Sep 2007 23:06:47 +0200

> suggest using IPsec to fix the distortion and finally calling that a

Hi Ahmad... sorry for misunderstanding...

I didn't mean the MIP4 replay protection based on timestamps doesn't 
work.  It can work.

IPsec used on MIP4 to ensure replay protection is a good thing.  I even 
think it's better than using timestamps in MIP4.

Alex