Subject: Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt

From: Aaron Falk <[email-masked]>
Date: Mon, 5 Oct 2015 14:42:40 -0400

Have others read this draft yet?   It is clearly aimed at addressing
charter deliverable #1.  Do other folks have an opinion on how well it
helps the group achieve the goals in our charter?  Should we use this
document in some way? I'm looking for more input from the working group on
how we should proceed.

My opinion: I am very mindful (& appreciative) of the significant effort by
Mirja and Brian and the other contributors on draft-ietf-taps-transports.
 The discussion around this doc has been very useful for clarifying (to me)
how difficult it can be to pull useful common abstractions out of the 30+
years of transport technologies.  Having been down this path for over a
year, I appreciate the fairly narrow approach draft-welzl-taps-transports
and think it may be the best chance for TAPS to succeed.

Please share your views.

--aaron

On Sat, Sep 26, 2015 at 10:50 AM, Michael Welzl <[email-masked]> wrote:

> +1
>
> > On 26. sep. 2015, at 13.28, Marie-Jose Montpetit <[email-masked]>
> wrote:
> >
> > Makes sense.
> >
> >> On Sep 26, 2015, at 3:17 AM, [email-masked] wrote:
> >>
> >> We seem to have two documents in a space where we started with one.
> These
> >> are different, to me this is OK. Both seem close to charter milestone
> 1. I
> >> don't see much overlap between the contents of the descriptive language
> >> and the API-focussed analysis, and any overlap could be eliminated.
> >>
> >> To me, doc 1 (current chartered item) can evolve to provide background
> and
> >> missing documentation for anyone in the IETF, and should compare
> >> transports in a broad way and draw out the idea that they provide
> >> services. This appears to be harder to get right than I for one had
> hoped,
> >> and still has a wide scope. Not a bad thing. I suggest it will provide a
> >> reference to stop us rat-holing when people ask what is "this" and
> explain
> >> how all these transports stack-up against one another (good pun?). We
> can
> >> (I suggest) finish this doc in this way.
> >>
> >> I do like the idea of a second document focussed ONLY on the Transport
> API
> >> (I'd call this 1a). In this we can avoid this"discussion of what are
> >> transports"  and move to  a  more focussed  process in doc 1b,  Most of
> >> that troublesome descriptive  text can go into 1, and ensure we keep
> that
> >> one readable to anyone in the  IETF.
> >>
> >> Could  I suggest the two docs against the first milestone will help us
> >> make  progress towards the next milestone faster. (Assuming we can keep
> >> the two aligned, which seems quite doable). I can see also how the  docs
> >> are useful to different people. I'd like to see both mature and provide
> >> inputs to move forward.
> >>
> >> Gorry
> >>
> >>
> >>> Interesting and inline to getting transport API(s)
> >>>
> >>> Marie-JosÃ© Montpetit
> >>> [email-masked]
> >>> [email-masked]
> >>>
> >>>> On Sep 21, 2015, at 04:44, Michael Welzl <[email-masked]> wrote:
> >>>>
> >>>> Dear all,
> >>>>
> >>>> In my presentation in Prague, I proposed an approach to identify the
> >>>> services that transport protocols provide. At the end of the ensuing
> >>>> discussion, I said that I (with co-authors) would write a draft that
> >>>> explains the proposal by applying the proposed method to TCP and SCTP.
> >>>>
> >>>> We just submitted this document - see below;  I hope that this will
> lead
> >>>> to some discussion on the list...
> >>>>
> >>>> Cheers,
> >>>> Michael
> >>>>
> >>>>
> >>>>> Begin forwarded message:
> >>>>>
> >>>>> From: <[email-masked]>
> >>>>> Subject: New Version Notification for
> >>>>> draft-welzl-taps-transports-00.txt
> >>>>> Date: 21 Sep 2015 10:35:33 CEST
> >>>>> To: Michael Welzl <[email-masked]>, Michael Welzl
> >>>>> <[email-masked]>, Michael Tuexen <[email-masked]>, Naeem
> >>>>> Khademi <[email-masked]>, Michael Tuexen <[email-masked]>,
> >>>>> Naeem Khademi <[email-masked]>
> >>>>> Resent-From: <[email-masked]>
> >>>>>
> >>>>>
> >>>>> A new version of I-D, draft-welzl-taps-transports-00.txt
> >>>>> has been successfully submitted by Michael Welzl and posted to the
> >>>>> IETF repository.
> >>>>>
> >>>>> Name:        draft-welzl-taps-transports
> >>>>> Revision:    00
> >>>>> Title:        An Approach to Identify Services Provided by IETF
> >>>>> Transport Protocols and Congestion Control Mechanisms
> >>>>> Document date:    2015-09-21
> >>>>> Group:        Individual Submission
> >>>>> Pages:        23
> >>>>> URL:
> >>>>>
> https://www.ietf.org/internet-drafts/draft-welzl-taps-transports-00.txt
> >>>>> Status:
> >>>>> https://datatracker.ietf.org/doc/draft-welzl-taps-transports/
> >>>>> Htmlized:
> >>>>> https://tools.ietf.org/html/draft-welzl-taps-transports-00
> >>>>>
> >>>>>
> >>>>> Abstract:
> >>>>> This document describes a method to identify services in transport
> >>>>> protocols and congestion control mechanisms.  It shows the approach
> >>>>> using TCP and SCTP (base protocol) as examples.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Please note that it may take a couple of minutes from the time of
> >>>>> submission
> >>>>> until the htmlized version and diff are available at tools.ietf.org.
> >>>>>
> >>>>> The IETF Secretariat
> >>>>
> >>>> _______________________________________________
> >>>> Taps mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/taps
> >>>
> >>> _______________________________________________
> >>> Taps mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/taps
> >>>
> >>
> >
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>

---

From: Brian Trammell <[email-masked]>
Date: Mon, 5 Oct 2015 12:49:06 -0700

In transit, please excuse the brevity.

Broadly I appreciate the effort to do the decomposition in a less arbitrary way. I'm not convinced it's actually less arbitrary, but this is largely irrelevant: it's a *different* way to do the decomposition, so points of agreement (of which, at least on TCP and SCTP, there are many) reinforce confidence that we're doing this right. I tend to agree with Gorry's suggestion on the way forward.

Cheers, Brian

Sent from my iPhone

> On 05 Oct 2015, at 11:42, Aaron Falk <[email-masked]> wrote:
> 
> Have others read this draft yet?   It is clearly aimed at addressing charter deliverable #1.  Do other folks have an opinion on how well it helps the group achieve the goals in our charter?  Should we use this document in some way? I'm looking for more input from the working group on how we should proceed. 
> 
> My opinion: I am very mindful (& appreciative) of the significant effort by Mirja and Brian and the other contributors on draft-ietf-taps-transports.    The discussion around this doc has been very useful for clarifying (to me) how difficult it can be to pull useful common abstractions out of the 30+ years of transport technologies.  Having been down this path for over a year, I appreciate the fairly narrow approach draft-welzl-taps-transports and think it may be the best chance for TAPS to succeed.  
> 
> Please share your views.
> 
> --aaron
> 
> 
>> > On 26. sep. 2015, at 13.28, Marie-Jose Montpetit <[email-masked]> wrote:
>> >
>> > Makes sense.
>> >
>> >> We seem to have two documents in a space where we started with one. These
>> >> are different, to me this is OK. Both seem close to charter milestone 1. I
>> >> To me, doc 1 (current chartered item) can evolve to provide background and
>> >> services. This appears to be harder to get right than I for one had hoped,
>> >> reference to stop us rat-holing when people ask what is "this" and explain
>> >> how all these transports stack-up against one another (good pun?). We can
>> >> I do like the idea of a second document focussed ONLY on the Transport API
>> >> that troublesome descriptive  text can go into 1, and ensure we keep that
>> >>>> We just submitted this document - see below;  I hope that this will lead

---

From: Michael Welzl <[email-masked]>
Date: Wed, 7 Oct 2015 09:17:49 +0200

Hi,

> On 05 Oct 2015, at 20:42, Aaron Falk <[email-masked]> wrote:
> 
> My opinion: I am very mindful (& appreciative) of the significant effort by Mirja and Brian and the other contributors on draft-ietf-taps-transports.

+1

>    The discussion around this doc has been very useful for clarifying (to me) how difficult it can be to pull useful common abstractions out of the 30+ years of transport technologies.  Having been down this path for over a year, I appreciate the fairly narrow approach draft-welzl-taps-transports and think it may be the best chance for TAPS to succeed.  
> 
> Please share your views.

You say you appreciate the "fairly narrow" approach of draft-welzl-taps-transports. This makes me wonder - maybe draft-welzl-taps-transports should only cover a subset of the transports in draft-ietf-taps-transports, based on what we can see in draft-ietf-taps-transports?   (e.g. the eventual text on RTP in draft-ietf-taps-transports will probably not be a short list of features, which may indicate that RTP should not be included in draft-welzl-taps-transports).

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Wed, 7 Oct 2015 11:17:49 +0200

> On 07 Oct 2015, at 09:17, Michael Welzl <[email-masked]> wrote:
> 
> Hi,
> 
> 
> You say you appreciate the "fairly narrow" approach of draft-welzl-taps-transports. This makes me wonder - maybe draft-welzl-taps-transports should only cover a subset of the transports in draft-ietf-taps-transports, based on what we can see in draft-ietf-taps-transports?

Definitely. I think the "narrow" approach can work here -- the scope is already narrowed by only considering unicast services, which simplifies things quite a bit. The question is how and whether to narrow further. TCP (and MPTCP), UDP (and UTP-lite), and SCTP clearly make the cut, as they are widely deployed and/or there is active work on top of them for which we expect wide deployment. Others I'm less sure of.

Cheers,

Brian

> (e.g. the eventual text on RTP in draft-ietf-taps-transports will probably not be a short list of features, which may indicate that RTP should not be included in draft-welzl-taps-transports).
> 
> Cheers,
> Michael
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Oct 2015 18:15:04 -0700

+1

I have read this version in detail (and provided feedback), and think it
is a useful document.

Joe

On 10/5/2015 12:49 PM, Brian Trammell wrote:
> Broadly I appreciate the effort to do the decomposition in a less
> arbitrary way. I'm not convinced it's actually less arbitrary, but this
> is largely irrelevant: it's a *different* way to do the decomposition,
> so points of agreement (of which, at least on TCP and SCTP, there are
> many) reinforce confidence that we're doing this right. I tend to agree
> with Gorry's suggestion on the way forward.
> 
> Cheers, Brian
> 
> Sent from my iPhone
> 
> On 05 Oct 2015, at 11:42, Aaron Falk <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>> document in some way? I'm looking for more input from the working
>> group on how we should proceed. 
>>
>> My opinion: I am very mindful (& appreciative) of the significant
>> effort by Mirja and Brian and the other contributors on
>> draft-ietf-taps-transports.    The discussion around this doc has been
>> very useful for clarifying (to me) how difficult it can be to pull
>> useful common abstractions out of the 30+ years of transport
>> technologies.  Having been down this path for over a year, I
>> appreciate the fairly narrow approach draft-welzl-taps-transports and
>> think it may be the best chance for TAPS to succeed.  
>>
>> Please share your views.
>>
>> --aaron
>>
>>
>> On Sat, Sep 26, 2015 at 10:50 AM, Michael Welzl <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     +1
>>
>>     > On 26. sep. 2015, at 13.28, Marie-Jose Montpetit
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>     >
>>     > Makes sense.
>>     >
>>     >> On Sep 26, 2015, at 3:17 AM, [email-masked]
>>     <mailto:[email-masked]> wrote:
>>     >>
>>     >>> [email-masked] <mailto:[email-masked]>
>>     >>> [email-masked] <mailto:[email-masked]>
>>     >>>
>>     >>>> On Sep 21, 2015, at 04:44, Michael Welzl <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>     >>>>
>>     >>>> Dear all,
>>     >>>>
>>     >>>>> From: <[email-masked]
>>     <mailto:[email-masked]>>
>>     >>>>> To: Michael Welzl <[email-masked]
>>     <mailto:[email-masked]>>, Michael Welzl
>>     >>>>> <[email-masked] <mailto:[email-masked]>>, Michael
>>     Tuexen <[email-masked] <mailto:[email-masked]>>, Naeem
>>     >>>>> Khademi <[email-masked] <mailto:[email-masked]>>,
>>     Michael Tuexen <[email-masked] <mailto:[email-masked]>>,
>>     >>>>> Naeem Khademi <[email-masked] <mailto:[email-masked]>>
>>     >>>>> Resent-From: <[email-masked] <mailto:[email-masked]>>
>>     >>>>>
>>     >>>>>
>>     >>>>> until the htmlized version and diff are available at
>>     tools.ietf.org <http://tools.ietf.org>.
>>     >>>>>
>>     >>>>> The IETF Secretariat
>>     >>>>
>>     >>>> [email-masked] <mailto:[email-masked]>
>>     >>> [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Tue, 27 Oct 2015 14:58:52 +0100

HI,

FWIIW please accept the following comments to the document:

Section 3.1:

"Passive open with fully specified foreign socket"

Is that a typical function provided to ULP by TCP ?
Our POSIX socket api implementation does not really provide this. Or it
does by set of special filters on the
listening socket, but I wasn't aware that this was a feature generally
available in TCP.

"Passive open with fully specified foreign socket" on a unspecified
passive open socket ?

I assume we speak listening socket. Again is this something typically
provided as an option to ULP by TCP ?

"Send: and PUSH flag description":

The PUSH flag is typically set inside the TCP implementation and the ULP
typically has no direct influence on the setting of it. I think that it is
strange that this function
is chosen to be described as if it is controlled directly by ULP when it
is indeed not.

There is some text later in section 3.1.1 motivating the choice. Yes it is
correct that TCP implementations implement
set of PUSH flag causing a behavior (i.e., a set of PUSH) that matches
that the PUSH flag is set in the end of a communication,
but again it is not controlled by ULP. As the intend of this document is
to expose services that the ULP
can invoke, I think that it is problematic that it is described as if the
ULP can control PUSH directly, when it indeed (often) cannot.

Section 3.2:

General comment:

The multi-stream capability and stream prioritization/scheduling
possibilities of SCTP is a feature
differentiating SCTP from TCP. The same is the fact that SCTP (SCTP-PR)
also provide unreliable (no retransmissions) and partial reliable
transport service (timeout).

I think that these service features are important for certain SCTP
deployment scenarios
and that it would be desirable for these to be exposed here. (The timeout
is described)
 It not included here in the first pass it will never even get considered
 for TAPS as a potential service, would it ?
 (It might end up being excluding, but then this should be a
conscious (visible) choice, I think).

Detailed comments:

"Initialize needs be called only once per set of local addresses":

This is the case when supporting one-to-many style sockets. Perhaps one
might add
"but ULP may also initialize each association endpoint instance
individually".

"Associate":

I think that it is relevant to clarify that the remote SCTP instance in
the association primitive is
identified by one or multiple destination addresses thus allowing also the
association handshake
to proceed using multiple paths.

"Send":

"Another advisory flag indicates the ULP's preference to avoid bundling
user data .."

This is specified as an optional attribute in RFC4960. This is not
specified in the RFC6458 socket API.
((Yes it might be similar to the TCP PUSH flag in that it is not generally
implemented as directly controllable by ULP on a message basis - Or?))

Section 4.2:

SCTP implements NO_delay (Nagle) option on a per association basis (as TCP
on a per connection basis) but not typically
on a per message basis as described here. There are some additional
bundling control related to stream scheduling - some are described in
sctp-ndata draft.

Section 5.1:

"Disable Nagle algorithm:"

Not specified in RFC4960, but in RFC6458 for SCTP.
Is it really valid to use RFC4960 as a reference for the socket API when
the approach of
SCTP IETF community has been to use RFC6458 for this ?

***

BR, Karen

> -----Original Message-----
> From: Taps [mailto:[email-masked]] On Behalf Of Michael Welzl
> Sent: 21. september 2015 10:45
> To: taps WG
> Subject: [Taps] Fwd: New Version Notification for draft-welzl-taps-
> transports-00.txt
>
> Dear all,
>
services
> that transport protocols provide. At the end of the ensuing discussion,
I said
> that I (with co-authors) would write a draft that explains the proposal
by
> applying the proposed method to TCP and SCTP.
>
to
> some discussion on the list...
>
> Cheers,
> Michael
>
>
> > Begin forwarded message:
> >
> > Title:		An Approach to Identify Services Provided by
> IETF Transport Protocols and Congestion Control Mechanisms
> > URL:            https://www.ietf.org/internet-drafts/draft-welzl-taps-
> transports-00.txt
> > Status:
> > submission until the htmlized version and diff are available at
tools.ietf.org.

---

From: Michael Welzl <[email-masked]>
Date: Tue, 27 Oct 2015 15:07:20 +0100

Dear Karen,

Thanks a lot for your comments!
This was only meant as a starting point - e.g. the decision to only use RFC4960 but not RFC6458 is definitely not set in stone.

We’ll incorporate them in the next revision (and then maybe get back to you in case we need discussion) - thanks again!

Cheers,
Michael

> On 27. okt. 2015, at 14.58, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI,
>

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 28 Oct 2015 09:34:36 +0100

Hi,

Thanks.

If this was not clear, then I should emphasize that
I think this document is an excellent starting point !

BR, Karen

> From: Michael Welzl [mailto:[email-masked]]
> Sent: 27. oktober 2015 15:07
> To: Karen Elisabeth Egede Nielsen
> Cc: [email-masked]
> Subject: Re: [Taps] New Version Notification for
> This was only meant as a starting point - e.g. the decision to only use
> RFC4960
> but not RFC6458 is definitely not set in stone.
>
> We’ll incorporate them in the next revision (and then maybe get back to
> you
> in case we need discussion) - thanks again!
>
> Cheers,
> Michael
>
>