Subject: Re: [Tsvwg] AD review of: draft-ietf-sigtran-sctp-mib-07.txt

From: Maria-Carmen Belinchon <[email-masked]>
Date: Mon, 02 Sep 2002 16:11:14 +0200

Hi,

Thanks for a so detailed review.

Only included comments where remarks exist,

> More or less serious issues:
> - You must decide what to do with the DeleteTCB.
>   We cannot leave it as an open issue when doc goes to IESG
>   And this of cours eimpacts last para of sect 3.1.3.1

It's not an open point. It was already discussed and we agreed that it remains in
the MIB, if it's demostrated that none implements it then it will be removed when
passing to Draft Standard.

> - I am missing a reference to the/a discontinuity timer object
>   for your Counters. Such is needed as per RFC2978, sect 7.1.6
>   and sect 7.1.10

I guess this RFC number is not correct

> - A number of objects like sctpRtoMin, sctpRtoMax etc have
>   as data type Unsigned32. That means it can have a value of zero.
>   I wonder if a zero value makes sense. If it does, then maybe
>   it has special meaning? If so then pls describe. If it
>   does not make sense, then better add a range to exclude it.
>   I also wonder if a value of 1 or 2 millisecodns or such makes
>   sense. If not, maybe say some words about it or add a lower range
>   that sort of specifies the minimum that makes sense.
>   Does Max have to be GE than Min ??

We didn't want to remove zero value in some objects to allow implementations to
have zero for any proprietary use. But maybe we could change some of the objects to
avoid misuses. Let's see this proposal:

- sctpRtoMin  Unsigned32 (500..65535)
The recommended minimum RTO value in the SCTP RFC is 1000 milliseconds, the maximum
is 60000 milliseconds, and the default value is 30000 milliseconds. We could
configure all RTO objects to include these RFC recommended values but not being so
restrictive. That is 500-65535 milliseconds. But then it avoids Brian's
implementation to use zero.
I think we could add a DEFVAL clause for it (set to 1000 milliseconds)

- sctpRtoMax   Unsigned32 (500..65535)
I think we could add a DEFVAL clause for it (set to 60000 milliseconds). Again the
limitation avoids Brian's implementation to use zero.

- sctpRtoInitial  Unsigned32 (500..65535)
I think we could add a DEFVAL clause for it (set to 30000 milliseconds). Again the
limitation avoids Brian's implementation to use zero.

- sctpMaxAssoc Unsigned32
I'd change the TYPE to Unsigned32 to avoid using a wrong number, then the
DESCRIPTION should be changed to "The limit of the total number of SCTP
associations the entity can support. In entities where the maximum number of
associations is dynamic, this object should contain the value 0."

- sctpValCookieLife Unsigned32 (500..65535)
Recommended value is 60000 milliseconds, so we can limit to the same range as for
RTO.
DEFVAL clause?

- sctpMaxInitRetr
Zero value has to be allowed to indicate no retransmissions.

- sctpAssocHeartBeatTimer
Recommended value is 30000 milliseconds, so we can limit to the same range as for
RTO. Then we limit the individual solutions as the Brian's one.

- sctpAssocInStreams
At least one stream should be configured as incoming, but we could keep value zero
in case applications want to use this value to mean that it's in the start up phase
and the negotiation has not finished. I could modify the DESCRIPTION to "Inbound
Streams according to the negotiation at association start up. Value zero is
reserved for start up phase when the real value is being negotiated."

- sctpAssocOutStreams
The same as before: "Outbound Streams according to the negotiation at association
start up. Value zero is reserved for start up phase when the real value is being
negotiated".

- sctpAssocMaxRetr
No modification. Zero value means no retransmissions.

- sctpAssocRemAddressRTO
Change to RTO above modifications: Unsigned32 (500..65535)

- sctpAssocRemAddressMaxPathRtx
No modification. Zero value means no retransmissions.

