Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

["Scharf, Michael" <[e-mail]>]

Hi Praveen,

Thanks a lot for feedback!

The hint on counter overflow is excellent feedback. We should probably change at least the two counters to 64 bit in the next version of the I-D. (And, while it seems obvious, I wasn't aware of that. Aren't these sort of details a good reason to discuss the modeling in TCPM?)

Regarding the implications on existing TCP implementations:

I think the answer depends a lot on how the TCP implementation is managed as of today. If a device is already managed by NETCONF, e.g., because it is a modern router or another network device (optical switch, access node, etc.), a YANG model for TCP offers a standard way to configure the TCP stack on that device. This could possibly replace, or complement, vendor-specific YANG models. That device could either implement the YANG model itself (e.g., stats when deprecating the TCP MIB), or only import subsets of the model, e.g., certain definitions (say, the TCP-AO parameters if the device needs TCP-AO). The question whether to implement an IETF YANG model will be owned by the implementer and governed by the product roadmap, which is typically driven by commercial customer demand.

For TCP stacks that are currently not managed by NETCONF, which most likely includes all main desktop and server PC operating systems, the YANG model probably has no immediate implications. For instance, I would be somewhat surprised if desktop and server operating systems would migrate from their existing management interfaces to NETCONF/YANG. Without the NETCONF (or RESTCONF) protocol, it is difficult to actually implement a YANG model completely. A more realistic future is that operating systems could perhaps follow the YANG model object naming and definitions within their own interfaces, e.g., to complement or replace entries taken from the old TCP MIB. For instance, this could include the Linux /proc/ system or a new version of the Windows stats you have shown, at some point in future. As always, it would be up to the implementers to make their call whether to do so, and when. Also, as existing management interfaces may not have equivalent to all YANG functionality, implementers may have to make some adoptions regarding syntax and semantics in any case. This is no different to what has happened to the TCP MIB in the past. For instance, an operating system could use for 64 bit counter variants definitions from a new YANG model, instead of the TCP MIB.

And there may be more use cases beyond these two cases. This also depends on the scope of the YANG model, which is open for discussion - stats are probably easier than configuration.

In any case, it is always up to implementers to decide whether to use YANG models, and, if so, to which extend. The management plane is much more heterogeneous than the data/control plane in IP networks. The IETF has published many YANG models already, and many MIBs in the past. I think some MIBs some are more widely implemented than others, and the same will most likely happen to IETF YANG models, too.

Best regards

Michael


From: Praveen Balasubramanian <[e-mail]>
Sent: Friday, March 27, 2020 5:42 PM
To: Scharf, Michael <[e-mail]>; Joseph Touch <[e-mail]>
Cc: Michael Tuexen <[e-mail]>; [e-mail]; tcpm IETF list <[e-mail]>
Subject: RE: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

FWIW these are the publicly documented global stats in Windows TCP:
  union {
    DWORD             dwRtoAlgorithm;
    TCP_RTO_ALGORITHM RtoAlgorithm;
  };
  DWORD dwRtoMin;
  DWORD dwRtoMax;
  DWORD dwMaxConn;
  DWORD dwActiveOpens;
  DWORD dwPassiveOpens;
  DWORD dwAttemptFails;
  DWORD dwEstabResets;
  DWORD dwCurrEstab;
  DWORD dwInSegs;
  DWORD dwOutSegs;
  DWORD dwRetransSegs;
  DWORD dwInErrs;
  DWORD dwOutRsts;
  DWORD dwNumConns;

There are per connection stats too. Everything is based on MIB AFAIK. We have had some new additions over time for the per connection stats. 32 bits is now insufficient for InSegs and OutSegs and can and does overflow.

What are the implications of a YANG model to existing TCP implementations?

From: tcpm <[e-mail]<mailto:[e-mail]>> On Behalf Of Scharf, Michael
Sent: Friday, March 27, 2020 8:52 AM
To: Joseph Touch <[e-mail]<mailto:[e-mail]>>
Cc: Michael Tuexen <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; tcpm IETF list <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

Hi Joe,

Regarding stats, this is a YANG "feature" in draft -04. That explicitly specifies that a NETCONF server compliant to the YANG model does not have to provide the stats. We added this because of your past comment on that.

For the stats, -04 relatively closely follows the TCP-MIB (and the WG explicitly ask not to try a 1:1 mapping).

Given the pushback, here is a copy the current spec from -04:

    container statistics {
        if-feature statistics;
        config false;

        leaf active-opens {
          type yang:counter32;
          description
            "The number of times that TCP connections have made a direct
             transition to the SYN-SENT state from the CLOSED state..";
        }

        leaf passive-opens {
          type yang:counter32;
          description
            "The number of times TCP connections have made a direct
             transition to the SYN-RCVD state from the LISTEN state..";
        }

        leaf attempt-fails {
          type yang:counter32;
          description
            "The number of times that TCP connections have made a direct
             transition to the CLOSED state from either the SYN-SENT
             state or the SYN-RCVD state, plus the number of times that
             TCP connections have made a direct transition to the
             LISTEN state from the SYN-RCVD state.";
        }

        leaf establish-resets {
          type yang:counter32;
          description
            "The number of times that TCP connections have made a direct
             transition to the CLOSED state from either the ESTABLISHED
             state or the CLOSE-WAIT state.";
        }

        leaf currently-established {
          type yang:gauge32;
          description
            "The number of TCP connections for which the current state
             is either ESTABLISHED or CLOSE-WAIT.";
        }

        leaf in-segments {
          type yang:counter32;
          description
            "The total number of segments received, including those
             received in error.  This count includes segments received
             on currently established connections.";
        }

        leaf out-segments {
          type yang:counter32;
          description
            "The total number of segments sent, including those on
             current connections but excluding those containing only
             retransmitted octets.";
        }

        leaf retransmitted-segments {
          type yang:counter32;
          description
            "The total number of segments retransmitted; that is, the
             number of TCP segments transmitted containing one or more
             previously transmitted octets.";
        }

        leaf in-errors {
          type yang:counter32;
          description
            "The total number of segments received in error (e.g., bad
             TCP checksums).";
        }

        leaf out-resets {
          type yang:counter32;
          description
            "The number of TCP segments sent containing the RST flag.";
        }
...

I fully agree that we can discuss every single entry.. But, at least for the stats, I don't think this is really a lot of work.. It is a fairly short list quite similar to the deployed TCP-MIB. The assumption here is that the TCP-MIB is a reasonable baseline. Is it really hard to agree on a list of counters in TCPM and publish this?

In addition, there is one difference between a YANG model (and in fact also a MIB) and a TCP API: The TCP API is tightly coupled with the TCP protocol implementation typically in the kernel. Network management apps using YANG can run outside the kernel. There are certain dependencies to configure and to retrieve operational state. Nonetheless, the implementer of a YANG model may not be the implementer of a TCP stack. That may limit the burden to the latter.

Stats, TCP-AO and MD5 (with appropriate flagging) actually look like pretty low-hanging fruits to me. Of course, we need to discuss the modeling details,  but it is a fairly narrow and well-defined scope. Is this part really the most challenging part of the document that prevents us from adopting a YANG model in TCPM?

Michael


Von: Joseph Touch<mailto:[e-mail]>
Gesendet: Freitag, 27. März 2020 16:03
An: Scharf, Michael<mailto:[e-mail]>
Cc: Lars Eggert<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; tcpm IETF list<mailto:[e-mail]>; Michael Tuexen<mailto:[e-mail]>
Betreff: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

Hi, all,

I agree with Lars that, in effect, encoding certain stats in the YANG model runs the risk of making them "expected" in an implementation; if that's desired, the process should be inverted (decide what we think is necessary THEN add it; don't let the model drive the requirements).

That would be a LOT of work, equivalent to extending the API for TCP. If that happens, we need to be VERY careful to not burden implementers with implementation details or requirements.

As to MD5, agreed that it's important to include, but I would even go so far as to put it under a subtree of "Deprecated" components to make it very clear to everyone who uses them.

Joe


On Mar 27, 2020, at 7:49 AM, Scharf, Michael <[e-mail]<mailto:[e-mail]>> wrote:

I am not an expert for SNMP under Linux. But, at first sight, /proc/net/snmp provides basically all scalars from the TCP-MIB. The connection table seems missing. But those objects I would only expect when actually managing a Linux system by the SNMP protocol, not in the proc file system.

Search engines find quite a number of implementer questions on "/proc/net/snmp". So, it seems relatively likely that there is some use. And in the area of SNMP network management, there is often not much public documentation, so a professor may not be able to figure out any details of deployed systems.

Regarding MD5, I get told that there is still running code and operational deployment, even if TCP-AO is getting traction. As users seem to ask for it, my proposal would be to add big warning signs that it is deprecated, i.e., TCP-AO should be used instead. On that aspect, the other authors could maybe also chime in.

Michael


Von: Lars Eggert<mailto:[e-mail]>
Gesendet: Freitag, 27. März 2020 15:15
An: Scharf, Michael<mailto:[e-mail]>
Cc: Michael Tuexen<mailto:[e-mail]>; tcpm IETF list<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Betreff: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

Hi,

On 2020-3-27, at 15:52, Scharf, Michael <[e-mail]<mailto:[e-mail]>> wrote:
> But, wait a second: I recommend to have a look at the output of "cat /proc/net/snmp" under Linux (just tested on Debian Buster)...
>
> As far as I can see, these are the object definitions from the TCP-MIB.. If implemented on Linux, why does the TCP-MIB not matter?

/proc/net/snmp provides the scalars (a small subset of 4022), and obviously just in text form. Are you aware of any uses?

> However, we have learnt from that: We have explicitly decided not to include extended statistics in draft-scharf-tcpm-yang-tcp. The draft currently only includes basic stats.

Well, basic stats and AO detail. (And why still MD5? We obsoleted 2385 ten years ago.)

> It is well understood that there *are* challenges with coming up for a YANG model for TCP. But if RFC 4898 got it wrong, we could learn from that, IMHO.

You are much more optimistic than I am.

Lars


_______________________________________________
tcpm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tcpm<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb%40microsoft.com%7C8a4379e5f5b54b8c545a08d7d266daa4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637209211510907036&sdata=EnEtDfTSnPEsgQQJmHSdBczfNRWzsLSgRvLlHQjIFxU%3D&reserved=0>