I have a few comments, see below:
> 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.
GF: Not quite - To me, it prevents increased delay from the TCP protocol.
It doesn't really control anything to reduce delay.
> - Port multiplexing, with application-to-port mapping during connection
> setup:
GF: Thinking on this, is application-to-port mapping really a TCP
function? port-mapping is similar in other transports, and doesn't really
have any different support in TCP (contrast to the Service Code in DCCP)
> 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.
>
GF: This is the case only for those middle boxes that do NAPT,
load-ballancing etc, saying they are part of the endpoint address is to me
confusing forwarding by middle boxes from forwarding by routers - I'd
prefer to be more careful here.
> - 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.
>
GF: DupACK, SACK, and the RTO. (explicit NACK is I think only used in
SCPS-TP and probably doesn't nee dot be mentioned).
> - 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.
>
GF: True (actually packets header checks and data segments + pseudo header)
> - 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.
>
GF: Does environment mean path? or something else?
> - 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.
>
GF: Generally? Shouldn't RTO imply loss of path state and always result in
a larger reaction? (RTO back-off for instance).
>
> 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.
>
> Brian and Mirja
>
>
>
> _______________________________________________
> Taps mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/taps
>
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
