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?!
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?
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.
Cheers,
Michael
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
