Re: [Taps] TCP components

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

HI Mirja, All

Sorry for jumping late into this discussion.

>-----Original Message-----
>From: Taps [mailto:[e-mail]] On Behalf Of Mirja Kühlewind
>Sent: Thursday, June 18, 2015 10:48 AM
>To: Joe Touch
>Cc: Brian Trammell; Michael Welzl; [e-mail]
>Subject: Re: [Taps] TCP components
>
>Hi Joe,
>
>I believe the approach Michael is proposing is to look at existing APIs as
>a
>starting point; not only abstract APIs. The assumption is that someone who
>implemented/designed an API, thought that it would be worth to provide a
>configuration possibility to the higher layer. This assumption is more true
>for
>SCTP than for TCP because there are quite a few different TCP
>implementation that are grown over time. Quite often a new interface was
>only created because a new feature was added to TCP; and to be on the safe
>side we allow the user to turn it off again.
>
>That’s the reason why I prefer the approach we are/I'm taking right now
>(analyzing components). I think we should still describe the abstract API
>of
>RFC793 (and we do) as well as the SCTP API of RFC4960 in this document, but
>I
>personally would not and will not spend too much time analyzing other API.

[Karen ]

I really do not think that it makes much sense to look into outdated and
deprecated APIs
as specified in RFC793 and RFC4960 when we have better material available.
For SCTP here specifically RFC6458.
Personally I cannot support this approach. I am not saying that we need very
detailed APIs and therefore do not want RFC793 or RFC4960,
but I want that what we do is based on the right specs (or the right defacto
implementations) not on known-to-be outdated ones.

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.

BR, Karen