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

[Gyan Mishra <[e-mail]>]

Hi Michael

See in-line

Thanks

Gyan

On Wed, Jul 27, 2022 at 10:13 AM Scharf, Michael <
[e-mail]> wrote:

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


    Gyan> Understood.  Maybe if we focused on router vendor TCP
implementations.  Also maybe commonality across compute node 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.


    Gyan> Thank you

This includes for instance enabling/disabling ECN, Window Scaling,
> Timestamps, etc.


    Gyan> Perfect

But even in that case different stacks differ *a lot* and I am not aware of
> a simple way to work around that.


    Gyan> Understood

Details can be found in the IETF proceedings for previous TCPM meetings.


   Gyan> Ok

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


    Gyan> Understood

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

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*