> On 26. okt. 2015, at 14.17, Aaron Falk <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. > 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
