Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 2 May 2007 11:35:53 -0500

Sorry for not responding earlier. Please see comments inline.

Regards,
Ahmad

> -----Original Message-----
> From: Marco Liebsch [mailto:[email-masked]] 
> Sent: Friday, April 27, 2007 9:41 AM
> To: Sri Gundavelli
> Cc: [email-masked]
> Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic
> 
> I also think that the timestamp solution is only a 
> compromise, 

[Ahmad]
Why do you think timestamp is a compromise?

> which should be possible to switch off in case 
> future versions support more appropriate solutions. As a 

[Ahmad]
Without understanding what are the more appropriate solutions you have
in mind, I believe this stays within the theory space.

> general design goal, I think that we should avoid adding too 
> much complexity to nodes, such as solution #2 and #3.

[Ahmad]
Could you explain what do you mean by much complexity to the nodes? 
> 
> Even though solution #5 might imply double handshake between 
> nMAG and LMA before the new registration can be accepted, it 
> looks like the most clean solution. 

[Ahmad]
We differ here on the definition of "most clean solution" here.

> It can easily be omitted 
> in future versions, allowing the nMAG to use a correct 
> sequence number from the beginning. Maybe the first PBU from 
> the nMAG can create a 'tentative' registration, which is then 
> approved by the correct one. This would at least allow 
> packets to be forwarded from the beginning.

[Ahmad]
IMO, at any time the fundamental behavior of a protocol changes to
address a very specific and limited scenario, it is a RED flag and not
the best possible solution.

Let us assume that your justification of the use of solution # 5 is
valid and acceptable, and the first PBU created the tentative
registration. What happens if the second P-BU is lost? How long LMA
needs to keep the tentative registration? Does that add any complexity
to the nodes?

Another thing, reading your statement "This would at least allow packets
to be forwarded from the beginning." It seems to me that you believe
this is an advantage of solution #5 over other solutions. Are you under
the impression that other solutions would not allow moving the tunnel
right away during handoff.?

