Subject: [netlmm] comments on draft-devarapalli-netlmm-pmipv6-heartbeat

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 3 Jun 2008 14:37:29 +0200

Hi Vijay,
 
A couple of comments realted to MAG-LMA heartbeat mechanism:
 
The draft states that sequence numbers are used to match requests with replies. The draft also says that the LMA saves the sequence number received from MAG. If the sequence number is only used to match messages, there is no need for LMA to save the sequence number, it can forget about the sequence number as soon as it sends a response.
 
Maybe the intention was to use sequence number also to detect crashes/reboots of the MAG? I think this would be useful functionality, but it needs some supporting text. Likewise, it would be useful if the LMA could detect a MAG crash.
 
When the LMA sends a one-time heartbeat message to MAG, can it use any sequence number or should it use the one received from the MAG in the last heartbeat message and incremented by one? Or does the LMA maintain its own sequence number counter for this purpose?

Would it make sense that every successful MAG-LMA transaction (like (re-)registration of a MN) resets the HEARTBEAT_INTERVAL timer?
 
In the light of the generic notification discussion scope, do you think that heartbeat mechanism could be using the generic notification draft, or is it better to have new MH types for heartbeat messages? I don't have an opinion on this, simply trying to understand what would be the pros and cons of each approach in this particular case.
 
typo:
> The HEARTBEAT_INTERNAL SHOULD NOT be configured...  
s/INTERNAL/INTERVAL

domagoj

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 03 Jun 2008 11:52:02 -0700

Hi Domagoj,

On 6/3/08 5:37 AM, "Premec, Domagoj" <[email-masked]> wrote:

> The draft states that sequence numbers are used to match requests with
> replies. The draft also says that the LMA saves the sequence number received
> from MAG. If the sequence number is only used to match messages, there is no
> need for LMA to save the sequence number, it can forget about the sequence
> number as soon as it sends a response.
>  
> Maybe the intention was to use sequence number also to detect crashes/reboots
> of the MAG? I think this would be useful functionality, but it needs some
> supporting text. Likewise, it would be useful if the LMA could detect a MAG
> crash.

I will be submitting a new draft very soon. It has support for detecting
crashes/reboots through an explicit mechanism. The mechanism is very similar
to GTP's Restart Counter-based recovery mechanism.
  
> When the LMA sends a one-time heartbeat message to MAG, can it use any
> sequence number or should it use the one received from the MAG in the last
> heartbeat message and incremented by one? Or does the LMA maintain its own
> sequence number counter for this purpose?

The LMA maintains its own.
 
> Would it make sense that every successful MAG-LMA transaction (like
> (re-)registration of a MN) resets the HEARTBEAT_INTERVAL timer?

Good question. I didn't think about this. The MAG and the LMA should have a
good understanding of which successful message exchange can reset the
HEARTBEAT_INTERVAL timer. Don't have an opinion yet.
  
> In the light of the generic notification discussion scope, do you think that
> heartbeat mechanism could be using the generic notification draft, or is it
> better to have new MH types for heartbeat messages? I don't have an opinion on
> this, simply trying to understand what would be the pros and cons of each
> approach in this particular case.

Yes, these messages can re-use the generic notification message. Lets see
what the MEXT WG decides on the scope of the generic notification draft.
  
>> The HEARTBEAT_INTERNAL SHOULD NOT be configured...

Fixed, thanks.

Vijay

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 5 Jun 2008 15:13:25 +0200

Vijay,

I looked at the -02 version, and it doesn't explain why the LMA needs to save the sequence number received in the heartbeat message. Let me ask this in a different way: how does the LMA react when it receives the heartbeat message with unexpected sequence number?

I thought that the saved sequence numbers could be used to detect re-boots. If a node detects an unexpected sequence number, this is a signal that the peer node re-booted. To distinguish between the roll-over of a sequence number and re-boot, the sequnce number should re-start from 256 in case of roll-over. 

This seems as simpler mechanism since it uses only one counter and doesn't require non-volatile memory.

