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

"touch@strayalpha.com" <touch@strayalpha.com> Sat, 06 August 2022 15:25 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC87C14F72C for <tcpm@ietfa.amsl.com>; Sat, 6 Aug 2022 08:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.325
X-Spam-Level:
X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dtIIavSm11r for <tcpm@ietfa.amsl.com>; Sat, 6 Aug 2022 08:25:19 -0700 (PDT)
Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4B0C14F746 for <tcpm@ietf.org>; Sat, 6 Aug 2022 08:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BHF+y4yezsBI/8QBjP2mMO1Sm2ym4T6o4m6BZew47bQ=; b=2u2ad8Dj+wxrPdxO8RjK8Wp5pc qRHzuMddgHxHvJr66td+jMWx1hKt/HwT6K+aJb2Co6w3UDomEJdGZXs9Ci+0v1Bi8nVyv3ZfxSdk+ UOPelvyevJJjYJD5gzoyDhzflSajw+MUPmOFLkJqoRggSUMkUfPPlbEFjC6MEecQ1TEtJUYl/4kHb TXcWk9MGRSWY4Iq3JnklwvIxKYSZN2nl9rxZn56x5BEBCnafPiWE0510VFlyTzj07gKcCifc6qTXB exAtDgLlMYSlqunoYJwwLSx3DqUAZJ/fGKWlq18P7yUx3ysS14mDjaseLSRtTe486AScqGzlHFSBG 4kO0idyw==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:54424 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <touch@strayalpha.com>) id 1oKLfr-00Cr9G-Hc; Sat, 06 Aug 2022 11:25:16 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_46DCD20B-1062-40F7-977D-A1AA7B4772BD"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <CABNhwV1OZawGXbH4d9RGx0KWKoiKLdZnNPq1gOcSfMQeie3q4Q@mail.gmail.com>
Date: Sat, 06 Aug 2022 08:25:09 -0700
Cc: Jeffrey Haas <jhaas@pfrc.org>, Michael Tuexen <michael.tuexen@lurchi.franken.de>, Robert Raszuk <robert@raszuk.net>, Susan Hares <shares@ndzh.com>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, tcpm IETF list <tcpm@ietf.org>
Message-Id: <0D8E1E5A-5CD1-4302-8FE9-21EFF9847199@strayalpha.com>
References: <CAJhXr9-zcJg99ML3MSNMTvRFiT_BLzJihQucAdX8MZGDZ84dWw@mail.gmail.com> <CABNhwV1wz2Uhx+DWjabzVz8GAhQD78NFKhq2az=E7dhnxTC-Ww@mail.gmail.com> <A8851A57-748D-4504-97B6-677807EE0DB6@lurchi.franken.de> <EF72E595-0B1E-4AD9-BDFE-603B9B200F0D@strayalpha.com> <CABNhwV1OZawGXbH4d9RGx0KWKoiKLdZnNPq1gOcSfMQeie3q4Q@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/F0KzFQAd49E45b6c5rbo1DZr6hA>
Subject: Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Aug 2022 15:25:23 -0000

Replies below...
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Jul 29, 2022, at 8:14 AM, Gyan Mishra <hayabusagsm@gmail.com> wrote:
> 
> Hi Joe 
> 
> Responses in-line 
> 
> On Tue, Jul 26, 2022 at 10:13 PM touch@strayalpha.com <mailto:touch@strayalpha.com> <touch@strayalpha.com <mailto:touch@strayalpha.com>> wrote:
> Notes below.
> 
> > On Jul 26, 2022, at 6:19 PM, Michael Tuexen <michael.tuexen@lurchi.franken.de <mailto:michael.tuexen@lurchi.franken.de>> 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. 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.

> > • 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.

So if this is all aimed at helping BGP figure out when TCP isn’t making progress, it seems like an impossibly large task (too many CC algs). Are there particular parameters you think would be beneficial for BGP to know about TCP and can they be abstracted away from specific implementations?

Joe