Re: [Taps] Aaron Falk as BOF co-chair

[Michael Welzl]

On 10. juli 2014, at 07:19, Spencer Dawkins  
wrote:

> Dear TAPSters,
> 
> Martin and I recruited Aaron Falk to co-char the TAPS BOF at IETF 90.
> 
> Aaron is an experienced working group chair (he was, in fact, the experienced 
> working group co-chair for PILC, the first working group I co-chaired), and 
> has significant TSV experience, including co-chairing DCCP.
> 
> Aaron has also served the broader community as IRTF Chair, prior to Lars 
> Eggert.
> 
> Please welcome Aaron, and help him construct the right agenda for the TAPS 
> BOF.

A warm welcome indeed, Aaron!!

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Stream vs. packet

[Michael Welzl]

> 
>> IMHO, the API will do well to let the client advise it regarding what
>> type of interface it wants, and go with it.

Sure! But my point was that a byte stream can always be constructed over a 
packet stream for those who want it, at the potential loss of some efficiency. 
Vice versa doesn't make much sense to me - messages over a byte stream that 
then is split into packets that are sent over the networks is just silly. Yes 
certainly many apps do that over TCP (because TCP gives them many other good 
things and mostly works), but that sort of mismatch is what TAPS could help 
solve.

Hence, what I'd suggest is to not even consider "byte stream" in TAPS 
discussions - e.g. as a "service" or anything like that. Certainly, yes, a 
TAPS-based interface can always provide one.

As for Structured Streams, it's a nice paper but I never saw how this is much 
different from SCTP... anyway, bringing that into the discussion blends the 
*byte stream* that we're talking about here with *multi-streaming*  (which is 
what Structured Streams is about), which are really two separate things despite 
the name similarity. Multi-streaming can be (and is in fact best) done with 
messages, not a byte stream. As always, one can stack a byte stream on top with 
a possible efficiency loss.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Stream vs. packet

[Michael Welzl]

On 12. juli 2014, at 21:12, Fred Baker (fred)  wrote:

> 
> On Jul 12, 2014, at 12:47 AM, Michael Welzl  wrote:
> 
>> As for Structured Streams, it's a nice paper but I never saw how this is 
>> much different from SCTP... 
> 
> Is that a bad thing?

For the paper perhaps, in terms of innovation, as it doesn't talk much about 
SCTP IIRC...
But my intention was not to criticize the paper. I just meant that it's similar 
to multi-streaming in SCTP and thus probably not necessary to consider as yet 
another transport for TAPS to think about.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Stream vs. packet

[Michael Welzl]

On 13. juli 2014, at 19:39, Fred Baker (fred)  wrote:

> 
> On Jul 13, 2014, at 1:16 AM, Michael Welzl  wrote:
> 
>> 
>> On 12. juli 2014, at 21:12, Fred Baker (fred)  wrote:
>> 
>>> 
>>> On Jul 12, 2014, at 12:47 AM, Michael Welzl  wrote:
>>> 
>>>> As for Structured Streams, it's a nice paper but I never saw how this is 
>>>> much different from SCTP... 
>>> 
>>> Is that a bad thing?
>> 
>> For the paper perhaps, in terms of innovation, as it doesn't talk much about 
>> SCTP IIRC…
> 
> OK. There are at least two ways one can approach this kind of technology: 
> from the perspective of requirements, and from the perspective of innovation. 
> A problem I have with academic papers is that they often innovate for 
> innovation’s sake; they want desperately to create something novel, and will 
> often say repeatedly that whatever their innovation is is novel, as if saying 
> it frequently makes it so. My question is not whether it is novel, unless the 
> novelty represents and actual improvement. My question is whether it meets 
> the requirements.
> 
> In this case, we have a mechanism that carries data in IP datagrams. The 
> datagrams fundamentally carry one of two kinds of content: messages that are 
> exchanged between communicating peers, such as a BGP exchange might, and 
> streams of data that might carry on interminably, such as an interactive 
> exchange or an A/V application might. A stream must be delivered in sequence; 
> messages might accept delivery out of sequence, or even unreliability. In 
> between, the transport turns application data into IP datagrams and back into 
> application data.
> 
> The way the transport distinguishes between messages and streams, if it does 
> at all, is its designer’s call. But to say that the needs of two classes of 
> applications are irrelevant because one can be created out of the other - 
> which is the model that TCP used, and the model Sequenced packet used, and 
> the model you propose here - targets the transport at that class of 
> application. I think we’re far better off recognizing that there are multiple 
> kinds of applications, and making an API that works well with either or any 
> of them If that means that the API implements RFC 2126 internally to carry 
> messages over a stream transport, so be it. If it means that the transport 
> internally carries chunks, as SCTP does, and knows whether they are intended 
> to be streams or messages, so be it. But making it an application layer 
> problem doesn’t come across to me as having looked at it from the perspective 
> of the requirements of the application layer.

I agree with all of that (and have a feeling that you misunderstood me  :-)   ).

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

[Taps] Note takers and jabber scribes

[Michael Welzl]

Dear all,

We'll need note takers and jabber scribes at the TAPS BOF on Monday. PLEASE 
consider volunteering. Let Aaron and me know already now to save time at the 
meeting.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Note takers and jabber scribes

[Michael Welzl]

Hahaha, no!!   :-)because that was MYSELF, reading them very very carefully 
from the audio long after the meeting. It was a hell of a job, so I'll ask to 
get very experienced note takers to do the job on site this time, pretty 
please!!


On 19. juli 2014, at 14:16, Aaron Falk  wrote:

> Whoever took notes last time did a great job.  Please consider 
> re-volunteering!
> 
> 
> On Sat, Jul 19, 2014 at 8:12 AM, Michael Welzl  wrote:
> Dear all,
> 
> We'll need note takers and jabber scribes at the TAPS BOF on Monday. PLEASE 
> consider volunteering. Let Aaron and me know already now to save time at the 
> meeting.
> 
> Cheers,
> Michael
> 
> 

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS charter rev 20140818 - IMPORTANT CHANGE!

[Michael Welzl]

Dear all,

I'm surprised by the number of changes to the charter at this late stage. One 
particular change strikes me as quite significant: the following milestone was 
removed:

***
M18: Submit specification of how the transport services can be provided to IESG.
***
...and instead there is now text in the charter saying "The associated 
milestone will be scheduled and work on this document will begin when the TAPS 
Transport Services have been specified".

What's the point of this? Is it a concern about the time line? Milestone dates 
can be changed, if they must, but I think it's important that the charter 
contains the milestone, as a dedication to actually develop a workable 
solution, not just a list of things. The way it stands now, all the group 
produces is a long list and a shorter list. Not what most members of the group 
here wanted, I think. I object to this removal.

Cheers,
Michael



On 19. aug. 2014, at 02:37, Aaron Falk wrote:

> Hi Folks-
> 
> We received a bit more charter input from the IAB and I've incorporated it 
> into the draft below.  Diffs against the last rev and the version submitted 
> for IETF comment are also attached (as usual).  The IESG will be taking up 
> approval of the TAPS working group at their telechat on August 28 so 
> comments, including support, are appreciated.
> 
> Regards,
> 
> --aaron
> 
> --
> 
> Last updated 2014-08-18
> 
> 
> Transport Services (taps) 
> 
> The vast majority of Internet applications make use of the Transport Services 
> provided by TCP (a reliable, in-order stream protocol) or UDP (an unreliable 
> datagram protocol). We use the term "Transport Service" to mean an end-to-end 
> facility provided by the transport layer that can only be correctly provided 
> with information from the application. This information may be provided at 
> design time, compile time, or run time.  Additionally, it may include 
> guidance from the application on whether the facility in question is required 
> or simply a preference by the application. Four examples of Transport 
> Services are reliable delivery, no guarantee of order preservation, content 
> privacy to in-path devices, and minimal latency.
> 
> Other transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and UDP-Lite 
> and the LEDBAT congestion control mechanism extend the set of available 
> Transport Services beyond those provided to applications by TCP and UDP. For 
> example, SCTP provides potentially faster (than TCP) reliable delivery for 
> applications that can accept blocks of data out of order, and LEDBAT provides 
> low-priority "scavenger" communication. 
> 
> Application programmers face difficulty when they use protocols other than 
> TCP or UDP. Most network stacks ship with only TCP and UDP as transport 
> protocols.  Many firewalls only pass TCP and UDP and some only support HTTP 
> over TCP. As a result, using other transport protocols or building a new 
> protocol over raw sockets, risks having an application not work in many 
> environments. Applications, therefore, must always be able to fall back to 
> TCP or UDP, or even HTTP in many cases, and once the application programmer 
> has committed to making an application work on TCP or UDP or HTTP, there is 
> little incentive to try other transport protocols before falling back. 
> Further, different protocols can provide the same services in different ways. 
> Layering decisions must be made (for example, whether a protocol is used 
> natively or tunneled through UDP). 
> 
> Because of these complications, programmers often resort to either using TCP 
> or HTTP, or implementing their own customized "transport services" over UDP. 
> When application developers re-implement transport features already available 
> elsewhere, they open the door to problems that simply using TCP would have 
> avoided, and ensure that the applications can't benefit from other transport 
> protocols as they become available. 
> 
> Because even TCP and UDP are not guaranteed to work in all environments 
> today, some programmers simply give up on using TCP or UDP directly, relying 
> instead on "HTTP as a Substrate". BCP 56 identified many issues with this 
> strategy, but assuming that if "any protocol is available on a given network 
> path and on the hosts that will be communicating, that protocol will be HTTP" 
> is a reasonable strategy for today's Internet. The IESG has agreed with this 
> viewpoint enough to publish the WebSocket protocol on the standards track. 
> 
> The goal of the TAPS working group is to help application and network stack 
> programmers by describing an (abstract) interface for applications to make 
> use of Transport Services. The Working Group deliverables emphasize defining 
> Transport Services that are important to applications followed by 
> experimental mechanisms to a) determine if the protocols to provide the 
> requested services are available on the end points and supported along the 
> path in the net

[Taps] Another significant detail: status of RFCs

[Michael Welzl]

Hi again, all,

Did you notice that the two still existing milestones that we still have left 
also come with a status now?

Before the London BOF, this bit was:

***
* M7: Submit summary of the services provided by IETF transport protocols and 
congestion control mechanisms as well as requirements of common APIs to IESG as 
Informational
* M10: Submit draft on how transport services are identified to IESG as 
Proposed Standard
* M13: Submit set of services that a transport API should provide to IESG as 
Proposed Standard
***

- before the Toronto BOF, I was told that there's no need for milestones to 
mention the status of documents, and I should just remove that. So we had, in 
the version of the charter that went to IETF open review, even after the 
Toronto BOF:

***
* M9: Submit summary of the services provided by IETF transport protocols and 
congestion control mechanisms to IESG.
* M15: Submit end system transport services to IESG.
* M18: Submit specification of how the transport services can be provided to 
IESG.
***

 and now, all of a sudden, we have:

***
* M9: Submit to the IESG an Informational document defining a set of services 
provided by IETF transport protocols and congestion control mechanisms.
* M15: Submit to the IESG an Informational document recommending a minimal set 
of Transport Services that end systems should support.
***

Minor change? I think not. Might be okay or not - I just don't like this 
happening without people noticing and commenting.


Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS charter rev 20140818

[Michael Welzl]

Hi Brian, thanks getting into this discussion!

In line below:

On 19. aug. 2014, at 11:32, Brian Trammell wrote:

> Hi Aaron,
> 
> Following some (i.e. extensive) hallway discussion in Toronto to Thursday, 
> I'd make one following suggested changes to this draft charter, inline.
> 
> On 19 Aug 2014, at 02:37, Aaron Falk  wrote:
> 
>> Hi Folks-
>> 
>> We received a bit more charter input from the IAB and I've incorporated it 
>> into the draft below.  Diffs against the last rev and the version submitted 
>> for IETF comment are also attached (as usual).  The IESG will be taking up 
>> approval of the TAPS working group at their telechat on August 28 so 
>> comments, including support, are appreciated.
>> 
>> Regards,
>> 
>> --aaron
>> 
>> --
>> 
>> Last updated 2014-08-18
>> 
>> 
>> Transport Services (taps) 
>> 
>> The vast majority of Internet applications make use of the Transport 
>> Services provided by TCP (a reliable, in-order stream protocol) or UDP (an 
>> unreliable datagram protocol). We use the term "Transport Service" to mean 
>> an end-to-end facility provided by the transport layer that can only be 
>> correctly provided with information from the application. This information 
>> may be provided at design time, compile time, or run time.  Additionally, it 
>> may include guidance from the application on whether the facility in 
>> question is required or simply a preference by the application. Four 
>> examples of Transport Services are reliable delivery, no guarantee of order 
>> preservation, content privacy to in-path devices, and minimal latency.
>> 
>> Other transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and 
>> UDP-Lite and the LEDBAT congestion control mechanism extend the set of 
>> available Transport Services beyond those provided to applications by TCP 
>> and UDP. For example, SCTP provides potentially faster (than TCP) reliable 
>> delivery for applications that can accept blocks of data out of order, and 
>> LEDBAT provides low-priority "scavenger" communication. 
>> 
>> Application programmers face difficulty when they use protocols other than 
>> TCP or UDP. Most network stacks ship with only TCP and UDP as transport 
>> protocols.  Many firewalls only pass TCP and UDP and some only support HTTP 
>> over TCP. As a result, using other transport protocols or building a new 
>> protocol over raw sockets, risks having an application not work in many 
>> environments. Applications, therefore, must always be able to fall back to 
>> TCP or UDP, or even HTTP in many cases, and once the application programmer 
>> has committed to making an application work on TCP or UDP or HTTP, there is 
>> little incentive to try other transport protocols before falling back. 
>> Further, different protocols can provide the same services in different 
>> ways. Layering decisions must be made (for example, whether a protocol is 
>> used natively or tunneled through UDP). 
>> 
>> Because of these complications, programmers often resort to either using TCP 
>> or HTTP, or implementing their own customized "transport services" over UDP. 
>> When application developers re-implement transport features already 
>> available elsewhere, they open the door to problems that simply using TCP 
>> would have avoided, and ensure that the applications can't benefit from 
>> other transport protocols as they become available. 
>> 
>> Because even TCP and UDP are not guaranteed to work in all environments 
>> today, some programmers simply give up on using TCP or UDP directly, relying 
>> instead on "HTTP as a Substrate". BCP 56 identified many issues with this 
>> strategy, but assuming that if "any protocol is available on a given network 
>> path and on the hosts that will be communicating, that protocol will be 
>> HTTP" is a reasonable strategy for today's Internet. The IESG has agreed 
>> with this viewpoint enough to publish the WebSocket protocol on the 
>> standards track. 
>> 
>> The goal of the TAPS working group is to help application and network stack 
>> programmers by describing an (abstract) interface for applications to make 
>> use of Transport Services. The Working Group deliverables emphasize defining 
>> Transport Services that are important to applications followed by 
>> experimental mechanisms to a) determine if the protocols to provide the 
>> requested services are available on the end points and supported along the 
>> path in the network and b) fall back, i.e., select alternate, possibly 
>> less-preferred, protocols when desired protocols are not available. The 
>> Working Group will not define a richer set of Transport Services for 
>> applications, although the TAPS deliverables could inform proposals for 
>> future chartered work on Transport Services. 
>> 
>> The Working Group will:
>> 
>> 1) Define a set of Transport Services, prioritizing those provided by 
>> existing IETF protocols and congestion control mechanisms. As a starting 
>> point, the working group will

Re: [Taps] Another significant detail: status of RFCs

[Michael Welzl]

On 19. aug. 2014, at 12:07, Brian Trammell wrote:

> hi Michael,
> 
> On 19 Aug 2014, at 11:35, Michael Welzl  wrote:
> 
>> Hi again, all,
>> 
>> Did you notice that the two still existing milestones that we still have 
>> left also come with a status now?
>> 
>> Before the London BOF, this bit was:
>> 
>> ***
>> * M7: Submit summary of the services provided by IETF transport protocols 
>> and congestion control mechanisms as well as requirements of common APIs to 
>> IESG as Informational
>> * M10: Submit draft on how transport services are identified to IESG as 
>> Proposed Standard
>> * M13: Submit set of services that a transport API should provide to IESG as 
>> Proposed Standard
>> ***
>> 
>> - before the Toronto BOF, I was told that there's no need for milestones to 
>> mention the status of documents, and I should just remove that. So we had, 
>> in the version of the charter that went to IETF open review, even after the 
>> Toronto BOF:
>> 
>> ***
>> * M9: Submit summary of the services provided by IETF transport protocols 
>> and congestion control mechanisms to IESG.
>> * M15: Submit end system transport services to IESG.
>> * M18: Submit specification of how the transport services can be provided to 
>> IESG.
>> ***
>> 
>>  and now, all of a sudden, we have:
> 
> So let's look at these one by one:
> 
>> ***
>> * M9: Submit to the IESG an Informational document defining a set of 
>> services provided by IETF transport protocols and congestion control 
>> mechanisms.
> 
> I think this is pretty clearly Informational; it was also identified as such 
> pre-London, so I don't think this is particularly controversial as 
> Informational. 

ACK.


> (Not really relevant to the charter, but on this point as we discussed in the 
> hallway in Toronto, I think the right way to do this is to solicit 
> contributions from people in the community who have deep knowledge of certain 
> transport protocols to specify these in terms of their behaviors in 
> individual I-Ds or I-D sections, then to have an editor pull these together 
> into a coherent whole.)

Indeed, not a charter suggestion but a good plan I think.


>> * M15: Submit to the IESG an Informational document recommending a minimal 
>> set of Transport Services that end systems should support.
> 
> In my opinion, whether this is PS or Info comes down to two questions: (1) is 
> there an interoperability reason to specify a set of services that 
> must/should/may/must not be provided by end systems and (2) will there be 
> normative references to it from future PS documents?

What you say makes sense to me. I actually don't remember who proposed to make 
this PS and why, and I can live with both. I just wanted to bring the question 
back to the group, as it is a change to how things were originally written. We 
had PS written there for a long time, went to "no status mentioned" because it 
was said that it needs no mention, and now it's Informational.


> I don't really have an opinion here, though I think I'd lean toward PS just 
> for the sake of future utility. Note that if this milestone is PS it will 
> have to restate the salient points of each selected behavior / 
> service-in-terms-of-behaviors from the first milestone in normative language. 
> I'm okay with that too.

Me too...   sounds like we should go back to PS on this one, then.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS charter rev 20140818

[Michael Welzl]

On 19. aug. 2014, at 12:07, Brian Trammell wrote:

> 
> On 19 Aug 2014, at 11:41, Michael Welzl  wrote:
> 
>> Hi Brian, thanks getting into this discussion!
>> 
>> In line below:
>> 
>> On 19. aug. 2014, at 11:32, Brian Trammell wrote:
> 
> 
> 
>>> Per the third point of the charter, I think we want to add the third 
>>> milestone back, but make clear that the effort is experimental; something 
>>> like:
>>> 
>>> M18: Submit to the IESG an Experimental document exploring abstract 
>>> interfaces to Transport Services, and defining an experiment to evaluate 
>>> such interfaces for applicability to common application design patterns and 
>>> incremental deployability
>> 
>> I think this is a significant change to the wording that we had during IETF 
>> open review, which was:
>> 
>> M18: Submit specification of how the transport services can be provided to 
>> IESG.
>> 
>> I'd be fine with the status of this document explicitly being Experimental, 
>> as it was before, see:
>> https://sites.google.com/site/transportprotocolservices/charter-proposal/charter-before-london
>> i.e. to change this back to:
>> 
>> M18: Submit Experimental specification of how the transport services can be 
>> provided to IESG.
>> 
>> ...but your wording seems to be an entirely different thing: exploring 
>> abstract interfaces? defining an experiment to evaluate them for 
>> applicability to app design patterns? This is really something else. Why do 
>> you propose such a change at this late stage? Who else wants that, and why?
> 
> I think we need something a bit more specific than "submit specification of 
> how the transport services can be provided to the IESG" -- since (for my 
> part) I'm not really sure what that means. My wording is simply an attempt to 
> take the language from the third "working group will" point and turn it into 
> a milestone:
> 
>> 3) Specify experimental support mechanisms to provide the Transport Services 
>> identified in work item 2.
> 
> i.e. "Submit to the IESG an Experimental document exploring..."
> 
>> This document will explain how to select and engage an appropriate protocol 
>> and how to discover which protocols are available for a given connection. 
> 
> "...abstract interfaces to Transport Services..." (since "how to select and 
> engage" seems to me to very much be an abstract interface, maybe I'm reading 
> it wrong)

I'm pretty sure that the whole phrase was meant to mean some form of "Happy 
Eyeballs++ for transports". I think this is obvious for the second half 
("discover which protocols are available..."), but end-to-end, more than that 
is required. If Happy Eyeballs gives me a TCP response before it gives me a 
protocol X response that I'm hoping for, do I wait or just use X later in case 
it arrives? And: do we need to tell the other end what we're doing? Find out 
what the other side is even capable of?  (for some services we do, for some we 
don't).

We can now start wordsmithing to try to put this into clearer words, but I 
didn't think this is the right time to do that... we've been wordsmithing so 
much?!  and I have trouble interpreting the phrase as an "abstract interface", 
frankly, but this may be just me who has looked at the text from one particular 
angle for so long.


>> Further, it will provide a basis for incremental deployment. The associated 
>> milestone will be scheduled and work on this document will begin when the 
>> TAPS Transport Services have been specified. 
> 
> "...defining an experiment to evaluate such interfaces for... incremental 
> deployability". (The bit about application design patterns is admittedly 
> something I added to point out it's not _just_ incremental deployability we 
> care about, but I would submit that if we're not building this in the hope 
> that it addresses common application design patterns, then we can all go 
> home.)

We've been around the "common application application design patterns" block, 
see Martin Sustrik's presentation in London, the minutes, and extensive list 
discussion on that topic. This didn't culminate in charter text and I'd suggest 
to not insert such text now.


> I'm of course open to better wording that captures point (3), this is just a 
> first suggestion. And we do want something very open... but I think "Submit 
> Experimental specification of how the transport services can be provided to 
> IESG" is a bit too open.
> 
> Thoughts?

Personally I thin

Re: [Taps] TAPS charter rev 20140818

[Michael Welzl]

On 19. aug. 2014, at 14:01, Brian Trammell wrote:

> 
> On 19 Aug 2014, at 13:40, Michael Welzl  wrote:
> 
>> 
>> On 19. aug. 2014, at 12:07, Brian Trammell wrote:
>> 
>>> 
>>> On 19 Aug 2014, at 11:41, Michael Welzl  wrote:
>>> 
>>>> Hi Brian, thanks getting into this discussion!
>>>> 
>>>> In line below:
>>>> 
>>>> On 19. aug. 2014, at 11:32, Brian Trammell wrote:
>>> 
>>> 
>>> 
>>>>> Per the third point of the charter, I think we want to add the third 
>>>>> milestone back, but make clear that the effort is experimental; something 
>>>>> like:
>>>>> 
>>>>> M18: Submit to the IESG an Experimental document exploring abstract 
>>>>> interfaces to Transport Services, and defining an experiment to evaluate 
>>>>> such interfaces for applicability to common application design patterns 
>>>>> and incremental deployability
>>>> 
>>>> I think this is a significant change to the wording that we had during 
>>>> IETF open review, which was:
>>>> 
>>>> M18: Submit specification of how the transport services can be provided to 
>>>> IESG.
>>>> 
>>>> I'd be fine with the status of this document explicitly being 
>>>> Experimental, as it was before, see:
>>>> https://sites.google.com/site/transportprotocolservices/charter-proposal/charter-before-london
>>>> i.e. to change this back to:
>>>> 
>>>> M18: Submit Experimental specification of how the transport services can 
>>>> be provided to IESG.
>>>> 
>>>> ...but your wording seems to be an entirely different thing: exploring 
>>>> abstract interfaces? defining an experiment to evaluate them for 
>>>> applicability to app design patterns? This is really something else. Why 
>>>> do you propose such a change at this late stage? Who else wants that, and 
>>>> why?
>>> 
>>> I think we need something a bit more specific than "submit specification of 
>>> how the transport services can be provided to the IESG" -- since (for my 
>>> part) I'm not really sure what that means. My wording is simply an attempt 
>>> to take the language from the third "working group will" point and turn it 
>>> into a milestone:
>>> 
>>>> 3) Specify experimental support mechanisms to provide the Transport 
>>>> Services identified in work item 2.
>>> 
>>> i.e. "Submit to the IESG an Experimental document exploring..."
>>> 
>>>> This document will explain how to select and engage an appropriate 
>>>> protocol and how to discover which protocols are available for a given 
>>>> connection. 
>>> 
>>> "...abstract interfaces to Transport Services..." (since "how to select and 
>>> engage" seems to me to very much be an abstract interface, maybe I'm 
>>> reading it wrong)
>> 
>> I'm pretty sure that the whole phrase was meant to mean some form of "Happy 
>> Eyeballs++ for transports". I think this is obvious for the second half 
>> ("discover which protocols are available..."), but end-to-end, more than 
>> that is required. If Happy Eyeballs gives me a TCP response before it gives 
>> me a protocol X response that I'm hoping for, do I wait or just use X later 
>> in case it arrives? And: do we need to tell the other end what we're doing? 
>> Find out what the other side is even capable of?  (for some services we do, 
>> for some we don't).
> 
> ACK.
> 
>> We can now start wordsmithing to try to put this into clearer words, but I 
>> didn't think this is the right time to do that... we've been wordsmithing so 
>> much?!  and I have trouble interpreting the phrase as an "abstract 
>> interface", frankly, but this may be just me who has looked at the text from 
>> one particular angle for so long.
> 
> So to me the abstract interface is how the application specifies what things 
> should get happy eyeballs'd (since trying to figure out if we can get PR-SCTP 
> down the path is pointless if we don't want retransmission at all). I know we 
> don't belong to the the billion-knobs school of transport configuration here, 
> but the app needs to be able to specify what it expects. 
> 
> (Further down the program -- in the bit of the work we specifically agreed 
> not to do ye

Re: [Taps] TAPS charter rev 20140818

[Michael Welzl]

+1.


Now, we can perhaps head on to the other charter changes related to this 
re-inserted milestone. I suggest the following undo's => I mean going back from 
THIS VERSION to the PREVIOUS VERSION, which is the version that went to IETF 
review:

THIS VERSION:
2) Note that not all capabilities of IETF Transport protocols need to be 
exposed as Transport Services. This document will recommend the minimal set of 
Transport Services for inclusion in the abstract API. The resulting document 
will also provide guidance on making a choice among available mechanisms and 
protocols to obtain a certain Transport Service. 

PREVIOUS VERSION:
2) Note that not all capabilities of IETF Transport protocols need to be 
exposed as Transport Services. This document will recommend the minimal set of 
Transport Services that support mechanisms must provide (such as those in work 
item 3). The resulting document will also provide guidance on making a choice 
among available mechanisms and protocols to obtain a certain Transport Service. 


a bit below, for item 3 (last sentence):

THIS VERSION:
The associated milestone will be scheduled and work on this document will begin 
when the TAPS Transport Services have been specified. 

PREVIOUS VERSION:
Work on this document will begin when the TAPS Transport Services have been 
specified. 



Not relevant to this particular discussion, but a suggested minor change 
nevertheless, for the out-of-scope list:

THIS VERSION:
- Extension, modification, or creation of existing IETF transport protocols 

PREVIOUS VERSION:
- Extension, modification, or creation of transport protocols 


The only problem I have here is that "the creation of existing protocols" 
does not sound very logical. I suggest to remove "existing".


Cheers,
Michael



On 19. aug. 2014, at 17:32, Brian Trammell wrote:

> hi Toby,
> 
> On 19 Aug 2014, at 17:31, Toby Moncaster  wrote:
> 
>> 
>> I’d be happier with rephrasing it slightly as:
>> 
>> M18: Submit an Experimental document to the IESG specifying one or more 
>> methods to provide applications with the Transport Services identified by 
>> the WG.
> 
> Works for me.
> 
> Cheers,
> 
> Brian
> 
>> On 19 Aug 2014, at 16:27, Anna Brunstrom  wrote:
>> 
>>> On 2014-08-19 14:01, Brian Trammell wrote:
>>> 
>>> 
>>> 
 M18: Submit to the IESG an Experimental document specifying methods for 
 providing the Transport Services identified by the WG to applications. 
 How's that? Cheers, Brian 
>>> 
>>> Sounds good to me as well.
>>> 
>>> Cheers,
>>> Anna
>>> 
>>> 
>>> 
>>> ___
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>> 
>> ___
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS charter rev 20140818

[Michael Welzl]

On 19. aug. 2014, at 18:13, Toby Moncaster  wrote:

> 
> On 19 Aug 2014, at 17:00, Michael Welzl  wrote:
> 
>> +1.
>> 
>> 
>> Now, we can perhaps head on to the other charter changes related to this 
>> re-inserted milestone. I suggest the following undo's => I mean going back 
>> from THIS VERSION to the PREVIOUS VERSION, which is the version that went to 
>> IETF review:
>> 
>> THIS VERSION:
>> 2) Note that not all capabilities of IETF Transport protocols need to be 
>> exposed as Transport Services. This document will recommend the minimal set 
>> of Transport Services for inclusion in the abstract API. The resulting 
>> document will also provide guidance on making a choice among available 
>> mechanisms and protocols to obtain a certain Transport Service. 
>> 
>> PREVIOUS VERSION:
>> 2) Note that not all capabilities of IETF Transport protocols need to be 
>> exposed as Transport Services. This document will recommend the minimal set 
>> of Transport Services that support mechanisms must provide (such as those in 
>> work item 3). The resulting document will also provide guidance on making a 
>> choice among available mechanisms and protocols to obtain a certain 
>> Transport Service. 
>> 
> 
> I actually now think the previous version was a little clumsy. Also it sounds 
> really weird to start this item with a note… This makes me suspect this item 
> has been over-edited :)
> 
> Should we in fact say:
> 
> 2) Define the minimal set of Transport Services that must be provided by 
> mechanisms such as those to be specified in work item 3. The resulting 
> document will give guidance on choosing from available mechanisms and 
> protocols to provide a given Transport Service. Note that not all the 
> capabilities of IETF Transport protocols need to be exposed as Transport 
> Services.

I agree, much better, and it's not a semantic change, just language.


>> a bit below, for item 3 (last sentence):
>> 
>> THIS VERSION:
>> The associated milestone will be scheduled and work on this document will 
>> begin when the TAPS Transport Services have been specified. 
>> 
>> PREVIOUS VERSION:
>> Work on this document will begin when the TAPS Transport Services have been 
>> specified. 
> 
> Agreed since we will already have the milestone scheduled
> 
>> 
>> 
>> 
>> Not relevant to this particular discussion, but a suggested minor change 
>> nevertheless, for the out-of-scope list:
>> 
>> THIS VERSION:
>> - Extension, modification, or creation of existing IETF transport protocols 
>> 
>> PREVIOUS VERSION:
>> - Extension, modification, or creation of transport protocols 
>> 
>> 
>> The only problem I have here is that "the creation of existing 
>> protocols" does not sound very logical. I suggest to remove "existing”.
> 
> I’m guessing this was actually trying to cover 2 things: The creation of new 
> protocols and the extension or modification of existing protocols.

Yes, sure - but my point is that the word "existing" doesn't need to be there 
to convey that complete message.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] So, catching back up on the charter

[Michael Welzl]

Hi!

Below:

On 20. aug. 2014, at 05:30, Spencer Dawkins at IETF wrote:

> If I might make a couple of observations, and ask a question ...
> 
> Obs: document status:
> 
> This is actually not as nailed down as you might think. The IESG can, and 
> sometimes does, discuss the proper status for a document as late as IESG 
> Evaluation (I've been involved in one of those conversations today for a 
> document on this Thursday's telechat, although that doesn't happen every 
> telechat). It's good to start out with a goal in mind, but you actually have 
> some flexibility.
> 
> Obs: milestones in general:
> 
> Some folks might understand this better than I did when I became an AD, so I 
> apologize if I'm boring anyone, but the food chain works like this:
> 
> The charter text, and this doesn't include the milestones, is a matter for 
> the IESG, in consultation with the community. Rechartering goes back to the 
> IESG and to the community.
> 
> The milestone text is a matter for the AD, in consultation with the working 
> group. Additions, changes and deletions that are within scope of the agreed 
> charter don't go back to the IESG. We often stick document status in 
> milestones, and that doesn't go back to the IESG, either.
> 
> Milestone dates are a matter for the chairs, in consultation with the working 
> group. An AD might have opinions about how fast a working group should be 
> moving, but we don't approve milestone date changes.

Thanks a lot for all this information!


> The high-order bit is, you really want work described in the charter text 
> unless you want to go back to the IESG, but a working group can 
> add/change/remove milestones for work that's described in the charter at 
> whatever time seems appropriate. So, please look most carefully at the 
> non-milestone charter text, because that's what's most difficult to change.

There were some smaller changes to it in the last proposal that I suggested to 
undo in my previous email, because we do want to write that third document. 
Note that "undo" means "back to the version that was at IETF open review. I 
guess we should avoid semantic changes to that version unless we have very 
strong reasons.


> I would expect TAPS to add milestones when TAPS is ready to adopt an 
> individual draft (the draft name is one of the milestone attributes), and 
> work on it as a group. After that, the draft needs to reflect the editor's 
> understanding of what the working group thinks.
> 
> Q: So, my question: 
> 
> How important is it for the working group to begin work on the third 
> deliverable immediately?

I can't speak to "immediately" - logically, that work follows the first two 
items. Some people may be eager to start some of this work straight away, 
perhaps - I really don't know, this is for others to answer.

What I think is important to members of this group is that there is a 
dedication there that this document will be written. What you say above about 
milestones reflects their "internal" meaning, but I think there is another side 
to this: as someone external who *might* be interested in contributing to TAPS, 
I go to the IETF web site, click on TAPS, see e.g. the first two milestones and 
think "ah, these two lists is all they really develop". The most interesting 
bit is missing - so it's a boring, possibily useless group and I don't get 
involved.

Flexibility regarding how services really are provided is a key feature of 
TAPS, so it's absolutely natural for that third item to be experimental - but 
if we don't document an example way of implementing this, we really just have 
an empty shell. Similarly, if we don't put the milestone there now, we have an 
obviously boring group. That would be a bit like defining what DiffServ 
services do for the application without even hinting at how they could be 
implemented.

That's how I see things, at least...

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] So, catching back up on the charter

[Michael Welzl]

On 20. aug. 2014, at 16:46, Marie-Jose Montpetit  wrote:

> I may talk for myself but yes running code is one reason I am interested in 
> this. I have worked and still am working on architectures for this. But the 
> proof is in the pudding. As long as we cannot show a approach that works, 
> scales and is reliable we are doing research not engineering. And after 15 
> years of research I am ready for engineering :-)
> 
> /mjm
> From: Taps [taps-boun...@ietf.org] on behalf of Aaron Falk 
> [aaron.f...@gmail.com]
> Sent: Wednesday, August 20, 2014 10:16 AM
> To: Michael Welzl
> Cc: Spencer Dawkins at IETF; taps@ietf.org
> Subject: Re: [Taps] So, catching back up on the charter
> 
> First, apologies to the group for not explaining the reasoning for the 
> changes in the last draft.  
> 
> On Aug 20, 2014, at 3:15 AM, Michael Welzl  wrote:
> 
>> On 20. aug. 2014, at 05:30, Spencer Dawkins at IETF wrote:
>> 
>>> 
>>> The milestone text is a matter for the AD, in consultation with the working 
>>> group. Additions, changes and deletions that are within scope of the agreed 
>>> charter don't go back to the IESG. We often stick document status in 
>>> milestones, and that doesn't go back to the IESG, either.
>>> 
>>> Milestone dates are a matter for the chairs, in consultation with the 
>>> working group. An AD might have opinions about how fast a working group 
>>> should be moving, but we don't approve milestone date changes.
>> 
>> Thanks a lot for all this information!
> 
> Connecting the dots a bit here to make things more explicit: the removal of 
> the 3rd milestone was at Spencer’s request and in response to repeated IAB 
> guidance that work on the third deliverable was a possible distraction from 
> completing the 1st two.  The AD & IESG are the 'work managers' for the IETF 
> so their opinion counts on this topic.

IESG: is this indeed their opinion? If so, why didn't they say that during IESG 
review?
AD: in his email, Spencer essentially said that milestones don't matter much; I 
tried to explain why I think this milestone matters to us.
IAB: All I know is that IAB member Brian Trammell has written, to the list, 
yesterday: "Per the third point of the charter, I think we want to add the 
third milestone back, but make clear that the effort is experimental; something 
like:"

...add to this the fact that we're after IETF Open review, where this charter 
has been looked at and agreed upon by a lot of folks who might no longer agree 
if we do a significant content change, then this seems just weird to me.


>>> The high-order bit is, you really want work described in the charter text 
>>> unless you want to go back to the IESG, but a working group can 
>>> add/change/remove milestones for work that's described in the charter at 
>>> whatever time seems appropriate. So, please look most carefully at the 
>>> non-milestone charter text, because that's what's most difficult to change.
>> 
>> There were some smaller changes to it in the last proposal that I suggested 
>> to undo in my previous email, because we do want to write that third 
>> document. Note that "undo" means "back to the version that was at IETF open 
>> review. I guess we should avoid semantic changes to that version unless we 
>> have very strong reasons.
> 
> I’ll address that in the relevant thread. Keep in mind that the charter is 
> now being reviewed by folks outside the group so it is not surprising that 
> there are new questions coming up (particularly about clarity).  My 
> experience is that this broader review is often important for making explicit 
> some implied context.  I’ve tried to add detail in my changes but maybe I’ve 
> gotten it wrong.  If so, that’s useful to getting us all on the same page.
> 
>> 
>> 
>>> I would expect TAPS to add milestones when TAPS is ready to adopt an 
>>> individual draft (the draft name is one of the milestone attributes), and 
>>> work on it as a group. After that, the draft needs to reflect the editor's 
>>> understanding of what the working group thinks.
>>> 
>>> Q: So, my question: 
>>> 
>>> How important is it for the working group to begin work on the third 
>>> deliverable immediately?
>> 
>> I can't speak to "immediately" - logically, that work follows the first two 
>> items. Some people may be eager to start some of this work straight away, 
>> perhaps - I really don't know, this is for others to answer.
>> 
>> What I think is important to members of this group is

Re: [Taps] TAPS charter rev 20140818

[Michael Welzl]

On 20. aug. 2014, at 16:54, Aaron Falk  wrote:

> We have a problem that folks who have not been part of the discussion from 
> the beginning (like myself) need additional clarity when talking about 
> “support mechanisms”.  I’ve tried to add some in the descriptions of docs 2 
> and 3 but apparently it needs refinement.  The current charter says:
> 
>> 2) Note that not all capabilities of IETF Transport protocols need to be 
>> exposed as Transport Services. This document will recommend the minimal set 
>> of Transport Services for inclusion in the abstract API. The resulting 
>> document will also provide guidance on making a choice among available 
>> mechanisms and protocols to obtain a certain Transport Service. 
> 
> Some folks on the list have proposed the following alternative:
> 
>>> 2) Define the minimal set of Transport Services that must be provided by 
>>> mechanisms such as those to be specified in work item 3. The resulting 
>>> document will give guidance on choosing from available mechanisms and 
>>> protocols to provide a given Transport Service. Note that not all the 
>>> capabilities of IETF Transport protocols need to be exposed as Transport 
>>> Services.
> 
> The problem here is that we haven’t described what work item 3 is.  I’d 
> prefer a statement that stands on its own. If you don’t like my text above, 
> please propose something you like better.

Work item 3 is just the third item in the list, where the text you cite above 
is the 2nd item. If that isn't clear enough, we could replace the sentence 
above them:

The Working Group will:

with:

The Working Group will consider the following three work items:

In my opinion, the clearest version is in the charter that went to IETF open 
review:
***
- Specify the subset of those Transport Services, as identified in 
  item 1, that end systems supporting TAPS will provide, and give
  guidance on choosing among available mechanisms and protocols.
***

which you changed into the "work item 3" text on 26 July, i.e. during IETF open 
review, and documented in the diff file: "charter-diff-20140722e-20140726.pdf" 
that you sent to the list, and justified with:

"I've been working on a few changes that I think clarify the charter, 
particularly the document goals.  Since I wasn't part of the initial 
discussions I may have misunderstood where there is agreement.  For example, 
the role of the second document seems to be really about getting consensus on 
some requirements for the third."

I couldn't see any other input leading to this change. My suggestion would be 
to undo it.


> In the third doc I tried to be a little more concrete about what a “support 
> mechanism” is:
> 
>> 3) Specify experimental support mechanisms to provide the Transport Services 
>> identified in work item 2. This document will explain how to select and 
>> engage an appropriate protocol and how to discover which protocols are 
>> available for a given connection. Further, it will provide a basis for 
>> incremental deployment. The associated milestone will be scheduled and work 
>> on this document will begin when the TAPS Transport Services have been 
>> specified. 
> 
> 
> Trying to piece an alternate phrasing from the thread I get:
> 
>>> 3) Submit to the IESG an Experimental document exploring abstract 
>>> interfaces to Transport Services and defining an experiment to evaluate 
>>> such interfaces for incremental deployability.  The associated milestone 
>>> will be scheduled and work on this document will begin when the TAPS 
>>> Transport Services have been specified. 
> 
> This seems less concrete to me.  I like “select and engage protocols” but I’d 
> like to hear more input from the group.

What we did mean when we wrote this was "Happy Eyeballs ++". The Happy Eyeballs 
folks are on the list and have stated interest in continuing it here; there 
were ideas (all in the list archives..) on making it more scalable by using it 
later, i.e. no need to send out so much SYN-style traffic so fast; caching 
information; first asking the other side what protocols it supports to only 
test those that really must be tested. How to state this more clearly? Not 
sure. I think we were all quite happy with the "select and engage an 
appropriate protocol" sentence.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS charter rev 20140818

[Michael Welzl]

Hi,


On 21. aug. 2014, at 16:29, Aaron Falk wrote:

> 
> On Aug 20, 2014, at 6:00 PM, Michael Welzl  wrote:
> 
>> 
>> 
>> In my opinion, the clearest version is in the charter that went to IETF open 
>> review:
>> ***
>> - Specify the subset of those Transport Services, as identified in 
>>   item 1, that end systems supporting TAPS will provide, and give
>>   guidance on choosing among available mechanisms and protocols.
>> ***
>> 
>> which you changed into the "work item 3" text on 26 July, i.e. during IETF 
>> open review, and documented in the diff file: 
>> "charter-diff-20140722e-20140726.pdf" that you sent to the list, and 
>> justified with:
>> 
>> "I've been working on a few changes that I think clarify the charter, 
>> particularly the document goals.  Since I wasn't part of the initial 
>> discussions I may have misunderstood where there is agreement.  For example, 
>> the role of the second document seems to be really about getting consensus 
>> on some requirements for the third."
>> 
>> I couldn't see any other input leading to this change. My suggestion would 
>> be to undo it.
> 
> So, I admit that my understanding has been evolving over the course of the 
> charter discussion and I’m perfectly willing to undo prior ‘improvements’ 
> that I’ve made.   Anyone else want to weigh in?  
> 
> 
> 
>> 
>> 
>>> In the third doc I tried to be a little more concrete about what a “support 
>>> mechanism” is:
>>> 
>>>> 3) Specify experimental support mechanisms to provide the Transport 
>>>> Services identified in work item 2. This document will explain how to 
>>>> select and engage an appropriate protocol and how to discover which 
>>>> protocols are available for a given connection. Further, it will provide a 
>>>> basis for incremental deployment. The associated milestone will be 
>>>> scheduled and work on this document will begin when the TAPS Transport 
>>>> Services have been specified. 
>>> 
>>> 
>>> Trying to piece an alternate phrasing from the thread I get:
>>> 
>>>>> 3) Submit to the IESG an Experimental document exploring abstract 
>>>>> interfaces to Transport Services and defining an experiment to evaluate 
>>>>> such interfaces for incremental deployability.  The associated milestone 
>>>>> will be scheduled and work on this document will begin when the TAPS 
>>>>> Transport Services have been specified. 
>>> 
>>> This seems less concrete to me.  I like “select and engage protocols” but 
>>> I’d like to hear more input from the group.
>> 
>> What we did mean when we wrote this was "Happy Eyeballs ++". The Happy 
>> Eyeballs folks are on the list and have stated interest in continuing it 
>> here; there were ideas (all in the list archives..) on making it more 
>> scalable by using it later, i.e. no need to send out so much SYN-style 
>> traffic so fast; caching information; first asking the other side what 
>> protocols it supports to only test those that really must be tested. How to 
>> state this more clearly? Not sure. I think we were all quite happy with the 
>> "select and engage an appropriate protocol" sentence.
> 
> Ah!  I thought there was some objection to ‘select and engage’.  So, is the 
> version from the last charter rev acceptable?
> 
> 3) Specify experimental support mechanisms to provide the Transport Services 
> identified in work item 2. This document will explain how to select and 
> engage an appropriate protocol and how to discover which protocols are 
> available for a given connection. Further, it will provide a basis for 
> incremental deployment. The associated milestone will be scheduled and work 
> on this document will begin when the TAPS Transport Services have been 
> specified. 

Yes, except that I have requested and still request to remove the last sentence 
("The associated milestone will be scheduled and work on this document will 
begin when the TAPS Transport Services have been specified. "), but this is 
what you address below.


> Addressing the matter of whether to include a scheduled milestone for the 
> third document or not, let me make a suggestion.  I acknowledge and respect 
> that there are several folks in the group invested in seeing work take place 
> on the ‘engage & select’ mechanisms and I believe it is in the IETF’s 
> interests in seeing that work mature.  (Indeed, I hope there are teams off 
> busily working on implementatio

Re: [Taps] TAPS charter rev 20140826

[Michael Welzl]

Hi,

Thanks from me too! I'm also fine with it, great job!


Here are a few SUPER small nits, and I think none of them is necessary or 
"meaningful", it's just cosmetics, from carefully reading the whole thing yet 
again:

- par2: there's a double "and" - I'd replace "...and UDP-Lite and the 
LEDBAT..." with "..., UDP-Lite and the LEDBAT..."
- par 3: I think it would read better if "also" was inserted in the last 
sentence, replacing "Layering decisions must be made" was replace with 
"Layering decisions must also be made", but I'm not a native speaker...
- par 5: (starting with "Because even TCP and UDP"): isn't this paragraph 
logically connected to the previous one? I think they could be merged. Also 
(again, not a native speaker, so not sure) I'd replace "Because even TCP and 
UDP" with "Since even TCP and UDP" just to avoid having two sentences start 
with "Because..." so close to each other. But that's really not important and 
just style.

That's it!

Cheers,
Michael



On 27. aug. 2014, at 00:27, Aaron Falk wrote:

> See charter rev below.  Change highlights: 
> - reverted to earlier 2nd doc description
> - added back 3rd doc milestone
> - minor cleanup
> 
> I'm only attaching the diff to the last rev because it's rather a pain to 
> generate the other one.
> 
> --aaron
> 
> Transport Services (taps) 
> 
> 
> Most Internet applications make use of the Transport Services provided by TCP 
> (a reliable, in-order stream protocol) or UDP (an unreliable datagram 
> protocol). We use the term "Transport Service" to mean an end-to-end facility 
> provided by the transport layer that can only be correctly provided with 
> information from the application. This information may be provided at design 
> time, compile time, or run time and may include guidance from the application 
> on whether the facility in question is required or simply a preference by the 
> application. Four examples of Transport Services are reliable delivery, no 
> guarantee of order preservation, content privacy to in-path devices, and 
> minimal latency.
> 
> 
> Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and UDP-Lite and 
> the LEDBAT congestion control mechanism extend the set of available Transport 
> Services beyond those provided to applications by TCP and UDP. For example, 
> SCTP provides potentially faster (than TCP) reliable delivery for 
> applications because it can accept blocks of data out of order, and LEDBAT 
> provides low-priority "scavenger" communication. 
> 
> However, application programmers face difficulty when they use protocols 
> other than TCP or UDP. Most network stacks ship with only TCP and UDP as 
> transport protocols.  Many firewalls only pass TCP and UDP and some only 
> support HTTP over TCP. As a result, using other transport protocols or 
> building a new protocol over raw sockets risks having an application not work 
> in many environments. Applications, therefore, must always be able to fall 
> back to TCP or UDP, or even HTTP in many cases, and once the application 
> programmer has committed to making an application work on TCP or UDP or HTTP, 
> there is little incentive to try other transport protocols before falling 
> back. Further, different protocols can provide the same services in different 
> ways. Layering decisions must be made (for example, whether a protocol is 
> used natively or tunneled through UDP). 
> 
> Because of these complications, programmers often resort to either using TCP 
> or HTTP or implementing their own customized "transport services" over UDP. 
> When application developers re-implement transport features already available 
> elsewhere they open the door to problems that simply using TCP would have 
> avoided and ensure that the applications can't benefit from other transport 
> protocols as they become available. 
> 
> Because even TCP and UDP are not guaranteed to work in all environments 
> today, some programmers simply give up on using TCP or UDP directly, relying 
> instead on "HTTP as a Substrate". BCP 56 identified many issues with this 
> strategy, but assuming that if "any protocol is available on a given network 
> path and on the hosts that will be communicating, that protocol will be HTTP" 
> is a reasonable strategy for today's Internet. The IESG has agreed with this 
> viewpoint enough to publish the WebSocket protocol on the standards track. 
> 
> The goal of the TAPS working group is to help application and network stack 
> programmers by describing an (abstract) interface for applications to make 
> use of Transport Services. The Working Group deliverables emphasize defining 
> Transport Services that are important to applications followed by 
> experimental mechanisms to a) determine if the protocols to provide the 
> requested services are available on the end points and supported along the 
> path in the network and b) fall back, i.e., select alternate, possibly 
> less-preferred, protocols when desired protocols are not availa

Re: [Taps] TAPS charter rev 20140826

[Michael Welzl]

Great, thanks!

Cheers,
Michael


On 27. aug. 2014, at 16:27, Aaron Falk wrote:

> 
> 
> 
> On Wed, Aug 27, 2014 at 3:01 AM, Michael Welzl  wrote:
> Hi,
> 
> Thanks from me too! I'm also fine with it, great job!
> 
> 
> Here are a few SUPER small nits, and I think none of them is necessary or 
> "meaningful", it's just cosmetics, from carefully reading the whole thing yet 
> again:
> 
> - par2: there's a double "and" - I'd replace "...and UDP-Lite and the 
> LEDBAT..." with "..., UDP-Lite and the LEDBAT..."
> 
> This is an english thing.  We're adding a list of protocols ending in 
> UDP-Lite to a congestion control mechanism (LEDBAT).  I think it is correct 
> as written.  
>  
> - par 3: I think it would read better if "also" was inserted in the last 
> sentence, replacing "Layering decisions must be made" was replace with 
> "Layering decisions must also be made", but I'm not a native speaker...
> 
> Yup.  Fixed.
>  
> - par 5: (starting with "Because even TCP and UDP"): isn't this paragraph 
> logically connected to the previous one? I think they could be merged. Also 
> (again, not a native speaker, so not sure) I'd replace "Because even TCP and 
> UDP" with "Since even TCP and UDP" just to avoid having two sentences start 
> with "Because..." so close to each other. But that's really not important and 
> just style.
> 
> Combined the paras.  See below.
> 
> 
> Transport Services (taps) 
> 
> Most Internet applications make use of the Transport Services provided by TCP 
> (a reliable, in-order stream protocol) or UDP (an unreliable datagram 
> protocol). We use the term "Transport Service" to mean an end-to-end facility 
> provided by the transport layer that can only be correctly provided with 
> information from the application. This information may be provided at design 
> time, compile time, or run time and may include guidance from the application 
> on whether the facility in question is required or simply a preference by the 
> application. Four examples of Transport Services are reliable delivery, no 
> guarantee of order preservation, content privacy to in-path devices, and 
> minimal latency.
> 
> 
> Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and UDP-Lite and 
> the LEDBAT congestion control mechanism extend the set of available Transport 
> Services beyond those provided to applications by TCP and UDP. For example, 
> SCTP provides potentially faster (than TCP) reliable delivery for 
> applications because it can accept blocks of data out of order, and LEDBAT 
> provides low-priority "scavenger" communication. 
> 
> However, application programmers face difficulty when they use protocols 
> other than TCP or UDP. Most network stacks ship with only TCP and UDP as 
> transport protocols.  Many firewalls only pass TCP and UDP and some only 
> support HTTP over TCP. As a result, using other transport protocols or 
> building a new protocol over raw sockets risks having an application not work 
> in many environments. Applications, therefore, must always be able to fall 
> back to TCP or UDP, or even HTTP in many cases, and once the application 
> programmer has committed to making an application work on TCP or UDP or HTTP, 
> there is little incentive to try other transport protocols before falling 
> back. Further, different protocols can provide the same services in different 
> ways. Layering decisions must also be made (for example, whether a protocol 
> is used natively or tunneled through UDP). 
> 
> Because of these complications, programmers often resort to either using TCP 
> or HTTP or implementing their own customized "transport services" over UDP. 
> When application developers re-implement transport features already available 
> elsewhere they open the door to problems that simply using TCP would have 
> avoided and ensure that the applications can't benefit from other transport 
> protocols as they become available. And, since even TCP and UDP are not 
> guaranteed to work in all environments today, some programmers simply give up 
> on using TCP or UDP directly, relying instead on "HTTP as a Substrate". BCP 
> 56 identified many issues with this strategy, but assuming that if "any 
> protocol is available on a given network path and on the hosts that will be 
> communicating, that protocol will be HTTP" is a reasonable strategy for 
> today's Internet. The IESG has agreed with this viewpoint enough to publish 
> the WebSocket protocol on the standards track. 
> 
> The goal of the TAPS working g

Re: [Taps] WG Action: Formed Transport Services (taps)

[Michael Welzl]

Hooray! Thanks everyone for your efforts!!


On 24. sep. 2014, at 01:33, The IESG wrote:

> A new IETF working group has been formed in the Transport Area. For
> additional information please contact the Area Directors or the WG Chair.
> 
> Transport Services (taps)
> 
> Current Status: Proposed WG
> 
> Chairs:
>  Aaron Falk 
> 
> Assigned Area Director:
>  Spencer Dawkins 
> 
> Mailing list
>  Address: taps@ietf.org
>  To Subscribe: https://www.ietf.org/mailman/listinfo/taps
>  Archive: http://www.ietf.org/mail-archive/web/taps/
> 
> Charter:
> 
> Most Internet applications make use of the Transport Services 
> provided by TCP (a reliable, in-order stream protocol) or UDP 
> (an unreliable datagram protocol).   We use the term "Transport
> Service" to mean an end-to-end facility provided by the
> transport layer. That service can only be provided correctly if
> information is supplied from the application. The application may
> determine the information to be supplied at design time, 
> compile time, or run time and may include guidance on whether 
> the facility  in question is required or simply a preference by the 
> application. Four examples of Transport Services are reliable 
> delivery, ordered delivery of data, content privacy to in-path 
> devices, and minimal latency.
> 
> Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and 
> UDP-Lite and the LEDBAT congestion control mechanism extend the 
> set of available Transport Services beyond those provided to 
> applications by TCP and UDP. For example, SCTP provides potentially 
> faster reliable delivery for applications than TCP because it can 
> accept blocks of data out of order, and LEDBAT provides low-priority 
> "scavenger" communication. 
> 
> However, application programmers face difficulty when they use 
> protocols other than TCP or UDP. Most network stacks ship with only 
> TCP and UDP as transport protocols.  Many firewalls only pass TCP 
> and UDP and some  only allow TCP  when it carries HTTP as its payload. 
> As a result, using other transport protocols or building a new protocol 
> over raw sockets risks having an application not work in many 
> environments. Applications, therefore, must always be able to fall back 
> to TCP or UDP, or even to using HTTP as a transport substrate in some 
> cases, and once the application programmer has committed 
> to making an application work on TCP or UDP or HTTP, there is little 
> incentive to try other transport protocols before falling back. 
> Further, different protocols can provide the same services in different 
> ways. Layering decisions must also be made (for example, whether a 
> protocol is used natively or tunneled through UDP). 
> 
> Because of these complications, programmers often resort to either 
> using TCP or HTTP or implementing their own customized "transport 
> services" over UDP. When application developers re-implement transport 
> features already available elsewhere they open the door to problems 
> that simply using TCP would have avoided and ensure that the 
> applications can't benefit from other transport protocols as they 
> become available. And, since even TCP and UDP are not guaranteed to 
> work in all environments today, some programmers simply give up on 
> using TCP or UDP directly, relying instead on "HTTP as a Substrate". 
> BCP 56 identified many issues with this strategy, but assuming that 
> if "any protocol is available on a given network path and on the hosts 
> that will be communicating, that protocol will be HTTP" is a reasonable 
> strategy for today's Internet. The IESG has agreed with this viewpoint 
> enough to publish the WebSocket protocol on the standards track. 
> 
> The goal of the TAPS working group is to help application and network 
> stack programmers by describing an (abstract) interface for applications 
> to make use of Transport Services. The Working Group deliverables 
> emphasize defining Transport Services that are important to applications 
> followed by experimental mechanisms to a) determine if the protocols to 
> provide the requested services are available on the end points and 
> supported along the path in the network and b) fall back, i.e., select 
> alternate, possibly less-preferred, protocols when desired protocols 
> are not available. The Working Group will not define a richer set of 
> Transport Services for applications, although the TAPS deliverables 
> could inform proposals for future chartered work on Transport Services. 
> 
> The Working Group will:
> 
> 1) Define a set of Transport Services, identifying the 
>   services provided by existing IETF protocols and congestion 
>   control mechanisms. As a starting point, the working group will 
>   consider services used 
>   between two endpoints.
> 
> 2) Specify the subset of those Transport Services, as identified 
>   in item 1, that end systems supporting TAPS will provide, and 
>   give guidance on 

Re: [Taps] terminology for draft-fairhurst-taps-transports

[Michael Welzl]

On 4. nov. 2014, at 14:14, Brian Trammell wrote:

> Greetings, all,
> 
> As promised, here's an initial suggestion for terminology in 
> draft-fairhurst-taps-transports, compatible with but elaborating on the 
> minimal terminology in the charter, which would we would propose applies to 
> all TAPS work derived from this document:
> 
> 
> Transport Service: 
> An end-to-end facility provided by the transport layer that impacts the 
> design, operation, or deployment of the application using it. Example 
> Transport Services include reliable delivery of data, ordered delivery of 
> data, confidentiality of data with respect to in-path devices, or latency 
> guarantees for data transport. 
> 
> 
> Transport Service Composition: 
> A set of Transport Services taken together to meet the requirements of an 
> application for a given end-to-end interaction. Note that some potential sets 
> of Transport Services  given transport service may preclude the simultaneous 
> use of other transport services for a given end-to-end interaction (e.g. 
> "reliable delivery" and "time-dependent expiry of unacknowledged messages" as 
> per SCTP-PR are mutually exclusive). An example of a Transport Service 
> Composition would be that provided by the BSD SOCK_STREAM socket type: 
> reliable, ordered, non-boundary-perserving, stream-oriented transport, with 
> limited out of band capability. 
> 
> 
> Transport Instance: 
> A Transport Instance is an arrangement of transport protocols, potentially 
> encapsulated, and configurations thereof that implement a Transport Service 
> Composition. A given Transport Service Composition may be implemented by 
> multiple Instances (e.g., SOCK_STREAM can be implemented atop TCP, SCTP, or 
> SCTP over UDP). 
> 
> 
> Application: 
> In this and subsequent documents, an Application is defined as an entity that 
> uses the transport layer to interact with a remote Application according to 
> some set of requirements which can be met by Transport Services.
> 
> 
> Here I'm pointedly leaving "transport protocol" undefined, mainly so as to 
> sidestep marginally productive conversations about how many transport 
> protools SCTP over DTLS over UDP is. The exact implementation of a Transport 
> Service Composition would appear to be a matter for our third deliverable 
> anyway. :)
> 
> It's not perfect but it's a start. Thoughts?

We can and will probably debate this to death, but before that happens I'll 
say: I think this is a very good starting point, thanks!

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

[Michael Welzl]

Hi,

Thanks for this update!

A question:

> We've posted a -01 rev of the TAPS transports document. We believe that the 
> format and level of detail for the TCP section is about what we're targeting 
> for each of the other sections, but this is still open to discussion.

Why is Nagle not a part of the protocol components and interface description? 
It’s mentioned in the protocol description above, and it’s something that an 
application decides.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

[Michael Welzl]

> On 19. des. 2014, at 20.05, Brian Trammell  wrote:
> 
> 
>> On 18 Dec 2014, at 22:37, Michael Welzl  wrote:
>> 
>> Hi,
>> 
>> Thanks for this update!
>> 
>> A question:
>> 
>>> We've posted a -01 rev of the TAPS transports document. We believe that the 
>>> format and level of detail for the TCP section is about what we're 
>>> targeting for each of the other sections, but this is still open to 
>>> discussion.
>> 
>> Why is Nagle not a part of the protocol components and interface 
>> description? It’s mentioned in the protocol description above, and it’s 
>> something that an application decides.
> 
> Simple omission.
> 
> Should we make an attempt to give this (as a component) a generic name? 
> "Selectable sender side buffering"? Or can we just call it simply "Nagle"?

In http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf 
we took SCTP's term for the same function because we found it more meaningful 
than "Nagle": Application PDU Bundling.  I like that - it's also perhaps useful 
to folks to reuse terminology when we mean the exact same thing.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

[Michael Welzl]

> On 19. des. 2014, at 20.29, Michael Welzl  wrote:
> 
> 
>> On 19. des. 2014, at 20.05, Brian Trammell  wrote:
>> 
>> 
>>> On 18 Dec 2014, at 22:37, Michael Welzl  wrote:
>>> 
>>> Hi,
>>> 
>>> Thanks for this update!
>>> 
>>> A question:
>>> 
>>>> We've posted a -01 rev of the TAPS transports document. We believe that 
>>>> the format and level of detail for the TCP section is about what we're 
>>>> targeting for each of the other sections, but this is still open to 
>>>> discussion.
>>> 
>>> Why is Nagle not a part of the protocol components and interface 
>>> description? It’s mentioned in the protocol description above, and it’s 
>>> something that an application decides.
>> 
>> Simple omission.
>> 
>> Should we make an attempt to give this (as a component) a generic name? 
>> "Selectable sender side buffering"? Or can we just call it simply "Nagle"?
> 
> In http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf 
> we took SCTP's term for the same function because we found it more meaningful 
> than "Nagle": Application PDU Bundling.  I like that - it's also perhaps 
> useful to folks to reuse terminology when we mean the exact same thing.

Very sorry for writing a separate email! But having this open made me notice 
another one: "error detection" (or "integrity check", whatever you prefer). 
There's a checksum, it can't be disabled, it's covering the full data. 
Different from some other protocols.

And another: flow control. Mentioned in the text, but should be a component 
because the feature that it implements is meaningful to an application (if 
there's no flow control, you may have to take care of it yourself).

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

[Michael Welzl]

> On 20. des. 2014, at 01.13, Brian Trammell  wrote:
> 
> hi Michael,
> 
>> On 19 Dec 2014, at 10:29, Michael Welzl  wrote:
>> 
>> 
>>> On 19. des. 2014, at 20.05, Brian Trammell  wrote:
>>> 
>>> 
>>>> On 18 Dec 2014, at 22:37, Michael Welzl  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Thanks for this update!
>>>> 
>>>> A question:
>>>> 
>>>>> We've posted a -01 rev of the TAPS transports document. We believe that 
>>>>> the format and level of detail for the TCP section is about what we're 
>>>>> targeting for each of the other sections, but this is still open to 
>>>>> discussion.
>>>> 
>>>> Why is Nagle not a part of the protocol components and interface 
>>>> description? It’s mentioned in the protocol description above, and it’s 
>>>> something that an application decides.
>>> 
>>> Simple omission.
>>> 
>>> Should we make an attempt to give this (as a component) a generic name? 
>>> "Selectable sender side buffering"? Or can we just call it simply "Nagle"?
>> 
>> In 
>> http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf 
>> we took SCTP's term for the same function because we found it more 
>> meaningful than "Nagle": Application PDU Bundling.  I like that - it's also 
>> perhaps useful to folks to reuse terminology when we mean the exact same 
>> thing.
> 
> So I'd argue that (1) this isn't *exactly* the same thing, as the interface 
> to SOCK_SEQPACKET has application PDU preservation as an explicit part of the 
> API contract,

Ahh… let me see if I get this right: your point is, in terms of the actual 
function, the difference is:
SCTP: app can give app PDUs 1, 2, 3, 4, each 450 bytes into the buffer, out of 
which 3 may fit into a 1460-byte segment and get shipped together after an RTT, 
wasting space for 110 bytes.
TCP: app gives the same app PDUs into the send buffer, where they are treated 
as a byte stream and a segment of 1460 bytes can be exactly filled.

If that’s it, then I agree, that’s functionally different.


> while SOCK_STREAM does not, but (2) that at the protocol level it might as 
> well be, so "bundling" is exactly the right word. How about "sender segment 
> bundling" for TCP?

Ok by me, but we'll have to be careful later: when trying to unify access to 
these services across protocols, the two different names for SCTP and TCP may 
make it seem like they are entirely different in functionality when in fact 
they are not much different indeed: TCP’s Nagle operates on single bytes, 
SCTP’s app PDU bundling operates on potentially larger blocks of a given size?

What about: “data bundling (1 byte)”, as opposed to “data bundling (application 
PDU)”  for SCTP ?


Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

[Michael Welzl]

> On 20. des. 2014, at 09.24, Michael Tuexen  wrote:
> 
> On 19 Dec 2014, at 23:08, Michael Welzl  <mailto:mich...@ifi.uio.no>> wrote:
> 
>> 
>>> On 20. des. 2014, at 01.13, Brian Trammell  wrote:
>>> 
>>> hi Michael,
>>> 
>>>> On 19 Dec 2014, at 10:29, Michael Welzl  wrote:
>>>> 
>>>> 
>>>>> On 19. des. 2014, at 20.05, Brian Trammell  wrote:
>>>>> 
>>>>> 
>>>>>> On 18 Dec 2014, at 22:37, Michael Welzl  wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Thanks for this update!
>>>>>> 
>>>>>> A question:
>>>>>> 
>>>>>>> We've posted a -01 rev of the TAPS transports document. We believe that 
>>>>>>> the format and level of detail for the TCP section is about what we're 
>>>>>>> targeting for each of the other sections, but this is still open to 
>>>>>>> discussion.
>>>>>> 
>>>>>> Why is Nagle not a part of the protocol components and interface 
>>>>>> description? It’s mentioned in the protocol description above, and it’s 
>>>>>> something that an application decides.
>>>>> 
>>>>> Simple omission.
>>>>> 
>>>>> Should we make an attempt to give this (as a component) a generic name? 
>>>>> "Selectable sender side buffering"? Or can we just call it simply "Nagle"?
>>>> 
>>>> In 
>>>> http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf 
>>>> we took SCTP's term for the same function because we found it more 
>>>> meaningful than "Nagle": Application PDU Bundling.  I like that - it's 
>>>> also perhaps useful to folks to reuse terminology when we mean the exact 
>>>> same thing.
>>> 
>>> So I'd argue that (1) this isn't *exactly* the same thing, as the interface 
>>> to SOCK_SEQPACKET has application PDU preservation as an explicit part of 
>>> the API contract,
>> 
>> Ahh… let me see if I get this right: your point is, in terms of the actual 
>> function, the difference is:
>> SCTP: app can give app PDUs 1, 2, 3, 4, each 450 bytes into the buffer, out 
>> of which 3 may fit into a 1460-byte segment and get shipped together after 
>> an RTT, wasting space for 110 bytes.
> I guess the 1460 are related to the IP and TCP header.

Silly me, yes of course I was thinking of TCP while actually talking about SCTP 
 :)


> For SCTP it would be 
> 20 bytes for IPv4 header,
> 12 bytes for the SCTP common header,
> 16 bytes for the DATA chunk header,
> 450 byte payload
> 16 bytes for the DATA chunk header,
> 450 byte payload
> 16 bytes for the DATA chunk header,
> 450 byte payload
> This gives 1430 bytes.
> So 70 bytes are left. The SCTP implementation can just leave them unused or, 
> and that is the point I want to make,
> add
> 16 bytes for the DATA chunk header
> 54 bytes (the initial 54 bytes of the fourth 450 bytes user message)
> Then the frame is completely used.

Ah, ok. I wasn’t aware of that. Is that decision up to the application?


>> TCP: app gives the same app PDUs into the send buffer, where they are 
>> treated as a byte stream and a segment of 1460 bytes can be exactly filled.
>> 
>> If that’s it, then I agree, that’s functionally different.
>> 
>> 
>>> while SOCK_STREAM does not, but (2) that at the protocol level it might as 
>>> well be, so "bundling" is exactly the right word. How about "sender segment 
>>> bundling" for TCP?
>> 
>> Ok by me, but we'll have to be careful later: when trying to unify access to 
>> these services across protocols, the two different names for SCTP and TCP 
>> may make it seem like they are entirely different in functionality when in 
>> fact they are not much different indeed: TCP’s Nagle operates on single 
>> bytes, SCTP’s app PDU bundling operates on potentially larger blocks of a 
>> given size?
>> 
>> What about: “data bundling (1 byte)”, as opposed to “data bundling 
>> (application PDU)”  for SCTP ?
> I wouldn't object against using the term Nagle also for SCTP. It refers to 
> delaying the initial
> sending of user message in case of outstanding data. Bundling in SCTP might 
> happen even when
> Nagle is turned off, for example when you retransmit messages.

I like Brian’s proposal of unqualified “data bundling” - it is just a bit more 
meaningful than “Nagle” (despite the historic relevance of the latter).

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

[Michael Welzl]

> On 1. feb. 2015, at 08.51, go...@erg.abdn.ac.uk wrote:
> 
>> Would it make sense to include statements about latency?
>> 
> I think if we come to think about the API that could be presented by TAPS
> to the application, we'll need to focus on what characteristics the Apps
> expect from the network. Low latency is clearly one service that many apps
> will desire.

Then again, we may decide to reserve this for doc #2?
My thinking was that this should be the home of such generalization (which is 
one way to reduce the number of services exposed).


>> We recently had a discussion with one of our suppliers about application
>> layer timeouts that fired while the request was still stuck in the send
>> queue.
>> 
>> There were statements like 'UDP never queues' or 'we can't control the TCP
>> send buffer size'.
>> 
>> Maybe some general discussion of the interactions between application
>> layer
>> timers and transport layer retransmission strategies (like Nagle) would be
>> useful.
>> 
> I agree, some words on the Latency introduced by mechanisms would be good.

If you go that way, here’s one of the drafts preceding the BOF, and written for 
the purpose of this group, as possible for input:
http://tools.ietf.org/html/draft-petlund-latency-transport-services-00 


Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

[Michael Welzl]

> On 2. feb. 2015, at 19.03, Joe Touch  wrote:
> 
> 
> 
> On 1/30/2015 7:20 AM, Wolfgang Beck wrote:
>> Would it make sense to include statements about latency?
> 
> Yes, but I'm not sure what at this point.
> 
> Latency is a multidimensional property; it depends on the interaction of a 
> variety of factors, so even if you wanted to have the application say "I want 
> low latency", that's not well-defined.
> 
>> We recently had a discussion with one of our suppliers about application
>> layer timeouts that fired while the request was still stuck in the send
>> queue.
>> 
>> There were statements like 'UDP never queues' or 'we can't control the
>> TCP send buffer size'.
> 
> UDP doesn't queue, but UDP implementations do. The interface between 
> applications and UDP does too.
> 
>> Maybe some general discussion of the interactions between application
>> layer timers and transport layer retransmission strategies (like Nagle)
>> would be useful.
> 
> That's a really good example of how poorly understood this problem is.
> 
> Nagle should be off for multi-byte transaction protocols using TCP, but TCP 
> isn't a low-latency protocol to start with. Nagle is as much about minimizing 
> short packets as it is about the effect on transaction interaction delay.
> 
> However, it's also well-understood that Nagle should be off for transactions 
> involving multiple bytes - whether that's because the transaction itself is 
> larger (e.g., web transactions) or because the character encoding is larger 
> (e.g., telnet using Unicode rather than ASCII). (J. Heidemann, K. Obraczka, 
> J. Touch, “Modeling the Performance of HTTP Over Several Transport 
> Protocols,” IEEE/ACM Transactions on Networking, V5, N5, Oct. 1997, 
> pp.616-630.)
> 
> The fact that TCP doesn't have a way for the application to signal a 
> transaction boundary (it's a byte stream model) means that the entire issue 
> of latency of transactions over TCP is questionable.
> 
> --
> 
> So, in summary, yes, an API from transport to the service layer should have 
> an indication of latency, but this is a very complex, *bidirectional* 
> interface. So other than saying that this should be addressed in the future, 
> anything said now will be at best woefully incomplete, and at worst, wrong.

I’m for keeping this first document correct and complete.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] agenda topic: application - transport abstractions

[Michael Welzl]

> On 05 Feb 2015, at 00:29, Marie-Jose Montpetit  wrote:
> 
>> snip/snip
> 
>> In summary, we need a better way to describe the services we want before 
>> we'll ever be able to expect the transport to handle them properly.
>> 
> I totally agree.

We've been around the "let's specify what the application wants, not what 
protocols can do" block a couple of times prior to creation of this group. We 
started and ended with the bottom-up'ish plan that is in the charter now.

So, if you take a look at item #2 in the charter, it's rather unclear what that 
item is going to look like, and in particular how we'll arrive there:

"2) Specify the subset of those Transport Services, as identified 
in item 1, that end systems supporting TAPS will provide, and 
give guidance on choosing among available mechanisms and 
protocols. Note that not all the capabilities of IETF Transport 
protocols need to be exposed as Transport Services."

We'll have to figure out reasonable ways to shorten the list in item #1 at some 
point; this could include compiling a number of services under more 
application-oriented terms - such as "willing to choose low latency at the cost 
of X". What this statement precisely means depends on "X", and I think we can 
get an idea of what "X" is when we create that service from the list in item 
#1, not out of the blue.

Does that make sense?

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] agenda topic: application - transport abstractions

[Michael Welzl]

> On 05 Feb 2015, at 09:54, Marie-Jose Montpetit  wrote:
> 
> 
> 
> 
>> On Feb 5, 2015, at 3:44 AM, Michael Welzl  wrote:
>> 
>> 
>>> On 05 Feb 2015, at 00:29, Marie-Jose Montpetit  wrote:
>>> 
>>>> snip/snip
>>> 
>>>> In summary, we need a better way to describe the services we want before 
>>>> we'll ever be able to expect the transport to handle them properly.
>>>> 
>>> I totally agree.
>> 
>> We've been around the "let's specify what the application wants, not what 
>> protocols can do" block a couple of times prior to creation of this group. 
>> We started and ended with the bottom-up'ish plan that is in the charter now.
> 
> Yes but in fact I think that you have to look at both ends: define what the 
> service wants can be tricky but necessary. On the other hand it also almost 
> implies that the mechanims or services also expose their characteristics - if 
> not, matching of services to transport cannot happen.

I couldn't parse this. What do you mean?


>> So, if you take a look at item #2 in the charter, it's rather unclear what 
>> that item is going to look like, and in particular how we'll arrive there:
>> 
>> "2) Specify the subset of those Transport Services, as identified 
>> in item 1, that end systems supporting TAPS will provide, and 
>> give guidance on choosing among available mechanisms and 
>> protocols. Note that not all the capabilities of IETF Transport 
>> protocols need to be exposed as Transport Services."
>> 
>> We'll have to figure out reasonable ways to shorten the list in item #1 at 
>> some point; this could include compiling a number of services under more 
>> application-oriented terms - such as "willing to choose low latency at the 
>> cost of X". What this statement precisely means depends on "X", and I think 
>> we can get an idea of what "X" is when we create that service from the list 
>> in item #1, not out of the blue.
>> 
>> Does that make sense?
> Yes but the issue will be in defining X - less latency at the expense of 
> bandwidth or more complexity in the network or ??? Each of those may imply a 
> different transport. 

Agreed - my point is: when we build #1, X will come.

Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] agenda topic: application - transport abstractions

[Michael Welzl]

Then we agree.


On Feb 5, 2015, at 12:21 PM, Marie-Jose Montpetit  wrote:

> What I mean is defining what the apps need is not independent of also 
> defining what the protocols offer.
> 
> Marie-Jose Montpetit, Ph.D.
> mari...@mit.edu
> @SocialTVMIT
> 
>> On Feb 5, 2015, at 4:57 AM, Michael Welzl  wrote:
>> 
>> 
>>> On 05 Feb 2015, at 09:54, Marie-Jose Montpetit  wrote:
>>> 
>>> 
>>> 
>>> 
>>>> On Feb 5, 2015, at 3:44 AM, Michael Welzl  wrote:
>>>> 
>>>> 
>>>>> On 05 Feb 2015, at 00:29, Marie-Jose Montpetit  wrote:
>>>>> 
>>>>>> snip/snip
>>>>> 
>>>>>> In summary, we need a better way to describe the services we want before 
>>>>>> we'll ever be able to expect the transport to handle them properly.
>>>>>> 
>>>>> I totally agree.
>>>> 
>>>> We've been around the "let's specify what the application wants, not what 
>>>> protocols can do" block a couple of times prior to creation of this group. 
>>>> We started and ended with the bottom-up'ish plan that is in the charter 
>>>> now.
>>> 
>>> Yes but in fact I think that you have to look at both ends: define what the 
>>> service wants can be tricky but necessary. On the other hand it also almost 
>>> implies that the mechanims or services also expose their characteristics - 
>>> if not, matching of services to transport cannot happen.
>> 
>> I couldn't parse this. What do you mean?
>> 
>> 
>>>> So, if you take a look at item #2 in the charter, it's rather unclear what 
>>>> that item is going to look like, and in particular how we'll arrive there:
>>>> 
>>>> "2) Specify the subset of those Transport Services, as identified 
>>>> in item 1, that end systems supporting TAPS will provide, and 
>>>> give guidance on choosing among available mechanisms and 
>>>> protocols. Note that not all the capabilities of IETF Transport 
>>>> protocols need to be exposed as Transport Services."
>>>> 
>>>> We'll have to figure out reasonable ways to shorten the list in item #1 at 
>>>> some point; this could include compiling a number of services under more 
>>>> application-oriented terms - such as "willing to choose low latency at the 
>>>> cost of X". What this statement precisely means depends on "X", and I 
>>>> think we can get an idea of what "X" is when we create that service from 
>>>> the list in item #1, not out of the blue.
>>>> 
>>>> Does that make sense?
>>> Yes but the issue will be in defining X - less latency at the expense of 
>>> bandwidth or more complexity in the network or ??? Each of those may imply 
>>> a different transport. 
>> 
>> Agreed - my point is: when we build #1, X will come.
>> 
>> Michael
>> 
> 

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt

[Michael Welzl]

Hi,


> On 16 Mar 2015, at 23:54, Karen Elisabeth Egede Nielsen 
>  wrote:
> 
> HI,
> 
> Please accept the following "minor" comments/questions to the TCP protocol
> components:
> 
> #1:
> The list include both of the followings:
> 
> *ordered delivery for each byte stream
> * stream-oriented delivery in a single stream
> 
> Wouldn't it be more fair to combine these two and say:
> 
> *ordered delivery in a single stream
> 
> "Each stream" seems a little too much for TCP, I think.
> 
> #2:
> Segmentation and bundling is listed as separate components, even if
> bundling, for TCP, is part of the segmentation process.
> I suppose that is as it should be, but when speaking "Bundling" then I
> actually think that "Bundling delay" is a better term. Especially for TCP.
> 
> To put in context:
> For SCTP it is actually relevant to discuss bundling and bundling delay
> separately  as two different components.
> Meaning that SCTP WILL bundle PDUs up to PMTU size (and I would call that
> bundling), but it CAN (depending on no_delay setting) implement bundling
> delay or not.

So how does bundling without delaying work?

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt

[Michael Welzl]

> On 17 Mar 2015, at 12:26, Karen Elisabeth Egede Nielsen 
>  wrote:
> 
> Hi,
> 
>> -Original Message-----
>> From: Michael Welzl [mailto:mich...@ifi.uio.no]
>> Sent: Tuesday, March 17, 2015 11:09 AM
>> To: Karen Elisabeth Egede Nielsen
>> Cc: taps@ietf.org
>> Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt
>> 
>> Hi,
>> 
>> 
>>> On 16 Mar 2015, at 23:54, Karen Elisabeth Egede Nielsen
>>  wrote:
>>> 
>>> HI,
>>> 
>>> Please accept the following "minor" comments/questions to the TCP
>>> protocol
>>> components:
>>> 
>>> #1:
>>> The list include both of the followings:
>>> 
>>> *ordered delivery for each byte stream
>>> * stream-oriented delivery in a single stream
>>> 
>>> Wouldn't it be more fair to combine these two and say:
>>> 
>>> *ordered delivery in a single stream
>>> 
>>> "Each stream" seems a little too much for TCP, I think.
>>> 
>>> #2:
>>> Segmentation and bundling is listed as separate components, even if
>>> bundling, for TCP, is part of the segmentation process.
>>> I suppose that is as it should be, but when speaking "Bundling" then I
>>> actually think that "Bundling delay" is a better term. Especially for
> TCP.
>>> 
>>> To put in context:
>>> For SCTP it is actually relevant to discuss bundling and bundling
>>> delay separately  as two different components.
>>> Meaning that SCTP WILL bundle PDUs up to PMTU size (and I would call
>>> that bundling), but it CAN (depending on no_delay setting) implement
>>> bundling delay or not.
>> 
>> So how does bundling without delaying work?
>> 
> [Karen ]
> If there are multiple messages available for transmittal in the SND
> buffer. E.g.,
> 2 messages of 600 bytes would be bundled into the same SCTP packet.
> This of course is only in situations where there has been congestion or
> receiver window blocking.
> 
> For TCP this "bundling" of data bytes is part of the basic segment
> partitioning of the data byte stream.

Ok, thanks...  yes this is indeed different from "Nagle'ing"...

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

[Taps] Comments on draft-ietf-taps-transports-03

[Michael Welzl]

Hi,

Terribly sorry for looking at this so late! I just couldn't do it earlier. Also 
sorry for only "looking at it", not reading it in depth yet! Here are some 
early comments (I might have more after a deeper read):


Major:
- I do think that the terminology actually needs to clarify about what a 
"service" is. Following the chain of dependencies here, it is found in 
"Transport Service", where it says "... which provides a complete service to an 
application."

The reason I think we need to define this is that we should (IMO) explicitly 
exclude protocol functions that can improve the performance of the protocol 
*only* depending on environment characteristics but *irrespective* of the 
application. For example, things like ECN, SACK etc. shouldn't be regarded as a 
"service" in my opinion. As I'll say in my presentation tomorrow: for the work 
we previously did, we decided to ask, for every protocol component (adapted 
terminology here ;-) ):  "without knowledge about network conditions, would an 
application ever have a reason to say 'no' to this?"   => if the answer is 
"no", it's not a protocol component, because if it's purely a network 
optimization, it better be implemented in the protocol and not shown to the 
application. E.g., AFAIK the API of TCP does not allow the application to turn 
SACK on or off. That would be pointless, right?  => same logic here.


Why do I bring this up? Because I saw a few components that seem to me to fall 
in this category of "optimization depending on environment conditions but 
otherwise irrelevant for the application":
- IPv6 jumbograms in UDP. Though I don't know much about jumbograms, so I might 
be very wrong here.
 - timestamps in DCCP
- I didn't see ECN support mentioned elsewhere, but listed in the table in 4.1. 
I think it also falls in this category. 
- segmentation in TCP. Yes it's a part of what TCP does, but, repeating my 
question: "without knowledge about network conditions, would an application 
ever have a reason to say 'no' to this?" ... I think there's even one more 
reason to remove this: isn't this an inevitable element of stream-oriented data 
delivery (which is already listed)? Can you do this without segmentation?

UDP(-Lite) messes this up a bit... because it provides almost nothing and 
leaves all the job available to applications, hence an application running over 
UDP(-Lite) may need to be aware of almost everything, e.g. ECN capability. 
Maybe the right thing to do would be to treat UDP(-Lite) as a special case...



Minor:
- last para of intro: this talks about LEDBAT as if it was a protocol, not a 
congestion control mechanism.

- for better or worse, shouldn't "identification of urgent data" be a part of 
the protocol components of TCP?


Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Comments on draft-ietf-taps-transports-03

[Michael Welzl]

> On 23. mar. 2015, at 11.34, Joe Touch  wrote:
> 
> 
> 
> On 3/22/2015 7:34 AM, Michael Welzl wrote:
>> Major:
>> - I do think that the terminology actually needs to clarify about
>> what a "service" is. Following the chain of dependencies here, it is found in
>> "Transport Service", where it says "... which provides a complete
>> service to an application."
>> 
>> The reason I think we need to define this is that we should (IMO)
>> explicitly exclude protocol functions that can improve the performance
>> of the protocol *only* depending on environment characteristics but
>> *irrespective* of the application. For example, things like ECN, SACK
>> etc. shouldn't be regarded as a "service" in my opinion.
> 
> IMO, a "service" is a coherent whole. ECN, SACK, etc. are capabilities
> within a service.
> 
> The difference is simple: a service is the smallest set of capabilities
> that can be used independent of all others.

I completely agree and apologize, that was slopping writing on my side: I 
should have said "service component". Anyway my point was that ECN, SACK etc. 
shouldn't be any of that.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> On 28. mai 2015, at 20.18, Joe Touch  wrote:
> 
> 
> 
> On 5/28/2015 11:05 AM, Mirja Kühlewind wrote:
>> Hi Joe,
>> 
>> here is where the confusion comes from: this doc is not about APIs,
>> it’s about transport services, or to say it even more concrete,
>> transport services components and features.
> 
> Such services are either inherent to the transport (e.g., in-order,
> reliable delivery) or exposed as a control to the user (by the API).
> 
> I.e., APIs are necessary but not sufficient to describe transport services.

Agreed. Things that are in the APIs are what the document calls "transport 
service features", whereas what you here call "inherent services" is what the 
document calls "transport protocol components".

I think it's a bit unfortunate that the API descriptions look very different in 
style from the list of components. Maybe a line could be drawn between:

"transport service features"  (components that are exposed to the application)
... and here come all the things found in today's (not tomorrow's!) APIs, as 
defined by the specs alone, not implementations
and "transport protocol components"  ... which is all the rest. I'm thinking of 
just a way of splitting the component lists, just to say "the following ones 
are exposed in the API today".


>> We do have a section on
>> interfaces for each protocol but that just an add-on which might or
>> might not be useful to have in this document, but the core of the
>> document is to describe the components that are currently implemented
>> independent of the current provided (app-layer) interface and then add
>> some discuss of which of these components are useful to expose to the
>> app as transport services feature (and which level of detail/degree of
>> decision freedom for each feature).
> 
> But then isn't it critical to also know what's already exposed, e.g., in
> the existing API?

I think so - and the document tries to say that, by describing APIs. Doing it 
like I propose above could add clarity.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] API richness

[Michael Welzl]

> On 27. mai 2015, at 08.22, Karen Elisabeth Egede Nielsen 
>  wrote:
> 
> HI,
> 
> As an example of presently relied on API richness, then the following
> parameters of TCP/SCTP are parameters that today typically are tuned by
> signaling applications on a per connection/association basis or an a per
> signaling application basis. Here multiple signaling applications may share
> the same TCP/SCTP transport layer instance (SW block) but may configure
> their usage of the protocol (of their TCP connection/SCTP assoc
> differently).
> In terms of Taps terminology I think this corresponds to a  shared "
> Transport Service Instance".
> 
> I may note that the parameters even typically are exposed at O&M level as
> configurable by the Operators,
> here even possibly on an association/connection basis.
> 
> For TCP:
> 
> RTO_MIN, RTO_MAX, MAXRT, SND  BUF, RCV BUF, Delay_ack, No_delay, TCP keep
> alive settings,
> 
> For SCTP:
> 
> RTO_MIN, RTO_MAX, RTO_INITIAL, SND BUF, RCV BUF, Delay_ack, No_delay, HBI,
> Association.Max.Retrans, Path.Max.Retrans,
> 
> There are other parameters as well that are tuned on a per TCP
> connection/SCTP association basis, but this is in more special cases.
> For example TCP (and even SCTP) ABC slow start parameter L, TCP time wait
> period.
> 
> The above parameters relates only to the core TCP and SCTP functions relied
> on by signaling applications.
> Speaking additional features, e.g., ECN, special SCTP features management
> opens up for more of course.

This strikes me as out of scope of TAPS: why discuss what (some) applications 
today typically tune?


> The CC algorithm today is not tuned - default is used - in the future this
> should be different, but I think that there is general agreement that such
> should
> indeed be tuned at the TAPS API.

Then I think I'm in the "don't agree" camp...

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> On 29 May 2015, at 10:27, Mirja Kühlewind  
> wrote:
> 
> Hi Oliver,
> 
> I mostly agree with your understand, only minor points below.
> 
>> Am 29.05.2015 um 10:05 schrieb Olivier Mehani :
>> 
>> Hi all,
>> 
>> On Thu, May 28, 2015 at 09:33:43PM +0200, Michael Welzl wrote:
>>>>> here is where the confusion comes from: this doc is not about APIs,
>>>>> it’s about transport services, or to say it even more concrete,
>>>>> transport services components and features.
>>>> Such services are either inherent to the transport (e.g., in-order,
>>>> reliable delivery) or exposed as a control to the user (by the API).
>>>> I.e., APIs are necessary but not sufficient to describe transport
>>>> services.
>>> Agreed. Things that are in the APIs are what the document calls
>>> "transport service features", whereas what you here call "inherent
>>> services" is what the document calls "transport protocol components".
>> 
>> I am not sure I have the same understanding of what features are. More
>> than what is exposed through the API (which indeed is very little in the
>> majority of the cases), I think features is what the application
>> implicitly expects when selecting a specific transport.
> 
> Yes and no. So what you describe is the current state. A transport service is 
> a set of transport services features and today you can select those features 
> only implicitly by selection the transport protocol itself.
> 
> However, I think that it is worth to provide an interface to configure each 
> feature explicitly. Not completely sure yet that it is true. But for me 
> that’s one of the goals of this working group to figure out if this statement 
> is true.
> 
>> 
>> I agree more about the components. The application however has no idea
>> about the components. This is internal stuff within each protocol to
>> provide the features (e.g., retransmission for reliability), or to be
>> nice to the network (e.g., congestion control). I don't think the
>> applications would care much for the latter (or maybe as a hindrance
>> which limits how much of the capacity it can grab).
>> 
>> At the moment, looking at the draft, I think that most “Transport
>> Protocol Components” sections actually conflate features and components,
>> and probably list more of the former than the latter. I don't think this
>> is quite in line with the terminology:
>> 
>>  Transport Service Feature: : a specific end-to-end feature that
>>  a transport service provides to its clients. Examples include
>>  confidentiality, reliable delivery, ordered delivery,
>>  message-versus-stream orientation, etc.
>> 
>>  Transport Protocol Component: : an implementation of a transport
>>  service feature within a protocol.
>> 
>> For example for TCP, I would say that the following are features (that the 
>> application wants)
>> - reliable delivery
>> - ordered delivery for each byte stream
>> - stream-oriented delivery in a single stream
>> - unicast
>> - data bundling (Nagle's algorithm)
>> - port multiplexing
>> while these are components (that the application doesn't see)
>> - connection setup with feature negotiation and application-to-port mapping
>> - error detection (checksum)
>> - segmentation
>> - flow control
>> - congestion control
> 
> I also see this very slightly different. Features and components are for my 
> understanding nothing exclusive. Each feature also has a corresponding 
> component (but not the other way around). However, while the feature is 
> ‚reliable delivery‘ (because that all the app cares about), the component 
> might be more specific like "reliable delivery using accumulated ACKs and 
> retransmissions’ as TCP does.
> 
> The more important point is, that the current lists in the doc need work! 
> Maybe some of the point you’ve listed above as features must be phrased more 
> detailed to describe/list the actually component and then we need to decide 
> which components actually also provide a feature (that should be exposed) and 
> on which level this correlates to a feature. So the split you proposed above 
> is a good starting point for this.
> 
> 
>> 
>>> "transport service features"  (components that are exposed to the
>>> application) ... and here come all the things found in today's (not
>>> tomorrow's!) APIs, as defined by the specs alone, not implementations
>>> and "transport protocol componen

Re: [Taps] API richness

[Michael Welzl]

> On 29 May 2015, at 11:25, Karen Elisabeth Egede Nielsen 
>  wrote:
> 
> HI Mirja,
> 
> 
>> -Original Message-
>> From: Mirja Kühlewind [mailto:mirja.kuehlew...@tik.ee.ethz.ch]
>> Sent: Friday, May 29, 2015 10:13 AM
>> To: Karen Elisabeth Egede Nielsen
>> Cc: Michael Welzl; taps WG
>> Subject: Re: [Taps] API richness
>> 
>> Hi Karen,
>> 
>> instead of discussing what applications currently configure, I would rather
>> like
>> to know why they configure it; what the goal they try to reach and what’s
>> the
>> problem they try to handle with that. The reason why I’m saying this, is
>> because the current configuration possibilities are often very limited and
>> something even on the wrong level. To figure out how to do this better, we
>> need to understand what the application really wants.
>> 
> [Karen ] Yes I couldn't agree more.
> I will also concur that some of the present tuning is done to overcome some
> deficiencies in the protocol algorithms, but generally the below reflect
> needs of
> the applications to have the transport layer service stay within certain
> latency limits and to
> bail out from using the particular transport service layer (connection) if
> these limits are not withheld.
> 
> I agree than one should extrapolate to the right generic features,
> to do that one should extrapolate from the existing concrete examples.


Okay, it seems we're all on the same page. My heavy reaction to the email 
before (and sorry Karen, I had forgotten why you sent it! Indeed that was 
agreed upon at the last meeting) was because I'm afraid of the logical 
conclusion:
"this is what applications currently configure in current protocols" => "this 
is what a TAPS API would need to provide".

Rather, I think it would be better to focus on *why* applications currently 
configure the things they do, such that we can then provide something 
reasonable and meaningful to them.
Then again, even that is something we could spend much time on, and possibly in 
vain: I believe that applications that  are configuring all these things 
nowadays probably wouldn't be "customers" of TAPS anyway.
TAPS generally targets programmers of applications who are willing to give up 
some control, for the possible benefits that come with abstraction. This will 
always only be a subset of applications.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> On 29. mai 2015, at 19.32, Joe Touch  wrote:
> 
> First, I think this discussion would benefit from a clarification of
> what "API" means, or at least to stop using that term in isolation.
> 
> There are three distinct concepts:
> 
>   A- abstract protocol "upper layer interface"
>   e.g., OPEN, CLOSE, ABORT, as per RFC 793
> 
>   B- programmer API
>   e.g., Linux C/C++ TCP socket interface
> 
>   C- instance of a programmer API
>   e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface
> 
> IMO, this document MUST discuss A, and can be address potential
> extensions to A based on examining variants of B and C.
> 
> There are also the protocol features, which are the properties of the
> protocol that:
>   - can be explicitly configured and monitored
>   these are *exactly* A, B, and/or C above
> 
>   - can be implicitly detected
>   some are based on the definition of the protocol,
>   such as reliable, byte sequence delivery
> 
>   some are an artifact of the implementation,
>   such as specific delays due to burst losses
> 
> However, *none* of this is a rat-hole IF TAPS is intended to explain the
> service interface to the user. IMO, B and C above should be secondary
> considerations after A is clearly documented, but this draft is a long
> way from that.

I agree: A should be there, and it should probably the primary focus, as 
starting with a list of A would add a lot of clarity to the document and the 
discussion of it.

Some text on protocol internals, explaing what a protocol does even though 
these things may not be exposed to an application, can be valuable even if only 
to know which protocol to choose. So I'm not suggesting removing everything but 
I'd agree that the focus of the document should shift towards a list of A.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> On 28. mai 2015, at 11.08, Brian Trammell  wrote:
> 
> hi Mirja, Joe,
> 
> two more points inline...
> 
>> On 28 May 2015, at 10:49, Mirja Kühlewind  
>> wrote:
>> 
>> Hi Joe,
>> 
>> see below...
>> 
>> 
>>> Am 27.05.2015 um 19:20 schrieb Joe Touch :
>>> 
>>> 
>>> On 5/27/2015 6:02 AM, Mirja Kühlewind wrote:
 Hi Joe,
 
 I agree. This is a working document and we are still in the phase of
 collecting data while the next step is to discuss which things that are
 currently listed must/should be listed or not and also which of the
 things must/should be exposed to the app.
>>> 
>>> To be clear, can you clarify the focus?:
>>> 
>>> - what IS/IS NOT (i.e., current requirements)
>>> 
>>> - what WILL BE/WILL NOT BE (i.e., future goals)
>>> 
>>> AFAICT, this is about IS/IS NOT. With that in mind, it should not be
>>> necessary to "collect data" and then decide later what is exposed or not.
>> 
>> It’s about IS/IS NOT. However, currently there is very little (explicitly) 
>> exposed to the app.
>> 
>> So the question is actually what should be exposed from the transport 
>> service components that are currently implemented in the then different 
>> existing transport protocols.
>> 
 However, I think we are on the write track for the TSC because these
 are thing that are implemented independent of the question if these
 things should be exposed to the app or not.
>>> 
>>> There seems to be ample confusion about:
>>> 
>>> - upper layer interface (abstract "API"): services to the user
>>> 
>>> - lower layer interface: services needed from the next protocol layer
>>> 
>>> - the protocol itself (as an abstract specification: i.e., the finite
>>> state machine rules that relate commands and responses to the ULI, calls
>>> and returns to the LLI, and internal state and events (e.g., timers)
>>> 
>>> - the *implementation* of any of the above, e.g.:
>>> - Unix sockets API
>>> - interface to IPv4
>>> - Differences that include Reno vs. Cubic..., MTU algs, etc.
>>> 
 However, features in
 contrast should really only be the things that should be exposed.
>>> 
>>> IMO, implementation issues should be fully out of scope.
> 
> I disagree that implementation- (and indeed, deployment-) level concerns are 
> out of scope here. It's implementation level concerns which have made it 
> necessary to do something like TAPS in the first place. In a world without 
> middlebox impairment you don't need any path condition measurement or 
> negotiation at all, and "transport flexibility" would simply be a matter of 
> sticking libraries on top of TCP and/or SCTP options.

This sounds like you were talking cross purposes. My interpretation here is 
that Joe is saying (as in his other email) that "concept A" in his other email:
http://www.ietf.org/mail-archive/web/taps/current/msg00490.html
should be in scope of the discussion, but B and C should not. I agree with that 
and your answer doesn't say you don't.

How to implement / deploy something are concerns that should be in scope of 
TAPS (they clearly are as per item 3 in its charter), but not necessarily in 
scope of this first document.


>> It’s not about implementation issues but it’s not always absolutely clear 
>> which level of detail must be exposed to the app. Is it enough to only have 
>> an interface where you can choose to use congestion control or not, or do 
>> you need to choose between delay-based and lost-based congestion control, or 
>> foreground and background congestion control, or one specify algorithm, or 
>> just specify one specify detail of the algorithm e.g. don’t increase fast 
>> than one packet per RTT…?
> 
> There's a second issue here, as well, and it's kind of hiding behind the 
> current structure of the document and the terminology.
> 
> Right now, which transport protocol to use is either an explicit choice of 
> the application developer (by selecting an API / library and set of 
> configuration parameters which always map to a single wire protocol) or an 
> implicit one (e.g. by selecting a library or higher-layer protocol on which 
> to develop the application which only supports a single transport protocol).
> 
> These protocols have positive properties (which we've called components) and 
> negative properties (that is, use of this protocol excludes some other thing 
> you might want to have). Stupid example: fully reliable single-streaming 
> implies head-of-line blocking. Here the positive and negative properties are 
> intrinsically linked. Less stupid example: assume you want reliable transport 
> of messages but don't care at all about the order in which they arrive (e.g. 
> because you're doing bulk object synchronization as with NORM). In this case 
> reliability would be a positive property of TCP, and head-of-line blocking is 
> a negative property, the positive counterpart of which (stream orientation) 
> you don't even want. In this case, it is the choice of components pulled

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> On 1. jun. 2015, at 03.17, Olivier Mehani  wrote:
> 
> Hey Mirja,
> 
> On Fri, May 29, 2015 at 10:27:46AM +0200, Mirja Kühlewind wrote:
>>> I am not sure I have the same understanding of what features are.
>>> More than what is exposed through the API (which indeed is very
>>> little in the majority of the cases), I think features is what the
>>> application implicitly expects when selecting a specific transport.
>> Yes and no. So what you describe is the current state. A transport
>> service is a set of transport services features and today you can
>> select those features only implicitly by selection the transport
>> protocol itself.
>> However, I think that it is worth to provide an interface to configure
>> each feature explicitly. Not completely sure yet that it is true. But
>> for me that’s one of the goals of this working group to figure out if
>> this statement is true.
> 
> Yes, that's how I understand it too. Nonetheless, we need to start with
> what we have: groups of features that we need to identify and separate.
> 
>>> At the moment, looking at the draft, I think that most “Transport
>>> Protocol Components” sections actually conflate features and components,
>>> and probably list more of the former than the latter. I don't think this
>>> is quite in line with the terminology:
> [...]
>>> 
>>> For example for TCP, I would say that the following are features (that the 
>>> application wants)
>>> - reliable delivery
>>> - ordered delivery for each byte stream
>>> - stream-oriented delivery in a single stream
>>> - unicast
>>> - data bundling (Nagle's algorithm)
>>> - port multiplexing
>>> while these are components (that the application doesn't see)
>>> - connection setup with feature negotiation and application-to-port mapping
>>> - error detection (checksum)
>>> - segmentation
>>> - flow control
>>> - congestion control
>> I also see this very slightly different. Features and components are
>> for my understanding nothing exclusive. Each feature also has a
>> corresponding component (but not the other way around). However, while
>> the feature is ‚reliable delivery‘ (because that all the app cares
>> about), the component might be more specific like "reliable delivery
>> using accumulated ACKs and retransmissions’ as TCP does.
> 
> Yes, I completely agree. But I think the difference you higlight is
> important: each feature has one (or more, I'd say) corresponding
> components, while components might not necessarily result in an
> application-visible feature. 
> 
>> The more important point is, that the current lists in the doc need
>> work! Maybe some of the point you’ve listed above as features must be
>> phrased more detailed to describe/list the actually component and then
>> we need to decide which components actually also provide a feature
>> (that should be exposed) and on which level this correlates to a
>> feature. So the split you proposed above is a good starting point for
>> this.
> 
> I'm glad to read it (:
> 
 "transport service features"  (components that are exposed to the
 application) ... and here come all the things found in today's (not
 tomorrow's!) APIs, as defined by the specs alone, not
 implementations and "transport protocol components"  ... which is
 all the rest. I'm thinking of just a way of splitting the component
 lists, just to say "the following ones are exposed in the API
 today".
>>> I think this makes sense. That said, beyond just the specs, I think
>>> it would be useful to consider what current implementations provide
>>> too, as this may offer a slightly different set of features which
>>> is, nonetheless, what developers of real applications are dealing
>>> with.
>> You mean it term of APIs or component? Collecting information of
>> components are are currently implemented/used is the purpose of this
>> doc. Collecting information about API/config interfaces of what is
>> implemented/used today is also useful but a rat-hole… therefore we try
>> cover this aspect briefly in this doc but do not aim for completeness
>> here.
> 
> Yes, this is likely for a later document. However, I think we should
> make sure that some transport API have not implemented some
> non-standardised behaviours that a non-negligible number of applications
> use. I am not sure it's the case, but if it is so, we probably want to
> take that onboard at some point too.

I'd like to stress "at some point"  (if at all).  Maybe not even in this 
particular document?

This is exactly the layering problem here - transport protocol designers will 
have thought through what kind of information should be exposed. App 
programmers are now facing today's systems that they need to optimize as good 
as they can. Maybe ad hoc decisions are / were made to allow some protocol 
tuning that shouldn't really be an application's problem.

To me, apps fine tuning protocols in non-standard ways is already one small 
step in the direction of what TAPS is trying to help again

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> On 1. jun. 2015, at 16.32, Mirja Kühlewind  
> wrote:
> 
> Hi Joe, hi Michael,
> 
> I completely welcome to add more text to the Interface description section 
> (3.1.2). Currently this section is very short and says regarding the (higher 
> layer) interface described in FRC793:
> 
> "A User/TCP Interface is defined in [RFC0793] providing six user
>   commands: Open, Send, Receive, Close, Status.  This interface does
>   not describe configuration of TCP options or parameters beside use of
>   the PUSH and URGENT flags.“
> 
> This text was already added based on Joe’s input. Please provide more text if 
> you think this is not sufficient. 
> 
> Probably we should at least add one more sentence describing the TCP-to-User 
> interface (as it is called in RFC 793) like this:
> 
> „Further the TCP-to-User interface is described providing information on the 
> local connection name, the response string, the send and received buffer 
> addresses, the Byte count (which counts bytes received) as well as the PUSH 
> flag and URGENT flag.“

I agree


> However, from my point of view I actually think that these (basic) things do 
> not need to be discussed in more detail because the described interface is 
> completely okay and can probably be mostly say as it is.

I agree


> The more complicated question is which additional things are needed and, even 
> more important, how can you design a transport interface where the 
> application does not need to choose the protocol first. Because the interface 
> in RFC 793 only describes a User/TCP interface where TCP already determines a 
> certain transport service or a set of transport services features relating to 
> specific transport components. The whole goal or taps is to make things more 
> flexible which mean we need more information before we open a connection and 
> probably also during the connection.

True, but this sounds out of scope of this document? This is just supposed to 
list the services...
 

> One information could be „I want to use a TCP header“ and maybe together with 
> these features… However, as soon as we have chosen certain protocol which 
> might be TCP be still need Open, send, receive and closes commands as 
> described in RFC 793.

I'd say "I want to use a TCP header" should definitely be out of scope of all 
this because it defeats the purpose of the TAPS idea. If I know I want to use a 
TCP header, I don't use TAPS, I use TCP!  We're not aiming at replacing the 
interface for all applications, just offering something new.


> So what I want to say is, that the described interface in RFC 793 is so basic 
> that it is not wrong and should be described in this doc (as it is) but it 
> does help us very much to get to the goal we would like to reach in taps 
> which I currently would describe as: Extend the application layer interface 
> to consequently provide a more flexible transport layer. Or even better the 
> other way around: Create a more flexible transport layer which most likely 
> will lead to an extended application-level interface.


Yes, but...

> Another thing I also would like to say (again) at this point is that the 
> current doc will not specify an new interface.

Exactly  :-)


> We on purpose ‚only‘ talk about transport components and features in this 
> document because we first need to know what we want to do before we can talk 
> about the interface.
> 
> However, again, if you think there is something important missing in this 
> doc, please send text!
> Currently we will (more or less) just integrate all text that we get because 
> it is much easier to discuss about text that is there and something that is 
> not there. That does also mean that any text that is currently in the doc can 
> be discussed, changed or removed!

Good, thanks. Anyway my point was that, in this list of services, we should be 
clear about Joe's item A: what is currently offered to apps by the current 
specs. This is the most important part of the list because it reflects what 
designers of these protocols (and with them, some form of prior IETF group 
consensus) think should be offered to apps.

Going beyond that by discussing internals or things that some apps now can tune 
is a nice extra perhaps, but I think it should be a secondary goal.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

About one bit in particular:


> That’s to bad. Maybe we should state this more explicitly in the intro…? 
> According to our charter, while taps itself is chartered to describe "an 
> (abstract) interface for applications 
> to make use of Transport Services“, this first document is only used to 
> "identifying the 
> [components] provided by existing IETF protocols“ as a starting point. 
> Further we would like to add some discussion in section 4 which of the 
> identified components should/can be exposed as a transport feature that the 
> app should see. [Note that the terminology changed and whenever services is 
> written in the charter it should basically be component.]

This confuses me.

draft-ietf-taps-transports-04 defines a "Transport Protocol Component" as "an 
implementation of a transport service feature within a protocol."
I'm fine with that definition but I can't see why this should replace "service" 
in the charter. The first document should list the services provided by 
existing IETF protocols, that's how to get started. Additionally listing 
components is probably fine if that helps explaining how services are 
constructed, but the focus is on what transports provide - services.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

I'll try addressing another detail, maybe that helps get us aligned:


> On 1. jun. 2015, at 21.38, Mirja Kühlewind  
> wrote:
> 
> Hi Joe
>> 
>> My concern is that there is no clear relation between 3.1.2 and 3.1.3.
> 
> Yes, that’s actually true. Initially there was no section 3.1.2 as this doc 
> is not on interfaces. However it seems to be incomplete without mentioning 
> interfaces at all. If we keep this section, you are right, the relation 
> should be there.

The document is about services. These are provided via interfaces - so the 
document should very much be about interfaces.
3.1.3 describes TCP, it lists all the things you get with TCP - nothing that 
the application can configure, but what you get with it anyway.

The complete service provided by TCP consists of everything TCP is AND the what 
the application can configure about it.
It gives you segmentation, congestion control,  AND it lets you use PUSH 
and an URGENT pointer and ...

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> On 1. jun. 2015, at 23.17, Joe Touch  wrote:
> 
> 
> 
> On 6/1/2015 12:23 PM, Michael Welzl wrote:
>> I'll try addressing another detail, maybe that helps get us aligned:
>> 
>> 
>>> On 1. jun. 2015, at 21.38, Mirja Kühlewind 
>>>  wrote:
>>> 
>>> Hi Joe
>>>> 
>>>> My concern is that there is no clear relation between 3.1.2 and 3.1.3.
>>> 
>>> Yes, that’s actually true. Initially there was no section 3.1.2 as this doc 
>>> is not on interfaces. However it seems to be incomplete without mentioning 
>>> interfaces at all. If we keep this section, you are right, the relation 
>>> should be there.
>> 
>> The document is about services. These are provided via interfaces - so the 
>> document should very much be about interfaces.
>> 3.1.3 describes TCP, it lists all the things you get with TCP - nothing that 
>> the application can configure, but what you get with it anyway.
>> 
>> The complete service provided by TCP consists of everything TCP is AND the 
>> what the application can configure about it.
> 
> Yes.
> 
>> It gives you segmentation, congestion control,  AND it lets you use PUSH 
>> and an URGENT pointer and ...
> 
> Segmentation is HOW TCP gives you a reliable byte-sequence service over
> a packet service.
> 
> It is absolutely NOT something provided to the user or under user
> control. Users can set MTU values on *some systems*, but that's not part
> of the TCP API (to the application) nor does MTU necessarily correspond
> to actual data boundaries (TCP is allowed to do a lot of things).

Yes, I didn't mean that segmentation is under user control. Let me rephrase my 
above sentence:

>> It gives you, via its non-configurable static behavior: segmentation, 
>> congestion control,  AND it lets you control some things: PUSH and an 
>> URGENT pointer and ...


Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

[Taps] A proposal to throw out RTP

[Michael Welzl]

Hi,

I know this has been discussed before, but only briefly. I have two arguments 
that I'd like to bring forward towards removing RTP (/RTCP) from 
draft-ietf-taps-transports-04 and the documents that will follow it. I 
understand that it's a non-obvious question whether RTP should be considered a 
transport protocol or not, and I don't want to take a side in this or step on 
anyone's toes here - these are more practical, pragmatic considerations, and 
I'd just like to see how people react. If folks go crazy in response to this I 
won't keep arguing, but I'd be happy if I'd see some agreement:

Argument #1: RTP implementations need to be tied closer to the application than 
the implementation of transport such as TCP, DCCP, SCTP. There is usually a 
very tight interaction with the codec and RTP - a reaction to one specific 
incoming RTCP message, for instance. So I'd rather see a future TAPS system 
being *used* by RTP instead of *providing* RTP functionality.

Argument #2: TAPS has a non-negligible risk of ending up as an academic 
exercise. I understand that but I don't want that - I think we should do our 
best to keep TAPS "real". If that is our goal, including the world's largest 
protocol isn't perhaps ideal... I think it should be in our interest to try to 
keep the list in draft-ietf-taps-transports-04.txt reasonably contained.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Michael Welzl]

i'm fine with all that...

Sent from my iPhone

> On 3. juni 2015, at 17:58, Mirja Kühlewind  
> wrote:
> 
> Hi all,
> 
>> On 03.06.2015 17:04, Brian Trammell wrote:
>> 
 On 03 Jun 2015, at 16:48, go...@erg.abdn.ac.uk wrote:
 
 Hi,
 
 I know this has been discussed before, but only briefly. I have two
 arguments that I'd like to bring forward towards removing RTP (/RTCP) from
 draft-ietf-taps-transports-04 and the documents that will follow it. I
 understand that it's a non-obvious question whether RTP should be
 considered a transport protocol or not, and I don't want to take a side in
 this or step on anyone's toes here - these are more practical, pragmatic
 considerations, and I'd just like to see how people react. If folks go
 crazy in response to this I won't keep arguing, but I'd be happy if I'd
 see some agreement:
 
 Argument #1: RTP implementations need to be tied closer to the application
 than the implementation of transport such as TCP, DCCP, SCTP. There is
 usually a very tight interaction with the codec and RTP - a reaction to
 one specific incoming RTCP message, for instance. So I'd rather see a
 future TAPS system being *used* by RTP instead of *providing* RTP
 functionality.
>>> I think the same.
>> 
>> +1
> 
> Actually I think I don't agree here. Yes, it's tied closer to the application 
> but I think for taps this is a (good) example where the interface is at a 
> much higher level and therefore might have a value to discuss it. However... 
> (see below)
> 
>> 
>>> 
 Argument #2: TAPS has a non-negligible risk of ending up as an academic
 exercise. I understand that but I don't want that - I think we should do
 our best to keep TAPS "real". If that is our goal, including the world's
 largest protocol isn't perhaps ideal... I think it should be in our
 interest to try to keep the list in draft-ietf-taps-transports-04.txt
 reasonably contained.
>>> I'd prefer the document not to ignore RTP - but to say enough, so that
>>> people can read further should this wish. If the above is correct, then I
>>> think perhaps this document can cover this in the introduction, along with
>>> a mention perhaps of other framing or content-oriented protocols that can
>>> use transports.
>> 
>> Agree as well. If we completely ignore RTP, it will be conspicuous in its 
>> absence.
>> 
>> I'd suggest a bit of tombstone text in the RTP section that explains the 
>> rationale behind not really digging into RTP for components/features... I 
>> can put together something (based more or less on this message) for the -05 
>> rev I'm working on...
> 
> ... I agree here. But I think (right now) I would still like to have an own 
> RTP section but be very brief and give some reasoning why we don't wnant to 
> go into further details. Just as a side remark, I don't see any reason to 
> mention RTP in any following documents though.
> 
> Mirja
> 
> 
>> 
>> Cheers,
>> 
>> Brian
>> 
 Cheers,
 Michael
>>> Gorry
>>> 
 ___
 Taps mailing list
 Taps@ietf.org
 https://www.ietf.org/mailman/listinfo/taps
>>> 
>>> ___
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>> 
>> 
>> 
>> ___
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 
> -- 
> --
> Dipl.-Ing. Mirja Kühlewind
> Communication Systems Group
> Institute TIK, ETH Zürich
> Gloriastrasse 35, 8092 Zürich, Switzerland
> 
> Room ETZ G93
> phone: +41 44 63 26932
> email: mirja.kuehlew...@tik.ee.ethz.ch
> --
> 
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Michael Welzl]

Okay, I promised I won't insist, and I don't... still contributing to the tech 
debate here:

In line - essentially, I'm suggesting RTP-over-TAPS here. BTW and just to be 
clear, I agree about mentioning RTP in the draft and I agree that it provides 
important functions! The question is whether RTP's functions should belong to 
the TAPS "service set" (which in fact is going to be defined in the group's 
second item, but this depends on the first...).


> On 3. jun. 2015, at 20.44, Christian Huitema  wrote:
> 
>> Actually I think I don't agree here. Yes, it's tied closer to the 
>> application but I
>> think for taps this is a (good) example where the interface is at a much 
>> higher
>> level and therefore might have a value to discuss it. However... (see below)
> 
> I don't quite agree either.
> 
> RTP is an extreme example of the split between "generic transport library" 
> and "application specific transport implementation." There are quite a few 
> RTP functions that are seldom found in other transports, but are worth 
> considering:
> 
> 1) The use of timestamps. This is quite fundamental for "real time" 
> applications that need to synchronize the rendering of different media 
> streams.

Agreed - but that would make sense and work *over* pretty much every transport 
protocol, right?


> 2) The tolerance for losses. This requires alignment of transmission units to 
> "natural" media boundaries such as audio or video frames, or compression 
> units within video frames.

... which just means that RTP has to run over a transport that allows the 
application to control message boundaries.


> 3) The practice of FEC, including variable rate FEC. This is quite common in 
> video transmission. A given frame will be transmitted as N data packets plus 
> P redundancy packets, where N and P depend on size and importance of the 
> frame, e.g. anchor frame versus delta.

... which is indeed very closely tied to the application, and might not be the 
kind of thing you want to have in a generic layer, but you could implement it 
on top?


Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Michael Welzl]

nono. read the charter. it says that we’ll:

"1) Define a set of Transport Services, identifying the 
services provided by existing IETF protocols and congestion 
control mechanisms. As a starting point, the working group will 
consider services used 
between two endpoints.”

This is bottom-up, and let’s start this as small as … feasible.

Cheers,
Michael


> On 3. jun. 2015, at 23.26, Mohamed Oulmahdi  wrote:
> 
> I think that speaking specifically about any protocol in this document will 
> not be in the sens of an "abstract" interface for the Transport layer, 
> because abstraction means that application will no longer be aware of who or 
> what Transport services are really offered. But in the same time, this 
> abstract interface should cover all the protocols aspects, and so, 
> applications should not see a difference in the offered service, i.e. some 
> services (or functionalities) which are no longer available. I think that 
> this list of services is too short and must be extended to add more services, 
> especially those already offered, like data encryption for example, or 
> message-oriented transmission ... 
> 
> 
> On Wed, Jun 3, 2015 at 10:07 PM, Michael Welzl  <mailto:mich...@ifi.uio.no>> wrote:
> Okay, I promised I won't insist, and I don't... still contributing to the 
> tech debate here:
> 
> In line - essentially, I'm suggesting RTP-over-TAPS here. BTW and just to be 
> clear, I agree about mentioning RTP in the draft and I agree that it provides 
> important functions! The question is whether RTP's functions should belong to 
> the TAPS "service set" (which in fact is going to be defined in the group's 
> second item, but this depends on the first...).
> 
> 
> > On 3. jun. 2015, at 20.44, Christian Huitema  > <mailto:huit...@microsoft.com>> wrote:
> >
> >> Actually I think I don't agree here. Yes, it's tied closer to the 
> >> application but I
> >> think for taps this is a (good) example where the interface is at a much 
> >> higher
> >> level and therefore might have a value to discuss it. However... (see 
> >> below)
> >
> > I don't quite agree either.
> >
> > RTP is an extreme example of the split between "generic transport library" 
> > and "application specific transport implementation." There are quite a few 
> > RTP functions that are seldom found in other transports, but are worth 
> > considering:
> >
> > 1) The use of timestamps. This is quite fundamental for "real time" 
> > applications that need to synchronize the rendering of different media 
> > streams.
> 
> Agreed - but that would make sense and work *over* pretty much every 
> transport protocol, right?
> 
> 
> > 2) The tolerance for losses. This requires alignment of transmission units 
> > to "natural" media boundaries such as audio or video frames, or compression 
> > units within video frames.
> 
> ... which just means that RTP has to run over a transport that allows the 
> application to control message boundaries.
> 
> 
> > 3) The practice of FEC, including variable rate FEC. This is quite common 
> > in video transmission. A given frame will be transmitted as N data packets 
> > plus P redundancy packets, where N and P depend on size and importance of 
> > the frame, e.g. anchor frame versus delta.
> 
> ... which is indeed very closely tied to the application, and might not be 
> the kind of thing you want to have in a generic layer, but you could 
> implement it on top?
> 
> 
> Cheers,
> Michael
> 
> ___
> Taps mailing list
> Taps@ietf.org <mailto:Taps@ietf.org>
> https://www.ietf.org/mailman/listinfo/taps 
> <https://www.ietf.org/mailman/listinfo/taps>
> 

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Michael Welzl]

Well... it's a typical engineering trade-off decision to make...


> On 04 Jun 2015, at 07:45, Marie-Jose Montpetit  wrote:
> 
> In my presentation in Dallas I had suggested adding RTP (and even HTTP) 
> because as both Mirja and Christian mention some 'applications' are 
> requesting functionalities that are got given elsewhere.
> 
> Marie-José Montpetit
> ma...@mjmontpetit.com
> mari...@mit.edu
> 
> On Jun 3, 2015, at 20:44, Christian Huitema  wrote:
> 
>>> Actually I think I don't agree here. Yes, it's tied closer to the 
>>> application but I
>>> think for taps this is a (good) example where the interface is at a much 
>>> higher
>>> level and therefore might have a value to discuss it. However... (see below)
>> 
>> I don't quite agree either.
>> 
>> RTP is an extreme example of the split between "generic transport library" 
>> and "application specific transport implementation." There are quite a few 
>> RTP functions that are seldom found in other transports, but are worth 
>> considering:
>> 
>> 1) The use of timestamps. This is quite fundamental for "real time" 
>> applications that need to synchronize the rendering of different media 
>> streams.
>> 
>> 2) The tolerance for losses. This requires alignment of transmission units 
>> to "natural" media boundaries such as audio or video frames, or compression 
>> units within video frames.
>> 
>> 3) The practice of FEC, including variable rate FEC. This is quite common in 
>> video transmission. A given frame will be transmitted as N data packets plus 
>> P redundancy packets, where N and P depend on size and importance of the 
>> frame, e.g. anchor frame versus delta.
>> 
>> -- Christian Huitema
>> 
>> ___
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> On 5. jun. 2015, at 10.12, Mirja Kühlewind  
> wrote:
> 
> Okay, just to quickly clarify. In the charter only the word service is used. 
> We defined later on the words component and feature which are currently not 
> reflected in the charter. The part I've cited below, I think, it should say 
> components. However, it does not really matter because we will in the current 
> document first identify components and then discuss features. In any case 
> this document will not define a new interface.

I got that but I disagree about "it should say components" for the part in the 
charter: from the definition, the component is an implementation, not what is 
exposed to the application. I think the more important part is to capture 
what's exposed to the application. For example: SCTP has a component called 
"strong error detection (CRC32C)". TCP has a component called "error detection 
(checksum)". This is probably not exposed to the application as such by any of 
these protocols. I'll explain below why this makes it less important in my 
opinion...


> I'd also say that this is not the flag ship document (as stated by Joe). The 
> flagship document probably is the third item on the charter which then will 
> probably also talk about the interface in more detail (charter says on the 
> third doc: "This document will explain how to select and engage an 
> appropriate protocol ...").

Well, this first document is no less important, everything hinges on it.

So let's think of the future system we're envisioning here. Is it going to 
provide "error detection" as a service? Is it going to provide "strong error 
detection"?

When making these decisions, I think we'd first need to go through the list of 
things provided to applications by the protocols in what Joe calls the abstract 
API. Probably we won't find it there: it's a static property of the protocols 
AFAIK. So, next, we go through all the static properties to figure out what we 
need to expose. Then, the question becomes: should a TAPS system decide for or 
against SCTP based on the level of error protection? Is this a basis for 
deciding for this or the other protocol?

These are important decisions but I think they are secondary, whereas what the 
protocols now explicitly offer is primary - because it would be very strange 
not to offer what is being offered today. We can decide to not expose "level of 
error protection" and give the TAPS more freedom in choosing the protocol; 
given that the goal is to stop connection applications to specific protocols, 
we CAN do that.

That's why I think the service is more important than the component, and that's 
why I'm on Joe's side here.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

Sorry for sending an extra email - I just had an extra thought and think this 
is important to add:

Below:

> On 5. jun. 2015, at 11.05, Michael Welzl  wrote:
> 
> 
>> On 5. jun. 2015, at 10.12, Mirja Kühlewind  
>> wrote:
>> 
>> Okay, just to quickly clarify. In the charter only the word service is used. 
>> We defined later on the words component and feature which are currently not 
>> reflected in the charter. The part I've cited below, I think, it should say 
>> components. However, it does not really matter because we will in the 
>> current document first identify components and then discuss features. In any 
>> case this document will not define a new interface.
> 
> I got that but I disagree about "it should say components" for the part in 
> the charter: from the definition, the component is an implementation, not 
> what is exposed to the application. I think the more important part is to 
> capture what's exposed to the application. For example: SCTP has a component 
> called "strong error detection (CRC32C)". TCP has a component called "error 
> detection (checksum)". This is probably not exposed to the application as 
> such by any of these protocols. I'll explain below why this makes it less 
> important in my opinion...
> 
> 
>> I'd also say that this is not the flag ship document (as stated by Joe). The 
>> flagship document probably is the third item on the charter which then will 
>> probably also talk about the interface in more detail (charter says on the 
>> third doc: "This document will explain how to select and engage an 
>> appropriate protocol ...").
> 
> Well, this first document is no less important, everything hinges on it.
> 
> So let's think of the future system we're envisioning here. Is it going to 
> provide "error detection" as a service? Is it going to provide "strong error 
> detection"?
> 
> When making these decisions, I think we'd first need to go through the list 
> of things provided to applications by the protocols in what Joe calls the 
> abstract API. Probably we won't find it there: it's a static property of the 
> protocols AFAIK. So, next, we go through all the static properties to figure 
> out what we need to expose. Then, the question becomes: should a TAPS system 
> decide for or against SCTP based on the level of error protection? Is this a 
> basis for deciding for this or the other protocol?
> 
> These are important decisions but I think they are secondary, whereas what 
> the protocols now explicitly offer is primary - because it would be very 
> strange not to offer what is being offered today. We can decide to not expose 
> "level of error protection" and give the TAPS more freedom in choosing the 
> protocol; given that the goal is to stop connection applications to specific 
> protocols, we CAN do that.

as Brian pointed out in a previous email, a protocol comes with a series of 
what he called "positive properties" and "negative properties". Anyway, 
properties: your application may like some and hate some. It's always a suite 
of properties - then, we probably can't expose them individually - e.g. with 
today's protocols, you can't get MPTCP's usage of multiple paths with coupled 
congestion control but at the same time have SCTP's strong CRC.

Sure, we can say the same about combinations of things that are currently being 
offered in the abstract APIs of the protocols, but still, things will get 
easier there: the list is shorter, it's clearer what we need to include and 
what not (basically everything must be included), and certain API elements will 
clearly dictate which protocol(s) to use. Therefore I do believe that the job 
gets much easier if we focus on the abstract APIs first. I'm not against 
listing the components, it's about what matters more (and it should be 
reflected in the document accordingly - maybe it could even be an idea to split 
the document in two, one purely about the "abstract API" and one about 
"components", and possibly merge them later?).

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> On 05 Jun 2015, at 13:29, Mirja Kühlewind  
> wrote:
> 
> Hi Michael,
> 
> see below.
> 
> 
> On 05.06.2015 11:05, Michael Welzl wrote:
>> 
>>> On 5. jun. 2015, at 10.12, Mirja Kühlewind 
>>>  wrote:
>>> 
>>> Okay, just to quickly clarify. In the charter only the word service is 
>>> used. We defined later on the words component and feature which are 
>>> currently not reflected in the charter. The part I've cited below, I think, 
>>> it should say components. However, it does not really matter because we 
>>> will in the current document first identify components and then discuss 
>>> features. In any case this document will not define a new interface.
>> 
>> I got that but I disagree about "it should say components" for the part in 
>> the charter: from the definition, the component is an implementation, not 
>> what is exposed to the application. I think the more important part is to 
>> capture what's exposed to the application. For example: SCTP has a component 
>> called "strong error detection (CRC32C)". TCP has a component called "error 
>> detection (checksum)". This is probably not exposed to the application as 
>> such by any of these protocols. I'll explain below why this makes it less 
>> important in my opinion...
> 
> I don't think that this decision is (in general) that easy. That's why we go 
> through the exercise of decomposing existing protocols into their components 
> and based on this information discuss what potentially could be exposed and 
> further reason about what should be exposed (because there are implications 
> for the application).
> 
> From my point of view this process it independent of the interface (not 
> matter if we talk about an abstract interface, a certain implementation or 
> what we want to have in future). However, looking at current interfaces will 
> probably help us to make the right decisions.
> 
>> 
>> 
>>> I'd also say that this is not the flag ship document (as stated by Joe). 
>>> The flagship document probably is the third item on the charter which then 
>>> will probably also talk about the interface in more detail (charter says on 
>>> the third doc: "This document will explain how to select and engage an 
>>> appropriate protocol ...").
>> 
>> Well, this first document is no less important, everything hinges on it.
>> 
>> So let's think of the future system we're envisioning here. Is it going to 
>> provide "error detection" as a service? Is it going to provide "strong error 
>> detection"?
>> 
>> When making these decisions, I think we'd first need to go through the list 
>> of things provided to applications by the protocols in what Joe calls the 
>> abstract API. Probably we won't find it there: it's a static property of the 
>> protocols AFAIK. So, next, we go through all the static properties to figure 
>> out what we need to expose. Then, the question becomes: should a TAPS system 
>> decide for or against SCTP based on the level of error protection? Is this a 
>> basis for deciding for this or the other protocol?
>> 
>> These are important decisions but I think they are secondary, whereas what 
>> the protocols now explicitly offer is primary - because it would be very 
>> strange not to offer what is being offered today. We can decide to not 
>> expose "level of error protection" and give the TAPS more freedom in 
>> choosing the protocol; given that the goal is to stop connection 
>> applications to specific protocols, we CAN do that.
>> 
>> That's why I think the service is more important than the component, and 
>> that's why I'm on Joe's side here.
> 
> I didn't say anything about the importance of anything. I think all three 
> documents and and all kind of transport 'things' we talk about are important. 
> And most important is the process of getting things 'decomposed' correctly 
> and discussed in the right document at the right time.
> 
> What I wanted to say is that people who later on read these docs (because 
> they want to use taps), probably only read the third doc, maybe the second, 
> and very likely will only read this document if they already have read the 
> other two and would like have additional information.
> 
> I do have the feeling that parts of what Joe wants to discuss should however 
> be in the third doc. And therefore I think that the current first doc is not 
> the taps flagship doc because for me a

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> On 05 Jun 2015, at 12:35, Michael Tuexen  
> wrote:
> 
>> On 05 Jun 2015, at 11:05, Michael Welzl  wrote:
>> 
>> 
>>> On 5. jun. 2015, at 10.12, Mirja Kühlewind 
>>>  wrote:
>>> 
>>> Okay, just to quickly clarify. In the charter only the word service is 
>>> used. We defined later on the words component and feature which are 
>>> currently not reflected in the charter. The part I've cited below, I think, 
>>> it should say components. However, it does not really matter because we 
>>> will in the current document first identify components and then discuss 
>>> features. In any case this document will not define a new interface.
>> 
>> I got that but I disagree about "it should say components" for the part in 
>> the charter: from the definition, the component is an implementation, not 
>> what is exposed to the application. I think the more important part is to 
>> capture what's exposed to the application. For example: SCTP has a component 
>> called "strong error detection (CRC32C)". TCP has a component called "error 
>> detection (checksum)". This is probably not exposed to the application as 
>> such by any of these protocols. I'll explain below why this makes it less 
>> important in my opinion...
>> 
>> 
>>> I'd also say that this is not the flag ship document (as stated by Joe). 
>>> The flagship document probably is the third item on the charter which then 
>>> will probably also talk about the interface in more detail (charter says on 
>>> the third doc: "This document will explain how to select and engage an 
>>> appropriate protocol ...").
>> 
>> Well, this first document is no less important, everything hinges on it.
>> 
>> So let's think of the future system we're envisioning here. Is it going to 
>> provide "error detection" as a service? Is it going to provide "strong error 
>> detection"?
>> 
>> When making these decisions, I think we'd first need to go through the list 
>> of things provided to applications by the protocols in what Joe calls the 
>> abstract API. Probably we won't find it there: it's a static property of the 
>> protocols AFAIK. So, next, we go through all the static properties to figure 
>> out what we need to expose. Then, the question becomes: should a TAPS system 
>> decide for or against SCTP based on the level of error protection? Is this a 
>> basis for deciding for this or the other protocol?
>> 
>> These are important decisions but I think they are secondary, whereas what 
>> the protocols now explicitly offer is primary - because it would be very 
>> strange not to offer what is being offered today. We can decide to not 
>> expose "level of error protection" and give the TAPS more freedom in 
>> choosing the protocol; given that the goal is to stop connection 
>> applications to specific protocols, we CAN do that.
> I consider "protecting against bit errors" a service. And I think the level 
> is important. I agree, TCP and SCTP provide
> a protocol dependent level of protection, so there is no need to expose this 
> in the API of the particular protocol,
> however, I do think someone wants a strong checksum or not, and that will 
> influence the choice of protocols.
> So we do have services which are not configurable via the API.

Just for clarification: this wasn't about whether the level of "protection 
against bit errors" as such is important or not: I think the level of 
protection is a less important item to cover in the first document because, 
given current protocols (what this doc is about), you can't just switch it on 
or off - it comes with a choice of a whole protocol. So it's just a part of a 
protocol description - static protocol properties that come as a whole whenever 
you pick the protocol.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> On 05 Jun 2015, at 15:52, Michael Tuexen  
> wrote:
> 
>> On 05 Jun 2015, at 15:39, Michael Welzl  wrote:
>> 
>> 
>>> On 05 Jun 2015, at 12:35, Michael Tuexen  
>>> wrote:
>>> 
>>>> On 05 Jun 2015, at 11:05, Michael Welzl  wrote:
>>>> 
>>>> 
>>>>> On 5. jun. 2015, at 10.12, Mirja Kühlewind 
>>>>>  wrote:
>>>>> 
>>>>> Okay, just to quickly clarify. In the charter only the word service is 
>>>>> used. We defined later on the words component and feature which are 
>>>>> currently not reflected in the charter. The part I've cited below, I 
>>>>> think, it should say components. However, it does not really matter 
>>>>> because we will in the current document first identify components and 
>>>>> then discuss features. In any case this document will not define a new 
>>>>> interface.
>>>> 
>>>> I got that but I disagree about "it should say components" for the part in 
>>>> the charter: from the definition, the component is an implementation, not 
>>>> what is exposed to the application. I think the more important part is to 
>>>> capture what's exposed to the application. For example: SCTP has a 
>>>> component called "strong error detection (CRC32C)". TCP has a component 
>>>> called "error detection (checksum)". This is probably not exposed to the 
>>>> application as such by any of these protocols. I'll explain below why this 
>>>> makes it less important in my opinion...
>>>> 
>>>> 
>>>>> I'd also say that this is not the flag ship document (as stated by Joe). 
>>>>> The flagship document probably is the third item on the charter which 
>>>>> then will probably also talk about the interface in more detail (charter 
>>>>> says on the third doc: "This document will explain how to select and 
>>>>> engage an appropriate protocol ...").
>>>> 
>>>> Well, this first document is no less important, everything hinges on it.
>>>> 
>>>> So let's think of the future system we're envisioning here. Is it going to 
>>>> provide "error detection" as a service? Is it going to provide "strong 
>>>> error detection"?
>>>> 
>>>> When making these decisions, I think we'd first need to go through the 
>>>> list of things provided to applications by the protocols in what Joe calls 
>>>> the abstract API. Probably we won't find it there: it's a static property 
>>>> of the protocols AFAIK. So, next, we go through all the static properties 
>>>> to figure out what we need to expose. Then, the question becomes: should a 
>>>> TAPS system decide for or against SCTP based on the level of error 
>>>> protection? Is this a basis for deciding for this or the other protocol?
>>>> 
>>>> These are important decisions but I think they are secondary, whereas what 
>>>> the protocols now explicitly offer is primary - because it would be very 
>>>> strange not to offer what is being offered today. We can decide to not 
>>>> expose "level of error protection" and give the TAPS more freedom in 
>>>> choosing the protocol; given that the goal is to stop connection 
>>>> applications to specific protocols, we CAN do that.
>>> I consider "protecting against bit errors" a service. And I think the level 
>>> is important. I agree, TCP and SCTP provide
>>> a protocol dependent level of protection, so there is no need to expose 
>>> this in the API of the particular protocol,
>>> however, I do think someone wants a strong checksum or not, and that will 
>>> influence the choice of protocols.
>>> So we do have services which are not configurable via the API.
>> 
>> Just for clarification: this wasn't about whether the level of "protection 
>> against bit errors" as such is important or not: I think the level of 
>> protection is a less important item to cover in the first document because, 
>> given current protocols (what this doc is about), you can't just switch it 
>> on or off - it comes with a choice of a whole protocol. So it's just a part 
>> of a protocol description - static protocol properties that come as a whole 
>> whenever you pick the protocol.
> Such as "reliable" for TCP? Or &qu

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> On 5. jun. 2015, at 19.52, Michael Tuexen  
> wrote:
> 
>> On 05 Jun 2015, at 16:03, Michael Welzl  wrote:
>> 
>> 
>>> On 05 Jun 2015, at 15:52, Michael Tuexen  
>>> wrote:
>>> 
>>>> On 05 Jun 2015, at 15:39, Michael Welzl  wrote:
>>>> 
>>>> 
>>>>> On 05 Jun 2015, at 12:35, Michael Tuexen 
>>>>>  wrote:
>>>>> 
>>>>>> On 05 Jun 2015, at 11:05, Michael Welzl  wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 5. jun. 2015, at 10.12, Mirja Kühlewind 
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> Okay, just to quickly clarify. In the charter only the word service is 
>>>>>>> used. We defined later on the words component and feature which are 
>>>>>>> currently not reflected in the charter. The part I've cited below, I 
>>>>>>> think, it should say components. However, it does not really matter 
>>>>>>> because we will in the current document first identify components and 
>>>>>>> then discuss features. In any case this document will not define a new 
>>>>>>> interface.
>>>>>> 
>>>>>> I got that but I disagree about "it should say components" for the part 
>>>>>> in the charter: from the definition, the component is an implementation, 
>>>>>> not what is exposed to the application. I think the more important part 
>>>>>> is to capture what's exposed to the application. For example: SCTP has a 
>>>>>> component called "strong error detection (CRC32C)". TCP has a component 
>>>>>> called "error detection (checksum)". This is probably not exposed to the 
>>>>>> application as such by any of these protocols. I'll explain below why 
>>>>>> this makes it less important in my opinion...
>>>>>> 
>>>>>> 
>>>>>>> I'd also say that this is not the flag ship document (as stated by 
>>>>>>> Joe). The flagship document probably is the third item on the charter 
>>>>>>> which then will probably also talk about the interface in more detail 
>>>>>>> (charter says on the third doc: "This document will explain how to 
>>>>>>> select and engage an appropriate protocol ...").
>>>>>> 
>>>>>> Well, this first document is no less important, everything hinges on it.
>>>>>> 
>>>>>> So let's think of the future system we're envisioning here. Is it going 
>>>>>> to provide "error detection" as a service? Is it going to provide 
>>>>>> "strong error detection"?
>>>>>> 
>>>>>> When making these decisions, I think we'd first need to go through the 
>>>>>> list of things provided to applications by the protocols in what Joe 
>>>>>> calls the abstract API. Probably we won't find it there: it's a static 
>>>>>> property of the protocols AFAIK. So, next, we go through all the static 
>>>>>> properties to figure out what we need to expose. Then, the question 
>>>>>> becomes: should a TAPS system decide for or against SCTP based on the 
>>>>>> level of error protection? Is this a basis for deciding for this or the 
>>>>>> other protocol?
>>>>>> 
>>>>>> These are important decisions but I think they are secondary, whereas 
>>>>>> what the protocols now explicitly offer is primary - because it would be 
>>>>>> very strange not to offer what is being offered today. We can decide to 
>>>>>> not expose "level of error protection" and give the TAPS more freedom in 
>>>>>> choosing the protocol; given that the goal is to stop connection 
>>>>>> applications to specific protocols, we CAN do that.
>>>>> I consider "protecting against bit errors" a service. And I think the 
>>>>> level is important. I agree, TCP and SCTP provide
>>>>> a protocol dependent level of protection, so there is no need to expose 
>>>>> this in the API of the particular protocol,
>>>>> however, I do think someone wants a strong checksum or not, and that will 
>>>>> influence the choice of protocols.
>>>>>

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

I do, too - I didn't mean that we should merge the abstract APIs together right 
now, in this first doc! This was just about the thought process - while my 
answer to Michael Tuexen is "yes, I meant the complete abstract API", that was 
just about what we could eventually get from having a complete view of this API.


> On 6. jun. 2015, at 06.37, Marie-Jose Montpetit  wrote:
> 
> I completely agree.
> 
> Marie-Jose Montpetit, Ph.D.
> mari...@mit.edu
> @SocialTVMIT
> 
>> On Jun 6, 2015, at 12:12 AM, Anna Brunstrom  wrote:
>> 
>> 
>> On 2015-06-05 22:17, Michael Welzl wrote:
>>>> On 5. jun. 2015, at 19.52, Michael Tuexen 
>>>>  wrote:
>>>> 
>>>>> On 05 Jun 2015, at 16:03, Michael Welzl  wrote:
>>>>> 
>>>>> 
>>>>>> On 05 Jun 2015, at 15:52, Michael Tuexen 
>>>>>>  wrote:
>>>>>> 
>>>>>>> On 05 Jun 2015, at 15:39, Michael Welzl  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On 05 Jun 2015, at 12:35, Michael Tuexen 
>>>>>>>>  wrote:
>>>>>>>> 
>>>>>>>>> On 05 Jun 2015, at 11:05, Michael Welzl  wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 5. jun. 2015, at 10.12, Mirja Kühlewind 
>>>>>>>>>>  wrote:
>>>>>>>>>> 
>>>>>>>>>> Okay, just to quickly clarify. In the charter only the word service 
>>>>>>>>>> is used. We defined later on the words component and feature which 
>>>>>>>>>> are currently not reflected in the charter. The part I've cited 
>>>>>>>>>> below, I think, it should say components. However, it does not 
>>>>>>>>>> really matter because we will in the current document first identify 
>>>>>>>>>> components and then discuss features. In any case this document will 
>>>>>>>>>> not define a new interface.
>>>>>>>>> I got that but I disagree about "it should say components" for the 
>>>>>>>>> part in the charter: from the definition, the component is an 
>>>>>>>>> implementation, not what is exposed to the application. I think the 
>>>>>>>>> more important part is to capture what's exposed to the application. 
>>>>>>>>> For example: SCTP has a component called "strong error detection 
>>>>>>>>> (CRC32C)". TCP has a component called "error detection (checksum)". 
>>>>>>>>> This is probably not exposed to the application as such by any of 
>>>>>>>>> these protocols. I'll explain below why this makes it less important 
>>>>>>>>> in my opinion...
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> I'd also say that this is not the flag ship document (as stated by 
>>>>>>>>>> Joe). The flagship document probably is the third item on the 
>>>>>>>>>> charter which then will probably also talk about the interface in 
>>>>>>>>>> more detail (charter says on the third doc: "This document will 
>>>>>>>>>> explain how to select and engage an appropriate protocol ...").
>>>>>>>>> Well, this first document is no less important, everything hinges on 
>>>>>>>>> it.
>>>>>>>>> 
>>>>>>>>> So let's think of the future system we're envisioning here. Is it 
>>>>>>>>> going to provide "error detection" as a service? Is it going to 
>>>>>>>>> provide "strong error detection"?
>>>>>>>>> 
>>>>>>>>> When making these decisions, I think we'd first need to go through 
>>>>>>>>> the list of things provided to applications by the protocols in what 
>>>>>>>>> Joe calls the abstract API. Probably we won't find it there: it's a 
>>>>>>>>> static property of the protocols AFAIK. So, next, we go through all 
>>>>>>>>> the static properties to figure out what we need to expose. Then, the 
>>>>>>

Re: [Taps] TCP components

[Michael Welzl]

Hi,


> On 11 Jun 2015, at 13:52, Mirja Kühlewind  
> wrote:
> 
> Hi all,
> 
> we gave it a first try to rewrite the component section for TCP. The insight 
> I took from the discussion on the list is that components probably are much 
> more linked to the implementation (choices) a certain protocol made while 
> features are probably more high-level having the question in mind what does 
> an application potentially want/need to know.
> 
> So for the components in TCP we now have the following list:
> 
> - Connection-oriented bidirectional communication using three-way handshake 
> connection setup with
>   feature negotiation and an explicit distinction between passive and 
> active open:
>   This implies both unicast addressing and a guarantee of return 
> routability.
> - Single stream-oriented transmission:
>   The stream abstraction atop the datagram service provided by IP is 
> implemented by dividing
>   the stream into segments.
> - Limited control over segment transmission scheduling (Nagle's algorithm):
>   This allows for delay minimization in interactive applications.
> - Port multiplexing, with application-to-port mapping during connection setup:
>   Note that in the presence of network address and port translation 
> (NAPT), TCP ports are
>   in effect part of the endpoint address for forwarding purposes.
> - Full reliability based on ack-based loss detection and retransmission:
>   Loss is sensed using duplicated acks ("fast retransmit"), which places 
> a lower bound on
>   the delay inherent in this approach to reliability.
> - Error detection based on a checksum covering the network and transport 
> headers as well as payload:
>   Packets that are detected as corrupted are dropped, relying on the 
> reliability mechanism
>   to retransmit them.
> - Window-based flow control, with receiver-side window management and 
> signaling of available window:
>   Scaling the flow control window beyond 64kB requires the use of an 
> optional feature,
>   which has performance implications in environments where this option is 
> not supported.
> - Window-based congestion control reacting to loss, delay, retransmission 
> timeout, or
>   an explicit congestion signal (ECN):
>   Most commonly used is a loss signal from the reliability component's 
> retransmission mechanism.
>   TCP reacts to a congestion signal by reducing the size of the 
> congestion window;
>   retransmission timeout is generally handled with a larger reaction than 
> other signals.
> 
> We are currently still working on the list of features that results from 
> thiese components but we are not there yet. Probably we not only need the 
> features itself but also properties/aspects (or however you want to call 
> this) of the feature. We already had this discussion a bit but wanted to 
> postpone the decision if we really need to define an own term for this until 
> we are sure that we need it.
> 
> We are posting this list of (TCP) components now because we would like to get 
> some feedback if this goes into the right direction/is on the right level of 
> detail before we go on and apply this also to other protocols.

I agree that the list below is closer to what I think a "component" should be 
... but looking at it, is it not even clearer now that components are not what 
TAPS is after? To me this list now contains lots and lots of details that are 
irrelevant to the service provided to the application. Not harmful to list but 
pretty useless?!

And how do you draw the line for what goes in and out of such a list? E.g., on 
which basis did you decide that FACK, FRTO, PRR and DSACK are not mentioned?

To me, this whole thing is just too full of arbitrariness. We should aim for a 
systematic approach that minimizes the number of arbitrary decisions made IMO.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Michael Welzl]

On Jun 17, 2015, at 10:28 AM, Mirja Kühlewind  
wrote:

> Hi Michael,
> 
> see below.
> 
>> Am 17.06.2015 um 09:36 schrieb Michael Welzl :
>> 
>> Hi,
>> 
>> 
>>> On 11 Jun 2015, at 13:52, Mirja Kühlewind  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> we gave it a first try to rewrite the component section for TCP. The 
>>> insight I took from the discussion on the list is that components probably 
>>> are much more linked to the implementation (choices) a certain protocol 
>>> made while features are probably more high-level having the question in 
>>> mind what does an application potentially want/need to know.
>>> 
>>> So for the components in TCP we now have the following list:
>>> 
>>> - Connection-oriented bidirectional communication using three-way handshake 
>>> connection setup with
>>> feature negotiation and an explicit distinction between passive and 
>>> active open:
>>> This implies both unicast addressing and a guarantee of return 
>>> routability.
>>> - Single stream-oriented transmission:
>>> The stream abstraction atop the datagram service provided by IP is 
>>> implemented by dividing
>>> the stream into segments.
>>> - Limited control over segment transmission scheduling (Nagle's algorithm):
>>> This allows for delay minimization in interactive applications.
>>> - Port multiplexing, with application-to-port mapping during connection 
>>> setup:
>>> Note that in the presence of network address and port translation 
>>> (NAPT), TCP ports are
>>> in effect part of the endpoint address for forwarding purposes.
>>> - Full reliability based on ack-based loss detection and retransmission:
>>> Loss is sensed using duplicated acks ("fast retransmit"), which places 
>>> a lower bound on
>>> the delay inherent in this approach to reliability.
>>> - Error detection based on a checksum covering the network and transport 
>>> headers as well as payload:
>>> Packets that are detected as corrupted are dropped, relying on the 
>>> reliability mechanism
>>> to retransmit them.
>>> - Window-based flow control, with receiver-side window management and 
>>> signaling of available window:
>>> Scaling the flow control window beyond 64kB requires the use of an 
>>> optional feature,
>>> which has performance implications in environments where this option is 
>>> not supported.
>>> - Window-based congestion control reacting to loss, delay, retransmission 
>>> timeout, or
>>> an explicit congestion signal (ECN):
>>> Most commonly used is a loss signal from the reliability component's 
>>> retransmission mechanism.
>>> TCP reacts to a congestion signal by reducing the size of the 
>>> congestion window;
>>> retransmission timeout is generally handled with a larger reaction than 
>>> other signals.
>>> 
>>> We are currently still working on the list of features that results from 
>>> thiese components but we are not there yet. Probably we not only need the 
>>> features itself but also properties/aspects (or however you want to call 
>>> this) of the feature. We already had this discussion a bit but wanted to 
>>> postpone the decision if we really need to define an own term for this 
>>> until we are sure that we need it.
>>> 
>>> We are posting this list of (TCP) components now because we would like to 
>>> get some feedback if this goes into the right direction/is on the right 
>>> level of detail before we go on and apply this also to other protocols.
>> 
>> I agree that the list below is closer to what I think a "component" should 
>> be ... but looking at it, is it not even clearer now that components are not 
>> what TAPS is after? To me this list now contains lots and lots of details 
>> that are irrelevant to the service provided to the application. Not harmful 
>> to list but pretty useless?!
> 
> In this case we decided to list/discuss rather some more details, so that 
> people can understand what we had in mind. We might remove some of these 
> details/explanations at the end (or move those parts that are actually 
> relevant into the feature section (4)).
> 
>> 
>> And how do you draw the line for what goes in and out of such a list? E.g., 
>> on which basis did you decide that FACK, FRTO, PRR and DSACK are not 
>>

Re: [Taps] TCP components

[Michael Welzl]

> On 18 Jun 2015, at 10:48, Mirja Kühlewind  
> wrote:
> 
> Hi Joe,
> 
> I believe the approach Michael is proposing is to look at existing APIs as a 
> starting point; not only abstract APIs.

No, wrong. Only abstract ones from RFCs, I said this before. These things would 
typically have preceding IETF debate, whereas trying to cover implementations 
is a huge and probably meaningless endeavour (the bar may be high for adding 
function calls to an API on system X and low for an API on system Y).


> 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. 
> However, everybody who has time and is interested in this can of course 
> provide his/her outcome as input for this document and we will happily take 
> it and compare it to what we have so far.

But you misunderstood me. I was talking about RFCs (btw 6458, not 4960), not 
implementations out there.

More below, answering Joe  (hm, that rhymes ;-)  ) -


> 
> Mirja
> 
> 
>> Am 17.06.2015 um 20:10 schrieb Joe Touch :
>> 
>> 
>> 
>> On 6/17/2015 1:44 AM, Michael Welzl wrote:
>>> I think that this discussion with Joe maybe suffered from focusing on
>>> TCP. 
>> 
>> To be fair, TCP has a simpler abstract API.
>> 
>>> SCTP is perhaps a better starting point because it supports
>>> almost everything. 
>> 
>> IMO, that makes it very hard as a starting point, and I also think that
>> TCP's variant of an API description is much better as an example.
>> 
>> E.g., Section 10 of RFC4960 claims it defines an abstract API
>> (ULP-to_SCTP), but it begins by describing a call to initialize a data
>> structure (INITIALIZE). That's decidedly NOT an abstract API; it's a
>> generic description of an implementation issue.
>> 
>> IMO, if we don't understand the difference between the API in RFC793 vs.
>> that in RFC4960 (and why 793 is a better example), then this is going to
>> be a very bumpy road.

How abstract it is in the RFC indeed isn't my main concern here: it's to start 
with the interface (however abstract it is) offered to applications as 
described in the RFCs, as this reflects what the designers (with some level of 
IETF consensus) thought should be exposed.
Now, of course SCTP has more options and is more complex in its usage than TCP, 
but it covers a larger part of the space of services in protocols - so I 
thought it's a good starting point, as in: 80% done by looking at 1 protocol, 
check the others for the remaining 20%. Something like that.

This is just me being pragmatic and trying to have a more systematic approach 
to developing a list of services. I agree with Brian that some level of 
arbitrariness will always be there, but we must try to minimize it I think.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Michael Welzl]

> On 17 Jun 2015, at 12:13, Brian Trammell  wrote:
> 
> hi Michael, all,
> 
> A couple of random points inline at various levels of quotation...
> 
>> On 17 Jun 2015, at 10:44, Michael Welzl  wrote:
>> 
>> 
>> On Jun 17, 2015, at 10:28 AM, Mirja Kühlewind 
>>  wrote:
>> 
>>> Hi Michael,
>>> 
>>> see below.
>>> 
>>>> Am 17.06.2015 um 09:36 schrieb Michael Welzl :
>>>> 
>>>> Hi,
>>>> 
>>>> 
>>>>> On 11 Jun 2015, at 13:52, Mirja Kühlewind 
>>>>>  wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> we gave it a first try to rewrite the component section for TCP. The 
>>>>> insight I took from the discussion on the list is that components 
>>>>> probably are much more linked to the implementation (choices) a certain 
>>>>> protocol made while features are probably more high-level having the 
>>>>> question in mind what does an application potentially want/need to know.
>>>>> 
>>>>> So for the components in TCP we now have the following list:
>>>>> 
>>>>> - Connection-oriented bidirectional communication using three-way 
>>>>> handshake connection setup with
>>>>>   feature negotiation and an explicit distinction between passive and 
>>>>> active open:
>>>>>   This implies both unicast addressing and a guarantee of return 
>>>>> routability.
>>>>> - Single stream-oriented transmission:
>>>>>   The stream abstraction atop the datagram service provided by IP is 
>>>>> implemented by dividing
>>>>>   the stream into segments.
>>>>> - Limited control over segment transmission scheduling (Nagle's 
>>>>> algorithm):
>>>>>   This allows for delay minimization in interactive applications.
>>>>> - Port multiplexing, with application-to-port mapping during connection 
>>>>> setup:
>>>>>   Note that in the presence of network address and port translation 
>>>>> (NAPT), TCP ports are
>>>>>   in effect part of the endpoint address for forwarding purposes.
>>>>> - Full reliability based on ack-based loss detection and retransmission:
>>>>>   Loss is sensed using duplicated acks ("fast retransmit"), which places 
>>>>> a lower bound on
>>>>>   the delay inherent in this approach to reliability.
>>>>> - Error detection based on a checksum covering the network and transport 
>>>>> headers as well as payload:
>>>>>   Packets that are detected as corrupted are dropped, relying on the 
>>>>> reliability mechanism
>>>>>   to retransmit them.
>>>>> - Window-based flow control, with receiver-side window management and 
>>>>> signaling of available window:
>>>>>   Scaling the flow control window beyond 64kB requires the use of an 
>>>>> optional feature,
>>>>>   which has performance implications in environments where this option is 
>>>>> not supported.
>>>>> - Window-based congestion control reacting to loss, delay, retransmission 
>>>>> timeout, or
>>>>>   an explicit congestion signal (ECN):
>>>>>   Most commonly used is a loss signal from the reliability component's 
>>>>> retransmission mechanism.
>>>>>   TCP reacts to a congestion signal by reducing the size of the 
>>>>> congestion window;
>>>>>   retransmission timeout is generally handled with a larger reaction than 
>>>>> other signals.
>>>>> 
>>>>> We are currently still working on the list of features that results from 
>>>>> thiese components but we are not there yet. Probably we not only need the 
>>>>> features itself but also properties/aspects (or however you want to call 
>>>>> this) of the feature. We already had this discussion a bit but wanted to 
>>>>> postpone the decision if we really need to define an own term for this 
>>>>> until we are sure that we need it.
>>>>> 
>>>>> We are posting this list of (TCP) components now because we would like to 
>>>>> get some feedback if this goes into the right direction/is on the right 
>>>>> level of detail before we go on and apply this also to other protocols.
>>>> 
>>>

Re: [Taps] TCP components

[Michael Welzl]

> On 18. jun. 2015, at 15.56, Mirja Kühlewind  
> wrote:
> 
> Hi Michael,
> 
>> Am 18.06.2015 um 15:43 schrieb Michael Welzl :
>> 
>> 
>>> On 18 Jun 2015, at 10:48, Mirja Kühlewind  
>>> wrote:
>>> 
>>> Hi Joe,
>>> 
>>> I believe the approach Michael is proposing is to look at existing APIs as 
>>> a starting point; not only abstract APIs.
>> 
>> No, wrong. Only abstract ones from RFCs, I said this before. These things 
>> would typically have preceding IETF debate, whereas trying to cover 
>> implementations is a huge and probably meaningless endeavour (the bar may be 
>> high for adding function calls to an API on system X and low for an API on 
>> system Y).
> 
> Okay, but then I don’t really understand your approach fully. Yes we should 
> document and look at what’s already specified in RFC, however isn’t the goal 
> of taps to actually figure out how to change/extend/improve these APIs? How 
> can we figure out what’s missing/wrong if we only look at what’s already 
> there?

*My* goal is, and has always been, to provide a simpler, general API that is 
protocol independent. Note that this is not only for simplicity for ease of use 
BUT also for the sake of being able to automatize. After all the major goal is 
to remove the strict binding between applications and a specific protocol 
choice.

To be able to do this (documents 2 and 3), we first need a list of the existing 
services - our toolbox, if you wish (document 1). Figuring out what's missing / 
wrong about today's APIs (except that they are bound to a specific protocol) 
has never been *my* major intention, and I certainly don't see that as the goal 
of this document. I'd be surprised if that's what the charter suggests?! But of 
course my opinion is only what it is, the charter reflects the consensus...

All this being said, it can be a nice side-effect of the document (and note 
that noone knows what a TAPS system will really look like, and how these RFCs 
will actually end up being used). So I'm not strongly opposing the approach 
you're now following in that I don't see a big issue with there being a list of 
components - I just think it's not particularly useful for the goal of the 
document and doesn't really help the group progress towards its goals. I 
thought that proposing something more systematic with less arbitrariness could 
make it easier to put everyone in the same boat (in a way: "look, the boat HAS 
to be like that, there wasn't much choice, sit down please" rather than "sorry 
I painted it green, I like that color; I can understand you would have 
preferred a blue boat...").

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Michael Welzl]

> On 19 Jun 2015, at 12:07, Brian Trammell  wrote:
> 
> hi Michael,
> 
> A few replies inline.
> 
>> On 18 Jun 2015, at 15:54, Michael Welzl  wrote:
>> 
>> 
>>> On 17 Jun 2015, at 12:13, Brian Trammell  wrote:
>>> 
>>> hi Michael, all,
>>> 
>>> A couple of random points inline at various levels of quotation...
>>> 
>>>> On 17 Jun 2015, at 10:44, Michael Welzl  wrote:
>>>> 
>>>>>> 
>>>>>> I agree that the list below is closer to what I think a "component" 
>>>>>> should be ... but looking at it, is it not even clearer now that 
>>>>>> components are not what TAPS is after? To me this list now contains lots 
>>>>>> and lots of details that are irrelevant to the service provided to the 
>>>>>> application.
>>> 
>>> That's part of the point we're trying to address here. The realization we 
>>> had here is that components *don't* necessarily map to feature, and it's 
>>> not clear that we can simply ignore those components that don't map, since 
>>> they may have impact on the interfaces/features it is possible to 
>>> (reasonably) implement atop those protocols.
>>> 
>>>>>> Not harmful to list but pretty useless?!
>>> 
>>> Let's start with TCP as probably the most difficult example (indeed, that's 
>>> why we worked out this "new" arrangement of components for TCP first). A 
>>> completely clean and unambiguous decomposition of TCP into its features -- 
>>> what, I agree, we're after in the end -- is not *really* possible, because 
>>> the protocols as defined and implemented weren't really composed of 
>>> discrete features. The evolution of loss-based congestion control, for 
>>> instance, was predicated on the particular loss signals that were available 
>>> at the time it was first defined. The error detection mechanism likewise 
>>> relies on the fact that reliability is provided by retransmission. One 
>>> could say that given the parallel evolution of computing power that all 
>>> these choices made by TCP were the only obvious ones at the time. But it's 
>>> precisely the co-evolution of reliability and congestion control that makes 
>>> gluing FEC to TCP so fraught with peril. That's an important point to 
>>> capture IMO.
>>> 
>>> I expect that the same exercise for SCTP will show a simpler mapping 
>>> between components and features, since it *was* designed as a composition 
>>> of features.
>> 
>> I expect that too, but I still don't understand the point of the component 
>> list above. I mean, yes, you may be able to map and say "we need components 
>> X Y Z to provide features A and B" but how does this help TAPS?
> 
> So as I see it, "features" are the TAPS view of the world of the future -- 
> the set of things that transport protocols can do, and that a better 
> interface can give you access to. "Components" are the view of the world of 
> the present -- what the current definitions *and deployed implementations* of 
> transport protocols can do, and what each of those features imply.
> 
> There are a few ways you can implement the TAPS API. The one we chose to 
> pursue in the WG (or at least I thought we had) is that the TAPS API takes 
> (1) information from the application about its requirements in terms of 
> features and parameters on those features (if available), (2) information 
> from the path about which transport protocols and options are usable on the 
> path, and the selects a transport protocol, and acts as glue between the API 
> and the underlying protocol.
> 
> In this approach, it is IMO important to catalog the protocol components (and 
> the interactions among them) since the mappings between components and 
> features might not be clean. This might not be the document to do that in. 
> But we wanted to do the exercise to see what the outcome looked like.

I see. Well I don't have a problem with that, I was just suggesting that this 
is probably not the path of easy agreement.


> 
> 
>>>>> However, you could go for a even more generic approach and only look at 
>>>>> the implementation and as a first step figure where are any knobs that in 
>>>>> principle could be configurable and then afterwards discuss all of these 
>>>>> very specific knobs. I though about this approach and think it would be 
>>>>> an interest exercise and

Re: [Taps] TCP components

[Michael Welzl]

> On 19 Jun 2015, at 14:03, Mirja Kühlewind  
> wrote:
> 
> Hi Michael,
> 
>> *My* goal is, and has always been, to provide a simpler, general API that is 
>> protocol independent. Note that this is not only for simplicity for ease of 
>> use BUT also for the sake of being able to automatize. After all the major 
>> goal is to remove the strict binding between applications and a specific 
>> protocol choice.
> 
> Yes, I agree! (not sure if this is simpler though… depends on the definition 
> of simple… but hopefully easier to use and understand for the overlying 
> application).

Agree too, easier to use is what I meant


>> To be able to do this (documents 2 and 3), we first need a list of the 
>> existing services - our toolbox, if you wish (document 1). Figuring out 
>> what's missing / wrong about today's APIs (except that they are bound to a 
>> specific protocol) has never been *my* major intention, and I certainly 
>> don't see that as the goal of this document. I'd be surprised if that's what 
>> the charter suggests?! But of course my opinion is only what it is, the 
>> charter reflects the consensus…
> 
> So there current API is always bound to a specify protocol which already 
> provides you a certain set of service feature. At least in TCP there is not 
> much choice left and there the current API does not give us a good indication 
> which services are actually provided by TCP. Therefore from my point of view 
> the only way to identify these services is to look at the protocol itself and 
> not only the API. In SCTP it’s different and we definitely have to and will 
> discuss the existing API in the document.

Exactly that's why I thought starting with TCP's API (even when it's the 
abstract one) is not very helpful.
Joe, Aaron: what is it you were expecting us to take away from reading section 
3.8 of RFC 793?
( I can see it highlighting the need to discuss communication patterns  (or 
decide for a specific one) in document #2, but not really contributing much to 
the list in document #1 ? )


>> All this being said, it can be a nice side-effect of the document (and note 
>> that noone knows what a TAPS system will really look like, and how these 
>> RFCs will actually end up being used). So I'm not strongly opposing the 
>> approach you're now following in that I don't see a big issue with there 
>> being a list of components - I just think it's not particularly useful for 
>> the goal of the document and doesn't really help the group progress towards 
>> its goals. I thought that proposing something more systematic with less 
>> arbitrariness could make it easier to put everyone in the same boat (in a 
>> way: "look, the boat HAS to be like that, there wasn't much choice, sit down 
>> please" rather than "sorry I painted it green, I like that color; I can 
>> understand you would have preferred a blue boat...“).
> 
> I totally understand this point. But at least for TCP I think it is not 
> sufficient to look at the (abstract) API because in TCP there are not much 
> choices and therefore the services TCP provides are not exposed over the API. 
> I personally currently don’t see how another approach would bring us the the 
> goal of identify existing services.

Agree about TCP


> Again, if you have time to work on an alternative approach, please go ahead 
> and provide input or even submit an own draft and I’m/we’re really open to 
> discuss this and see what makes more sense. 

Ok  well, I agree that what I request is easier said than done  :-( 
myself, I've been working on a first version of document #2 as I think this 
would help us understand if the set of "services" or whatever we call them in 
document #1 is useful for the group's purpose.

Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Michael Welzl]

> On 19 Jun 2015, at 14:32, Brian Trammell  wrote:
> 
> hi Michael,
> 
> continued, inline.
> 
>> On 18 Jun 2015, at 18:44, Michael Welzl  wrote:
>> 
>> 
>>> On 18. jun. 2015, at 15.56, Mirja Kühlewind 
>>>  wrote:
>>> 
>>> Hi Michael,
>>> 
>>>> Am 18.06.2015 um 15:43 schrieb Michael Welzl :
>>>> 
>>>> 
>>>>> On 18 Jun 2015, at 10:48, Mirja Kühlewind 
>>>>>  wrote:
>>>>> 
>>>>> Hi Joe,
>>>>> 
>>>>> I believe the approach Michael is proposing is to look at existing APIs 
>>>>> as a starting point; not only abstract APIs.
>>>> 
>>>> No, wrong. Only abstract ones from RFCs, I said this before. These things 
>>>> would typically have preceding IETF debate, whereas trying to cover 
>>>> implementations is a huge and probably meaningless endeavour (the bar may 
>>>> be high for adding function calls to an API on system X and low for an API 
>>>> on system Y).
>>> 
>>> Okay, but then I don’t really understand your approach fully. Yes we should 
>>> document and look at what’s already specified in RFC, however isn’t the 
>>> goal of taps to actually figure out how to change/extend/improve these 
>>> APIs? How can we figure out what’s missing/wrong if we only look at what’s 
>>> already there?
>> 
>> *My* goal is, and has always been, to provide a simpler, general API that is 
>> protocol independent.
> 
> +1, though I would at this point say "better" as opposed to "simpler" and 
> "general", with the caveat that i'm not yet sure what better looks like. This 
> gets back to my point about interaction patterns in the previous message, 
> though: if the simpler API provides only stream interaction, or packet 
> sequence interaction, or if it only allows receivers to get data through 
> asynchronous notifications, it will make it hard to support . So maybe we 
> want a better common API for defining the *requirements* of an association, 
> and better TX/RX *APIs* plural, one for each interaction pattern we want to 
> support.

I agree.


>> Note that this is not only for simplicity for ease of use BUT also for the 
>> sake of being able to automatize. After all the major goal is to remove the 
>> strict binding between applications and a specific protocol choice.
> 
> We share this higher level goal in any case.
> 
>> To be able to do this (documents 2 and 3), we first need a list of the 
>> existing services - our toolbox, if you wish (document 1). Figuring out 
>> what's missing / wrong about today's APIs (except that they are bound to a 
>> specific protocol) has never been *my* major intention, and I certainly 
>> don't see that as the goal of this document. I'd be surprised if that's what 
>> the charter suggests?! But of course my opinion is only what it is, the 
>> charter reflects the consensus...
> 
> I don't think that's in scope for this document, either. The component (and 
> decomposition) work is aimed at figuring out what the available features are, 
> and what (in a "TAPS as glue layer over existing transports" design) the 
> implications of using protocol X for feature Y are. The API work is a bit of 
> a non-sequitur (but also important to note...)
> 
>> All this being said, it can be a nice side-effect of the document (and note 
>> that noone knows what a TAPS system will really look like, and how these 
>> RFCs will actually end up being used).
> 
> In general, if there's any content in this document that is useful but 
> doesn't fit but we still find useful, we can certainly put it something else.
> 
>> So I'm not strongly opposing the approach you're now following in that I 
>> don't see a big issue with there being a list of components - I just think 
>> it's not particularly useful for the goal of the document and doesn't really 
>> help the group progress towards its goals. I thought that proposing 
>> something more systematic with less arbitrariness could make it easier to 
>> put everyone in the same boat (in a way: "look, the boat HAS to be like 
>> that, there wasn't much choice, sit down please" rather than "sorry I 
>> painted it green, I like that color; I can understand you would have 
>> preferred a blue boat...").
> 
> I agree. Given, though, that the protocols we're looking at, that they 
> weren't designed from components, it is really not clear to me how to 
>

Re: [Taps] TCP components

[Michael Welzl]

> On 20. jun. 2015, at 00.55, Joe Touch  wrote:
> 
> 
> 
> On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:
>> 
>> 
>> On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch > > wrote:
>> 
>> 
>>You're getting far ahead of the conversation, IMO. This document
>>needs to start by explaining the services we already have before
>>jumping into a "service of services" model.
>> 
>>I don't disagree with the goal, but it's impractical to develop a
>>meta-interface when the base interface has not been described.
>> 
>> 
>> It is just to say that TCP already defines its services, and the goal is
>> not to give another definition of these services, but only to change the
>> way they are exposed to applications. So the services definition already
>> exists, but implicitly.
> 
> It's explicit - see section 3.8 of RFC 793. The issue with that variant is 
> that it captures the state of TCP in 1981; it has evolved quite a bit since 
> then. Although we do have a 793-bis in the works, the update of that section 
> hasn't been tackled yet.
> 
> Let's put it this way:
> 
>   - if the goal of TAPS is to unify existing APIs,
>   then those APIs need to be summarized together in one place
> 
> 
>   - if TAPS is indeed focused solely on an alternate API,
>   then it should NOT try to 'restate' the existing TCP API
>   in a TAPS doc
> 
> "Do, or do not; there is no try."
>   - Yoda

TAPS is focused on an alternate API that it's based on existing transports. As 
a way of analyzing existing transports and creating a foundation for this API, 
document #1 is written. I think this discussion is about the approach taken to 
write document #1.

So now I wonder what you're complaining about, as you go on about TCP already 
defining its services implicitly in the API. I mean, yes it does, okay - and 
so?  You criticized the SCTP API for not being abstract enough - so clearly if 
we'd just copy+paste the API descriptions of the RFCs of the considered 
transports in a list, that would look pretty messy. You seem to want a "clean" 
approach, but you're not going to get that unless we focus on TCP alone  :-)

I've been proposing go through transport APIs and then analyze what we have, 
because this way, SCTP is already going to give us a long list of services.
You've been saying that we should start with TCP. Well okay, but the service 
list there is pretty narrow. Maybe the TCP API isn't properly described in the 
current draft, okay, I think we can take that criticism for what it is. Still, 
I don't know what you're really after - in the end, we're going to get a list 
that's pretty similar to what's there now, and that's what we want, right?

- unordered reliable delivery of messages
- delivery of messages with timed delivery
- reliable delivery of a data stream (naturally that's ordered)

 and so on. Right? Or what else is it you want / expect? 

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

[Taps] Fwd: New Version Notification for draft-gjessing-taps-minset-00.txt

[Michael Welzl]

Dear all,

This is a very first stab at a draft addressing the charter's second item - the 
minimal set of transport services that end systems should support.

It is based on version 4 of draft-ietf-taps-transports, so the list of features 
/ components is not up to date - but that's not really the main point of the 
document for now anyway:
it's about showing how the number of exposed services *could* be reduced. Our 
hope is that, by sketching the possible destination of our journey, this helps 
the current discussion of the first document.

Cheers,
Michael



> Begin forwarded message:
> 
> From: 
> Subject: New Version Notification for draft-gjessing-taps-minset-00.txt
> Date: 22 Jun 2015 14:37:43 CEST
> To: Michael Welzl , Stein Gjessing , 
> Stein Gjessing , Michael Welzl 
> Resent-From: 
> 
> 
> A new version of I-D, draft-gjessing-taps-minset-00.txt
> has been successfully submitted by Michael Welzl and posted to the
> IETF repository.
> 
> Name: draft-gjessing-taps-minset
> Revision: 00
> Title:A Minimal Set of Transport Services for TAPS Systems
> Document date:2015-06-22
> Group:Individual Submission
> Pages:10
> URL:
> https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-00.txt
> Status: https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/
> Htmlized:   https://tools.ietf.org/html/draft-gjessing-taps-minset-00
> 
> 
> Abstract:
>   This draft will eventually recommend a minimal set of IETF Transport
>   Services offered by end systems supporting TAPS, and give guidance on
>   choosing among the available mechanisms and protocols.  As a starting
>   point for discussion, it currently only gives an overview of some
>   ways to categorize the set of transport services in the first TAPS
>   document (version 4: draft-ietf-taps-transports-04), assuming that
>   the eventual minimal set of transport services will be based on a
>   similar form of categorization.
> 
> 
> 
> 
> 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
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Michael Welzl]

> On 15 Jul 2015, at 11:03, Karen Elisabeth Egede Nielsen 
>  wrote:
> 
> HI Mirja, All
> 
> Sorry for jumping late into this discussion.
> 
>> -Original Message-
>> From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of Mirja Kühlewind
>> Sent: Thursday, June 18, 2015 10:48 AM
>> To: Joe Touch
>> Cc: Brian Trammell; Michael Welzl; taps@ietf.org
>> 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 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.


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

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Michael Welzl]

> On 15 Jul 2015, at 12:40, Karen Elisabeth Egede Nielsen 
>  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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Comments on draft-gjessing-taps-minset-00.txt

[Michael Welzl]

Hi, thanks!

Below:


> On 16 Jul 2015, at 11:22, Karen Elisabeth Egede Nielsen 
>  wrote:
> 
> HI,
> 
> A few initial comments the definition of the transport service features as
> they appear from section 3 (and TAPS1):
> 
> Unidirectional/bidirectional: I am not sure what this means exactly:
> Does it refer to that data transfer is negotiated for both directions
> perhaps ? But then it only applies to connection oriented transport.
> Does it refer to that control info is going back ?
> Does it refer to that messages (which ever form) are going back on the
> reverse network path ? Then it does not necessarily apply to SCTP MH.

Sorry for not being clear enough: it means that it's a feature that can be used 
just on one side, without requiring the other side to be involved  (e.g. Nagle 
is just a sender-side mechanism).


>   o  non-reliable delivery:
>   add SCTP
> 
>   o  reliable delivery:
>add SCTP
> 
>  Suggest to rephrase
> 
>   o  reliable and partially reliable delivery
> -->
>   o  partially reliable delivery:
>  SCTP
> 
>   o  drop notification :
>   add SCTP
> 
>   o  ordered delivery:
>   add SCTP
> 
>   o  unordered delivery:
>   add SCTP

ACK, thanks


> Ideally, I think, then one would use a common term for Nagle(-like)
> bundling for TCP and SCTP.

Agreed, we actually did that in Michael Welzl, Stefan Jörer, Stein Gjessing: 
"Towards a Protocol-Independent Internet Transport API", FutureNet IV workshop 
in conjunction with of IEEE ICC 2011, 5-9 June 2011, Kyoto, Japan,
using app PDU bundling because it's more meaningful than Nagle.

But here the idea was just to copy+paste the list from doc 1 (version 4) and 
put things under the correct headings, as a way to show how we *could* apply 
categorization methods.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Comments on draft-gjessing-taps-minset-00.txt

[Michael Welzl]

> On 16. jul. 2015, at 15.04, Brian Trammell  wrote:
> 
> hi Michael,
> 
> ...inline...
> 
>> On 16 Jul 2015, at 13:23, Michael Welzl  wrote:
> 
> 
> 
>>> Ideally, I think, then one would use a common term for Nagle(-like)
>>> bundling for TCP and SCTP.
>> 
>> Agreed, we actually did that in Michael Welzl, Stefan Jörer, Stein Gjessing: 
>> "Towards a Protocol-Independent Internet Transport API", FutureNet IV 
>> workshop in conjunction with of IEEE ICC 2011, 5-9 June 2011, Kyoto, Japan,
>> using app PDU bundling because it's more meaningful than Nagle.
>> 
>> But here the idea was just to copy+paste the list from doc 1 (version 4) and 
>> put things under the correct headings, as a way to show how we *could* apply 
>> categorization methods.
> 
> hm, so perhaps we should have coordinated here. That list, in that version, 
> wasn't quite complete.

That doesn't matter - the point of the doc was to introduce the possible 
categorization and fill the "functional / non-functional" part with some 
examples so it's more understandable. If this list of examples is complete 
really doesn't matter.


> In the current version it's still not quite complete, as we're still trying 
> to nail down how to partition the space of features (and how to divide things 
> that are actually features from things that are just accidental effects of 
> the way protocols have evolved). There are also aspects of the interfaces 
> (coming from the interface discussion) we'd like to capture, on which we'd 
> like to discuss f2f next Thursday.

ACK, indeed...


> Perhaps another way to approach this would be to start with a list of 
> features we think we want in doc 2, and to use the background from doc 1 to 
> fill in the gaps...

Bad idea I think. It raises horrible memories of TAPS creation. See, I started 
this off by saying that we have to do it bottom-up, by beginning with what 
protocols can do, not what services apps could want. This has disadvantages and 
is a compromise but it comes from looking at a history of well above a decade 
of people proposing these kinds of things and nothing coming out of it. That's 
because there are so many degrees of freedom and it's practically impossible to 
end up agreeing on anything.

My take-away from TAPS creation was that people had to share this experience 
together with me: let's do it top-down - oh, really, we can't agree - and now 
we're back at what I started with: bottom up.

Please please please let's not do another round on this ride with doc 2!   :-)

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Michael Welzl]

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: 
> Subject: New Version Notification for draft-welzl-taps-transports-00.txt
> Date: 21 Sep 2015 10:35:33 CEST
> To: Michael Welzl , Michael Welzl , 
> Michael Tuexen , Naeem Khademi , 
> Michael Tuexen , Naeem Khademi 
> Resent-From: 
> 
> 
> 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
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Michael Welzl]

+1

> On 26. sep. 2015, at 13.28, Marie-Jose Montpetit  
> wrote:
> 
> Makes sense. 
> 
>> On Sep 26, 2015, at 3:17 AM, go...@erg.abdn.ac.uk 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
>>> ma...@mjmontpetit.com
>>> mari...@mit.edu
>>> 
>>>> On Sep 21, 2015, at 04:44, Michael Welzl  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: 
>>>>> Subject: New Version Notification for
>>>>> draft-welzl-taps-transports-00.txt
>>>>> Date: 21 Sep 2015 10:35:33 CEST
>>>>> To: Michael Welzl , Michael Welzl
>>>>> , Michael Tuexen , Naeem
>>>>> Khademi , Michael Tuexen ,
>>>>> Naeem Khademi 
>>>>> Resent-From: 
>>>>> 
>>>>> 
>>>>> 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
>>>> Taps@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/taps
>>> 
>>> ___
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>> 
>> 
> 

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Michael Welzl]

