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

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

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] <mailto:[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] <mailto:[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] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>> wrote:
> See below inline:
> 
>> On Aug 7, 2022, at 4:31 PM, Gyan Mishra <[e-mail] <mailto:[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
> 
> -- 
>  <http://www.verizon.com/>
> Gyan Mishra
> Network Solutions Architect 
> Email [e-mail] <mailto:[e-mail]>
> M 301 502-1347
> 
> 
> -- 
>  <http://www.verizon.com/>
> Gyan Mishra
> Network Solutions Architect 
> Email [e-mail] <mailto:[e-mail]>
> M 301 502-1347
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm