RE: [netlmm] timestamp vs seqno redux

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

Hi Sri,
Please see comments inline.

Regards,
Ahmad
 

> -----Original Message-----
> From: Sri Gundavelli [mailto:[e-mail]] 
> Sent: Thursday, September 06, 2007 2:58 PM
> To: 'Alexandru Petrescu'; 'netlmm'
> Subject: 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.

[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.
> 
> 
> Please comment. I want to close this issue. 
> 
> 
> 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.

> 
> 
> 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