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

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 27 Mar 2020 14:49:58 +0000

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:[email-masked]>
Gesendet: Freitag, 27. März 2020 15:15
An: Scharf, Michael<mailto:[email-masked]>
Cc: Michael Tuexen<mailto:[email-masked]>; tcpm IETF list<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 <[email-masked]> 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

---

From: Joseph Touch <[email-masked]>
Date: Fri, 27 Mar 2020 08:02:51 -0700

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 <[email-masked]> wrote:
> 
> Von: Lars Eggert <mailto:[email-masked]>
> An: Scharf, Michael <mailto:[email-masked]>
> Cc: Michael Tuexen <mailto:[email-masked]>; tcpm IETF list <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On 2020-3-27, at 15:52, Scharf, Michael <[email-masked] <mailto:[email-masked]>> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 27 Mar 2020 15:51:41 +0000

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:[email-masked]>
Gesendet: Freitag, 27. März 2020 16:03
An: Scharf, Michael<mailto:[email-masked]>
Cc: Lars Eggert<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; tcpm IETF list<mailto:[email-masked]>; Michael Tuexen<mailto:[email-masked]>
Betreff: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

Hi, all,

Joe

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

Michael

Hi,

Lars

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Praveen Balasubramanian <[email-masked]>
Date: Fri, 27 Mar 2020 16:42:02 +0000

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 <[email-masked]> On Behalf Of Scharf, Michael
Sent: Friday, March 27, 2020 8:52 AM
To: Joseph Touch <[email-masked]>
Cc: Michael Tuexen <[email-masked]>; [email-masked]; tcpm IETF list <[email-masked]>
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.

    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

        leaf establish-resets {
          type yang:counter32;
          description

        leaf in-segments {
          type yang:counter32;
          description

        leaf out-segments {
          type yang:counter32;
          description

        leaf in-errors {
          type yang:counter32;
          description

        leaf out-resets {
          type yang:counter32;
          description
...

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?

Michael

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).

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

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.

Michael

Hi,

On 2020-3-27, at 15:52, Scharf, Michael <[email-masked]<mailto:[email-masked]>> 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?

Lars

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
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>

---

From: Joseph Touch <[email-masked]>
Date: Fri, 27 Mar 2020 09:49:04 -0700

> On Mar 27, 2020, at 8:51 AM, Scharf, Michael <[email-masked]> wrote:
> 
> Hi Joe,
>  

AOK, but is that clear in the model itself? I.e., is there a way that merely using that subtree of data forces the user to realize that it’s explicitly optional?

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

AOK.

> ...
> 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.

Agreed; this isn’t onerous esp. if optional.

> 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.

In-kernel or out-of-kernel are implementation decisions. Neither is driven by MIB vs YANG or even the TCP API (or TCP) itself, agreed.

My point is that we need to be careful to not make this model an explicit or implicit extension of the API. The optional part above should do that.

> 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…

The TCP roadmap should help us understand what’s critical and not in this model, IMO.

Joe

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 30 Mar 2020 11:52:24 +0000

Hi Joe,

In the YANG model, the statement “if-feature statistics;“ explicitly specifies that an implementation only has to support that if it supports the “feature” statistics of the model, for instance, if it announces that support (e.g., during the NETCONF handshake). It is entirely up to the implementer whether to support a given feature or not. This is just using the tools from the YANG language.

In addition, keep in mind that objects in a YANG model are optional by default. A node in the tree must only be present if the keyword “mandatory true” is specified in YANG. We don’t use this keyword in the model. So, for somebody who reads the YANG model, IMHO it should be more than clear that the model is optional.

We have discussed quite a bit how to address your past comment and this seems the most obvious approach to somebody who is familiar with YANG.

As a side note, we can see here that this is about details of the YANG language. One of the challenges with this doc is that one may need both some TCP and some YANG expertise to understand some of the details. Probably only very few people deal with both topics at the same time. For example, I am not a real YANG expert myself. But, well, I am not the only author of the I-D... The idea of the I-D is to bring together the needed expertise among the authors. (And there would still be room for more co-authors.) Also, for the TCPM working group probably some of the YANG details are less interesting. More relevant is probably how TCP configuration and stats are modelled, e.g., what parameters are used, what values parameters can take, how the parameters are described precisely, etc. And I think we have *a lot* of expertise on that in TCPM.

I am not sure how the TCP roadmap helps us with the YANG model, tough. It is unrealistic to model in YANG everything that the IETF has written on TCP so far. To make a trivial example: We don’t need a YANG model for Quick-Start TCP ;-) This is why the I-D takes the opposite approach: The focus is on configuration attributes and stats that exist on (several) existing TCP implementations. So, basically the proposal is to only model attributes that exist (in somewhat similar from) on several TCP stacks, i.e., it can be configured already, albeit not necessarily by YANG. This set of attributes mostly corresponds to what follows from the standards-track TCP specification, albeit of course the devil is in the details. In any case, to me it doesn’t make a lot of sense to model something in a YANG model that a corresponding NETCONF server implementation cannot implement because no relevant TCP stack supports it.

Thanks

Michael

From: Joseph Touch <[email-masked]>
Sent: Friday, March 27, 2020 5:49 PM
To: Scharf, Michael <[email-masked]>
Cc: Lars Eggert <[email-masked]>; [email-masked]; tcpm IETF list <[email-masked]>; Michael Tuexen <[email-masked]>
Subject: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

On Mar 27, 2020, at 8:51 AM, Scharf, Michael <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joe,

AOK.

...

...

Joe

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 30 Mar 2020 14:21:50 +0000

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 <[email-masked]>
Sent: Friday, March 27, 2020 5:42 PM
To: Scharf, Michael <[email-masked]>; Joseph Touch <[email-masked]>
Cc: Michael Tuexen <[email-masked]>; [email-masked]; tcpm IETF list <[email-masked]>
Subject: RE: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

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

Hi Joe,

    container statistics {
        if-feature statistics;
        config false;

        leaf active-opens {
          type yang:counter32;
          description

        leaf passive-opens {
          type yang:counter32;
          description

        leaf attempt-fails {
          type yang:counter32;
          description

        leaf establish-resets {
          type yang:counter32;
          description

        leaf in-segments {
          type yang:counter32;
          description

        leaf out-segments {
          type yang:counter32;
          description

        leaf in-errors {
          type yang:counter32;
          description

        leaf out-resets {
          type yang:counter32;
          description

Michael

Hi, all,

Joe

Michael

Hi,

Lars

---

From: Joseph Touch <[email-masked]>
Date: Mon, 30 Mar 2020 07:23:34 -0700

Hi Michael,

My intent was to suggest using the roadmap as a way to “check” whether items you want to add should be required, optional, or not needed.

It’s not to drive the model to cover EVERYTHING in the roadmap, though if there’s a key area that’s required and isn’t covered, it signals a gap.

It IS to avoid having implementations be the sole driver of the model. Just because something IS measured or controllable doesn’t mean it should be in the model.

Joe

> On Mar 30, 2020, at 4:52 AM, Scharf, Michael <[email-masked]> wrote:
> 
> Hi Joe,
>  
> From: Joseph Touch <[email-masked] <mailto:[email-masked]>> 
> To: Scharf, Michael <Michael.Scharf@hs-esslinge <mailto:[email-masked]>n.de <mailto:[email-masked]>>
> Cc: Lars Eggert <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; tcpm IETF list <[email-masked] <mailto:[email-masked]>>; Michael Tuexen <[email-masked] <mailto:[email-masked]>>
> On Mar 27, 2020, at 8:51 AM, Scharf, Michael <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Joe,
>