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

[Gyan Mishra <[e-mail]>]

Hi Joe

Our main concern is how best to monitor the occurrence of TCP Zero window
on the BGP client so that we can take action and reset the peer.

So any and all TCP parameters that can help provide us better insight into
connection state is what we are after.

Also if there is anything proactive as far as tx and rx buffer and if the
buffer is depleting or system resource issues writing to the buffer that is
causing the window to collapse to be able to possibly proactively monitor
leading up to the zero window.

Thanks

Gyan

On Mon, Aug 8, 2022 at 11:16 AM [e-mail] <[e-mail]>
wrote:

> 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] <[e-mail]>
> wrote:
>
>> Replies below...
>> —
>> Dr. Joe Touch, temporal epistemologist
>> www.strayalpha.com
>>
>> On Jul 29, 2022, at 8:14 AM, Gyan Mishra <[e-mail]> wrote:
>>
>> Hi Joe
>>
>> Responses in-line
>>
>> On Tue, Jul 26, 2022 at 10:13 PM [e-mail] <
>> [e-mail]> wrote:
>>
>>> Notes below.
>>>
>>> > On Jul 26, 2022, at 6:19 PM, Michael Tuexen <
>>> [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
>
>
> 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
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*