Re: [Taps] TCP components

[Michael Welzl <[e-mail]>]

> On 15 Jul 2015, at 12:40, Karen Elisabeth Egede Nielsen <[e-mail]> wrote:
> 
> 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.

Okay, sigh  :(   not easy, is it?


> 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


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

Agreed!

Cheers,
Michael