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

[Gyan Mishra <[e-mail]>]

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.

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?

>
> > • All TCP parameters that would be accessible with a local OS kernel
>> hook.
>> > Doesn't that mean the complete set of state variable the kernel has and
>> isn't that implementation dependent?
>> > • All windowing parameters including window scaling as well as any
>> windowing related optimizations.
>> > You mean the receiver window including the window scaling.
>> > • All TCP options and optimizations set such as Selective ACK.
>> > I guess you mean the set of TCP extensions which have been negotiated.
>> > • All TCP slow start congestion control parameters CWIN etc.
>> > There are a multiple Congestion Controls, even ones not being specified
>> by the IETF.
>> > So this might get very hard to do. Or do you require a specific CC when
>> using TCP for BGP?
>>
>> This is where things get confusing to me; it seems that there is either a
>> model for TCP or a model for TCP implementations. The two should not be
>> confused with each other
>
>
>     Gyan> Yes I think specific CC-Congestion Control when using TCP for
> BGP.  As there are many implementations variations I think we want a model
> for TCP that covers most all implementations
>
>
> BGP is an application (to TCP); there is no one CC alg used in TCP just
> because it supports BGP.
>
> Esp. given BGP runs not only on hardware routers but also on regular
> computers.
>

   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.

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.

https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml

Many Thanks!


> Joe
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*