On Jun 17, 2015, at 10:28 AM, Mirja Kühlewind <mirja.kuehlew...@tik.ee.ethz.ch> wrote:
> Hi Michael, > > see below. > >> Am 17.06.2015 um 09:36 schrieb Michael Welzl <mich...@ifi.uio.no>: >> >> Hi, >> >> >>> On 11 Jun 2015, at 13:52, Mirja Kühlewind <mirja.kuehlew...@tik.ee.ethz.ch> >>> wrote: >>> >>> Hi all, >>> >>> we gave it a first try to rewrite the component section for TCP. The >>> insight I took from the discussion on the list is that components probably >>> are much more linked to the implementation (choices) a certain protocol >>> made while features are probably more high-level having the question in >>> mind what does an application potentially want/need to know. >>> >>> So for the components in TCP we now have the following list: >>> >>> - Connection-oriented bidirectional communication using three-way handshake >>> connection setup with >>> feature negotiation and an explicit distinction between passive and >>> active open: >>> This implies both unicast addressing and a guarantee of return >>> routability. >>> - Single stream-oriented transmission: >>> The stream abstraction atop the datagram service provided by IP is >>> implemented by dividing >>> the stream into segments. >>> - Limited control over segment transmission scheduling (Nagle's algorithm): >>> This allows for delay minimization in interactive applications. >>> - Port multiplexing, with application-to-port mapping during connection >>> setup: >>> Note that in the presence of network address and port translation >>> (NAPT), TCP ports are >>> in effect part of the endpoint address for forwarding purposes. >>> - Full reliability based on ack-based loss detection and retransmission: >>> Loss is sensed using duplicated acks ("fast retransmit"), which places >>> a lower bound on >>> the delay inherent in this approach to reliability. >>> - Error detection based on a checksum covering the network and transport >>> headers as well as payload: >>> Packets that are detected as corrupted are dropped, relying on the >>> reliability mechanism >>> to retransmit them. >>> - Window-based flow control, with receiver-side window management and >>> signaling of available window: >>> Scaling the flow control window beyond 64kB requires the use of an >>> optional feature, >>> which has performance implications in environments where this option is >>> not supported. >>> - Window-based congestion control reacting to loss, delay, retransmission >>> timeout, or >>> an explicit congestion signal (ECN): >>> Most commonly used is a loss signal from the reliability component's >>> retransmission mechanism. >>> TCP reacts to a congestion signal by reducing the size of the >>> congestion window; >>> retransmission timeout is generally handled with a larger reaction than >>> other signals. >>> >>> We are currently still working on the list of features that results from >>> thiese components but we are not there yet. Probably we not only need the >>> features itself but also properties/aspects (or however you want to call >>> this) of the feature. We already had this discussion a bit but wanted to >>> postpone the decision if we really need to define an own term for this >>> until we are sure that we need it. >>> >>> We are posting this list of (TCP) components now because we would like to >>> get some feedback if this goes into the right direction/is on the right >>> level of detail before we go on and apply this also to other protocols. >> >> I agree that the list below is closer to what I think a "component" should >> be ... but looking at it, is it not even clearer now that components are not >> what TAPS is after? To me this list now contains lots and lots of details >> that are irrelevant to the service provided to the application. Not harmful >> to list but pretty useless?! > > In this case we decided to list/discuss rather some more details, so that > people can understand what we had in mind. We might remove some of these > details/explanations at the end (or move those parts that are actually > relevant into the feature section (4)). > >> >> And how do you draw the line for what goes in and out of such a list? E.g., >> on which basis did you decide that FACK, FRTO, PRR and DSACK are not >> mentioned? > > We tried to ask ourself which parts have an effect on the behavior of the > flow that could potentially be of interest for the application. We might have > missed some points. Actually Gorry already point out some. Okay; btw just to be clear, I didn't mean that FACK etc. should be in the list - on the contrary! My point was really about "how do you draw the line", which you answered in the first sentence here. > The next step is to work on the feature list and figure out how these things > that are interesting for the application would be described in a more general > way (independent of the concrete algorithm that is used by one protocol) and > also discuss which features actually should be exposed because they have a > real use for the application. > >> >> To me, this whole thing is just too full of arbitrariness. We should aim for >> a systematic approach that minimizes the number of arbitrary decisions made >> IMO. > > For us the systematic approach is to look at the implementation of existing > protocol an figure out which algorithm have an influence on the traffic that > might be interest for a higher layer to control. So we always had, to some > extend, the application in mind. Okay, I understand. Thanks for clarifying! > However, you could go for a even more generic approach and only look at the > implementation and as a first step figure where are any knobs that in > principle could be configurable and then afterwards discuss all of these very > specific knobs. I though about this approach and think it would be an > interest exercise and potentially the right way to go. But I also think that > the overhead would be super large and I don’t think it would give us much > more than we have right now. So we the current approach we might need to > expect some arbitrariness… I lean towards this other one, of beginning with the knobs, but not with the implementation but rather the "abstract API" as Joe called it: the interface to the app as defined in the RFCs (for where it really *is* defined). I think that this discussion with Joe maybe suffered from focusing on TCP. SCTP is perhaps a better starting point because it supports almost everything. So I'm thinking that a different (and, to me, perhaps more appropriate and more systematic) method to get a list of features could be to start with the read / write options in RFC 6458, extend it with all such options from the other protocols, and then, protocol by protocol, ask: "what does this protocol provide that the list now doesn't contain?". Not sure the overhead of this approach would be super large? But I agree, you may end up with the same list the way you do it now. Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps