Subject: Re: [Taps] TCP components

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 15 Jul 2015 11:03:58 +0200

HI Mirja, All

Sorry for jumping late into this discussion.

>-----Original Message-----
>From: Taps [mailto:[email-masked]] On Behalf Of Mirja Kühlewind
>Sent: Thursday, June 18, 2015 10:48 AM
>To: Joe Touch
>Cc: Brian Trammell; Michael Welzl; [email-masked]
>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

---

From: Michael Welzl <[email-masked]>
Date: Wed, 15 Jul 2015 11:33:12 +0200

> On 15 Jul 2015, at 11:03, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI Mirja, 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.

> we should go with the most recent and sane ones and not with the outdated

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

Cheers,
Michael

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 15 Jul 2015 12:40:55 +0200

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

---

From: Michael Welzl <[email-masked]>
Date: Wed, 15 Jul 2015 12:47:31 +0200

> On 15 Jul 2015, at 12:40, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> Hi Michael, All
> 
>> 

Okay, sigh  :(   not easy, is it?

> one will not look beyond them is a misunderstanding. In my view.

I understand

> a more qualified view on what the "rules" should be.

Agreed!

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Jul 2015 11:17:45 -0700

> Sorry for jumping late into this discussion.
...
> as specified in RFC793 and RFC4960 when we have better material available.

What portion of RFC793's API do you consider outdated?

AFAICT, it's exactly what most sockets try to support (I can't speak
about SCTP, as I haven't used it much).

Joe

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 16 Jul 2015 09:57:24 +0200

HI,

I was thinking about the PUSH flag mainly.

In our socket api implementation we do not allow for set of PUSH in send
calls nor do we provide the PUSH flag indication upwards on the receiver
side.
I think that after RFC793 it has been clarified that TCP MAY allow for set
of PUSH flag in send() and MAY OPTIONALLY provide this information upwards
on the receiver side.
I think that it would be questionable to follow RFC793 wording here on
PUSH.

I have no much experience with the URGENT flag - we actually don't support
it, which I agree to be non-compliant.
Perhaps the API parts of RFC793 is right, whereas  it is only the function
as such that has been clarified later.

BR, Karen

>From: Taps [mailto:[email-masked]] On Behalf Of Joe Touch
>Sent: Wednesday, July 15, 2015 8:18 PM
>To: Karen Elisabeth Egede Nielsen; Mirja Kühlewind
>Cc: Brian Trammell; [email-masked]; Michael Welzl; [email-masked]
>> 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.
>
about
>SCTP, as I haven't used it much).
>
>Joe
>
>_______________________________________________
>Taps mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/taps

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jul 2015 14:51:23 -0700

Hi, Karen,

>> What portion of RFC793's API do you consider outdated?
....
> calls nor do we provide the PUSH flag indication upwards on the receiver

That's consistent with RFC1122, which updates RFC793.

> of PUSH flag in send() and MAY OPTIONALLY provide this information upwards

Yes.

> I think that it would be questionable to follow RFC793 wording here on

Sure; I was being broad in my reference back to RFC793; updates need to
be chased down too, so to the extent that the updates make RFC793
outdated, you're correct. However, the bulk of RFC793's API remains in
effect.

Joe