Re: [Taps] IETF planning

[Aaron Falk]

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

[Aaron Falk]

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?



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

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.
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps