RE: [netlmm] timestamp vs seqno redux

["Ahmad Muhanna" <[e-mail]>]

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
 

> -----Original Message-----
> From: Muhanna, Ahmad (RICH1:2H10) 
> Sent: Monday, September 10, 2007 1:34 PM
> To: 'DE JUAN HUARTE FEDERICO'; 'Sri Gundavelli'
> Cc: 'netlmm'
> Subject: 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.
> 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
>  
> 
> > -----Original Message-----
> > From: DE JUAN HUARTE FEDERICO
> > [mailto:[e-mail]]
> > Sent: Monday, September 10, 2007 12:44 PM
> > To: Sri Gundavelli
> > Cc: netlmm
> > Subject: RE: [netlmm] timestamp vs seqno redux
> > 
> > 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?
> 
> [Ahmad]
> Timestamp option is used in case 2 and 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:[e-mail]] 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 ..
> > 
> > 
> > > -----Original Message-----
> > > From: DE JUAN HUARTE FEDERICO
> > > [mailto:[e-mail]]
> > > Sent: Friday, September 07, 2007 2:04 AM
> > > To: Sri Gundavelli
> > > Cc: netlmm
> > > Subject: RE: [netlmm] timestamp vs seqno redux
> > > 
> > > 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
> > > 
> > 
> > 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.
> > 
> > 
> > > 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
> > > 
> > 
> > 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
> > > 
> > > 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
> > 
> > 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)
> > > 
> > > 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"
> > 
> > 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 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
> > > 
> > 
> > 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
> > 
> > 
> > 
> > > 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
> > 
> 

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