On 26/10/2015 13:46, Michael Welzl wrote:
On 26. okt. 2015, at 14.17, Aaron Falk <aaron.f...@gmail.com
<mailto:aaron.f...@gmail.com>> wrote:
On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst <go...@erg.abdn.ac.uk
<mailto:go...@erg.abdn.ac.uk>> 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
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