> 
> marco
> 
> 
> 
> 
> Sri Gundavelli wrote:
> 
> >This issue was raised by Ahmad Muhanna. This is about the Time Stamp 
> >option that we introduced in the Proxy Mobile IPv6 
> specification. Ahmad 
> >did not like the timestamp option and suggested two other possible 
> >solutions and I've added two more possible solutions to the list, in 
> >addition to the time stamp based solution.
> > 
> >We have discussed with Ahmad offline and wanted to bring 
> this to the ML 
> >for getting some ideas. Please comment, if the time stamp 
> option what 
> >we have is better than the other options or if we need to 
> remove that.
> >
> >
> >
> >Scenario:
> >
> >        [LMA]
> >          |
> >          |
> >    -----(NET)----
> >    |            |
> > [MAG-1]      [MAG-2]
> >    |
> >   MN1 ----->
> >
> >
> >MN1 was attached to MAG-1
> >MAG-1 sends a PBU(1) to LMA and right then,
> >
> >MN1 moves from MAG-1 and attaches to MAG-2.
> >MAG-2 sends a PBU(2) to LMA. 
> >
> >LMA may or may not receive both the messages in
> >the same order as they were sent.
> >
> >Correct Arriving Sequence: 
> >The correct sequence of packet arrival at the LMA is as 
> >follows: PBU(1) then PBU(2)
> >
> >Possible Arriving Sequence: 
> >The possible sequence of packet arrival at the LMA is as 
> >follows: PBU(2) then PBU(1)
> >
> >Impact:
> >LMA accepts PBU(2) and creates the tunnel to MAG-2. Immediately
> >it receives PBU(1) and it deletes the tunnel and creates a tunnel
> >to MAG-1.
> >
> >
> >
> >Possible Solutions:
> >-------------------
> >Solution#1: Use of Time Stamp 
> >
> >Source: Proxy Mobile IPv6 specification
> >
> >1. Add the Time Stamp Option to the Proxy Binding Update message.
> >
> >2. LMA should verify the time stamp value on the received PBU is
> >   later than the time stamp value in the currently accepted PBU.
> >
> >3. If the time stamp in the received PBU is older than what was
> >   the time stamp in the currently accepted PBU, reject the request.
> >
> >
> >Advantages:
> >No special logic is required. Check the time stamp on the 
> received PBU,
> >
> >Disadvantages: 
> >Requires NTP service in the PMIP domain and the clocks on the LMA
> >and all the MAG's in the domain must be synced to 
> millisecond accuracy.
> >
> >
> >
> >Solution#2: 
> >
> >Source: Ahmad Muhanna
> >
> >1. When LMA receives a P-BU with a CoA different than the CoA in the
> >MN's BCE, LMA MUST do the following: 
> >
> >1.1. LMA must verify that the sequence number in P-BU is more recent
> >than the last sequence number received from the same MAG which host
> >the CoA in the PBU. i.e. per Node SA.
> >
> >1.2. If the PBU passes the sequencing check and other 
> security checks,
> >LMA must update the BCE with the new CoA and the per-Node sequence
> >number counter as per the received seq. No.
> >
> >1.3. LMA must starts a timer, for example, of 5 seconds and track the
> >old CoA(old). 
> >
> >1.4. If LMA receives a PBU with a CoA = CoA(old) before the timer
> >expires, LMA ignore the P-BU waiting for the MAG1 to retransmit. If
> >MAG1 did not retransmit before the timer expires, LMA cancel 
> the timer
> >and goes back to normal mode.
> >
> >1.5. If LMA receives a retransmit of the P-BU before the 
> timer expires,
> >LMA honors the P-BU. 
> >
> >
> >Disadvantages:
> >
> >Any movements within 5 sec interval after anchoring will require
> >additional registration round trip ?
> >
> >
> >
> >Solution#3: 
> >
> >Source: Ahmad Muhanna
> >
> >1. When LMA receives a PBU with a CoA different than the CoA in the
> >MN's BCE, LMA MUST do the following:
> >
> >1.1. LMA must verify that the sequence number in P-BU is more recent
> >than the last sequence number received from the same MAG which host
> >the CoA received in the PBU. i.e. per Node SA.
> >
> >1.2. If the PBU passes the sequencing check and other 
> security checks,
> >LMA must update the BCE with the new CoA and the per-Node sequence
> >number counter as per the received seq. No.
> >
> >1.3. LMA must starts a timer, for example, of 5 seconds and track
> >the old CoA(old). 
> >
> >1.4. If LMA receives a PBU with a CoA = CoA(old) before the timer
> >expires, LMA rejects the PBU with an error code (for example: MN is
> >process of HO) This error code should make the MAG retransmit or
> >retry if the MN is really attached to it and it was not just a race
> >condition.
> >
> >
> >Disadvantages:
> >
> >Any movements within 5 sec interval after anchoring will require
> >additional registration round trip ?
> >
> >
> >
> >
> >Solution#4:
> >
> >Source: Sri Gundavelli
> >
> >1. On detecting a mobile node on its access link. the MAG must send
> >the PBU. Once,	 the MAG receives a successful PBA, it 
> must again
> >send a second PBU request after 1 sec. This method of sending two
> >consecutive PBU messages will ensure the binding request from the
> >currently anchored MAG survives against any network out of order
> >delivery conditions.
> >
> >2. This resending logic is required only for the first registration
> >request sent by a MAG after detecting a mobile node on its access
> >link.
> >
> >
> >Disadvantages:
> >
> >1 extra packet (not round trip) sent for the first registration
> >after a mobile attaches to a new MAG.
> >
> >
> >
> >
> >Solution#5: 
> >
> >Source: Julien Laganier
> >
> >1. The LMA on receiving a PBU message from a new CoA, the LMA must
> >reject the request and provide the sequence number that the 
> MAG should
> >use in the subsequent PBU message. Typically, the suggested value is
> >+2 than what is the currently accepted sequence number.
> >
> >Disadvantages:
> >
> >1. One additional round trip for all initial registrations from a new
> >MAG.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >_______________________________________________
> >netlmm mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/netlmm
> >  
> >
> 
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
> 

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 3 May 2007 12:09:07 -0500

Hi Sri,

After some offline discussions, I would like to clarify one thing about
the use of SQN. I believe the per-MN SQN mechanism as per RFC3775 should
work for PMIPv6 and it can address the race condition specified in this
thread. For that cause, probably the following text is a good start for
capturing this conclusion;

A Per-MN SQN mechanism, as per RFC3775, can address the identified race
condition and also avoid a two round trip registration during inter-MAG
handoff by using an out of scope mechanism to transfer the MN session
SQN state from the source MAG to the target MAG; e.g. Context Transfer.

One last thing that probably an oversight of the PMIPv6 draft is the
following: In order to enable a per-MN SQN mechanism in the case of
PMIPv6, the MN-ID must be included in all P-BA, which is probably
given.:)

Thanks for consideration.

