Re: [Taps] TCP components

[Michael Welzl <[e-mail]>]

> On 17 Jun 2015, at 12:13, Brian Trammell <[e-mail]> wrote:
> 
> hi Michael, all,
> 
> A couple of random points inline at various levels of quotation...
> 
>> On 17 Jun 2015, at 10:44, Michael Welzl <[e-mail]> wrote:
>> 
>> 
>> On Jun 17, 2015, at 10:28 AM, Mirja Kühlewind <[e-mail]> wrote:
>> 
>>> Hi Michael,
>>> 
>>> see below.
>>> 
>>>> Am 17.06.2015 um 09:36 schrieb Michael Welzl <[e-mail]>:
>>>> 
>>>> Hi,
>>>> 
>>>> 
>>>>> On 11 Jun 2015, at 13:52, Mirja Kühlewind <[e-mail]> 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.
> 
> That's part of the point we're trying to address here. The realization we had here is that components *don't* necessarily map to feature, and it's not clear that we can simply ignore those components that don't map, since they may have impact on the interfaces/features it is possible to (reasonably) implement atop those protocols.
> 
>>>> Not harmful to list but pretty useless?!
> 
> Let's start with TCP as probably the most difficult example (indeed, that's why we worked out this "new" arrangement of components for TCP first). A completely clean and unambiguous decomposition of TCP into its features -- what, I agree, we're after in the end -- is not *really* possible, because the protocols as defined and implemented weren't really composed of discrete features. The evolution of loss-based congestion control, for instance, was predicated on the particular loss signals that were available at the time it was first defined. The error detection mechanism likewise relies on the fact that reliability is provided by retransmission. One could say that given the parallel evolution of computing power that all these choices made by TCP were the only obvious ones at the time. But it's precisely the co-evolution of reliability and congestion control that makes gluing FEC to TCP so fraught with peril. That's an important point to capture IMO.
> 
> I expect that the same exercise for SCTP will show a simpler mapping between components and features, since it *was* designed as a composition of features.

I expect that too, but I still don't understand the point of the component list above. I mean, yes, you may be able to map and say "we need components X Y Z to provide features A and B" but how does this help TAPS?


>>> 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,
> 
> ... understanding that interface definitions aren't just about which knobs (and indicators) the API provides, but also the interaction patterns it enables, and that these interaction patterns can also be made inefficient or even impractical by the details of the protocol in question. (It's always *possible* to implement object transfer over streams, or time domain transfer over objects, or to translate asynchonous events into a synchronous API. That the Web and video thereon "work" is proof of that. You can run the whole Internet over DNS, if you want to. It would not work as well as the one we have today. :) )

Yes, I agree, and I hope that this won't really bite us... or what's your plan for addressing this problem?


>> 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.
> 
> We can certainly do SCTP next, which should make the exercise look less arbitrary. (FWIW I don't think we can *eliminate* arbitrary decisions in classification and where to cut the line between components, or to determine which components are worth talking about. But minimizing them is a good goal. :) )
> 
>> 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.
> 
> Again, that captures knobs and indicators, less so interaction patterns. (I will say I'm not 100% convinced the interaction patterns are important to capture for the individual protocols, but paying attention to them will be *crucial* to making sure that TAPS-the-system sees uptake among application and platform developers)

I agree about that, but components won't capture these interaction patterns either, or (why/how) would they?

Cheers,
Michael