> On 26. okt. 2015, at 15.46, Gorry Fairhurst <[email protected]> wrote: > > On 26/10/2015 13:46, Michael Welzl wrote: >> >>> On 26. okt. 2015, at 14.17, Aaron Falk <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst <[email protected] >>> <mailto:[email protected]>> 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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