Regards,
Ahmad

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 1:50 AM
> To: [email-masked]
> Subject: [netlmm] Issue: Timestamp vs Sequence Number based logic
> 
> This issue was raised by Ahmad Muhanna. This is about the 
> Time Stamp option that we introduced in the Proxy Mobile IPv6 
> specification. Ahmad did not like the timestamp option and 
> suggested two other possible solutions and I've added two 
> more possible solutions to the list, in addition to the time 
> stamp based solution.
>  
> We have discussed with Ahmad offline and wanted to bring this 
> to the ML for getting some ideas. Please comment, if the time 
> stamp option what we have is better than the other options or 
> if we need to remove that.
> 
> 
> 
> Scenario:
> 
>         [LMA]
>           |
>           |
>     -----(NET)----
>     |            |
>  [MAG-1]      [MAG-2]
>     |
>    MN1 ----->  
> 
> 
> LMA may or may not receive both the messages in the same 
> order as they were sent.
> 
> LMA accepts PBU(2) and creates the tunnel to MAG-2. 
> Immediately it receives PBU(1) and it deletes the tunnel and 
> creates a tunnel to MAG-1.
> 
> 
> 
> Possible Solutions:
> -------------------
> Requires NTP service in the PMIP domain and the clocks on the 
> LMA and all the MAG's in the domain must be synced to 
> millisecond accuracy.
> 
> 
> 
> Solution#2: 
> 
> Source: Ahmad Muhanna
> 
> 1. When LMA receives a P-BU with a CoA different than the CoA 
> in the MN's BCE, LMA MUST do the following: 
> 
> 1.1. LMA must verify that the sequence number in P-BU is more 
> recent than the last sequence number received from the same 
> MAG which host the CoA in the PBU. i.e. per Node SA.
> 
> security checks, LMA must update the BCE with the new CoA and 
> the per-Node sequence number counter as per the received seq. No.
> 
> 1.3. LMA must starts a timer, for example, of 5 seconds and 
> track the old CoA(old). 
> 
> 1.4. If LMA receives a PBU with a CoA = CoA(old) before the 
> timer expires, LMA ignore the P-BU waiting for the MAG1 to 
> retransmit. If
> the timer and goes back to normal mode.
> 
> timer expires, LMA honors the P-BU. 
> 
> 
> Disadvantages:
> 
> Any movements within 5 sec interval after anchoring will 
> require additional registration round trip ?
> 
> 
> 
> Solution#3: 
> 
> Source: Ahmad Muhanna
> 
> 1. When LMA receives a PBU with a CoA different than the CoA 
> in the MN's BCE, LMA MUST do the following:
> 
> 1.1. LMA must verify that the sequence number in P-BU is more 
> recent than the last sequence number received from the same 
> MAG which host the CoA received in the PBU. i.e. per Node SA.
> 
> security checks, LMA must update the BCE with the new CoA and 
> the per-Node sequence number counter as per the received seq. No.
> 
> 1.3. LMA must starts a timer, for example, of 5 seconds and 
> track the old CoA(old). 
> 
> 1.4. If LMA receives a PBU with a CoA = CoA(old) before the 
> timer expires, LMA rejects the PBU with an error code (for 
> example: MN is process of HO) This error code should make the 
> MAG retransmit or retry if the MN is really attached to it 
> and it was not just a race condition.
> 
> 
> Disadvantages:
> 
> Any movements within 5 sec interval after anchoring will 
> require additional registration round trip ?
> 
> 
> 
> 
> Solution#4:
> 
> Source: Sri Gundavelli
> 
> send a second PBU request after 1 sec. This method of sending 
> two consecutive PBU messages will ensure the binding request 
> from the currently anchored MAG survives against any network 
> out of order delivery conditions.
> 
> 2. This resending logic is required only for the first 
> registration request sent by a MAG after detecting a mobile 
> node on its access link.
> 
> 
> Disadvantages:
> 
> 1 extra packet (not round trip) sent for the first 
> registration after a mobile attaches to a new MAG.
> 
> 
> 
> 
> Solution#5: 
> 
> Source: Julien Laganier
> 
> 1. The LMA on receiving a PBU message from a new CoA, the LMA 
> must reject the request and provide the sequence number that 
> the MAG should use in the subsequent PBU message. Typically, 
> the suggested value is
> 1. One additional round trip for all initial registrations 
> from a new MAG.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 3 May 2007 22:05:00 -0700

Hi Ahmad:

Thanks for the clarification. So, I assume from all the
offline and online email exchanges, the input is that:

- We can continue to have the time-stamp option as defined
  in the draft.

- We will also continue to support Per-MN sequence number,
  and in the absence of time stamp option, this will be used. 
  However, the exact mechanism of how this is transferred
  between MAG's or context transfer scheme is out the scope
  for this document.

- The PBA must return the MN-ID, for error code 135, for the
  MAG to be able to match the request to the response. As there
  may be a collision of sequence number for the pending requests
  for different mobiles, using their respective seq number.