domagoj

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: 03. lipanj 2008 20:52
> To: Premec, Domagoj
> Cc: [email-masked]
> Subject: Re: comments on draft-devarapalli-netlmm-pmipv6-heartbeat
> 
> Hi Domagoj,
> 
> > replies. The draft also says that the LMA saves the sequence number 
> > received from MAG. If the sequence number is only used to match 
> > messages, there is no need for LMA to save the sequence 
> number, it can 
> > forget about the sequence number as soon as it sends a response.
> >  
> > Maybe the intention was to use sequence number also to detect 
> > crashes/reboots of the MAG? I think this would be useful 
> > functionality, but it needs some supporting text. Likewise, 
> it would 
> > be useful if the LMA could detect a MAG crash.
> 
> I will be submitting a new draft very soon. It has support 
> for detecting crashes/reboots through an explicit mechanism. 
> The mechanism is very similar to GTP's Restart Counter-based 
> recovery mechanism.
>   
> > sequence number or should it use the one received from the 
> MAG in the 
> > last heartbeat message and incremented by one? Or does the LMA 
> > maintain its own sequence number counter for this purpose?
> 
> Good question. I didn't think about this. The MAG and the LMA 
> should have a good understanding of which successful message 
> exchange can reset the HEARTBEAT_INTERVAL timer. Don't have 
> an opinion yet.
>   
> > In the light of the generic notification discussion scope, do you 
> > think that heartbeat mechanism could be using the generic 
> notification 
> > draft, or is it better to have new MH types for heartbeat 
> messages? I 
> > don't have an opinion on this, simply trying to understand 
> what would 
> > be the pros and cons of each approach in this particular case.
> 
> Yes, these messages can re-use the generic notification 
> message. Lets see what the MEXT WG decides on the scope of 
> the generic notification draft.
>   
> > typo:

---

From: Julien Laganier <[email-masked]>
Date: Thu, 5 Jun 2008 15:32:33 +0200

On Thursday 05 June 2008, Premec, Domagoj wrote:
> Vijay,
>
> I looked at the -02 version, and it doesn't explain why the LMA needs
> to save the sequence number received in the heartbeat message. Let me
> ask this in a different way: how does the LMA react when it receives
> the heartbeat message with unexpected sequence number?
>
> I thought that the saved sequence numbers could be used to detect
> re-boots. If a node detects an unexpected sequence number, this is a
> signal that the peer node re-booted. To distinguish between the
> roll-over of a sequence number and re-boot, the sequnce number should
> re-start from 256 in case of roll-over.
>

Domagoj,

Sequence number and restart counter have different semantics.

The sequence number is used to match a response with a request and thus 
should be different for different requests sent out. Independent from 
the fact the peer restarted or nor, this allows to test reachability of 
the peer. 

OTOH, the restart counter is used to detect if a peer has restarted. It 
shall stay the same if no restart occurred, and shall be incremented if 
the peer restarted.

Using the sequence number as the restart counter would tie reachability 
testing and restart detection. In the absence of restart, that would 
not allow the receiver of a response to match it with the appropriate 
request.

--julien

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 5 Jun 2008 15:48:20 +0200

Julien,

> Using the sequence number as the restart counter would tie 
> reachability testing and restart detection.

I think of it as a single mechanism that is able to detect both restarts and reachability.

>  In the absence of 
> restart, that would not allow the receiver of a response to 
> match it with the appropriate request.

I'm not sure I understand your point.

I thought that using a single counter would be simpler. Anyway, I have no strong opinion on this. .

