Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model

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

Hi all,

See below...

> -----Original Message-----
> From: tcpm <[e-mail]> On Behalf Of [e-mail]
> Sent: Wednesday, July 27, 2022 4:13 AM
> To: Michael Tuexen <[e-mail]>
> Cc: Gyan Mishra <[e-mail]>; tcpm IETF list
> <[e-mail]>; Robert Raszuk <[e-mail]>; Van De Velde,
> Gunter (Nokia - BE/Antwerp) <[e-mail]>; Jeffrey
> Haas <[e-mail]>; Susan Hares <[e-mail]>
> Subject: Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model
> 
> Notes below.
> 
> > On Jul 26, 2022, at 6:19 PM, Michael Tuexen
> <[e-mail]> wrote:
> >
> >>
> >>
> >> Dear TCPM
> >>
> >> Attached is the slide deck for the NG TCP Yang model discussion.
> >>
> >> Sue, Robert, Jeff, Gunter
> >>
> >> Please review and let me know if I missed any talking points for the NG
> TCP Yang model.
> > A couple of clarifying questions related to slide "What to add to NG TCP
> Yang Model?",
> > especially since I know almost nothing about YANG:
> >
> > • All TCP states part of the FSM state machine.
> > Understood.
> These make sense.

Indeed.

draft-ietf-tcpm-yang-tcp-07 already models the states of a TCP connection, using the definitions from 793bis:

<snip>
leaf state {
             type enumeration {
               enum closed {
                 value 1;
                 description
                   "Connection is closed. Connections in this state
                    may not appear in this list.";
               }
               enum listen {
                 value 2;
                 description
                   "Represents waiting for a connection request from any
                    remote TCP peer and port.";
               }
               enum syn-sent {
                 value 3;
                 description
                   "Represents waiting for a matching connection request
                    after having sent a connection request.";
               }
               enum syn-received {
                 value 4;
                 description
                   "Represents waiting for a confirming connection
                    request acknowledgment after having both received
                    and sent a connection request.";
               }
               enum established {
                 value 5;
                 description
                   "Represents an open connection, data received can be
                    delivered to the user. The normal state for the data
                    transfer phase of the connection.";
               }
               enum fin-wait-1 {
                 value 6;
                 description
                   "Represents waiting for a connection termination
                    request from the remote TCP peer, or an
                    acknowledgment of the connection termination request
                    previously sent.";
               }
               enum fin-wait-2 {
                 value 7;
                 description
                   "Represents waiting for a connection termination
                    request from the remote TCP peer.";
               }
               enum close-wait {
                 value 8;
                 description
                   "Represents waiting for a connection termination
                    request from the local user.";
               }
               enum last-ack {
                 value 9;
                 description
                   "Represents waiting for an acknowledgment of the
                    connection termination request previously sent to
                    the remote TCP peer (this termination request sent
                    to the remote TCP peer already included an
                    acknowledgment of the termination request sent from
                    the remote TCP peer)";
               }
               enum closing {
                 value 10;
                 description
                   "Represents waiting for a connection termination
                    request acknowledgment from the remote TCP peer.";
               }
               enum time-wait {
                 value 11;
                 description
                   "Represents waiting for enough time to pass to be
                    sure the remote TCP peer received the acknowledgment
                    of its connection termination request, and to avoid
                    new connections being impacted by delayed segments
                    from previous connections.";
               }
             }
             description
               "The state of this TCP connection.";
           }
           description
             "List of TCP connections with their parameters. The list
              is modeled as writeable, but implementations may not
              allow creation of new TCP connections by adding entries to
              the list. Furthermore, the behavior upon removal is
              implementation-specific. Implementations may support
              closing or resetting a TCP connection upon an operation
              that removes the entry from the list.";
         }
</snip>

This creates feature parity with the TCP MIB regarding state.

All: Please have a look at this model, which was added to address the IETF LC feedback, and let us know if anything is missing.

> > • All TCP flags and respective states.
> > Do you mean the TCP flags SYN, FIN, PSH, ... Does a YANG module all to
> describe
> > packets sent and received?
> 
> I can’t see how this can model the TCP flags; all it should be modeling is the
> states of the connection. The model is for TCP, not TCP packets.

I am very confused here, too.

> > • All TCP parameters that would be accessible with a local OS kernel hook.
> > Doesn't that mean the complete set of state variable the kernel has and
> isn't that implementation dependent?
> > • All windowing parameters including window scaling as well as any
> windowing related optimizations.
> > You mean the receiver window including the window scaling.
> > • All TCP options and optimizations set such as Selective ACK.
> > I guess you mean the set of TCP extensions which have been negotiated.
> > • All TCP slow start congestion control parameters CWIN etc.
> > There are a multiple Congestion Controls, even ones not being specified by
> the IETF.
> > So this might get very hard to do. Or do you require a specific CC when
> using TCP for BGP?
> 
> This is where things get confusing to me; it seems that there is either a model
> for TCP or a model for TCP implementations. The two should not be confused
> with each other

Yep, and a lot of details are very implementation specific and differ a lot in the long tail of existing TCP implementations.

In the first discussions regarding draft-scharf-tcpm-yang-tcp, I have shown some examples for TCP parameters that are implemented relatively similarly across major TCP stacks and that a more comprehensive TCP YANG model could possibly include. This includes for instance enabling/disabling ECN, Window Scaling, Timestamps, etc. But even in that case different stacks differ *a lot* and I am not aware of a simple way to work around that. Details can be found in the IETF proceedings for previous TCPM meetings.

If there is interest in modeling TCP beyond draft-ietf-tcpm-yang-tcp-07, the discussion needs to ensure that the model roughly corresponds to running code. 

Unfortunately, I probably cannot attend this TCPM session because of my day job, but I obviously follow the mailing list.

Thanks

Michael


> 
> Joe
> 
> >
> > Best regards
> > Michael
> >>
> >> Thanks
> >>
> >> Gyan
> >>
> >> ---------- Forwarded message ---------
> >> From: Mishra, Gyan S <[e-mail]>
> >> Date: Mon, Jul 25, 2022 at 11:36 PM
> >> Subject: IETF 114 TCPM WG - NG TCPM Yang Model
> >> To: Hayabusanew <[e-mail]>
> >>
> >>
> >> --
> >>
> >>
> >> Gyan Mishra
> >> Network Solutions Architect
> >> Email [e-mail]
> >> M 301 502-1347
> >>
> >>
> >> <IETF-114 TCPM TCP Yang
> Model.pdf>_______________________________________________
> >> tcpm mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tcpm
> >
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm