Subject: [Tsvwg] SCTP Heartbeat with multi-homing question

From: Robert Brennan <[email-masked]>
Date: Tue, 10 Jul 2001 13:55:52 +0100 (BST)

Hi All,

I'm trying to do some simulations of multi-homed
endpoints and I have some questions about heartbeats
in the current spec.

First (from section 8.3)
"   On an idle destination address that is allowed to heartbeat, a
   HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that
   destination address plus the protocol parameter 'HB.interval' , with
   jittering of +/- 50%, and exponential back-off of the RTO if the
   previous HEARTBEAT is unanswered."

Does this mean that the +/-50% jittering applies in all cases, or
only when the previous HEARTBEAT is unanswered? (I think the
former, but a little more clarity in the spec may be good to
prevent any confusion).

Then from the next paragraph
"... Only one heartbeat should be sent each time the heartbeat timer
 expires (if multiple destinations are idle)."

The concept of a HEARTBEAT being sent to only one idle address
once per RTO + HB.interval +/-50% doesn't seem consistent with
keeping seperate RTOs for each idle address... surely this implies
seperate heartbeat timer expiry times for each address (or at least
each RTO)?

Finally is it the intention that heartbeating to all idle addresses
backs off exponentially if any one address fails to answer?

Thanks for your help.

rgds
rob

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 10 Jul 2001 12:19:15 -0500

Rob,

See my comments below...

-Qiaobing

> former, but a little more clarity in the spec may be good to

Yes, it applies to all the cases.

> seperate heartbeat timer expiry times for each address (or at least

This is indeed an implementation related suggestion (noting the use of
"should"). You are right that it only makes sense if you use separate HB
timer for each different destination address. 

> backs off exponentially if any one address fails to answer?

No, you only back off the RTO of the address that fails to answer a
previous heartbeat sent to it.

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Tue, 10 Jul 2001 15:01:53 -0400

Q and Randy,

I would agree that the vagaries of the English language
warrant explicit wording so that questions similar to
Robert's are not raised in the future.

My comments/suggestions are in line. I mean for
them to be constructive.

Michael

>Yes, it applies to all the cases.

I think that is it clear that the jittering applied to all cases if you
saw the ", with jittering of +/- 50%," as a modifier to the heartbeat
interval. Thus, I think that this question was unwarranted and
unlikely to occur with great frequency. But I agree it would be
good to add more clarity.

However ... the jittering is on the sum of the {RTO + HB.interval}.
I would have guessed this as your intended meaning. But
the ", with jittering of +/- 50%," (in English) is a subordinate clause
that only serves to clarify what is already in the sentence; the
sentence (and its fundamental meaning) should stand correct
without its inclusion. If you strike this clause ... you lose a
significant informational content of the sentence. Thus, if you
have the ability to clarify this in the future, I'd recommend that
you state it more explicitly.

Also, I assume the exponential back-off is only on the
RTO and not on the sum {RTO + HB.interval} ... as it
is presently stated.

>timer for each different destination address.

I think one could add a suggestion to cover this question. A couple
of more "should" recommendations for clarification of this case
couldn't hurt.

>previous heartbeat sent to it.

I would have thought this was your intention also ... but this
question derived again from the overloaded information sentence
referenced in their email.

In technical English you should use the same exact adjectives
that modify a noun if you mean the same thing. Thus, in the
beginning of the sentence you use "RTO of that destination
address". Later in that sentence you use only "RTO" (without
the modifier). While OK in conversational English and in
prose ... you should use the full modification of the noun
again ... if you mean the same thing .. which you do. This
question was derived from a good engineer trying to
parse English as formalist. Thus simply adding "of the
destination address" after the second mention of RTO
would fix the sentence (and make it even longer!).

Normally I would not comment so explicitly ... but Randy
has confessed that Technical English formalisms are not
a strong suit for him.

Michael

> > rob

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Summer Office: +1.941.923.1203 (July/Aug 2001)
Office: +1.732.449.5762
Cell: +1.732.809.0188

---

From: Randall Stewart at work <[email-masked]>
Date: Thu, 19 Jul 2001 08:27:53 -0500

Michael:

Thanks for the suggestions... I think we do
need to clearify the heartbeat timing issues
in possibly the implementors guide... I missed
this one.. 

A while back we had a conversation on one of
the lists... I think sigtran... discussing the
intention of the jitter. The jitter is supposed
to be a 0 - 2 second random addition to the timing
so that you don't sync up the heartbeats :/ 

So we you should be starting a timer along the lines of

RTO + HB.Interval + (Random value between 0.0 - 2.0)seconds.

This provides a jitter but not such a huge varience as
is currently specified... I will attempt to work your suggestions
into a new section in the implementors guide... I have started 
accumulating some comments and I am sure I will find many
more when I finally catch up with my email :-0

R

-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 19 Jul 2001 13:18:42 -0500

...
> RTO + HB.Interval + (Random value between 0.0 - 2.0)seconds.

Randy,

I don't remember what was the conclusion from our previous discussion,
but I still have trouble with this change (making the jitter additive to
HB.Interval).

> is currently specified... 

This is not always true. 

For example, assuming typical value RTO = 1 sec and HB.Interval = 1 sec,
the current formula in RFC2960 will lead to an evenly distributed HB
time from 1.5 to 2.5 secs (variance=0.083), while your proposed additive
jitter will result in an evenly distributed HB time from 2 -4 secs
(variance=0.333). In this case, your change actually makes the variance
4 times bigger than what the current formula gives!

-Qiaobing

> I will attempt to work your suggestions

---

From: Randall Stewart at work <[email-masked]>
Date: Fri, 20 Jul 2001 06:56:43 -0500

> 4 times bigger than what the current formula gives!

Ok, 

But the recommended HB.Interval is 30 seconds... very few applications
will use 1 sec  and has Lixia has told us ... the vast majority of
folks will use the defualt..

so my formula:

1 + 30 + 0-2 = 31 - 33 seconds

Your formula:

1 + 15 - 45  = 16 - 46 seconds

a HUGE variation which was never never intended... the idea that
Vern and I have discussed it to provide a SMALL random jitter to
break things up... NOT to provide a vast varience in the jitter...

Let me dig back through and find the old email chain... 

R

ppp

---

From: Randall Stewart <[email-masked]>
Date: Fri, 20 Jul 2001 09:55:30 -0500

Ok,

After MUCH digging around... I finally have found
what you/Vern and I agreed to in the email archives...

The period of time for this dicussion is right when I
lost my DSL so it took me a bit of time :<

Now what we agreed to was the following:

Value for timer = (RTO) + (HB.Interval) + (+/- 50% * RTO)

This seems to me the right approach.. since if your RTO is scaling
up anyway it is better to be conservative... 

In the case where you are dealing with a 1 second min RTO, you
get a .5 - 1 second jitter which is exactly what we were
after so that things don't "sync up"

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)