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

[Gyan Mishra <[e-mail]>]

Hi Robert

I have been monitoring and posted to the thread this topic about a NG TCP
Yang model to help detect the TCP Zero window state and then take action
with the send timer proposal.

Alternatively as you mentioned the TCP_USER_TIMEOUT timer to help reset the
Stuck TCP connection proposed by Enke.

It did not seem there was yet consensus on the thread to use the TCP
timeout timer to reset the connection over the send timer draft.

I think handling at the TCP layer makes sense then messing with BGP.

So from the Yang model monitoring aspect here, if we go the route of using
the TCP timeout to reset the connection as opposed to the send timer draft,
in both cases we still have the problem of trying to detect the zero window
condition which is where the Yang model comes into play.

So I think the Yang model would be useful to first detect the occurrence of
the zero window condition as well as you mentioned report the critical TCP
FSM timers and when they expire and cause connection resets.

Kind Regards

Gyan

On Mon, Aug 8, 2022 at 5:19 PM Robert Raszuk <[e-mail]> wrote:

> Hi Gyan,
>
> As you perhaps are watching the IDR discussion there is a proposal not to
> monitor zero windows on the client side.
>
> Instead we do believe that stuck TCP connections should be handled by TCP
> itself preferably with the use of TCP_USER_TIMEOUT timer.
>
> So all I would expect from the YANG model here would be to report critical
> TCP FSM timers when they expire and cause connection resets.
>
> Thx,
> Robert
>
>
>
>
>
>
> On Mon, Aug 8, 2022 at 11:14 PM Gyan Mishra <[e-mail]> wrote:
>
>>
>> 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*
>>
>> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*