> On 17 Jun 2015, at 12:13, Brian Trammell <i...@trammell.ch> wrote:
>
> hi Michael, all,
>
> A couple of random points inline at various levels of quotation...
>
>> On 17 Jun 2015, at 10:44, Michael Welzl <mich...@ifi.uio.no> wrote:
>>
>>
>> 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.
>
> 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
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