> - sctpAssocRemHostName is OCTET STRING
>   Mmm... currently I believe DNS names are US ASCII
>   If that gets changed in the future, then I would assume it would
>   possibly some form of UTF-8 ?? Not sure what the best approach
>   is here... but at least I would like to make the WG aware of
>   OCTET STRING meaning that it can be any string of octets. So
>   please make sure to think about this before you decide.

We could use the DNS behaviour and indicate this in the DESCRIPTION clause.

There are no more comments to yours remarks. Still left the Compilation Notes, I'll
go through it today.

br,
MCarmen

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

---

From: Andreas Jungmaier <[email-masked]>
Date: Tue, 3 Sep 2002 17:24:57 +0200

Hi all,

just a small remark to the mentioned idea of limiting some of the
variables to a minimum value (e.g. 500ms). I believe (similar to what
Brian Bidulock recommended) that this is not a good idea for implementations
in used in environments that aim to reach performance competitive
to SS7 networks. The range of values should stay as it is.

Please see 
"On the Use of SCTP in Failover-Scenarios", presented at the SCI2002 in
July 2002, it's at
http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/sctp-failover.pdf
for some details as to why you may need lower values.

Regards,
Andreas

> We didn't want to remove zero value in some objects to allow
> implementations to have zero for any proprietary use. But maybe we could
> change some of the objects to avoid misuses. Let's see this proposal:
>
> The recommended minimum RTO value in the SCTP RFC is 1000 milliseconds, the
> maximum is 60000 milliseconds, and the default value is 30000 milliseconds.
> We could configure all RTO objects to include these RFC recommended values
> but not being so restrictive. That is 500-65535 milliseconds. But then it
> avoids Brian's implementation to use zero.
> I think we could add a DEFVAL clause for it (set to 60000 milliseconds).
> Again the limitation avoids Brian's implementation to use zero.
>
> I think we could add a DEFVAL clause for it (set to 30000 milliseconds).
> Again the limitation avoids Brian's implementation to use zero.
>
> Recommended value is 30000 milliseconds, so we can limit to the same range
> as for RTO. Then we limit the individual solutions as the Brian's one.
>
> - sctpAssocInStreams
> At least one stream should be configured as incoming, but we could keep
> value zero in case applications want to use this value to mean that it's in
> the start up phase and the negotiation has not finished. I could modify the
> DESCRIPTION to "Inbound Streams according to the negotiation at association
> start up. Value zero is reserved for start up phase when the real value is
> being negotiated."
>
> - sctpAssocRemAddressRTO
- -- 
- ---------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier              |  Stop sending E-POSTCARDS ! 
Computer Networking Technology Group      |  Send E-MAILS --  Use PGP !
University of Essen                       | 
http://www.exp-math.uni-essen.de/~ajung   |   http://www.gnupg.org
My PGP Key-ID: D3824AC0                   |   http://wwwkeys.pgp.net
- ---------------------------------------------------------------------------
My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4  9998 2812 5C0B 0B04  D382 4AC0 
- ---------------------------------------------------------------------------

---

From: Maria-Carmen Belinchon <[email-masked]>
Date: Thu, 05 Sep 2002 18:38:35 +0200

Bert,

We're drafting the new SCTP MIB version, but still 2 concerns about the MIB:

- Maximum number of associations
TCP MIB defines:
tcpMaxConn OBJECT-TYPE
    SYNTAX     Integer32 (-1 | 0..2147483647)
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
           "The limit on the total number of TCP connections the entity
            can support.  In entities where the maximum number of
            connections is dynamic, this object should contain the
            value -1."
    ::= { tcp 4 }
When trying to align with TCP, the question is what 0 means here. Actually, we were
thinking of limiting the object to Unsigned32, where 0 means that the maximum
number of associations is dynamic. What is the advantage of the TCP approach?

- RTO values
Again, trying to align with TCP, either RTOmin and RTOmax are defined as Integer32
(0..2147483647). What is the meaning of value zero?

br,
MCarmen