Re: [Taps] TCP components

[Karen Elisabeth Egede Nielsen <[e-mail]>]

Hi Michael, All

>
>I have been pointing at RFC6458 but was recently told (and I should have
>just
>read the thing instead of being told, sorry  :-(    ) that this RFC does
>not specify
>how SCTP's functions are supposed to be exposed to applications using them,
>but describes one example implementation (in great detail) instead.
>So, to identify the core functions of the protocol, RFC 4960 is probably a
>more
>appropriate source.
>
[Karen ] I both agree and disagree with this statement. My view on this is:

If looking for an abstract interface I agree that many "implementation"
details of RFC6458 are unnecessary.
However a significant number of abstract functions are not described in
RFC4960 and for control of/API for those
one need to consult either RFC6458 - or for some of the functions - the api
section of the RFCs defining these abstract functions.

I would not know why one should consider only the "core"  services of SCTP
defined by RFC4960
as some significant protocol features are only defined by auxiliary RFCs.
Further there are "core" features defined in RFC4960 for which - used (!) -
control functions are only exposed in RFC6458.

I don't like the API parts of RFC793 as it does not so well represent the
API of the defacto TCP implementations - not the (very few) I know anyway.
For example both the sender side and the receiver side handling of PUSH
flag, which we seem to speak much about here, is not an example of a feature
where the RFC793 description well represent the implementations.
Also it obviously cannot well represent newer features, like e.g. control of
ECN.
Then, right, ECN may not make it as something we want to expose. Not sure.

I think that RFC793 and RFC4960 may be good starting points, but saying that
one will not look beyond them is a misunderstanding. In my view.

>
>> I understand that it is difficult to find out exactly what is the
>> fundament of TAPS - sometimes it is said that it is the existing IETF
>> specifications - which means for example that SCTP-CMT and QUIC is
>> outside of the scope.
>> Then in other Taps communications - e.g. TCP components - it is said
>> that one cannot fix the congestion control aspects of TCP as there I
>> not one CC for TCP - and "one do not know what people implements". I
>> am not sure exactly what Taps should to do when the defacto standards
>> (e.g. TCP) have superseded the actual standard. I think that it shall
>> be on a best judgment basis and when there _are_ specs we should go
>> with the most recent and sane ones and not with the outdated ones.
>
>One of the very first versions of our charter started the work off with a
>document that would lay out rules for us, as a basis to make such
>decisions.
>I venture to say that I was right to put this document there, and whoever
>recommended that I should remove it was wrong  :-)    because such a
>document would now be good to have, and I think it's easier to first try to
>agree on detailed rules (a more fine-grain charter, if you will - which
>protocols
>are in scope, how do we decide what a "service" is, etc.) than trying to
>immediately agree on the actual items themselves (SCTP-CMT: include it or
>not? Is the Nagle algorithm a service or not?  etc.)
>
[Karen ] Yes. But learning by doing has merits as well. Perhaps one now has
a more qualified view on what the "rules" should be.

BR, Karen

>Cheers,
>Michael