Hi,


> On 05 Oct 2015, at 20:42, Aaron Falk  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.

+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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] IETF planning

[Michael Welzl]

> On 19. okt. 2015, at 20.44, Aaron Falk  wrote:
> 
> Hi Folks-
> 
> So, we have these two docs and a rough agreement that they are complimentary. 
>  Gorry suggests that they both progress as responsive to milestone 1:
> 
>>  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.
> 
> Is there agreement on this?  I’ve heard no objections.  Assuming so, we 
> should move on.
> 
> First, I would ask that the authors summarize the work remaining on each doc 
> to the list and call out any topics requiring discussion at the Yokohama 
> meeting.

draft-welzl-taps-transports currently only covers TCP and SCTP. But then: how 
many other protocols?
It seems people agree that the protocols covered in draft-welzl-taps-transports 
should be a subset of the protocols covered in draft-ietf-taps-transports. My 
question is, then: how to choose the subset?

It seems obvious to include protocols that are seeing some deployment, i.e. of 
course UDP, maybe UDP-Lite (?), but also MPTCP…
However: if that is the only decision ground, we probably wouldn’t include 
DCCP. Are we then making a significant mistake, missing a lesson to be learned?

That, to me, is a discussion I’d like to have in Yokohama.


> Second, let’s hear some proposals for addressing the second milestone.  
> 
> 2) Specify the subset of those Transport Services, as identified
>in item 1, that end systems supporting TAPS will provide, and
>give guidance on choosing among available mechanisms and
>protocols.  Note that not all the capabilities of IETF Transport
>protocols need to be exposed as Transport Services.

It may not be much, but fwiw, draft-gjessing-taps-minset exists. It contains 
some ideas on how services could be narrowed down, and these could be applied 
to draft-welzl-taps-transports just as well as to draft-ietf-taps-transports  
(which it’s currently written around).

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] IETF planning

[Michael Welzl]

> On 22. okt. 2015, at 16.14, Aaron Falk  wrote:
> 
> 
> > draft-welzl-taps-transports currently only covers TCP and SCTP. But then: 
> > how many other protocols?
> > It seems people agree that the protocols covered in 
> > draft-welzl-taps-transports should be a subset of the protocols covered in 
> > draft-ietf-taps-transports. My question is, then: how to choose the subset?
> >
> > It seems obvious to include protocols that are seeing some deployment, i.e. 
> > of course UDP, maybe UDP-Lite (?), but also MPTCP…
> > However: if that is the only decision ground, we probably wouldn’t include 
> > DCCP. Are we then making a significant mistake, missing a lesson to be 
> > learned?
> >
> > That, to me, is a discussion I’d like to have in Yokohama.
> 
> +1, and FWIW that's exactly the same starting point I got to on my own.
> 
> 
> Any volunteers to kick off the lead the discussion?

Let me try to roll this some more on the list, because I gave it some thought:

The goal is to have something buildable. So if we allow protocols that are 
hardly deployed into draft-welzl-taps-transports, then this gives us a list 
that may include services that one can never implement unless hardly-deployed 
protocol X is used, or other protocols are extended to all of a sudden provide 
this functionality.

Thus, boring as it may seem, “widely deployed protocols” can be the only 
reasonable criterion to allow adding protocols in draft-welzl-taps-transports

Thoughts?

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] IETF planning

[Michael Welzl]

> On 19. okt. 2015, at 20.44, Aaron Falk  wrote:
> 
> Hi Folks-
> 
> So, we have these two docs and a rough agreement that they are complimentary. 
>  Gorry suggests that they both progress as responsive to milestone 1:
> 
>>  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.
> 
> Is there agreement on this?  I’ve heard no objections.  Assuming so, we 
> should move on.

=> So, I’d like to ask for WG adoption of draft-welzl-taps-transports

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] IETF planning

[Michael Welzl]

> On 22. okt. 2015, at 22.23, Brian Trammell  wrote:
> 
> hi Michael,
> 
>> On 22 Oct 2015, at 18:19, Michael Welzl  wrote:
>> 
>> 
>>> On 22. okt. 2015, at 16.14, Aaron Falk  wrote:
>>> 
>>> 
>>>> draft-welzl-taps-transports currently only covers TCP and SCTP. But then: 
>>>> how many other protocols?
>>>> It seems people agree that the protocols covered in 
>>>> draft-welzl-taps-transports should be a subset of the protocols covered in 
>>>> draft-ietf-taps-transports. My question is, then: how to choose the subset?
>>>> 
>>>> It seems obvious to include protocols that are seeing some deployment, 
>>>> i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP…
>>>> However: if that is the only decision ground, we probably wouldn’t include 
>>>> DCCP. Are we then making a significant mistake, missing a lesson to be 
>>>> learned?
>>>> 
>>>> That, to me, is a discussion I’d like to have in Yokohama.
>>> 
>>> +1, and FWIW that's exactly the same starting point I got to on my own.
>>> 
>>> 
>>> Any volunteers to kick off the lead the discussion?
>> 
>> Let me try to roll this some more on the list, because I gave it some 
>> thought:
>> 
>> The goal is to have something buildable. So if we allow protocols that are 
>> hardly deployed into draft-welzl-taps-transports, then this gives us a list 
>> that may include services that one can never implement unless 
>> hardly-deployed protocol X is used, or other protocols are extended to all 
>> of a sudden provide this functionality.
>> 
>> Thus, boring as it may seem, “widely deployed protocols” can be the only 
>> reasonable criterion to allow adding protocols in draft-welzl-taps-transports
> 
> s/widely deployed/widely implemented/g, but yes.

Agreed


> Another thought: draft-gjessing (as it currently is) looks at the minimal set 
> of services. If there are services we believe are useful to support that are 
> not presently widely implemented or deployed, we can certainly add them as 
> optional, no? The only services that could not be handled in such a way would 
> be those that have an impact on the API other than just adding knobs and 
> meters, no?

Sorry, you lose me here - in particular I don’t get the part about “have an 
impact on the API…”. Could you maybe give a toy example?

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] IETF planning

[Michael Welzl]

Hi,

About this:

> Second, let’s hear some proposals for addressing the second milestone.  
> 
> 2) Specify the subset of those Transport Services, as identified
>in item 1, that end systems supporting TAPS will provide, and
>give guidance on choosing among available mechanisms and
>protocols.  Note that not all the capabilities of IETF Transport
>protocols need to be exposed as Transport Services.

I think this should be based on the services in draft-welzl-taps-transports. 
Then, isn’t it a bit premature to worry about this second item? Yes I think we 
can progress fast with draft-welzl-taps-transports, but still it’s only the 
first version now. I think this item should therefore wait a bit.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] IETF planning

[Michael Welzl]

> On 26. okt. 2015, at 14.17, Aaron Falk  wrote:
> 
> On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst  > wrote:
> On 22/10/2015 15:14, Aaron Falk wrote:
> 
> > draft-welzl-taps-transports currently only covers TCP and SCTP. But 
> then: how many other protocols?
> > It seems people agree that the protocols covered in 
> draft-welzl-taps-transports should be a subset of the protocols covered in 
> draft-ietf-taps-transports. My question is, then: how to choose the subset?
> >
> > It seems obvious to include protocols that are seeing some deployment, 
> i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP…
> > However: if that is the only decision ground, we probably wouldn’t 
> include DCCP. Are we then making a significant mistake, missing a lesson to 
> be learned?
> >
> > That, to me, is a discussion I’d like to have in Yokohama.
> 
> +1, and FWIW that's exactly the same starting point I got to on my own.
> 
> 
> Any volunteers to kick off the lead the discussion?
> 
> 
> 
> 
> 
> So, I think UDP, and UDP-Lite *NEED* to be included. MPTCOP also.

Assuming this is a typo and you mean MPTCP, I agree.


> On DCCP, this has many services being re-invented above. I think we have an 
> interesting dilemma about whether to describe this, I suggest one of the 
> reason for the minimal use of DCCP (DCCP/UDP) could well be the lack of a 
> framework that allows this to be done without recoding an app. So, if we had 
> such a framework *WHEN* DCCP/UDP was done, we may now have seen more usage.

I understand and agree, but that doesn’t help us now…



> I don't understand.  Why leave out any of the protocols included in 
> draft-ietf-taps-transports?  Is there an argument other than for expedience?

Working towards a realistic end-goal of a deployable system.

So we’re i) describing services; ii) narrowing them down somehow; iii) 
describing how to build this thing.
My concern is with iii) being something feasible and useful, not an obscure 
sci-fi document.

Say we include DCCP. It’ll add some services that aren’t in the other protocols 
listed so far in this mail - e.g. drop notification (see section 3.6.3 in 
draft-ietf-taps-transports). Say, in step ii), we find no good arguments to 
remove drop notification. Then, in step iii), we’ll have to say how a TAPS 
system can support drop notification. So, to build a working TAPS system, one 
has to either:
- include DCCP in the code base
- extend other protocols to provide this functionality

None of these two options are very helpful if we want to TAPS to be real thing 
one day.

I understand that we can see these as optional, and end up with a document iii) 
that has a small mandatory base and lots of optional things - but this will 
then be a huge document, of which only a small subset will ever be implemented. 
Personally I think that’s a possibility but not really what we should aim at.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] IETF planning

[Michael Welzl]

> On 26. okt. 2015, at 15.46, Gorry Fairhurst  wrote:
> 
> On 26/10/2015 13:46, Michael Welzl wrote:
>> 
>>> On 26. okt. 2015, at 14.17, Aaron Falk >> <mailto:aaron.f...@gmail.com>> wrote:
>>> 
>>> On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst >> <mailto:go...@erg.abdn.ac.uk>> wrote:
>>> 
>>>On 22/10/2015 15:14, Aaron Falk wrote:
>>> 
>>> 
>>>> draft-welzl-taps-transports currently only covers TCP
>>>and SCTP. But then: how many other protocols?
>>>> It seems people agree that the protocols covered in
>>>draft-welzl-taps-transports should be a subset of the
>>>protocols covered in draft-ietf-taps-transports. My question
>>>is, then: how to choose the subset?
>>>>
>>>> It seems obvious to include protocols that are seeing
>>>some deployment, i.e. of course UDP, maybe UDP-Lite (?), but
>>>also MPTCP…
>>>> However: if that is the only decision ground, we
>>>probably wouldn’t include DCCP. Are we then making a
>>>significant mistake, missing a lesson to be learned?
>>>>
>>>> That, to me, is a discussion I’d like to have in Yokohama.
>>> 
>>>+1, and FWIW that's exactly the same starting point I got
>>>to on my own.
>>> 
>>> 
>>>Any volunteers to kick off the lead the discussion?
>>> 
>>> 
>>> 
>>>
>>> 
>>>So, I think UDP, and UDP-Lite *NEED* to be included. MPTCOP also.
>> 
>> Assuming this is a typo and you mean MPTCP, I agree.
>> 
> Then we agree on this.

… and I guess we should add TLS, DTLS to that list.


>>>On DCCP, this has many services being re-invented above. I think
>>>we have an interesting dilemma about whether to describe this, I
>>>suggest one of the reason for the minimal use of DCCP (DCCP/UDP)
>>>could well be the lack of a framework that allows this to be done
>>>without recoding an app. So, if we had such a framework *WHEN*
>>>DCCP/UDP was done, we may now have seen more usage.
>> 
>> I understand and agree, but that doesn’t help us now…
>> 
>> 
>>> I don't understand.  Why leave out any of the protocols included in
>>> draft-ietf-taps-transports?  Is there an argument other than for
>>> expedience?
>> 
>> Working towards a realistic end-goal of a deployable system.
>> 
>> So we’re i) describing services; ii) narrowing them down somehow; iii)
>> describing how to build this thing.
>> My concern is with iii) being something feasible and useful, not an
>> obscure sci-fi document.
>> 
>> Say we include DCCP. It’ll add some services that aren’t in the other
>> protocols listed so far in this mail - e.g. drop notification (see
>> section 3.6.3 in draft-ietf-taps-transports). Say, in step ii), we find
>> no good arguments to remove drop notification. Then, in step iii), we’ll
>> have to say how a TAPS system can support drop notification. So, to
>> build a working TAPS system, one has to either:
>> - include DCCP in the code base
>> - extend other protocols to provide this functionality
>> 
>> None of these two options are very helpful if we want to TAPS to be real
>> thing one day.
>> 
>> I understand that we can see these as optional, and end up with a
>> document iii) that has a small mandatory base and lots of optional
>> things - but this will then be a huge document, of which only a small
>> subset will ever be implemented. Personally I think that’s a possibility
>> but not really what we should aim at.
>> 
>> Cheers,
>> Michael
>> 
> Yes, that discussion is probably consistent with my thinking - If we want to 
> focus on what can be made right now, we can't include DCCP - not because it 
> can't be done - a lot of code has been written, and we understand the spec - 
> but because it's one step further-on than we currently can achieve easily in 
> the first pass. (If that's the motivation for excluding it, I would 
> understand at this stage.)
> 
> I think one could say the same for other protocols that could/have been 
> layered over UDP. Does that also therefore mean we don't currently include 
> such other protocols?

Which protocols are you thinking of? I think the argument about widespread 
implementation and use, not whether it’s run over UDP or not…

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] IETF planning

[Michael Welzl]

> On 27. okt. 2015, at 10.44, Karen Elisabeth Egede Nielsen 
>  wrote:
> 
> HI,
> 
> Just a note. Not necessarily relevant for the overall argument however.
> 
>>> 
>>> So we’re i) describing services; ii) narrowing them down somehow; iii)
>>> describing how to build this thing.
>>> My concern is with iii) being something feasible and useful, not an
>>> obscure sci-fi document.
>>> 
>>> Say we include DCCP. It’ll add some services that aren’t in the other
>>> protocols listed so far in this mail - e.g. drop notification (see
>>> section 3.6.3 in draft-ietf-taps-transports). Say, in step ii), we
>>> find no good arguments to remove drop notification. Then, in step
>>> iii), we’ll have to say how a TAPS system can support drop
>>> notification. So, to build a working TAPS system, one has to either:
>>> - include DCCP in the code base
>>> - extend other protocols to provide this functionality
>>> 
> 
> SCTP also provides drop notification (SEND_FAILURE).

… and it’s actually covered in draft-welzl-taps-transports, on page 16  ( 
https://tools.ietf.org/html/draft-welzl-taps-transports-00#section-4.2 ). Silly 
me!

It’s an interesting example, though: forgetting that drop notification (with a 
cause code) exists in SCTP, I picked “drop notification” as an example service 
of DCCP because I remembered it as an interesting functionality when the 
protocol was made, and (more importantly) because it kind of stood out in the 
list in draft-ietf-transports.

Maybe the right thing to do is to use the list of “transport features" in 
draft-ietf-transports to see if a protocol adds anything new to the mix or is 
really just essentially duplicating services that already exist in the other 
protocols in draft-welzl-taps-transports, and use that to decide whether to 
include a protocol or not?

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] IETF planning

[Michael Welzl]

> On 26. okt. 2015, at 17.35, Aaron Falk  wrote:
> 
> On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl  <mailto:mich...@ifi.uio.no>> wrote:
> 
> Working towards a realistic end-goal of a deployable system.
> 
> So we’re i) describing services; ii) narrowing them down somehow; iii) 
> describing how to build this thing.
> My concern is with iii) being something feasible and useful, not an obscure 
> sci-fi document.
> 
> Uh, yeah.  That's our charter.  Narrowing down is in doc 2.  Are you making 
> the case we should do it in doc 1?  

Well, just because we narrow down in doc 2 doesn’t mean that doc 1 has to 
contain everything under the sun as a starting point. Consider the discussion 
around RTP in draft-ietf-taps-transports - I think the consensus was to have 
only very short text on RTP in there, not a list of all the protocol features. 
The starting point for draft-welzl-taps-transports should probably be limited 
in a similar way, but I’d suggest limiting it more than 
draft-ietf-taps-transports - partially because draft-ietf-taps-transports can 
already show that certain protocols are not adding new transport features to 
the mix that don’t yet exist.

Of course, the main reason behind my argument is to keep 
draft-welzl-taps-transports within a reasonable length. Look at its length now, 
with only two protocols!  I think the length is inevitable, but if we have good 
reasons not to cover certain protocols, I think we should keep them out. At 
least it’s a valuable discussion to have!


> Say we include DCCP. It’ll add some services that aren’t in the other 
> protocols listed so far in this mail - e.g. drop notification (see section 
> 3.6.3 in draft-ietf-taps-transports). Say, in step ii), we find no good 
> arguments to remove drop notification. Then, in step iii), we’ll have to say 
> how a TAPS system can support drop notification. So, to build a working TAPS 
> system, one has to either:
> - include DCCP in the code base
> - extend other protocols to provide this functionality
> 
> None of these two options are very helpful if we want to TAPS to be real 
> thing one day.
> 
> a: TAPS is not chartered to do anything normative.  Doc 3 is about 
> experimenting.

Sure! But it’s still about stuff that someone should be able to build - I just 
don’t want doc 3 to become a sci-fi literature piece  :-)


> b: You are having the discussion that we planned to have for Doc 2.  Make 
> your case to drop those protocols then.  Or, if no one wants to write 
> sections for the additional protocols for Doc 1a (an extended version of 
> draft-welzl-taps-transports), then folks are voting with their feet on the 
> utility of keeping them.

See my arguments above; about getting sections done for 
draft-welzl-taps-transports, I don’t worry too much: this is only the very 
first version, we haven’t asked anyone for inputs yet (and I can volunteer to 
cover a few more protocols myself).


> c: One of the goals of TAPS is to enable deployment of transport protocols 
> such as DCCP where networks permit it without forcing application (or 
> library) authors to handle probe and fallback.  If we don't include protocols 
> that aren't seeing deployment, what is the value of this activity?

This is a very good point. I’m not sure - do we really need to cover absolutely 
all protocols that are in draft-ietf-transports in draft-welzl-taps-transports, 
then? I am concerned about the implementability of the final beast…

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Michael Welzl]

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 
>  wrote:
> 
> 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:taps-boun...@ietf.org] 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,
>> 
>> 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
>

Re: [Taps] IETF planning

[Michael Welzl]

> On 27. okt. 2015, at 15.00, Mirja Kühlewind  
> wrote:
> 
> Hi all,
> 
> I didn’t say anything so far because I don’t mind to have a second protocol 
> here, but I personally don’t see this doc as really needed. Effectively we 
> will have two docs that have the same results (a list of features) at the end.

I think draft-welzl-taps-transports highlights how many services (or transport 
features or whatever we want to call them) are lost when we just compile a list 
as in draft-ietf-taps-transports.
To give a few examples: SCTP: "ordered and unordered delivery within a stream” 
does not make it clear that you can in fact specify per-message whether 
ordering matters or not.
In TCP, during the lifetime of a connection, you can change the DSCP value.
In TCP, you can open a connection to listen at one local interface or any; in 
SCTP, you can specify a list of local interfaces

We can debate whether these things are unnecessary details, but they are things 
that appear in draft-welzl-taps-transports as a result of the systematic 
approach I’ve taken.
 

> I personally find the approach taken in the new doc even more arbitrary and 
> reading this discussion of what should be in and out just underlines this 
> point.

Even more arbitrary => could you please explain?
I think the discussion of what should be in and out has absolutely nothing to 
do with the arbitrariness of the approach taken in the doc.


> From my point of view the taps-transports is ready now. Btw. we did not leave 
> out (hopefully) any features of RTP, we just decided to keep the description 
> very short and only focus in the description on those parts that are actually 
> transport related. 
> 
> I agree that the taps-transport doc is quite long, but for the wg I don’t the 
> the purpose of this doc in having it but in getting it. I mean the process we 
> had so far to get this doc in the right shape was very helpful and I believe 
> we are ready to move on. The only think that is interesting now for the wg is 
> the final list of feature, which is there and ready to use. 
> 
> As a side note, I also believe that other people might be interesting in 
> reading the doc for other reasons than participating in taps because it’s 
> actually a quite nice overview doc now.

I agree that it’s a nice document and ready. As for “The only thing interesting 
for the wg is he final list of features, which is there and ready to use”, see 
the discussion above: the draft-ietf-taps-transports is a nice and useful 
survey, but I do not think it is a good basis for an implementable TAPS system, 
which we eventually want (doc 3).

Cheers,
Michael



> 
> That’s just my 2c. I don’t want to hold the wg from any further steps 
> regarding draft-well-taps-transports; I just had the feeling I should also 
> express a different opinion here.
> 
> Mirja
> 
> 
>> Am 27.10.2015 um 14:47 schrieb Michael Welzl :
>> 
>> 
>>> On 26. okt. 2015, at 17.35, Aaron Falk  wrote:
>>> 
>>> On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl  wrote:
>>> 
>>> Working towards a realistic end-goal of a deployable system.
>>> 
>>> So we’re i) describing services; ii) narrowing them down somehow; iii) 
>>> describing how to build this thing.
>>> My concern is with iii) being something feasible and useful, not an obscure 
>>> sci-fi document.
>>> 
>>> Uh, yeah.  That's our charter.  Narrowing down is in doc 2.  Are you making 
>>> the case we should do it in doc 1?  
>> 
>> Well, just because we narrow down in doc 2 doesn’t mean that doc 1 has to 
>> contain everything under the sun as a starting point. Consider the 
>> discussion around RTP in draft-ietf-taps-transports - I think the consensus 
>> was to have only very short text on RTP in there, not a list of all the 
>> protocol features. The starting point for draft-welzl-taps-transports should 
>> probably be limited in a similar way, but I’d suggest limiting it more than 
>> draft-ietf-taps-transports - partially because draft-ietf-taps-transports 
>> can already show that certain protocols are not adding new transport 
>> features to the mix that don’t yet exist.
>> 
>> Of course, the main reason behind my argument is to keep 
>> draft-welzl-taps-transports within a reasonable length. Look at its length 
>> now, with only two protocols!  I think the length is inevitable, but if we 
>> have good reasons not to cover certain protocols, I think we should keep 
>> them out. At least it’s a valuable discussion to have!
>> 
>> 
>>> Say we include DCCP. It’ll add some services that aren’t in the other 
>>> protocols listed so far in this mail - e.g. drop notifi

Re: [Taps] IETF planning

[Michael Welzl]

> On 27. okt. 2015, at 15.08, Marie-Jose Montpetit  
> wrote:
> 
> I agree with Mirja. We have done a lot of “background” work up to now and I 
> don’t mind long documents as long as they are useful references which I think 
> the current document is. I am ok with keeping the work on 
> draft-welzl-taps-transports. But I would also want to move to the next steps 
> - not that I want a science experiment but my interest from the beginning was 
> to define how applications can use transports more efficiently both for 
> existing transports and potential future ones - APIs, discovery etc. I don’t 
> think we need detailed lists of features as all these transports are 
> documented elsewhere but better means to advertise them and use them.

How are you going to do this when you don’t know what applies to connection 
opening, connection maintenance, data transfer? What kinds of error messages 
are available?
I think it’s a much more obvious step from draft-welzl-taps-transports to a 
generic TAPS API than from draft-ietf-taps-transports, and that’s the whole 
point. draft-ietf-taps-transports is a nice survey but it doesn’t really help 
you much for creating an API, I think.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] IETF planning

[Michael Welzl]

> On 27. okt. 2015, at 15.46, Mirja Kühlewind  
> wrote:
> 
> Hi Michael,
> 
> for me, when I was reading the following, that was when I found it quite 
> arbitrary again:
> 
> "In the list resulting from the second pass, some services are missing
>   because they are implicit in some protocols, and they only become
>   explicit when we consider the superset of all services offered by all
>   protocols. „
> 
> So how do we know that we actually caught everything?

Everything here is based on text parts of the RFCs that focus on what a 
protocol provides to the upper layer and how it is used.
This should be everything that’s relevant as a service.
Now, when you have all these bits covered, for all the protocols you want to 
cover, this should give you *exactly* the services of relevance - that’s the 
idea of this procedure.

For example, now the document contains only TCP and SCTP. There is no mention 
of congestion control, because, to choose between these two, congestion control 
is not a relevant service: they both have it, in the same way. If the document 
would only cover TCP and SCTP, I think that’s exactly how it should be.

When we add UDP, the obvious RFC to cover is the one on usage guidelines 
(RFC5405). It will tell us that UDP does not have congestion control, which 
means that the application has to take care of it. Thus, “no congestion 
control” becomes a part of the services. Because “lack of XY” is a bit strange 
as a service, it’d be obvious to write “congestion control” as a service for 
the other protocols instead.

Consider another example. Assume, for a second, that all protocols had the same 
checksum, and no option to turn it off or configure it. This is not true, but 
just imagine it for the example.
In this case, there would never be text in any of the RFCs talking about the 
relevance of the checksum to the application - and it would never appear as a 
service, which is exactly the right decision, it would be an integral part of 
communication that is the same everywhere. Anyway, in reality, as soon as we 
add UDP-Lite and/or DCCP, we have configurable checksums as a service in the 
list. But if these protocols are not covered, what’s the point of describing a 
“configurable checksum” service?
(I’m ignoring the fact that the checksum can be disabled in UDP now, for 
simplicity)



> Further see below.
> 
>> Am 27.10.2015 um 15:27 schrieb Michael Welzl :
>> 
>> 
>>> On 27. okt. 2015, at 15.00, Mirja Kühlewind 
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> I didn’t say anything so far because I don’t mind to have a second protocol 
>>> here, but I personally don’t see this doc as really needed. Effectively we 
>>> will have two docs that have the same results (a list of features) at the 
>>> end.
>> 
>> I think draft-welzl-taps-transports highlights how many services (or 
>> transport features or whatever we want to call them) are lost when we just 
>> compile a list as in draft-ietf-taps-transports.
>> To give a few examples: SCTP: "ordered and unordered delivery within a 
>> stream” does not make it clear that you can in fact specify per-message 
>> whether ordering matters or not.
>> In TCP, during the lifetime of a connection, you can change the DSCP value.
>> In TCP, you can open a connection to listen at one local interface or any; 
>> in SCTP, you can specify a list of local interfaces
>> 
>> We can debate whether these things are unnecessary details, but they are 
>> things that appear in draft-welzl-taps-transports as a result of the 
>> systematic approach I’ve taken.
>> 
> 
> For me that would be good feedback for taps-transport, to include these 
> things. We have for each protocol a section on interface(s). We could even 
> include more background text there if needed.
> 
> However, for the things you’ve mentioned that’s for me rather a question on 
> the level of detail of certain features. We’ve already discussed that we 
> might need something like ‚aspects‘ for each feature. I believe we decided to 
> not provide more details in this doc because we wanted to move on. However, I 
> also believe that people in this group understand well that in some cases 
> we’ll need more detailed information on the feature. And for me even if we 
> submit and publish the taps-transport as it is, this is not written in stone 
> and we can still say later on, that we rename a feature or split it up or 
> whatever.

Indeed, taps-transport is just at a slightly higher abstraction layer than 
draft-welzl-taps-transports.


> For me that would even be part of the second doc in the charter.

Here I disagree. I think we need more detail to end up with an implementable 
system, as in draft-welzl-taps-transport

Re: [Taps] IETF planning

[Michael Welzl]

Hi Mirja,

I’m not sure where this discussion is leading us: twice you just say you 
disagree without giving a reason; then you seem to get kind of hung up on the 
“no congestion control” bit immediately after quoting my statement:

**
Thus, “no congestion control” becomes a part of the services. Because “lack of 
XY” is a bit strange as a service, it’d be obvious to write “congestion 
control” as a service for the other protocols instead.
**
i.e. the service would be "congestion control”, not “no congestion control”. 
The latter is just what you'd get in the first iteration when working through 
the UDP usage guidelines.


I’ll cut most of the text here to try to wrap this up, then answer a particular 
point, and then get to your conclusion:


> Further, back to your example above. To call „no congestion control“ a 
> service you have to analyze the protocol itself. „no congestion control“ is 
> not exposed in any interface!!! And analyzing the protocol is what we do in 
> the taps-transport doc!

No, you do *not* have to analyze the protocol, as this is not only about 
interfaces, it’s based on any text in the RFCs that describes what a protocol 
provides to the upper layer and how it is used. RFC 5405, as an obvious source 
of text on how to use UDP and what it provides to the layer above, tells us:
"It is important to stress
   that an application SHOULD perform congestion control over all UDP
   traffic it sends to a destination, independently from how it
   generates this traffic."

So, once we include UDP, we get congestion control as a service for TCP and 
SCTP, from this text.


> When I was reading draft-well-taps-transports I’d had the feeding you’ve 
> started with the interfaces but then detected that obvious things are 
> missing, so you basically also started analyzing the protocols itself but 
> very selectively and from my point of view even more arbitrary.

That’s not what I did. I strictly used only text that talks about what a 
protocol provides to the upper layer and how it is used.


> From my point of view, let's keep in mind all the discussion we had and what 
> we learned to far, and let’s move on!

Noting your statement from a previous email: "Again, I’m okay to have two docs 
here. I don’t think a second doc is absolutely necessary. An alternative would 
be to merge both docs… just as a side note. But I’m okay with both, two or one 
docs.”, I agree and think we should just move on.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] implementors

[Michael Welzl]

Hi,

There’s a European project dedicated to implementing a TAPS++ type system:  
https://www.neat-project.org 

All members of this project are naturally planning to do a TAPS implementation.

Cheers,
Michael


> On 28. okt. 2015, at 15.12, Aaron Falk  wrote:
> 
> TAPS was started based on the assumption that there are folks who want to 
> implement the API and supporting mechanism.  Do we have folks on the list who 
> plan to do this?
> 
> --aaron
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] adopting draft-welzl-taps-transports

[Michael Welzl]

So I did say this before, but to get the ball rolling:

> On 28. okt. 2015, at 15.10, Aaron Falk  wrote:
> 
> I've not heard any objections to work on this document and several proposals 
> for why it would help docs 2 & 3 (as well as the implementations based on 3). 
>  
> 
> 1. Should TAPS adopt draft-welzl-taps-transports as a working group 
> deliverable? 
> 
> 2. To some folks it sounds as though this doc is a pre-requisite to doc 2.  
> Do folks agree?  Can we start on doc 2 in parallel or should we wait?

I do think that doc 2 should be based on draft-welzl-taps-transports, i.e. I 
think we should wait for a bit. We could get started before 
draft-welzl-taps-transports is completely finished, but I think we should give 
it at least 1-2 more iterations before starting to narrow it down in doc 2. 

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

[Taps] RFC 6458 etc. in draft-welzl-taps-transports

[Michael Welzl]

Dear all,

Sorry for not being able to attend the TAPS meeting on site or even remotely. I 
just finished watching the recording, and I noticed that the question of RFC 
6458  - "why is the SCTP part of draft-welzl- ..  based on only RFC 4960 and 
not on RFC 6458?" - was brought up several times. I'd like to provide an answer 
and start a discussion about this.

There are two reasons why RFC 6458 wasn't used in 
draft-welzl-taps-transports-00: a very mundane one, and a more serious one. 
I'll list them both and hope we can discuss the second reason.

1) Reason one: RFC 6458 is quite long, and I wanted to limit the amount of work 
I'm putting into the -00 version, given that the point was to show people the 
procedure and the idea and see what they think, and not to fully cover 
everything 100% correctly yet. Basically, I didn't want to risk writing out all 
the stuff from RFC 6458 and then have people tell me to go away  :-)

2) Reason two, more serious: RFC 6458 is Informational, and my understanding 
was that this is just one description of one API implementation, not a 
recommendation or even prescription of what all SCTP implementations must 
provide. However, my decision for draft-welzl-taps-transports was to *exclude* 
things that are only optional to implement - I don't think we want to end up 
with a TAPS system that provides services that, alas, on Operating System XY 
are not available because here only a subset of the API is implemented. 
Therefore I went with a minimal set of functions that I thought we can assume 
are implemented everywhere (well, at least in every system that claims to 
"follow the spec").  Can we assume that every system that claims to implement 
SCTP in accordance with the spec fully implements RFC 6458?



A side note about TCP, because Karen made a comment about the TCP API too:  a 
similar logic applies here, irrespective of whether the API is old or not: I 
think we should cover whatever a system claiming to "implement the protocol in 
accordance with the spec" has to cover. Going down the path of looking at 
actual socket API implementations is dangerous in that we end up in "only 
implemented here, not there" - land. We want a minimal set of mechanisms that 
are (or at least really should be! for that, what else can we use as a basis 
than our own recommendations?!) available everywhere. Karen, you specifically 
mentioned URG and PSH and how they are implemented; what is it in 
draft-welzl-.. about these two mechanisms that you don't agree with?

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports

[Michael Welzl]

Hi,

Thanks Karen for your long email and helpful comments!

I re-order it a bit and cut some parts to get my answer more structured:


First, to get this straight in the discussion:


>>> A side note about TCP, because Karen made a comment about the TCP API
>> too:
>>> a similar logic applies here, irrespective of whether the API is old
>>> or
>>> not: I think we should cover whatever a system claiming to "implement
>>> the protocol in accordance with the spec" has to cover. Going down the
>>> path of looking at actual socket API implementations is dangerous in
>>> that we end up in "only implemented here, not there" - land. We want a
>>> minimal set of mechanisms that are (or at least really should be! for
>>> that, what else can we use as a basis than our own recommendations?!)
>> available everywhere.
> 
> [Karen Elisabeth Egede Nielsen] Yes I agree completely ! The difficult
> exercise is where from
> to gather this minimal set of mechanisms in a qualified manner.

So I think we really do need to rely on RFCs.


1)  TCP:
-

I think there is a misunderstanding about draft-welzl-taps-transports:


> On 04 Nov 2015, at 02:27, Karen Elisabeth Egede Nielsen 
>  wrote:
> 
> HI,
> 
> As a general comment then I believe that when describing what is supported
> by TCP/SCTP (or UDP) as standard then it does not suffice to look into
> IETF RFCs.
> One need at least to relate to the *basic functions* of the POSIX/Berkeley
> socket api standard.
> 
> My understanding of the TCP API, for example, is that while RFC793 did
> specify an abstract API for TCP, then
> the true defacto standard for the socket api is the Berkeley socket api
> from .?. around 1990.
> Not saying the different socket api standards don't differ and that there
> is *one* standard to look at.
> But making is be RFC793 rather then what emerged as defacto in the 1990's
> seems a "bit odd" to me.
> 
> Especially since we have RFCs RFC1122 dating back to 1989 already
> clarifying part of RFC793 (namely the PUSH bit)
> And one, much more recent, RFC6093, clarifying the urgent bit.


I only used RFC4960 for SCTP in this -00 version, but I did try to use all of 
the TCP spec as far as possible... never easy with all these RFCs - but at 
least I constantly checked what I'm doing against the Roadmap RFC 7414.
So I did include RFC 1122 and RFC 6093. Specifically, the text at the end of 
Pass 1, under "Excluded Services", says the following about URG:

***
   The 'send' and 'receive' commands include usage of an "URGENT"
   mechanism, which SHOULD NOT be implemented according to [RFC6093]
   and is therefore not described here.  This also concerns the notification
   "Urgent pointer advance" in the ERROR_REPORT described in 
   Section 4.2.4.1 of [RFC1122].
***

and about PUSH:

***
The 'receive'
   command can (under some conditions) yield the status of the PUSH flag
   according to [RFC0793], but this TCP functionality is made optional
   in [RFC1122] and hence not considered here.  Generally, section
   4.2.2.2 of [RFC1122] says that PUSH on send calls MAY be implemented,
   which could be a reason not to consider it here.  However, the text
   then explains that "an interactive application protocol must set the
   PUSH flag at least in the last SEND call in each command or response
   sequence", and most implementations provide some option to cause a
   behavior that is in some way similar to PUSH.  Therefore PUSH is
   described as a part of SEND here.
***

We can debate these decisions, but I did base them on RFC 1122 and RFC 6093.

More about PUSH:

> [Karen Elisabeth Egede Nielsen]
> 
> The PUSH bit as settable by application was recognized as being optional
> by RFC1122 (1989).
> 
> Enforcing the PUSH bit set via Nagle off, does not mean that one can
> control the PUSH function (one do get Nagle off at the same time).

Technically, I don't see a connection between Nagle and PUSH. It's kind of 
obvious though that if you want small messages to be delivered fast, you don't 
want Nagle and you do want PUSH, but still these are separate functions.
This sounds exactly like the type of confusion we may end up with if we follow 
actual API implementations and not what the spec says!


> Possible certain implementations have certain tweeks so that one may
> control the PUSH bit from ULP. If that is consider to be the
> Defacto standard, even if RFC1122 says that it is optional, then I do not
> disagree, but is it so ?

See my interpretation above: I think RFC 1122 is a bit ambiguous here, once 
saying it MAY be implemented, then saying "an interactive application protocol 
must set the PUSH flag "  ... though this isn't a capitalized MUST.


> The PUSH bit makes the data be available for read by the application (when
> in-line) but I am not sure this, as defacto, makes
> the data be pushed to the application in most common api's exposed to
> applications today. In some implementations, a socket becomes readable
> based on the amount of dat

Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports

[Michael Welzl]

Hi,

I'm cutting the part about URG, because here we agree. I think we agree about 
PUSH too, but I'll say it in line below  :-)


>> and about PUSH:
>> 
>> ***
>> The 'receive'
>>   command can (under some conditions) yield the status of the PUSH flag
>>   according to [RFC0793], but this TCP functionality is made optional
>>   in [RFC1122] and hence not considered here.  Generally, section
>>   4.2.2.2 of [RFC1122] says that PUSH on send calls MAY be implemented,
>>   which could be a reason not to consider it here.  However, the text
>>   then explains that "an interactive application protocol must set the
>>   PUSH flag at least in the last SEND call in each command or response
>>   sequence", and most implementations provide some option to cause a
>>   behavior that is in some way similar to PUSH.  Therefore PUSH is
>>   described as a part of SEND here.
>> ***
>> 
> [Karen Elisabeth Egede Nielsen] There is a very clear distinction in
> between
> capitalized Keywords and non-capitalized must's and should's in section
> 4.2.2.2 of rfc1122.

I know


> I have no problem with assuming that TCP implementations follow
>   MUST set the PSH bit in
>the last buffered segment (i.e., when there is no more
>queued data to be sent).

but it isn't a MUST, it's a "must".


> I have no problem with assuming that applications, if the MAY option is
> supported at the api, s
> Is assumed to set the PUSH flag at the occasions described in RFC1122.
> 
> But I do have a problem  with the following text - repeated from your
> paragraph above;:
> 
>> and most implementations provide some option to cause a
>>   behavior that is in some way similar to PUSH.  Therefore PUSH is
>>   described as a part of SEND here.
> 
> You are referring to "most implementations provide some option"
> 
> What do you mean by "most implementations" ?
> 
> What do you mean by "option" ?

GAAH !!   Here you did catch me diverging from my own rules!!!
That must have come from looking at actual API implementations, and no it 
REALLY shouldn't be there. I did intend to strictly only follow RFCs. Big 
mistake, very sorry!


> My problem particularly with "the option" part, is that is to me in the
> context of
> an API description sounds as if this "option" is a function in the API
> (read an "API option")
> that the ULP can invoke.

Based on what you said about capitalization and on the mistake in talking about 
actual implementations I saw, I tend to erase PUSH from SEND because it's only 
qualified as MAY, period.
Ok?


>> We can debate these decisions, but I did base them on RFC 1122 and RFC
>> 6093.
>> 
>> More about PUSH:
>> 
>>> [Karen Elisabeth Egede Nielsen]
>>> 
>>> The PUSH bit as settable by application was recognized as being
>>> optional by RFC1122 (1989).
>>> 
>>> Enforcing the PUSH bit set via Nagle off, does not mean that one can
>>> control the PUSH function (one do get Nagle off at the same time).
>> 
>> Technically, I don't see a connection between Nagle and PUSH. It's kind
> of
>> obvious though that if you want small messages to be delivered fast, you
>> don't want Nagle and you do want PUSH, but still these are separate
>> functions.
> 
> [Karen Elisabeth Egede Nielsen] Perfect. I cound't agree more !!
> I was trying to understand which "API option" that you might be referring
> to,
> and as I have had many (in my opinion confused) discussions with
> certain TCP users which looking for the "API option" for setting of the
> PUSH,
> thought they had to use Nagle off for this. While in fact they didn't have
> to do
> anything because the stack will set the PUSH bit following the RFC1122
> MUST.
> 
>> This sounds exactly like the type of confusion we may end up with if we
>> follow actual API implementations and not what the spec says!
>> 
> [Karen Elisabeth Egede Nielsen] GOOD. I am happy that we avoid this.
> So could we loose the text about that the TCP API provides an option to
> control the PUSH flag - :-) :-) !!

See above - we're in agreement. I'll drop it.


>>> Possible certain implementations have certain tweeks so that one may
>>> control the PUSH bit from ULP. If that is consider to be the Defacto
>>> standard, even if RFC1122 says that it is optional, then I do not
>>> disagree, but is it so ?
>> 
>> See my interpretation above: I think RFC 1122 is a bit ambiguous here,
> once
>> saying it MAY be implemented, then saying "an interactive application
>> protocol must set the PUSH flag "  ... though this isn't a
> capitalized MUST.
>> 
> [Karen Elisabeth Egede Nielsen] For what it is worth (if anything)  this
> is not how I interpret the text. I understand
> the text as saying that if the MAY option to set PUSH in the apu
> is implemented then applications must do what the text says. But as
> RFC1122 is not really specifying what applications should or must do.,
> these musts or should are not  capitalized.

- right.


> But I should assume that we could get the people wor

Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports

[Michael Welzl]

> On 4. nov. 2015, at 19.11, Joe Touch  wrote:
> 
> 
> 
> On 11/3/2015 5:27 PM, Karen Elisabeth Egede Nielsen wrote:
>> HI,
>> 
>> As a general comment then I believe that when describing what is supported
>> by TCP/SCTP (or UDP) as standard then it does not suffice to look into
>> IETF RFCs.
>> One need at least to relate to the *basic functions* of the POSIX/Berkeley
>> socket api standard.
>> 
>> My understanding of the TCP API, for example, is that while RFC793 did
>> specify an abstract API for TCP, then
>> the true defacto standard for the socket api is the Berkeley socket api
>> from .?. around 1990.
>> Not saying the different socket api standards don't differ and that there
>> is *one* standard to look at.
>> But making is be RFC793 rather then what emerged as defacto in the 1990's
>> seems a "bit odd" to me.
> 
> There are implementations of TCP that do not use the Berkeley sockets
> model. Note, though, that the concept of a socket for communications
> itself comes from RFC793, not Unix.
> 
>> Especially since we have RFCs RFC1122 dating back to 1989 already
>> clarifying part of RFC793 (namely the PUSH bit)
>> And one, much more recent, RFC6093, clarifying the urgent bit.
> 
> When we talk about TCP, we certainly mean more than just RFC793 - we
> include all updates to that spec, which include these documents. In some
> cases, the updates came from implementation experience; in other cases,
> they came from the standards community because of more fundamental concerns.

I believe that was just a misunderstanding: Karen thought that I had only used 
RFC793 when writing draft-welzl-taps-transports-00, but really I did try to use 
all relevant RFCs.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports

[Michael Welzl]

> On 5. nov. 2015, at 00.02, Karen Elisabeth Egede Nielsen 
>  wrote:
> 
> HI,
> 
>> 
>> I believe that was just a misunderstanding: Karen thought that I had
> only
>> used RFC793 when writing draft-welzl-taps-transports-00, but really I
> did try
>> to use all relevant RFCs.
>> 
> [Karen Elisabeth Egede Nielsen] ..well, I did observe that you were
> referring to rfc1122 (and also RFC6093).
> but the result and the emphasis on the PUSH bit made me think that weight
> only was put on what was written in RFC 793. ;-)
> 
> BTW,  something which I didn't mention yesterday, but now got the "energy"
> to in and find is the following:
> 
> Send:  This sends a message of a certain length in bytes over an
>  association.  A number can be provided to later refer to the
>  correct message when reporting an error and a stream id is
>  provided to specify the stream to be used inside an association
>  (we consider this as a mandatory parameter here for simplicity: if
>  not provided, the stream id defaults to 0).  An optional maximum
>  life time can specify the time after which the message should be
>  discarded rather than sent.  A choice (advisory, i.e. not
>  guaranteed) of the preferred path can be made by providing a
>  destination transport address, and the message can be delivered
>  out-of-order if the unordered flag is set.  Another advisory flag
>  indicates the ULP's preference to avoid bundling user data with
>  other outbound DATA chunks (i.e., in the same packet).  The
> 
> 
>  handling of this no-bundle flags is similar to the sender side
>  
>  handling of the TCP PUSH flag.
>  
>  A payload protocol-id can be
>  provided to pass a value that indicates the type of payload
>  protocol data to the peer.
> 
> Can we agree to have this be removed also :-).
> Bundling in SCTP is similar to Nagle. Indeed it is often implemented as
> Nagle exactly
> (though with add-ons). Comparing it to PUSH is NOT helpful.

Agreed. Actually I think that was not by intention, just a nit that happened as 
I wrote it: I don’t think I wanted to compare it with PUSH but indeed with 
Nagle.


> Then, there is the additional discussion about RFC4960 and RFC6458 (socket
> api) in that
> bundling control is not often implemented as a flag on a message, but as
> in TCP on a per association/connection level.
> This again made me think emphasis was put on RFC793/RFC4960 and not much
> else ;-).

Things like “[not] often implemented” really shouldn’t be there. All mistakes, 
all to be fixed. Apologies!

Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Draft TAPS minutes from IETF-94

[Michael Welzl]

Hi,

Two comments in line:



> On 17 Nov 2015, at 00:21, Aaron Falk  wrote:
> 
> Kyle Rose has done a nice job with the minutes based on his and Dave 
> Lawrence's notes.  Many thanks, guys!
> 
> TAPS folk: please review these minutes and send comments to the list.
> 
> Thanks,
> 
> --aaron
> 
> taps minutes
> IETF-94 Yokohama
> Reported by David Lawrence and Kyle Rose
> 
> Note Well covered.
> 
> 1. Agenda bashing
> 2. WG Status
> 3. draft-ietf-taps-transports
> 4. draft-welzl-taps-transports
> 5. A way forward for "document 2"
> 6. AOB
> 
> Dec 2015 planned: Document 1, informational, to be sent to IESG defining 
> services provided by IETF transport protos and congestion control mechanisms.
> 
> --
> Brian Trammell, speaking on draft-ietf-taps-transports (version 7)
> 
> Charter and abstract basically unchanged since last meeting.  Thinks the 
> document is ready for December publication.  There are a few editor's notes 
> which can mostly be dropped, except for some text needed in 3.9.2 about the 
> RTP interface.  Drop section 4.1 (Transport Matrix).  Then push as -08 and 
> ready for WGLC.
> 
> Poll of room:  anyone see any issues to prevent it going to WGLC?  Silence.
> 
> --
> Naeem Khademi, speaking on draft-welzl-taps-transports-00
> 
> Scope of the draft: describe only existing IETF protos for two endpoint 
> comms.  Covers only TCP and SCTP currently, but he intends to cover all the 
> protocols listed.
> 
> Goal: use a generic approach to help designers/API devs to know how to use 
> the protocols.
> 
> 3 pass approach:
> 
>   • 1. relevant parts of proto RFCs are summarized as to what they 
> provide and how they are used. Identify all defined forms of interaction 
> between the proto and its user.
> 
>   • 2. categorize into connection-related vs. data transmission, such as 
> identifying connect() in TCP as connection-related and sending and receiving 
> as about data transmission.
> 
>   • 3. present a superset of all services in all protos, turning it 
> upside down.  For each service, list which protocols provide it.
> 
> Karen: The document here needs to refer to latest RFCs on SCTP, like 6458, 
> not just 4960.
> Christian: We use protocols based on how they work and what costs are 
> involved, not solely based on the API that's available. Some cost resulting 
> from an implementation that does not appear anywhere in the API needs to be 
> taken into account.
> Aaron: Problem as he understood it is that there is a desire to be able to 
> use new protocols (starting with existing standards) where they would work, 
> and fall back to older protocols where they don't work. Goal wasn't 
> composition, but to use the best protocol you can that works end-to-end.
> Mirja: What's needed is a good interface for choosing the right protocol.
> Christian: Choose HTTP over TCP because they want to get through firewalls, 
> or need to limit overhead, etc. 
> Brian: deconstructing and reconstructing each protocol has been a very useful 
> process.  Would be interesting to see whether you get the same result if you 
> used SCTP's abstract API vs the newer SCTP socket api.
> 
> Mic (?): Doesn't seem that your looked at differences in implementations from 
> RFC specifications.  Really should cover that.
> Naeem: Hope to cover implementations as doc evolves.

Having watched it on the mic, I can't remember the statement on the mic or how 
it was phrased right now - but I do remember that Naeem's answer was about 
covering other protocols than just SCTP and TCP. In the minutes here it looks 
different.


> Gorry via Jabber: Just add the protos from mailing list discussion (UDP, 
> UDP-Lite, MPTCP, DTLS and TLS). And probably DCCP. (General agreement on 
> Cory's suggestion.) Will confirm on mailing list.
> 
> Aaron: Who's read the document? Raise your hands.
> Not many people have read the document, but at least the people at the 
> microphone had.
> 
> Aaron: Hum if we should adopt doc (as supplement to target 1). Some humming. 
> Not? Silence.
> 
> Determined that a milestone should be added based on what the document 
> addresses, but this does not require a change to the WG scope, and therefore 
> no change required to the charter. (Aaron) It is also the case that two 
> documents can address one milestone. (Brian T.)
> 
> Naeem will change his document to conform to the group's terminology 
> throughout. (Implication is that the other document will be changed as well, 
> if necessary.)
> 
> --
> Stein Gjessing on document 2, defining taps system between application layer 
> and transport layer.
> 
> Thinks that draft-welzl-taps-transport should really be addressing the needs 
> of document 2, specifing a minimal taps interface to the transport protos.

This is wro

Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports

[Michael Welzl]

> On 05 Dec 2015, at 17:02, Michael Tuexen  
> wrote:
> 
>> On 03 Nov 2015, at 14:33, go...@erg.abdn.ac.uk wrote:
>> 
>> A note just on the INFO status of SCTP APIs (below):
>>> 
>>> Dear all,
>>> 
>>> Sorry for not being able to attend the TAPS meeting on site or even
>>> remotely. I just finished watching the recording, and I noticed that the
>>> question of RFC 6458  - "why is the SCTP part of draft-welzl- ..  based on
>>> only RFC 4960 and not on RFC 6458?" - was brought up several times. I'd
>>> like to provide an answer and start a discussion about this.
>>> 
>>> There are two reasons why RFC 6458 wasn't used in
>>> draft-welzl-taps-transports-00: a very mundane one, and a more serious
>>> one. I'll list them both and hope we can discuss the second reason.
>>> 
>>> 1) Reason one: RFC 6458 is quite long, and I wanted to limit the amount of
>>> work I'm putting into the -00 version, given that the point was to show
>>> people the procedure and the idea and see what they think, and not to
>>> fully cover everything 100% correctly yet. Basically, I didn't want to
>>> risk writing out all the stuff from RFC 6458 and then have people tell me
>>> to go away  :-)
>>> 
>>> 2) Reason two, more serious: RFC 6458 is Informational, and my
>>> understanding was that this is just one description of one API
>>> implementation, not a recommendation or even prescription of what all SCTP
>>> implementations must provide. However, my decision for
>>> draft-welzl-taps-transports was to *exclude* things that are only optional
>>> to implement - I don't think we want to end up with a TAPS system that
>>> provides services that, alas, on Operating System XY are not available
>>> because here only a subset of the API is implemented. Therefore I went
>>> with a minimal set of functions that I thought we can assume are
>>> implemented everywhere (well, at least in every system that claims to
>>> "follow the spec").  Can we assume that every system that claims to
>>> implement SCTP in accordance with the spec fully implements RFC 6458?
>>> 
>> GF: From a TSVWG Chair perspective, beware here...  *ALL* more recent IETF
>> SCTP API work from TSVWG is INFO.  Each SCTP RFC is expected to have an
>> informative section that describes the API together with the normative
>> protocol spec. That is not because there are expected to be alternatives
>> to choose from:  It's because, as I understand, the IETF is not the formal
>> standards body for specification of such normative APIs.
> I would like to point out that the API sections focus on the socket based
> API described in RFC 6458.
> The abstract API described in RFC 4960 an the one described in RFC 6458
> are both informational. Therefore RFC 6458 should be also considered. You
> don't have to take the C structures and the exact function signatures into
> account, but you should consider what parameters can be changed, what
> information can be provided when sending a user message and so on.

That's in line with what Karen said. I wanted to hear a second opinion on this 
not because I didn't trust Karen's expertise (I do!) but because I wanted to 
make sure that I'm not doing this potentially rather large amount of work in 
vain.
=> that's all fine, I'll cover RFC 6458 in a future version of 
draft-welzl-taps-transports.

Cheers,
Michael


> The same applies to extensions. They don't have an abstract API at all,
> it was considered better to extend RFC 6458...
> 
> Best regards
> Michael
>>> 
>>> 
>>> A side note about TCP, because Karen made a comment about the TCP API too:
>>> a similar logic applies here, irrespective of whether the API is old or
>>> not: I think we should cover whatever a system claiming to "implement the
>>> protocol in accordance with the spec" has to cover. Going down the path of
>>> looking at actual socket API implementations is dangerous in that we end
>>> up in "only implemented here, not there" - land. We want a minimal set of
>>> mechanisms that are (or at least really should be! for that, what else can
>>> we use as a basis than our own recommendations?!) available everywhere.
>>> Karen, you specifically mentioned URG and PSH and how they are
>>> implemented; what is it in draft-welzl-.. about these two mechanisms that
>>> you don't agree with?
>>> 
>>> Cheers,
>>> Michael
>>> 
>>> ___
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>> 
>> Gorry
>> 
>> ___
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>> 
> 

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

[Taps] Comments on draft-ietf-taps-transports-08

[Michael Welzl]

Dear all,

I finally managed to read draft-ietf-taps-transports-08 in detail, here are my 
comments. Now, for the first time, I believe I deserve the ACK that is in there 
 :-)   Most of them are nits, and I apologize for presenting them mixed 
together with some larger issues (with the biggest issue being towards the end, 
where I comment on section 5) - but anyway there's nothing huge or 
show-stopping. There may also be duplicates between these comments and comments 
that were already given.

Cheers,
Michael



Comments on draft-ietf-taps-transports-08

sec 1:

s/MP-TCP/MPTCP   (for consistency)


sec 2:

This defines "Transport Service Feature" but all the text describing protocols 
talks about "Transport Features"  (with non-capitalized "features" in some 
section headings). Define both? Or only "Transport Features" maybe? "Transport 
Service Feature" seems unnecessarily lengthy...


sec 3:
unordered and unordered message delivery  => should probably be "ordered and 
unordered"


sec 3.1:
***
and other protocols that choose to use a
 datagram protocol (e.g., UDP or UDP-Lite) need to employ mechanisms
 to prevent congestion collapse
***
=> the fact that these protocols provide a datagram service isn't the issue - 
it's the lack of congestion control. (indeed just a bit further down there's 
talk of "datagram congestion control" in DCCP CCID-2).


***
Each technique requires that the protocol provide a method
***
=> provide_s_  ?

>From the 3rd paragraph onward, the text of this section seems a bit out of 
>place: in the context of this document, it would probably be better to explain 
>what the various congestion controls mean for applications (smooth TFRC, 
>bursty Reno, LBE-style LEDBAT...), but this text talks about loss vs. delay 
>vs. ECN signals etc. which seems largely irrelevant here. Well at least that 
>part does - rate- vs. window-based has a meaning for an application, so that 
>part is probably fine. Also, it's probably ok to have these explanations 
>there, but the meaning of different congestion control flavors for 
>applications is missing (can be short but should be there).


***
are are deployed in the Internet
***


sec 4

extra space in "connection- oriented"


***
TCP Selective Acknowledgment
 [RFC2018] extends this mechanism by making it possible to identify
 missing segments more precisely, reducing spurious retransmission.
***

I would have thought that DupACKs without SACK are just as precise as SACK is - 
they just contain less information, and thus it takes longer to notify the 
sender of multiple holes in one window. So I would say "faster" instead of 
"more precisely" - and I'm also not sure SACK (without DSACK) reduces spurious 
retransmission. Why would it?


4.1.2

***
This interface does
 not describe configuration of TCP options or parameters beside use of
 the PUSH and URGENT flags.
***

=> this is the first mention of PUSH, making it hard to understand what PUSH is 
about. Note however that PUSH is optional to implement, and see my discussion 
with Karen about it on the list - maybe it could be a better alternative to 
just not even mention PUSH here.


***
There are current no documents in the RFC Series
 that describe this interface.
***

s/current/currently


***
congestion control: a window-based method that uses Additive
Increase Multiplicative Decrease (AIMD) to control the sending
rate and to conservatively choose a rate after congestion is
detected.
***

I think only mentioning AIMD here is a bit weird - after all this only applies 
to long-running flows. I would at least also describe slow start.  AIMD needs a 
citation.


4.2.3

***
When aggregating capacity over multiple
 paths, and depending on the way packets are scheduled on each TCP
 subflow, an additional delay and higher jitter might be observed
 observed before in-order delivery of data to the applications.
***

=> remove "an" before "additional delay"


4.3.1

extra space in "un- ordered" and "user- messages"


4.4

missing space after comma in "error correction,congestion control"

Broken reference: {{I-D.ietf-tsvwg- rfc5405bis}}


This paragraph is confusing in the context of this section because it's 
strictly about IP, not UDP:

***
 On transmission, UDP encapsulates each datagram into an IP packet,
 which may in turn be fragmented by IP.  Fragments are reassembled
 before delivery to the UDP receiver.
***
=> I'd recommend removing it.


just before 4.4.2 begins: "etc" should be "etc."


4.5

space in UDP- Lite


4.5.1: another "etc"


4.5.3:

strange to have "(as for UDP)" listed only for some but not all features - 
maybe better to just say that this is completely the same as UDP except for the 
additional "real" UDP-Lite features. Or add (as for UDP) for *all* features 
that UDP-Lite shares with UDP.


NEXT: 4.6 DCCP

***
Specifically it includes core functions
  (feature negotiation, path state management, RTT calculation, PMTUD,
  etc): This allows applications to use a compati