RE: [netlmm] timestamp vs seqno redux

["Kilian Weniger" <[e-mail]>]

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

> -----Original Message-----
> From: Sri Gundavelli [mailto:[e-mail]] 
> Sent: Freitag, 7. September 2007 18:48
> To: 'Kilian Weniger'
> Cc: [e-mail]
> Subject: RE: [netlmm] timestamp vs seqno redux
> 
> Hi Kilian,
> 
>  
> 
> > -----Original Message-----
> > From: Kilian Weniger [mailto:[e-mail]] 
> > Sent: Friday, September 07, 2007 2:09 AM
> > To: Sri Gundavelli
> > Cc: [e-mail]
> > Subject: RE: [netlmm] timestamp vs seqno redux
> > 
> > Hi Sri, 
> > 
> > > - We are NOT mandating the nodes in the domain to sync up to
> > > a clock source. 
> > 
> > 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.
> > 
> 
> 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. 
> 
> 
> > > 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.
> > 
> > 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?
> > 
> 
> 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.
> 
> 
> > 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?
> > 
> 
> 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
> 
> > BR,
> > 
> > Kilian
> > 
> > 
> > Panasonic R&D Center Germany GmbH
> > 63225 Langen, Hessen, Germany
> > Reg: AG Offenbach (Hessen) HRB 33974
> > Managing Director: Thomas Micke
> 
> 


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



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