Subject: [Taps] IETF planning

From: Aaron Falk <[email-masked]>
Date: Mon, 19 Oct 2015 14:44:39 -0400

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.

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.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 22 Oct 2015 10:32:07 +0200

> On 19. okt. 2015, at 20.44, Aaron Falk <[email-masked]> wrote:
> 
> Hi Folks-
> 

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.

>    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

---

From: Brian Trammell <[email-masked]>
Date: Thu, 22 Oct 2015 11:40:13 +0200

> On 22 Oct 2015, at 10:32, Michael Welzl <[email-masked]> wrote:
> 
> 

+1, and FWIW that's exactly the same starting point I got to on my own.

> 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 wel…

There's probably quibbling to be done about the details, but I believe draft-gjessing is a good starting point for charter item 2.

Cheers,

Brian

> Cheers,
> Michael
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Aaron Falk <[email-masked]>
Date: Thu, 22 Oct 2015 10:14:28 -0400

> > 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?
> >
Any volunteers to kick off the lead the discussion?

> > 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).
>
> There's probably quibbling to be done about the details, but I believe
> draft-gjessing is a good starting point for charter item 2.
>
>

Stein, will you be in Yokohama and interested in leading a discussion on
this draft?

--aaron

---

From: Michael Welzl <[email-masked]>
Date: Thu, 22 Oct 2015 18:19:55 +0200

> On 22. okt. 2015, at 16.14, Aaron Falk <[email-masked]> wrote:
> 
> 

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

---

From: Michael Welzl <[email-masked]>
Date: Thu, 22 Oct 2015 20:46:52 +0200

> 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

---

From: Brian Trammell <[email-masked]>
Date: Thu, 22 Oct 2015 22:23:32 +0200

hi Michael,

> On 22 Oct 2015, at 18:19, Michael Welzl <[email-masked]> wrote:
> 
> 

s/widely deployed/widely implemented/g, but yes.

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?

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Fri, 23 Oct 2015 09:13:15 +0200

> On 22. okt. 2015, at 22.23, Brian Trammell <[email-masked]> wrote:
> 
> hi Michael,
> 

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 deploy…

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

---

From: Michael Welzl <[email-masked]>
Date: Fri, 23 Oct 2015 09:22:41 +0200

Hi,

>    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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 26 Oct 2015 09:54:14 +0000

> Any volunteers to kick off the lead the discussion?

<snip test on another draft>

So, I think UDP, and UDP-Lite *NEED* to be included. MPTCOP also.

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.

> --aaron

Gorry

---

From: Aaron Falk <[email-masked]>
Date: Mon, 26 Oct 2015 09:17:17 -0400

On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst <[email-masked]>
wrote:

>>     > It seems obvious to include protocols that are seeing some
>> deployment, i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP…
> 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 don't understand.  Why leave out any of the protocols included in
draft-ietf-taps-transports?  Is there an argument other than for expedience?

--aaron

---

From: Michael Welzl <[email-masked]>
Date: Mon, 26 Oct 2015 14:46:47 +0100

> On 26. okt. 2015, at 14.17, Aaron Falk <[email-masked]> wrote:
> 
> On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst <[email-masked] <mailto:[email-masked]>> wrote:

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 26 Oct 2015 14:46:26 +0000

On 26/10/2015 13:46, Michael Welzl wrote:
>
>> On 26. okt. 2015, at 14.17, Aaron Falk <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>             > draft-welzl-taps-transports currently only covers TCP
>>         and SCTP. But then: how many other protocols?
>>         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?
>>             >
Then we agree on this.

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

Gorry

---

From: Michael Welzl <[email-masked]>
Date: Mon, 26 Oct 2015 16:35:33 +0100

> On 26. okt. 2015, at 15.46, Gorry Fairhurst <[email-masked]> wrote:
> 

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

> 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

---

From: Aaron Falk <[email-masked]>
Date: Mon, 26 Oct 2015 12:35:53 -0400

> My concern is with iii) being something feasible and useful, not an

Uh, yeah.  That's our charter.  Narrowing down is in doc 2.  Are you making
the case we should do it in doc 1?

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

a: TAPS is not chartered to do anything normative.  Doc 3 is about
experimenting.

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.

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?

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

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Tue, 27 Oct 2015 10:44:50 +0100

HI,

Just a note. Not necessarily relevant for the overall argument however.

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

 SCTP also provides drop notification (SEND_FAILURE).

BR, Karen

---

From: Michael Welzl <[email-masked]>
Date: Tue, 27 Oct 2015 14:35:34 +0100

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

… 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

---

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

> On 26. okt. 2015, at 17.35, Aaron Falk <[email-masked]> wrote:
> 
> On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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!

> 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

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 27 Oct 2015 15:00:20 +0100

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

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.

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 <[email-masked]>:
> 
>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 27 Oct 2015 10:08:15 -0400

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.

Marie-José
> On Oct 27, 2015, at 10:00 AM, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi all,
>

---

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

> On 27. okt. 2015, at 15.00, Mirja Kühlewind <[email-masked]> 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.

> 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

---

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