domagoj

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: 05. lipanj 2008 15:33
> To: [email-masked]
> Cc: Premec, Domagoj; Vijay Devarapalli
> Subject: Re: [netlmm] comments on 
> draft-devarapalli-netlmm-pmipv6-heartbeat
> 
> The sequence number is used to match a response with a 
> request and thus should be different for different requests 
> sent out. Independent from the fact the peer restarted or 
> nor, this allows to test reachability of the peer. 
> 
> OTOH, the restart counter is used to detect if a peer has 
> restarted. It shall stay the same if no restart occurred, and 
> shall be incremented if the peer restarted.
> 
> Using the sequence number as the restart counter would tie 
> reachability testing and restart detection. In the absence of 
> restart, that would not allow the receiver of a response to 
> match it with the appropriate request.
> 
> --julien
>

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 05 Jun 2008 16:40:34 -0400

Hi Domagoj,
   If we use the same sequence number to detect restarts and for 
matching requests to replies there are some cases where we will get a 
false negative. e.g.

MAG -> LMA seq number x (received)
(MAG Reboot)
MAG -> LMA seq number x (lost)
MAG -> LMA seq number x+1 (received)

In this case the LMA would wrongly assume that the MAG had not 
restarted. This is why we require a separate restart counter stored in 
non-volatile memory.

Cheers
Suresh

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 6 Jun 2008 10:57:02 +0200

Hi Suresh,

hmm... MAG resets sequence number counter when it re-boots:

MAG -> LMA seq number x (received)
(MAG Reboot)
MAG -> LMA seq number 1 (lost)
...
MAG -> LMA seq number x (lost)
MAG -> LMA seq number x+1 (received)

The precondition is that first x messages after re-boot are lost. This can be taken care of by having the MAG increment the sequence number only for successful heartbeat transactions and not every time it sends a heartbeat message. So basically the MAG keeps re-transmitting the same message until it gets a response.

I just wanted to understand why the LMA is required to save the sequence number and as I couldn't see any other reasons I thought it must be to detect recoveries. I still don't have an answer to that question.

domagoj

> From: Suresh Krishnan [mailto:[email-masked]] 
> Sent: 05. lipanj 2008 22:41
> To: Premec, Domagoj
> Cc: Julien Laganier; [email-masked]
>    If we use the same sequence number to detect restarts and 
> for matching requests to replies there are some cases where 
> we will get a false negative. e.g.
> 
> 
> In this case the LMA would wrongly assume that the MAG had 
> not restarted. This is why we require a separate restart 
> counter stored in non-volatile memory.
> 
> Cheers
> Suresh
> 
> Premec, Domagoj wrote:
> > Julien,
> > 
> >> restart, that would not allow the receiver of a response 
> to match it 
> >> with the appropriate request.
> > 
> > I thought that using a single counter would be simpler. 
> Anyway, I have no strong opinion on this. .
> > 
> > domagoj
> > 
> >  
> > 
> >> From: julien laganier [mailto:[email-masked]] 
> On Behalf Of 
> >> Julien Laganier
> >>> This seems as simpler mechanism since it uses only one 
> counter and 
> >>> doesn't require non-volatile memory.
> >> Domagoj,
> >>
> >> The sequence number is used to match a response with a request and 
> >> thus should be different for different requests sent out. 
> Independent 
> >> from the fact the peer restarted or nor, this allows to test 
> >> reachability of the peer.
> >>
> restarted. 
> >> It shall stay the same if no restart occurred, and shall be 
> >> incremented if the peer restarted.
> >>
> >> restart, that would not allow the receiver of a response 
> to match it 
> >> with the appropriate request.
> >>
> >> --julien
> >>

---

From: Julien Laganier <[email-masked]>
Date: Fri, 6 Jun 2008 11:29:28 +0200

On Friday 06 June 2008, Premec, Domagoj wrote:
> I just wanted to understand why the LMA is required to save the
> sequence number and as I couldn't see any other reasons I thought it
> must be to detect recoveries. I still don't have an answer to that
> question.

I think there's no need to save the sequence number. An entity sending a 
request just need to remember the sequence number of outstanding 
requests. Once it got a matching reply to a request, the sequence 
number can be forgotten.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 6 Jun 2008 11:32:03 +0200

Domagoj,

The sequence number is used to match responses with requests. The 
restart counter is used to detect restart of the peer. These are two 
different things.

