Subject: [Tsvwg] TCP ESTATS: tcpEStatsConnectIdTable

From: Matt Mathis <[email-masked]>
Date: Fri, 24 Feb 2006 11:36:39 -0500 (EST)

Both of you commented on various aspects of tcpEStatsConnectIdTable (attached
below).    With the exception of a couple of unrelated details this table is
copied verbatim from RFC 4022, and your comments apply to that document as
well.

There is not a real problem making the editorial correction about the SNMP
version names, so I will do so.

About two type fields and non-address types:  with todays implementations, there
are no values that make sense other than IPv4-IPv4 or IPv6-IPv6.  However this
restriction in enforced by the TCP implementations themselves.  With the advent
of HIP like technologies other combinations might make sense: dns-IPv4 or
HipID-IPv6, etc.  Given the opportunity for future evolution, I would rather
not build in restrictions in the MIB that are not needed by the underlying
protocols.   If and when InetAddressType is revisited to support HIP etc, it
will force all management stations to be revised anyhow.  I would prefer not to
have unnecessary restrictive language here, where it is not absoluteley needed.

Does this make sense?  Is it ok with you?

Thanks,
--MM--
The latest update to draft-ietf-tsvwg-tcp-mib-extension-08.txt
can be obtained from http://www.web100.org/mib
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------

Dan:
> 14. The DESCRIPTION clause of tcpEStatsConnectLocalAddress and tcpEStatsConnectRemAddress still mentions SNMPv1, SNMPv2c and SNMPv3. The first two are Historical, SNMPv3 is the recurrent standard track version of SNMP, the text should be replaced by simply 'SNMP'.

Bert:
> When I see:
>    TcpEStatsConnectIdEntry ::= SEQUENCE {
>                  tcpEStatsConnectLocalAddressType  InetAddressType,
>                  tcpEStatsConnectLocalAddress      InetAddress,
>                  tcpEStatsConnectLocalPort         InetPortNumber,
>                  tcpEStatsConnectRemAddressType    InetAddressType,
>                  tcpEStatsConnectRemAddress        InetAddress,
>                  tcpEStatsConnectRemPort           InetPortNumber,
>                  tcpEStatsConnectIndex             Unsigned32
>                  }
> I always wonder if Local and Remote Address types can be different!??
> And if not, then I personally would use just one InetAddressType object.
>
> About the InetAddressType/InetAddress objects. I see no indication (at least not in the MIB
> module itself, which is where I looked) about any restrictions. So theoretocally one could
> use 'dns' as the InetAddressType. In that case, you MUST specify when such a DNS name
> gets resolbed (as RFC4001 explains).
>
> W.r.t. to Dan's comment 14.
> I know that we have such statements in other MIB modules (when all the SNMPv1,v2c,v3
> text just refers to the fact of those SNMP versions are not allowing more than 128 subids.).
> So personally I think I can live with it. I am checking with the set of MIB doctors.

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

---

From: Kristine Adamson <[email-masked]>
Date: Fri, 24 Feb 2006 10:23:31 -0700

Matt,
   I think that even though the connections have to be IPv6-IPv6, can't 
one endpoint be an IPv6 link-local address and the other not be a 
link-local address?  In this case, I believe this means that one endpoint 
would have an InetAddressType of ipv6z(4) and the other would have an 
InetAddressType of ipv6(2).  So wouldn't you need separate InetAddressType 
MIB objects. 

Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Phone: (919) 254-7911   T/L 444-7911
Internet e-mail:[email-masked]

Matt Mathis <[email-masked]> wrote on 02/24/2006 11:36:39 AM:

> > 14. The DESCRIPTION clause of tcpEStatsConnectLocalAddress and 
> tcpEStatsConnectRemAddress still mentions SNMPv1, SNMPv2c and SNMPv3. 
The 
> first two are Historical, SNMPv3 is the recurrent standard track version 
of 
> SNMP, the text should be replaced by simply 'SNMP'.
> 
> Bert:
> > When I see:
> > About the InetAddressType/InetAddress objects. I see no indication (at 
least
> not in the MIB
> > text just refers to the fact of those SNMP versions are not allowing 
more 
> than 128 subids.).

---

From: Matt Mathis <[email-masked]>
Date: Fri, 24 Feb 2006 18:06:58 -0500 (EST)

Let me explain why I made them counters, and then perhaps we can discuss what
if anything needs to be changed.

Except for SND.NXT during Tahoe style recovery, the TCP state variables
described in RFC 793 (SND.UNA, SND.NXT, SND.UP, RCV.NXT, and possibly SND.WND
and RCV.WND) are all counters32: they start at some random value and increment
monotonically, wrapping every 2^32 bytes.  Like SNMP counters all arithmetic
inside the protocol is done with deltas and is modulo 2^32.  This is specified
in RFC793, and has been implemented before even SGMP.

>From a management station's point of view, they are counters.  The have to be
delta'd just like other counters.  The only oddity is that sometimes it makes
sense to compare two of them, e.g. SND.NXT-SND.UNA, which has to be done modulo
2^32.

>From the agent's point of view, they just expose existing TCP state variables -
no math or conversion needed.   Not a counter per say, but more like integer32.

It seemd to me to be more important that the SYNTAX is appropirate for the
management stations (which there are many more of) than the agent.  For this
reason I made them counters, even though this is not strictly correct from the
perspecitive of the agent's snmp implementation.

Does this make sense?  I don't think there is any ambiguity.

Thanks,
--MM--

>From Bert:

> I find it strange that these object have a Counter32 SYNTAX:
>
>    tcpEStatsAppSndMax  OBJECT-TYPE
>        SYNTAX          Counter32
>        MAX-ACCESS      read-only
>        STATUS          current
>        DESCRIPTION
>           "The farthest forward (right most or largest) SND.NXT value.
>            Note that this will be equal to tcpEStatsAppSndNxt except
>            when tcpEStatsAppSndNxt is pulled back during recovery."
>        ::= { tcpEStatsAppEntry 3 }
>
>    tcpEStatsAppRcvNxt  OBJECT-TYPE
>        SYNTAX          Counter32
>        MAX-ACCESS      read-only
>        STATUS          current
>        DESCRIPTION
>           "The value of RCV.NXT from [RFC793]. The next sequence
>            number expected on an incoming segment, and the left or
>            lower edge of the receive window."
>        ::= { tcpEStatsAppEntry 6 }
>