> On 27. okt. 2015, at 15.00, Mirja Kühlewind <mirja.kuehlew...@tik.ee.ethz.ch> > wrote: > > Hi all, > > I didn’t say anything so far because I don’t mind to have a second protocol > here, but I personally don’t see this doc as really needed. Effectively we > will have two docs that have the same results (a list of features) at the end.
I think draft-welzl-taps-transports highlights how many services (or transport features or whatever we want to call them) are lost when we just compile a list as in draft-ietf-taps-transports. To give a few examples: SCTP: "ordered and unordered delivery within a stream” does not make it clear that you can in fact specify per-message whether ordering matters or not. In TCP, during the lifetime of a connection, you can change the DSCP value. In TCP, you can open a connection to listen at one local interface or any; in SCTP, you can specify a list of local interfaces We can debate whether these things are unnecessary details, but they are things that appear in draft-welzl-taps-transports as a result of the systematic approach I’ve taken. > I personally find the approach taken in the new doc even more arbitrary and > reading this discussion of what should be in and out just underlines this > point. Even more arbitrary => could you please explain? I think the discussion of what should be in and out has absolutely nothing to do with the arbitrariness of the approach taken in the doc. > From my point of view the taps-transports is ready now. Btw. we did not leave > out (hopefully) any features of RTP, we just decided to keep the description > very short and only focus in the description on those parts that are actually > transport related. > > I agree that the taps-transport doc is quite long, but for the wg I don’t the > the purpose of this doc in having it but in getting it. I mean the process we > had so far to get this doc in the right shape was very helpful and I believe > we are ready to move on. The only think that is interesting now for the wg is > the final list of feature, which is there and ready to use. > > As a side note, I also believe that other people might be interesting in > reading the doc for other reasons than participating in taps because it’s > actually a quite nice overview doc now. I agree that it’s a nice document and ready. As for “The only thing interesting for the wg is he final list of features, which is there and ready to use”, see the discussion above: the draft-ietf-taps-transports is a nice and useful survey, but I do not think it is a good basis for an implementable TAPS system, which we eventually want (doc 3). Cheers, Michael > > That’s just my 2c. I don’t want to hold the wg from any further steps > regarding draft-well-taps-transports; I just had the feeling I should also > express a different opinion here. > > Mirja > > >> Am 27.10.2015 um 14:47 schrieb Michael Welzl <mich...@ifi.uio.no>: >> >> >>> On 26. okt. 2015, at 17.35, Aaron Falk <aaron.f...@gmail.com> wrote: >>> >>> On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl <mich...@ifi.uio.no> wrote: >>> >>> 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. >>> >>> Uh, yeah. That's our charter. Narrowing down is in doc 2. Are you making >>> the case we should do it in doc 1? >> >> Well, just because we narrow down in doc 2 doesn’t mean that doc 1 has to >> contain everything under the sun as a starting point. Consider the >> discussion around RTP in draft-ietf-taps-transports - I think the consensus >> was to have only very short text on RTP in there, not a list of all the >> protocol features. The starting point for draft-welzl-taps-transports should >> probably be limited in a similar way, but I’d suggest limiting it more than >> draft-ietf-taps-transports - partially because draft-ietf-taps-transports >> can already show that certain protocols are not adding new transport >> features to the mix that don’t yet exist. >> >> Of course, the main reason behind my argument is to keep >> draft-welzl-taps-transports within a reasonable length. Look at its length >> now, with only two protocols! I think the length is inevitable, but if we >> have good reasons not to cover certain protocols, I think we should keep >> them out. At least it’s a valuable discussion to have! >> >> >>> 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. >>> >>> a: TAPS is not chartered to do anything normative. Doc 3 is about >>> experimenting. >> >> Sure! But it’s still about stuff that someone should be able to build - I >> just don’t want doc 3 to become a sci-fi literature piece :-) >> >> >>> b: You are having the discussion that we planned to have for Doc 2. Make >>> your case to drop those protocols then. Or, if no one wants to write >>> sections for the additional protocols for Doc 1a (an extended version of >>> draft-welzl-taps-transports), then folks are voting with their feet on the >>> utility of keeping them. >> >> See my arguments above; about getting sections done for >> draft-welzl-taps-transports, I don’t worry too much: this is only the very >> first version, we haven’t asked anyone for inputs yet (and I can volunteer >> to cover a few more protocols myself). >> >> >>> c: One of the goals of TAPS is to enable deployment of transport protocols >>> such as DCCP where networks permit it without forcing application (or >>> library) authors to handle probe and fallback. If we don't include >>> protocols that aren't seeing deployment, what is the value of this activity? >> >> This is a very good point. I’m not sure - do we really need to cover >> absolutely all protocols that are in draft-ietf-transports in >> draft-welzl-taps-transports, then? I am concerned about the implementability >> of the final beast… >> >> Cheers, >> Michael >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
