Re: [Taps] IETF planning

[Michael Welzl <[e-mail]>]

> On 26. okt. 2015, at 14.17, Aaron Falk <[e-mail]> wrote:
> 
> On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst <[e-mail] <mailto:[e-mail]>> 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?
> 
> 
> 
> <snip test on another draft>
> 
> 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