Re: [tcpm] [GROW] How to reuse the tcp model in the BMP model - asking for suggestions

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

Hi Jeff,

Sorry for the delayed response.

Note that this e-mail only focuses on MSS and related parameters. I know that further functionality has been discussed during the TCPM meeting - but it is not clear to me how  much some of these ideas are backed by running code.

> -----Original Message-----
> From: Jeffrey Haas <[e-mail]>
> Sent: Tuesday, August 9, 2022 4:54 PM
> To: Scharf, Michael <[e-mail]>
> Cc: Camilo Cardona <[e-mail]>; draft-ietf-tcpm-yang-
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [GROW] How to reuse the tcp model in the BMP model - asking
> for suggestions
> 
> Michael,
> 
> On Tue, Aug 09, 2022 at 10:31:47AM +0000, Scharf, Michael wrote:
> > As different interfaces can have a different MTU, it is not uncommen to
> > use different MSS values for connections originating/terminating on
> > different interfaces. At least the Linux kernel apparently picks the MSS
> > per interface. As a result, it hardly makes sense to model in YANG a
> > single MSS value for all interfaces. Instead, the MSS value would have to
> > be per interface and set in a corresponding YANG model for the interface.
> 
> Knowing the MSS that the host would pick for sessions over a given interface
> might be "nice", but I would tend to agree that it might not make great
> sense in the model.
> 
> > Theoretically, we could do this for MSS, e.g., by augmentation. But for
> > other parameters, such as hardware offload configuration, this would get
> > complex and technology-specific. As a result, the proposed YANG model
> > stays away from interface-specific parameters.
> 
> The underlying issue that Camilo is trying to raise isn't so much
> interface-specific as it is session specific.  Consider the following
> examples:
> 
> https://www.juniper.net/documentation/us/en/software/junos/bgp/topics
> /ref/statement/tcp-mss-edit-protocols-bgp.html
> https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/bgp/73x/b-bgp-cg-
> 8k-73x/implementing-bgp.html#task_sq1_xdk_4jb

Thanks for the pointers. Actually, I have looked at several router operating systems (including also Nokia SROS) when preparing the first individual versions of this draft.

For what it is worth, an old summary shown during IETF 105 (see https://datatracker.ietf.org/meeting/105/materials/slides-105-tcpm-yang-groupings-for-transmission-control-protocol-tcp-configuration-01) includes both router and host operating systems as examples.

In addition, I have now also checked the OpenConfig YANG models, and they also have ways to set the MSS, for instance:

    leaf tcp-mss {
      type uint16;
      description
        "Sets the max segment size for BGP TCP sessions.";
    }

    leaf mtu-discovery {
      type boolean;
      default false;
      description
        "Turns path mtu discovery for BGP TCP sessions on (true)
        or off (false)";
    }

The details, i.e., whether to configure a maximum value for the MSS as system default, per network interface, or per (BGP) neighbor may be specific to the system, but in general most router and host operating systems have ways to influence the MSS.

So, this clearly shows that the MSS might be relevant. But the reality is a bit more complex:

1/ The MSS value is per direction of a TCP connection, and the effective send MSS (called Eff.snd.MSS in RFC 9293) can be different from the receive MSS (called RMSS in RFC 9293)

2/ It is relatively common to also enable/disable PMTU discovery as alternative to an explicit MSS configuration (not only in OpenConfig, see again e.g. my old survey in https://datatracker.ietf.org/meeting/105/materials/slides-105-tcpm-yang-groupings-for-transmission-control-protocol-tcp-configuration-01)

3/ If a TCP stack allows setting a maximum, the effective MSS may be smaller than this configured parameter (config vs. operational state)

None of this is a fundamental problem for a YANG model, and we could figure out how to model this specific detail. Both MSS and PMTU discovery was in the list of features that were originally discussed in TCPM as potentially in scope of this document. But there was no strong interest in this inside TCPM without a clear use case.

If the feedback from BGP implementers is that MSS and MTU discovery is a MUST-HAVE, that situation could change.

Of course, anybody on the TCPM list is welcome to speak up here!

> The inconsistency Camilo mentioned aside, there are two aspects to sessions
> that are relevant to the management information:
> 
> - For the session, can you see the effective parameter?  (In this case, no.)
> - How do you configure the parameter in question?
> 
> For the first point, it might make sense to expose the effective MSS in the
> tcp/connections container.  Doing so in a typedef defined in this module may
> be helpful for the second point.

As already pointed out, we would have to understand whether it should be the MSS, or also PMTU discovery, or even more.

> For the second point, TCP sessions are created outside of the YANG module.
> Just like parameters like the endpoints and ports need to be configured
> (some explicitly, some implicitly) by other modules, MSS and other session
> parameters may be needed.  The typedef noted above provides a common
> way to
> model that configuration state and is supported by the operational state
> above.
> 
> Is a typedef required?  No... but it makes many things easier since it
> avoids everyone reinventing items like constraints, etc.

Personally, I agree that some typedef(s) or even leafs related to MSS and MTU discovery for would be doable in draft-ietf-tcpm-yang-tcp, if there was consensus in TCPM to add this. In this case, the scope is quite clear and there seems to be running code in implementations.

As the upcoming revision of the draft will have other changes, the authors could make a proposal in this space, too. But I'd really be more comfortable with this if there was some further list support from the community before going down that road.

Thanks for this good discussion!

Michael
 
> -- Jeff