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 Jul 4, 2022, at 12:15 PM, Robert Raszuk <robert@xxxxxxxxxx> 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
