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

"Ashish Gupta" <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <2690213D5CBF0C479454EE80957DA8BD092B37@in-exchange>
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/>

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