Re: [Taps] IETF planning

[Michael Welzl <[e-mail]>]

> On 26. okt. 2015, at 15.46, Gorry Fairhurst <[e-mail]> wrote:
> 
> 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.

… 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