Subject: Some comments (SCTP MIB v.03)

From: "Antonio Alonso Alarcon ECE/TL/NA TU-148 Tlf.3085" <[email-masked]>
Date: Fri, 9 Mar 2001 12:15:09 +0100 (MET)

Hi !

   I had some problems sending this mail, so maybe you
receive it before (sorry !!).

-----------------------------------------------------

Hi !

   I have some comments about new draft
"draft-ietf-sigtran-sctp-mib-03.txt". Some of them have
been raised in other mails (about revision 01 and 02):

(1) sctpRtoInitial / sctpInitialT1 / sctpInitialT2
===================================================

   Only parameter "sctpRtoInitial" is neccessary as:
   
   - "sctpInitialT1" is not used (when INIT is sent in order
   to request a new association, the "T1-init "timer 
   is started using the "sctpRtoInitial" parameter)
   
   - "sctpInitialT2" is not used (when SHUTDOWN/SHUTDOWN_ACK/
   SHUTDOWN_COMPLETE is sent in order to close an established
   association, the current value of the RTO parameter of the
   remote address in which the chunk is being sent is the one
   used to start the "T2-shutdown" timer).
   
(2) sctpMaxShutdownRetr (new object)
====================================

   The draft defines the "sctpMaxInitRetr" object used to know
   how many INIT/COOKIE_ECHO sending attempts mut be performed
   from the SCTP side requesting a new association. For
   shutdown purposes, the protocol layer needs another parameter
   specifying the number of attempts for SHUTDOWN/SHUTDOWN_ACK/
   SHUTOWN_COMPLETE sending.
   
(3) sctpAssocChecksumErrorCounter
======================================

   This object can NOT be into the assoc. table. We need the
   local and remote SCTP ports (carried in an SCTP packet) to
   select the TCB structure (i.e the association) to which
   the received packet belongs to. If the Adler-32 checksum
   check fails, we can not be sure about if the assoc. found
   is the one to which the packet was sent to (maybe the values
   received in the local/remote SCTP port fields are corrupted).
   We can NOT define management objects which can be storing
   wrong (not fully reliable) info. This variable can only be
   defined at protocol layer level.
   
   IMPLEMENTATION NOTE: Another big problem of defining it at
   association level is due to the fact that, when a "wrong
   checksum" packet is received, if the implementation wants
   to be MIB compliant, it must waste time looking for the assoc.
   related to this packet (and this is the more-expensive search
   in an SCTP implementation) when the RFC specify to (simply)
   discard this packet.

(4) sctpAssocRemAddressHeartBeatTimer
========================================

   This value has been defined at "remote address" level, but
   it should be defined at association level
   (sctpAssocHeartBeatTimer).
   
   RFC 2960 specifies a single HB.timer per assoc. Every time
   this timer expires, an idle "remote address" is selected (with
   HB enabled) and a HB chunk is sent to it. The assoc HB.timer is
   started to value: "HB.interval + RTO (of the selected remote
   address) [+ optimal jitter]"
   
   This "HB.interval" value (at assoc level) is the
   "sctpAssocHeartBeatTimer"
   
   NOTE: Check that in page 108 (RFC 2960), when describing the
   "Change Parameter" primitive, it is said about the "interval"
   parameter the following:
   
      o  interval - if present, indicates the frequency of the
         heartbeat if this is to enable heartbeat on a destination
         transport address. This value is added to the RTO of the
         destination transport address. This value, if present,
         effects all destinations.

   Please, tell me what you think about these issues.
   
Reagards / Antonio