Subject: Re: Advantage & disadvantage of static tcp/sctp link and dynamic tcp/sctp link

From: Randall Stewart <[email-masked]>
Date: Wed, 07 Dec 2005 15:14:39 -0500

Anatoly:

This is a bug in the socket api document.. we changed this
so that the spp_flags have:
"
     SPP_HB_ENABLE - Enable heartbeats on the specified address.  Note
          that if the address field is empty all addresses for the
          association have heartbeats enabled upon them.

       SPP_HB_DISABLE - Disable heartbeats on the speicifed address.
          Note that if the address field is empty all addresses for the
          association will have their heartbeats disabled.  Note also
          that SPP_HB_ENABLE and SPP_HB_DISABLE are mutually exclusive,
          only one of these two should be specified.  Enabling both
          fields will have undetermined results.

       SPP_HB_DEMAND - Request a user initiated heartbeat to be made
          immediately.
"

So I just missed taking out the sentence above it about
0...

I will fix this for the next draft :-D

Good catch..

R

Anatoly Khusid wrote:
> Hello,
> 
> Had a question about HB.Interval in SCTP Sockets API draft.
> It looks like HB timer value is computed using this formula:
> 
> Value for timer = (RTO) + (HB.Interval) + (+/- 50% * RTO)
> 
> However, SCTP sockets API draft page 53 states that when spp_hbinterval is
> set to zero, it will disable the heartbeat.
> My question is how can I provision the heartbeat such that value for a timer
> becomes:
> 
> RTO + 0(HB.Interval) + (+/- 50% * RTO)
> 
> Basically I want to use RTO as my offset for heartbeats, and don't want to
> add HB.Interval to it.
> 
> 
> Thanks a lot.
> 
> Anatoly
> 

-- 
Randall Stewart
ITD - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

---

From: Randall Stewart <[email-masked]>
Date: Wed, 07 Dec 2005 16:30:39 -0500

Anatoly Khusid wrote:
> Hi Randall,
> 
> Thanks for the explanation.  I was still looking at version 09, without
> realizing that version 11 is already out.
> So if you will remove this sentence:
> "If a  value of zero is present in this field then no changes are to be made
> to this parameter"
> from [page 55].
> Then I could set spp_hbinterval = 0, and make my HEARTBEATs sent every (RTO
> + jitter)  ?
> 
> Thanks,

Yep, The section now is:
"

<t>
     Applications can enable or disable heartbeats for any peer address
     of an association, modify an address's heartbeat interval, force a
     heartbeat to be sent immediately, and adjust the address's maximum
     number of retransmissions sent before an address is considered
     unreachable. The following structure is used to access and modify an
     address's parameters:
<figure>
<artwork>
struct sctp_paddrparams {
     sctp_assoc_t            spp_assoc_id;
     struct sockaddr_storage spp_address;
     uint32_t                spp_hbinterval;
     uint16_t                spp_pathmaxrxt;
     uint32_t                spp_pathmtu;
     uint32_t                spp_sackdelay;
     uint32_t                spp_flags;
};
</artwork>
</figure>
<list style="hanging">
   <t hangText="spp_assoc_id - ">(one-to-many style socket) This is 
filled in the
                     application, and identifies the association for
                     this query.
  </t>
  <t hangText="spp_address -"> This specifies which address is of interest.
  </t>
  <t hangText="spp_hbinterval -"> This contains the value of the 
heartbeat interval,
                     in milliseconds.  Note that unless the
                     spp_flag is set to SPP_HB_ENABLE the value
                     of this field is ignored.
  </t>
  <t hangText="spp_pathmaxrxt -"> This contains the maximum number of
                     retransmissions before this address shall be
                     considered unreachable. Note that unless the
                     spp_flag is set to SPP_PMTUD_ENABLE the value
                     of this field is ignored.
  </t>

  <t hangText="spp_pathmtu -"> When Path MTU discovery is disabled the value
                     specified here will be the "fixed" path mtu (i.e. the
                     value of the spp_flags field must be SPP_PMTUD_DISABLE
                     for this field to have any effect).
                     Note that if the spp_address field is empty
                     then all associations on this address will
                     have this fixed path mtu set upon them.
  </t>
  <t hangText="spp_sackdelay -"> When delayed sack is enabled, this 
value specifies
                     the number of milliseconds that sacks will be delayed
                     for. This value will apply to all addresses of an
                     association if the spp_address field is empty.
                     Note that unless the
                     spp_flag is set to SPP_SACKDELAY_ENABLE the value
                     of this field is ignored
  </t>
  <t hangText="spp_flags-"> These flags are used to control various features
                     on an association. The flag field may contain
                     zero or more of the following options.
  <t><list style="hanging">
     <t hangText="SPP_HB_ENABLE -"> Enable heartbeats on the
                     specified address. Note that if the address
                     field is empty all addresses for the association
                     have heartbeats enabled upon them.
     </t>
     <t hangText="SPP_HB_DISABLE -"> Disable heartbeats on the
                     speicifed address. Note that if the address
                     field is empty all addresses for the association
                     will have their heartbeats disabled. Note also
                     that SPP_HB_ENABLE and SPP_HB_DISABLE are
                     mutually exclusive, only one of these two should
                     be specified. Enabling both fields will have
                     undetermined results.
     </t>
     <t hangText="SPP_HB_DEMAND -"> Request a user initiated heartbeat
                     to be made immediately.
     </t>
     <t hangText="SPP_PMTUD_ENABLE -"> This field will enable PMTU
                     discovery upon the specified address. Note that
                     if the address feild is empty then all addresses
                     on the association are effected.
     </t>
     <t hangText="SPP_PMTUD_DISABLE -"> This field will disable PMTU
                     discovery upon the specified address. Note that
                     if the address feild is empty then all addresses
                     on the association are effected. Not also that
                     SPP_PMTUD_ENABLE and SPP_PMTUD_DISABLE are mutually
                     exclusive. Enabling both will have undetermined
                     results.
     </t>
     <t hangText="SPP_SACKDELAY_ENABLE -"> Setting this flag turns
                     on delayed sack. The time specified in spp_sackdelay
                     is used to specify the sack delay for this address. 
Note
                     that if spp_address is empty then all addresses will
                     enable delayed sack and take on the sack delay
                     value specified in spp_sackdelay.
     </t>
     <t hangText="SPP_SACKDELAY_DISABLE -"> Setting this flag turns
                     off delayed sack. If the spp_address field is blank 
then
                     delayed sack is disabled for the entire 
association. Note
                     also that this field is mutually exclusive to
                     SPP_SACKDELAY_ENABLE, setting both will have undefined
                     results.
     </t>
     </list></t>
  </t>
</list>
"

This of course includes the previous changes that you did
not see in -11... but gets rid of the zero references..

R

---

From: Frank Filz <[email-masked]>
Date: Thu, 08 Dec 2005 17:42:22 -0800

> > Then I could set spp_hbinterval = 0, and make my HEARTBEATs sent every (RTO

Having just implemented this for Linux, I have some issues with these
changes. Without these changes, it was possible to disable and then re-
enable one of these features without having to fill in the value field
since the flags operated independently. With the change, you will have
to fill in the value field when enabling the feature.

To do what Anatoly wants to do, it would be possible to set hb-interval
to 1 msec, and unless RTO is very small, would not be noticeable.

With this change, I also have a concern as to what enabling SACK delay
with a delay of 0 means. That could mean SACK delay is disabled (so
there would be two ways to disable SACK delay). I guess it might provide
an useful feature if the implementation handled a timeout of 0 by
processing all queued packets and then processing the timeout. The
result would be that the implementation would effectively immediately
respond with a SACK, but if two packets were queued, it would only send
1 SACK. While that would be a nice feature, it seems like it would be
very implementation dependent.

>   <t hangText="spp_address -"> This specifies which address is of interest.

When implementing, I considered the implication of various special
values for these fields. I have implemented the following:

If spp_assoc_id is zero, the parameters are set in the socket, and are
used for all future associations. A get will get the socket level
values.

If spp_address is set to INADDR_ANY or the IPV6 equivalent, the
parameters are set in the association for all current and future
transports. A get will get the association level parameters. I see from
below that you are specifying that an empty address would also have this
effect, which is good (my current code would not accept an empty value).

When setting parameters for a one-to-one style socket, any non-zero
spp_assoc_id value is accepted to indicate the parameters should be
changed at the association or transport level.

>                      have this fixed path mtu set upon them.

This value should not be able to be set lower than 512
(SCTP_DEFAULT_MINSEGMENT for Linux).

>                      spp_flag is set to SPP_SACKDELAY_ENABLE the value

This value should not be allowed to be > 500.

>                      of this field is ignored.

This doesn't quite make sense tying path max retransmits to whether Path
MTU discovery is enabled or not.

>                      be specified. Enabling both fields will have

I'd like to propose that setting both an ENABLE and DISABLE flag is
invalid and the call will return EINVAL. This is what I implemented.

For the get, these flags would be set to indicate the current
enable/disable status of each feature.

Frank Filz

---

From: Randall Stewart <[email-masked]>
Date: Mon, 12 Dec 2005 15:04:12 -0500

Frank/Anatoly:

Ok, let see here... comments in line..

Anatoly Khusid wrote:
> Yes, I suppose this would be a good approximation to what I want to do.
> But I am not sure if this approximation will be acceptable to some SIGTRAN
> protocols that run on top of SCTP and have aggressive requirements for
> quickly detecting the unavailability of the remote peer.
> 
> Perhaps its possible to add another spp_flags, something like
> SPP_HB_SET_DEFAULT
> This way you will not need to fill in the value to back enable the default
> HB_interval?

Frank: this might be a way forward.. how do you feel about this?

We can always go back to the 0 means leave it alone... but it
is nice to be able to set a 0 in :-0

I would think we would want to have a SPP_USE_DEFAULT as a general
flag that would cover all the field values.. otherwise you will
get an additional flag for each field :-0

> 
> Thanks,
> 
> Anatoly
> 
> -----Original Message-----
> From: Frank Filz [mailto:[email-masked]]
> Sent: Thursday, December 08, 2005 8:42 PM
> To: Randall Stewart
> Cc: Anatoly Khusid; [email-masked]; lksctp-developers
> Subject: Re: Advantage & disadvantage of static tcp/sctp link and
> dynamic tcp/sctp link
> 
> 
>>>"If a  value of zero is present in this field then no changes are to be
> 
> made
> 
>>>to this parameter"
>>>from [page 55].
>>>Then I could set spp_hbinterval = 0, and make my HEARTBEATs sent every
> 
> (RTO
> 
>>>+ jitter)  ?
>>>
>>>Thanks,
>>
>>Yep, The section now is:
> 
> 
>>  <t hangText="spp_address -"> This specifies which address is of
> 
> interest.
> 
>>  <t hangText="spp_pathmtu -"> When Path MTU discovery is disabled the
> 
> value
> 
>>                     value of the spp_flags field must be
> 
> SPP_PMTUD_DISABLE
> 

I have generally not put any limits on these.. the actual
protocol specs do that (this comment applies for the 200/500ms
limits as well)...

>>                     of this field is ignored.

Opps.. thats a mistake... I should NOT have touched the meaning of
the '0' means leave it the same... I will revert it back :-D
>>  <t hangText="spp_flags-"> These flags are used to control various
> 
> features
> 

ACK... I can add that too .. it makes sense...
> enable/disable status of each feature.

Sounds reasonable :-D

R

---

From: Frank Filz <[email-masked]>
Date: Mon, 12 Dec 2005 16:06:05 -0800

> get an additional flag for each field :-0

Since this field is somewhat exceptional in 0 being a meaningful value,
what if the added flag was SPP_HB_ZERO?

I was talking with Sridhar, and he pointed out that spp_pathmaxrxt would
also be nice to be able to be set to zero. We could do this either with
SPP_PATHMAXRXT_ZERO or SPP_PATHMAXRXT_DISABLE (and then add a
corresponding enable flag).

Frank