To match responses with requests the sequence number has to be different 
for different requests, while on the other hand to detect restart the 
restart counter has to stay the same until a restart occurs. These two 
have contradictory properties and thus merging them doesn't make sense.

--julien

On Thursday 05 June 2008, Premec, Domagoj wrote:
> > > I looked at the -02 version, and it doesn't explain why the
> >
> > LMA needs
> >
> > > to save the sequence number received in the heartbeat
> >
> > message. Let me
> >
> > > ask this in a different way: how does the LMA react when it
> >
> > receives
> >
> > > re-boots. If a node detects an unexpected sequence number,
> >
> > this is a
> >
> > > roll-over of a sequence number and re-boot, the sequnce
> >
> > number should
> >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 6 Jun 2008 10:07:23 -0500

Hi Domagoi/All,

My understanding of the restart counter that it is only used to indicate
that the Peer has restarted. If that that the case, then what you
mentioned about using the first 255 seq. nos as an indication for
restart should work (similar to FA restart mechanism in MIP4) However,
in order for that to work, the LMA needs to save the latest sq. no. at
least for the first 256 numbers.

In other words,

LMA does not save the sq. no. as long as the sq. no is larger than 256.
However, the first time the LMA receives a HB with sq. no. less than
256, LMA consider that the peer has rebooted and then save that number.
Because the next HB will possible have sq. no less that 256 and we do
not want the LMA to think that the MAG has rebooted one more time.

In response to the number of lost messages as a possible cause for not
detecting a failure, I guess the LMA need to miss 256 HB messages before
that ever happen. 

Regards,
Ahmad

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Premec, Domagoj
> Sent: Friday, June 06, 2008 3:57 AM
> To: Suresh Krishnan
> Cc: [email-masked]; Julien Laganier
> The precondition is that first x messages after re-boot are 
> lost. This can be taken care of by having the MAG increment 
> the sequence number only for successful heartbeat 
> transactions and not every time it sends a heartbeat message. 
> So basically the MAG keeps re-transmitting the same message 
> until it gets a response.
> 
> I just wanted to understand why the LMA is required to save 
> the sequence number and as I couldn't see any other reasons I 
> thought it must be to detect recoveries. I still don't have 
> an answer to that question.
> 
> domagoj
> 
> 
> 
> request and

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 9 Jun 2008 14:45:26 +0200

Ahmad,

I agree that if the seq. no. is used to detect re-boots, then the LMA needs to save it. And if it is used only to match requests to replies, then there is no need to save it. Meanwhile Julien explained that in the latter case the LMA is not required to save it, so I guess this requirement will be removed from the draft.

IMO, both approaches work and each has its own pros and cons.

domagoj

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: 06. lipanj 2008 17:07
> To: Premec, Domagoj; Suresh Krishnan
> Cc: [email-masked]; Julien Laganier; Julien Laganier
> Subject: RE: [netlmm] comments on 
> My understanding of the restart counter that it is only used 
> to indicate that the Peer has restarted. If that that the 
> case, then what you mentioned about using the first 255 seq. 
> nos as an indication for restart should work (similar to FA 
> restart mechanism in MIP4) However, in order for that to 
> work, the LMA needs to save the latest sq. no. at least for 
> the first 256 numbers.
> 
> In other words,
> 
> However, the first time the LMA receives a HB with sq. no. 
> less than 256, LMA consider that the peer has rebooted and 
> then save that number.
> Because the next HB will possible have sq. no less that 256 
> and we do not want the LMA to think that the MAG has rebooted 
> one more time.
> 
> In response to the number of lost messages as a possible 
> cause for not detecting a failure, I guess the LMA need to 
> miss 256 HB messages before that ever happen. 
> 
> 
> Regards,
> Ahmad
>  
> 
> lost. This 
> > can be taken care of by having the MAG increment the 
> sequence number 
> > only for successful heartbeat transactions and not every 
> time it sends 
> > a heartbeat message.
> until it 
> > gets a response.