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

["[e-mail]" <[e-mail]>]

See below inline:

> On Aug 7, 2022, at 4:31 PM, Gyan Mishra <[e-mail]> wrote:
> 
> 
> Replies below 
> 
> On Sat, Aug 6, 2022 at 11:25 AM [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>> wrote:
> Replies below...
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com <http://www.strayalpha.com/>
> 
>> On Jul 29, 2022, at 8:14 AM, Gyan Mishra <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi Joe 
>> 
>> Responses in-line 
>> 
>> On Tue, Jul 26, 2022 at 10:13 PM [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>> wrote:
>> Notes below.
>> 
>> > On Jul 26, 2022, at 6:19 PM, Michael Tuexen <[e-mail] <mailto:[e-mail]>> wrote:
>> > 
> ...
>> > • 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.
>> 
>>     Gyan> Agreed that we want to model the TCP states not the packets.
> 
> Then you need to consider only the parameters passed via socket options that control those flags, not the flags themselves.
> 
>     Gyan> Understood.  Yes so what we ar looking for is the state of the socket connection and and control flags for each state of the socket connection.

Socket options are OS state, not TCP state.

> I don’t know if there is a common framework for them, though, esp. given the IETF (incorrectly) abandoned the idea of the abstract user interface as part of a protocol definition, at least for decades.
> 
>     Gyan> I don’t know either.  Would the common framework be based on the  TCP FSM and socket connection states and related flags?

The TCP FSM is already part of the current TCP YANG model.

Flags, again, are not endpoint states - they are packet contents.

Socket connection states are tightly coupled to TCP FSM (though not identical), but these are OS-specific.

>> ...
> 
> 
>    Gyan> Understood and agreed there is no CC specific to BGP
> 
> So if this is all aimed at helping BGP figure out when TCP isn’t making progress,
> 
> Gyan> Yes that is the goal 
> 
> it seems like an impossibly large task (too many CC algs).
> 
> Gyan> If we can hone in on the popular CC Alg used today by routers and computers would be a start.

I think you may be missing the point. Rather than trying to figure out the common CC algs and parameterize them, why not explain what you really want to know about the connection?

Again, IMO, if this is really about trying to instrument an endpoint so that all possible attacks can be detected, it’s a non-starter to me.

> Are there particular parameters you think would be beneficial for BGP to know about TCP and can they be abstracted away from specific implementations?
> 
> Gyan> The main parameters are the TCP socket connection state and related header flags, TCP Congestion control algorithms common ones used by routers and computers, and looking at the TCP parameters list, timestamps, CC, Quick start, User timeout, ECN.

Again you mention header flags. Those are set by TCP based on connection state and user commands, but they are NOT properties of the connection itself. The rest of the list is just the set of everything om the endpoint that MIGHT be useful.

> https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml <https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml>
Those are code points used in TCP messages, not parameters to the TCP protocol.

—

I continue to see a disconnect here. There is a difference between TCP endpoints, TCP messages, and OS (i.e., socket) endpoints. TCP YANG models should reflect TCP endpoints; Netconf/YANG is not a packet inspection or packet debugging tool. And some of what you want to know refers to a socket, not TCP at all.

Joe