Re: [SCTP] clarification about HB.Max.Burst parameter

"Ashish Gupta" <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <2690213D5CBF0C479454EE80957DA8BD092B46@in-exchange>
Please see my comments inline.

 

Regards,

-Ashish

 

________________________________

From: Ash Kat [mailto:[email protected]] 
Sent: Wednesday, June 04, 2008 6:10 PM
To: Ashish Gupta; [email protected]
Subject: Re: [Sigtran] [SCTP] clarification about HB.Max.Burst parameter

 

Ashish,

 

You have mentioned the 2 points:

 

1.. HB.Max.Burst is a max value and the number of heartbeat sent should
be less then or equal to this number.

 

 

On what basis the SCTP will decide whether the number of heartbeats sent
is less then HB.Max.Burst or should it send number of Heartbeats equal
to the number of HB.Max.Burst?

It means RFC 4960 is not clear about the usage of HB.Max.Burst.

[Ashish] See, it is the number of HEARTBEATs sent during one execution
of your path probing module. It does not count HEARTBEATs sent in
earlier execution.

 

2. This parameter will prevent network from flooding with too many
heartbeats to network, in case peer has large number of addresses.

 

I do not think so, because keeping this parameter > 1 will create even
more traffic. As after the RTO expiry of an address, the SCTP will send
Heartbeat to even those addresses for which heartbeat was already been
sent.

If this happens, then we have 2 Heartbeats on network for an UNCONFIRMED
address for which Retransmission timer has still not expired.

 

One more question, is SCTP re-starting the RTO of those addresses for
which RTO has not expired but a heartbeat is sent to them only because
some other address' RTO has expired?

according to example mentioned in previous mail, will SCTP of IUT will
re-start the RTO for IP-Y when the RTO of IP-X expires, even if RTO for
IP-Y is still running?

[Ashish] You got me wrong. HEARTBEAT to IP-Y won't be sent again if it's
RTO is still running. That's what I said, it is a max value, if RTO is
till running for IP-Y, on RTO expiry for IP-X, heartbeat will be sent to
IP-X ONLY.

 

 

IMO the value of HB.Max.Burst can be equal to one only.(as also
recommended by the RFC 4960)

Keeping it greater then 1 would not control the flooding of Heartbeats
on network but will make it worse.

 

If this is not the case then there should be some other way to implement
this parameter which is still not clear to us.

 

Thanks & Regards

Ashwani Kathuria

 

----- Original Message ----
From: Ashish Gupta <[email protected]>
To: Ash Kat <[email protected]>; [email protected]
Sent: Wednesday, 4 June, 2008 5:29:33 PM
Subject: RE: [Sigtran] [SCTP] clarification about HB.Max.Burst parameter

Ashwani,

 

It's a max value. So, in the example scenario, it is not required to
send HEARTBEAT to IP-Y, on IP-X RTO expiry.

 

If the peer has got large number of addresses, then this parameter is
used to control the number of HEARTBEAT sent for probing as one would
not like to flood the network with too many heartbeats. You can think of
a scenario with 6 addresses and the value of HB.Max.Burst as 2. Every
time your path probing module get chance, it will send two HEARTBEATS to
probe the UNCONFIRMED addresses.

 

Regards,

-Ashish 

 

________________________________

From: Ash Kat [mailto:[email protected]] 
Sent: Wednesday, June 04, 2008 5:16 PM
To: Ashish Gupta; [email protected]; [email protected]
Subject: Re: [Sigtran] [SCTP] clarification about HB.Max.Burst parameter

 

Hello Ashish,

 

Thanks for your prompt response.

 

The purpose of HB.Max.Burst is still not clear to me.

 

Let us take an example scenario. 

 

Suppose the peer to IUT has 2 interfaces IP-X and IP-Y 

RTO for IP-X is 1 sec. and for IP-Y is 2 sec..

HB.Max.Burst at IUT set to 2.

 

The IUT has sent the HBeat to IP-X & IP-Y and started the
Retransmission-timer separately for IP-X (1 sec) and I-Y (2 sec).

 

Both IP-X and IP-Y are not responding.

 

After 1 sec.

RTO expired for IP-X. 

As the HB.Max.Burst in 2, so IUT will send the HBeat to both, IP-X and
IP-Y, on the expiry of RTO for IP-X alone.

 

Why SCTP needs to send the Heartbeat to IP-Y even if I have already sent
an Heartbeat to IP-Y for which Retransmission timer is already running?

Here, the retransmission timer for IP-Y will take 1 more second to
expire.

 

Also, if IUT sends the Heartbeat to IP-Y on the RTO expiry of IP-X then
will it restart the RTO timer for IP-Y?

 

Please clarify as I am not able to understand the benefit of making
HB.Max.Burst > 1.

 

Thanks & Regards,

Ashwani Kathuria

 

----- Original Message ----
From: Ashish Gupta <[email protected]>
To: Ash Kat <[email protected]>; [email protected];
[email protected]
Sent: Wednesday, 4 June, 2008 3:39:00 PM
Subject: RE: [Sigtran] [SCTP] clarification about HB.Max.Burst parameter

Hi Ashwani,

 

When RTO expires for an address, your path probing module will get
chance to send HEARTBEATS to other UNCONFIREMD addresses as well (NOT
only to the address for which RTO has expired) limited by HB..Max.Burst
parameter.

 

Hope this helps.

 

Regards,

-Ashish

 

________________________________

From: [email protected] [mailto:[email protected]] On
Behalf Of Ash Kat
Sent: Wednesday, June 04, 2008 3:14 PM
To: [email protected]; [email protected]
Subject: [Sigtran] [SCTP] clarification about HB.Max.Burst parameter

 

Hello All,

 

SCTP RFC 4690 has mentioned a parameter HB..Max.Burst.

As per RFC 4960 section 4.5 :

   The number of HEARTBEATS sent at each RTO SHOULD be limited by the
   HB.Max.Burst parameter.

 

During the Path verification when an RTO expires, SCTP will re-send the
Heartbeat to that address.

Please clarify me, how HB.Max.Burst parameter will control the number of
Heartbeat sent to that address.

Shouldn't the number of Heartbeat send to a particular address at any
time will always be 1? 

If Yes, then why HB.Max.Burst is required?

If No, then please make me understand that how this parameter is used.

 

Thanks & Regards,

Ashwani Kathuria

 

________________________________

Bring your gang together. Do your thing. Find your favourite Yahoo!
Group.
<http://in.rd.yahoo.com/tagline_groups_9/*http:/in.promos.yahoo.com/grou
ps/> 

 

________________________________

Bring your gang together. Do your thing. Find your favourite Yahoo!
Group.
<http://in.rd.yahoo.com/tagline_groups_9/*http:/in.promos.yahoo.com/grou
ps/> 


Send free SMS to your Friends on Mobile from your Yahoo! Messenger.
Download Now! http://messenger.yahoo.com/download.php

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.