RE: [netlmm] timestamp vs seqno redux

["DE JUAN HUARTE FEDERICO" <[e-mail]>]

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:[e-mail]] 
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.

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:[e-mail]]
> Sent: Thursday, September 06, 2007 2:01 AM
> To: netlmm
> Subject: [netlmm] timestamp vs seqno redux
> 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/netlmm

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

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