Re: [tcpm] [Last-Call] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Mon, 04 July 2022 19:48 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
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 702C8C14F726; Mon, 4 Jul 2022 12:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 (1024-bit key) header.d=hs-esslingen.de
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 lQVstIM9--p9; Mon, 4 Jul 2022 12:48:10 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A075AC14F724; Mon, 4 Jul 2022 12:48:09 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 34B2E25A12; Mon, 4 Jul 2022 21:48:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1656964087; bh=WyUAlK5dexBR5AyOVAWn8lE/dK5ypBjTLP/J3fXwKQs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=AAMiTeXf9KWyMcCYrAG+TOlej8AhnUGkrDeUAk/TZdaYy6T9lZ6Oai0vnK+MwgffQ j6dIBOb822Pf5CDGVy5qb2lE1QT4yxZuxzJl7OhOTgGhw1wyU057ZUMSemiVQL5DJ3 npXE7p/F6qo9w0M7VDrmESTFSvrAEv/+8XsTEknI=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHMyQzSrHWFw; Mon, 4 Jul 2022 21:48:05 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 4 Jul 2022 21:48:05 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Mon, 4 Jul 2022 21:48:05 +0200
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2375.028; Mon, 4 Jul 2022 21:48:05 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Robert Raszuk <robert@raszuk.net>, "touch@strayalpha.com" <touch@strayalpha.com>
CC: Gyan Mishra <hayabusagsm@gmail.com>, Last Call <last-call@ietf.org>, "draft-ietf-tcpm-yang-tcp.all@ietf.org" <draft-ietf-tcpm-yang-tcp.all@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [Last-Call] [tcpm] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07
Thread-Index: AQHYj1suxwnTXlZYAUSeZXWHLbVT561tgVQAgAAIwQCAAJzegIAANqyggAAW5oCAAAQggIAAAqcAgAAh3/A=
Date: Mon, 04 Jul 2022 19:48:05 +0000
Message-ID: <d7e412ff399544648d65b1d71d6caabc@hs-esslingen.de>
References: <165690747653.9313.6940379164951428048@ietfa.amsl.com> <DF6CF2BD-8418-4386-BB78-6E011A523FBA@strayalpha.com> <CABNhwV1SN+Ei_TScwUsg1scKhAAoxixfFTtXXghLXEPspU6gZA@mail.gmail.com> <893612ED-91B7-4492-8000-EF2D54AC49BC@strayalpha.com> <4688b79370e94df6b8af107a97be0a7f@hs-esslingen.de> <CAOj+MMGxUxqFko1R5yVkpc6Ujw6SJcOjB209YNKuGJo+MOZfvA@mail.gmail.com> <B130CC17-B93A-4D3F-90B1-01E29BDD6975@strayalpha.com> <CAOj+MMFeQ6AEQ_=yCurmE0tg2XqogtfmwL7EW5L0XhsN48h2uw@mail.gmail.com>
In-Reply-To: <CAOj+MMFeQ6AEQ_=yCurmE0tg2XqogtfmwL7EW5L0XhsN48h2uw@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.140.249]
Content-Type: multipart/alternative; boundary="_000_d7e412ff399544648d65b1d71d6caabchsesslingende_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/KzplkbCC05WsPVVCBy_yS_IpN3s>
Subject: Re: [tcpm] [Last-Call] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07
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: Mon, 04 Jul 2022 19:48:14 -0000

Robert,

There are other YANG models that actually model properties of a TCP connection as far as they are relevant for on-path middleboxes. See the references in draft-ietf-tcpm-yang-tcp.

What specifically is missing?

Also, note that many OS kernels don’t use YANG at all. One could write a lot in a YANG model, but who would actually implement that?

Michael

From: Robert Raszuk <robert@raszuk.net>
Sent: Monday, July 4, 2022 9:39 PM
To: touch@strayalpha.com
Cc: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Gyan Mishra <hayabusagsm@gmail.com>; Last Call <last-call@ietf.org>; draft-ietf-tcpm-yang-tcp.all@ietf.org; ops-dir@ietf.org; tcpm@ietf.org
Subject: Re: [Last-Call] [tcpm] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07

Hi,

I think the crux is here:

> remotely managed.

For me YANG is about visibility (or nowadays observability) (like was/is SNMP MIB) and not about remote management. I would never set any TCP parameters remotely as it does not make sense. That's role of client app via socket API.

So lot's of TCP parameters makes sense to me to observe state of TCP session irrespective on what is the client above it from remote controller. Especially that telemetry may use YANG format for packing this info.

Then what is missing - everything which I could see by using local OS hooks into kernel. That is all TCP parameters as well as connection state.

Thx.
R.

On Mon, Jul 4, 2022 at 9:30 PM touch@strayalpha.com<mailto:touch@strayalpha.com> <touch@strayalpha.com<mailto:touch@strayalpha.com>> wrote:
> On Jul 4, 2022, at 12:15 PM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
>
> Hi,
>
> > Any application can decide to configure TCP parameters as far as possible in the given operation
> > system, e.g., via the sockets API. That is orthogonal to the internals of the TCP implementation and the TCP protocol.
>
> While clients running on top of TCP can configure its parameters I would at least expect to be able to report such values (local and remote) when using the TCP YANG model. For example I can not find the Urgent Flag in the current YANG model.

That’s because URG is not a property of the TCP connection; it’s a property of a segment, not the connection. The same is true for PSH.

> Same for elementary window size of any given connection, same for connection duration, .

There is no such thing as “elementary window size”. There are a variety of window parameters, i.e., send window, congestion window, receive window. Only the send and receive windows are application / OS set.

If there’s a list of desired parameters, it would be useful to start by stating them in terms of the TCP specs and explaining why they need to be remotely managed.

Joe