I'm ok with this conclusion, if others agree.

Regards
Sri

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Thursday, May 03, 2007 10:09 AM
> To: Sri Gundavelli; [email-masked]
> Cc: Kilian Weniger; Jean-Mickael Guerin; Mohamed Khalil; 
> Vijay Devarapalli
> Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic
> 
> 
> Hi Sri,
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 4 May 2007 00:19:39 -0500

Hi Sri,

 - We will also continue to support Per-MN sequence number,
   and in the absence of time stamp option, this will be used. 
   However, the exact mechanism of how the Per-MN SQN state is 
   transferred between MAG's or context transfer scheme is out 
   of the scope for this document.

>   for different mobiles, using their respective seq number.
 
 - The PBA must always return the MN-ID in order to for the MAG
   to always be able to match the request to the response. As there
   may be a collision of sequence number for the pending requests
   for different mobiles, using their respective seq number.

Regards,
Ahmad

> Sent: Friday, May 04, 2007 12:05 AM
> To: Muhanna, Ahmad (RICH1:2H10); 'Kilian Weniger'; 
> 'Jean-Mickael Guerin'; Khalil, Mohamed (RICH2:2S20); 'Vijay 
> Devarapalli'
> Cc: [email-masked]
> > Cc: Kilian Weniger; Jean-Mickael Guerin; Mohamed Khalil; Vijay 
> > Devarapalli
> > After some offline discussions, I would like to clarify one thing 
> > about the use of SQN. I believe the per-MN SQN mechanism as per
> > RFC3775 should
> > work for PMIPv6 and it can address the race condition specified in 
> > this thread. For that cause, probably the following text is a good 
> > start for capturing this conclusion;
> > 
> > A Per-MN SQN mechanism, as per RFC3775, can address the identified 
> > race condition and also avoid a two round trip registration during 
> > inter-MAG handoff by using an out of scope mechanism to 
> transfer the 
> > MN session SQN state from the source MAG to the target MAG; e.g. 
> > Context Transfer.
> > 
> Time Stamp 
> > > option that we introduced in the Proxy Mobile IPv6 specification. 
> > > Ahmad did not like the timestamp option and suggested two other 
> > > possible solutions and I've added two more possible 
> solutions to the 
> > > list, in addition to the time stamp based solution.
> > >  
> this to the 
> > > ML for getting some ideas. Please comment, if the time 
> stamp option 
> > > what we have is better than the other options or if we need to 
> > > remove that.
> > > 
> > > 
> > > 
> > > Scenario:
> > > 
> > >         [LMA]
> > >           |
> > >           |
> > >     -----(NET)----
> > >     |            |
> > >  [MAG-1]      [MAG-2]
> > >     |
> > >    MN1 ----->
> > > 
> > > 
> > > LMA may or may not receive both the messages in the same order as 
> > > they were sent.
> > > 
> > > Immediately it receives PBU(1) and it deletes the tunnel 
> and creates 
> > > a tunnel to MAG-1.
> > > 
> > > 
> > > 
> > > Possible Solutions:
> > > -------------------
> received 
> > > PBU,
> > > and all the MAG's in the domain must be synced to millisecond 
> > > accuracy.
> > > 
> > > 
> > > 
> > > Solution#2: 
> > > 
> > > Source: Ahmad Muhanna
> > > 
> > > 1.2. If the PBU passes the sequencing check and other security 
> > > checks, LMA must update the BCE with the new CoA and the per-Node 
> > > sequence number counter as per the received seq. No.
> > > 
> > > MAG1 did not retransmit before the timer expires, LMA cancel the 
> > > timer and goes back to normal mode.
> > > 
> > > 1.5. If LMA receives a retransmit of the P-BU before the timer 
> > > expires, LMA honors the P-BU.
> > > 
> > > 
> > > Disadvantages:
> > > 
> > > 1.2. If the PBU passes the sequencing check and other security 
> > > checks, LMA must update the BCE with the new CoA and the per-Node 
> > > sequence number counter as per the received seq. No.
> > > 
> > > expires, LMA rejects the PBU with an error code (for
> > > example: MN is process of HO) This error code should make the MAG 
> > > retransmit or retry if the MN is really attached to it and it was 
> > > not just a race condition.
> > > 
> > > 
> > > Disadvantages:
> > > 
> registration 
> > > reject the request and provide the sequence number that the MAG 
> > > should use in the subsequent PBU message. Typically, the 
> suggested 
> > > value is
> > > 1. One additional round trip for all initial registrations from a 
> > > new MAG.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 3 May 2007 22:32:18 -0700

Hi Ahmad:

> Sent: Thursday, May 03, 2007 10:20 PM
> To: Sri Gundavelli; Kilian Weniger; Jean-Mickael Guerin; 
> Mohamed Khalil; Vijay Devarapalli
> Cc: [email-masked]

Offcourse ..its implied ...

>    for different mobiles, using their respective seq number.

Sure. Agreed.

Thanks
Sri

---

From: Christian Vogt <[email-masked]>
Date: Fri, 04 May 2007 09:38:51 +0300

Sri Gundavelli wrote:
> Thanks for the clarification. So, I assume from all the offline and
> online email exchanges, the input is that:
> 
> - We can continue to have the time-stamp option as defined in the
> draft.

I very much think this makes sense, at least as a default reordering
mechanism.  The level of clock synchronization between MAGs that PMIPv6
requires for timestamps is well above what NTP is able to provide,
especially within a single PMIPv6 domain.  I am specifically referring
to the 40-to-70-ms handover delay that is envisioned in the Goals
document.  Given this handover delay objective, it can be assumed that
the time span between the arrival of two subsequent PBUs at the LMA will
most likely be in the order of tens of milliseconds with base PMIPv6.

Should later optimizations allow for more efficient handovers, reducing
the potential inter-arrival time of PBUs at the LMA, those would likely
incorporate some inter-MAG interaction during handover, providing
exactly the right vehicle for context transfer and thus a seqno-based
reordering mechanism.

So this is a good way forward, I think.

One side note, though, to be kept in mind for future enhancements:  The
issue of clock synchronization is more substantial in the case of
roaming across different administrative PMIPv6 domains, since different
PMIPv6 domains might not (be willing to) synchronize the clocks of their
respective MAGs.

- Christian

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 4 May 2007 00:00:33 -0700

Hi Christian:

Please see inline.

> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Thursday, May 03, 2007 11:39 PM
> To: Sri Gundavelli
> Cc: 'Ahmad Muhanna'; 'Kilian Weniger'; 'Jean-Mickael Guerin'; 
> 'Mohamed Khalil'; 'Vijay Devarapalli'; [email-masked]
> mechanism.  The level of clock synchronization between MAGs 

[Sri] Ok. Good to know, you are ok with this as well. I think, we 
probably converged on this. We will have this as the default
mechanism.

> that PMIPv6

Ok. Probably, this might be ok as well, since, we dont talk about
the PMIP scope with in a domain. I agree, we need to keep this
parameter in mind.

Regards
Sri

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 4 May 2007 09:59:28 +0200

Hi Sri, 

I agree to this conclusion.

Regards,

Kilian

> Sent: Freitag, 4. Mai 2007 07:20
> specification. 

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

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 07 May 2007 09:19:26 +0200

Hi Ahmad,

>Why do you think timestamp is a compromise?
It has been proposed to solve some reordering issues. But with the costs of
additional complexity. And it depends on the accuracy of sync between nodes
by means of NTP or other mechanisms. It's ok for a first go, but it's 
cleaner
to solve this by means of context transfer or re-establisment.

>in mind, I believe this stays within the theory space.
:-) transfer of sequence number context, for example.
By the way, solution #5 is kind of sequence number context transfer via
the LMA.

>Could you explain what do you mean by much complexity to the nodes? 
Well, in my opinion it's a bit vague to specify tracking the old CoA for
a few seconds, maybe 5 (why 5 an not 10?). This is complexity at LMA on
a per-MN basis. Maybe not for the specification, but to implement. I must
admit that all proposed mechanisms imply some level of complexity.

>We differ here on the definition of "most clean solution" here.
Yes.

>needs to keep the tentative registration? Does that add any complexity
MAG does retransmission based on timeout, right?

>right away during handoff.?
No, I did not compare to other proposals. Just tried to optimize within
the scope of the same solution. The 'tentative' proposal was only to avoid
mandating always 2 handshakes before the states are accepted as updated 
on the
LMA. Would be sub-optimal when taking into account, that the race condition
case we are discussing might appear only rarely.

Thanks,
marco

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 8 May 2007 18:43:04 -0700

I think we have agreement on this issue, with Ahmad, Kilian,
Marco and Christian all agreeing to the conclusion. We will
close the discussions on this thread and we will adopt the
suggested line of text to the affect in the -01 version of
the draft that we are working on. Thanks to every one for
all the online and offline discussions.

Regards
Sri

> From: Kilian Weniger [mailto:[email-masked]] 
> Sent: Friday, May 04, 2007 12:59 AM
> To: Ahmad Muhanna; Sri Gundavelli; Jean-Mickael Guerin; 
> security 
> security