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

[Gyan Mishra <[e-mail]>]

Agreed.

Thanks

Gyan
On Mon, Aug 8, 2022 at 6:18 PM [e-mail] <[e-mail]>
wrote:

> FWIW, I agree with Robert. If what you are tracking is connection
> progress, then the existing timeout is the best indicator - esp. because
> there can be other reasons TCP doesn’t make progress.
>
> As to “handling this at the TCP layer”, the timeout would do exactly that
> already. At best, it seems you might like to know remotely that such a
> timeout has triggered.
>
> Joe
>
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com
>
> On Aug 8, 2022, at 2:46 PM, Gyan Mishra <[e-mail]> wrote:
>
>
> 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*
>
> _______________________________________________
> 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*