Re: [Taps] IETF planning

[Gorry Fairhurst <[e-mail]>]

On 26/10/2015 13:46, Michael Welzl wrote:
>
>> On 26. okt. 2015, at 14.17, Aaron Falk <[e-mail]
>> <mailto:[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.
>
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.
>
> 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?

Gorry