> On 27. okt. 2015, at 15.08, Marie-Jose Montpetit <[email-masked]> wrote:
> 

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

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 27 Oct 2015 10:33:35 -0400

> 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?
We need that of course but I don’t see now any list of what are the common features between all transports (to start with) and then how to discover the rest :-)
> 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 s…
I did not suggest abandoning it. Just making sure it does focus on what is needed.

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 27 Oct 2015 15:46:56 +0100

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?

Further see below.

> Am 27.10.2015 um 15:27 schrieb Michael Welzl <[email-masked]>:
> 
> 

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. For me that would even be part of the second doc in the charter.

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

See above. For me the only question is, how can we make sure we cover the right things and don’t forget important stuff. And in both cases the answer is we can’t.

For me analyzing (only) the interfaces, is the more arbitrary approach because the current interfaces are already arbitrary to some extend and that’s exactly what we want to change. But that’s my personal view and there might not be an objective conclusion here.

> 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-t…

I don’t have the feeling that the new doc is much better. Important is that the wg knows that these features are not written in stone and we still have to think about the right choices here for any future work. I believe that’s true for both docs.

Mirja

---

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

> On 27. okt. 2015, at 15.46, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Michael,
> 

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)

> 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-transports. The second doc in the charter is about narrowing down the services, not adding more detail.

> 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 think merging them would get messy.

> See above. For me the only question is, how can we make sure we cover the right things and don’t forget important stuff. And in both cases the answer is we can’t.

Given the RFC text describes well what a protocol offers to the upper layer and how it’s used, my procedure (above) should give you exactly what’s needed.

> For me analyzing (only) the interfaces, is the more arbitrary approach because the current interfaces are already arbitrary to some extend and that’s exactly what we want to change. But that’s my p…

This document is not about analyzing only the interfaces: it’s about analyzing RFC text that describes what a protocol offers to the upper layer and how it’s used. Because TCP and SCTP have abstract API descriptions, that makes up more than 90% of this text in case of these two protocols.

When you say that the current interfaces (which, for the context of draft-welzl-taps-transports, are the abstract interfaces in the RFCs) are "already arbitrary to some extent”, you really criticize the text in the RFC that describes how to use a protocol; then, I think you should be specific and explain what you think is wrong per protocol, and maybe suggest an update or errata. I do think that a lot of thinking has gone into these text bits… even though real-life implementations may diverge from these abstract APIs.

I also don’t think we want to *change* these interfaces, but describe how to create a generic one that is built upon them.

> I don’t have the feeling that the new doc is much better. Important is that the wg knows that these features are not written in stone and we still have to think about the right choices here for any…

I don’t get that; can you give an example?

Cheers,
Michael

---

From: Stein Gjessing <[email-masked]>
Date: Tue, 27 Oct 2015 20:31:21 +0100

Hi,

Sorry for the long silence.  I have been on vacation with  almost no internet connection.
I will attend IETF 94, but I don´t feel ready to lead a discussion about charter item 2.
However, I will take part in the discussion and gladly contribute to the draft we eventually have to make to fulfill the charter, possibly by revising draft-gjessing-taps-minset.

Stein

On 22 Oct 2015, at 16:14, Aaron Falk <[email-masked]> wrote:

> Stein, will you be in Yokohama and interested in leading a discussion on this draft?
> 
> --aaron

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 27 Oct 2015 22:02:48 +0100

Hi,

see inline.

> Am 27.10.2015 um 19:56 schrieb Michael Welzl <[email-masked]>:
> 
> 
I disagree.

> 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 ha…
I disagree.

> 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 i…

I don’t think „no congestion control“ is a service. That’s not a logic I understand; sorry.

I don’t think that the point we want to capture is if there is congestion control or not; it’s rather with choices you have about congestion control. And today you might pick one congestion control by name, where the name is a random pick and does not say anything about the mechanism that is used. I’d hope that taps could actually provide an interface that’s actual useful and understandable such that the transport layer can pick the right congestion control for you.

I thought that one of the main points!

> (I’m ignoring the fact that the checksum can be disabled in UDP now, for simplicity)
Okay, even if extending existing protocols not in the charter, just because every protocol would use the same checksum, that does not mean that it would not be useful to maybe disable it. And if that would be detected by taps which would mean a small protocol change, we could go to the respective wg (e.g. tsvwg or tcpm) and figure out if they would consider such an extension useful. I’m absolutely not convinced here that we don’t want to do that.

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!

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.

The true might be somewhere in between here and we might need to do both to get an as complete as possible picture. As I said in my previous mail, we could even even merge both docs and or have two separate ones. Again as I said before to me the approach you take is less logical and I don’t think it will led to a complete or ‚right‘ solution either.

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!

Mirja

---

From: Michael Welzl <[email-masked]>
Date: Wed, 28 Oct 2015 09:05:14 +0100

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.

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

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 p…

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

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 28 Oct 2015 13:23:36 +0100

Hi Micheal,

this is only a personal opinion and I do not object to work on this doc.

Mija

> Am 28.10.2015 um 09:05 schrieb Michael Welzl <[email-masked]>:
> 
> Hi Mirja,
>