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
