Re: [Taps] TCP components

gorry@erg.abdn.ac.uk Thu, 11 June 2015 12:32 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DA51ACE48 for <taps@ietfa.amsl.com>; Thu, 11 Jun 2015 05:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.911
X-Spam-Level:
X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWTnE1Gx0uWA for <taps@ietfa.amsl.com>; Thu, 11 Jun 2015 05:32:05 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id A4EA11ACE0C for <taps@ietf.org>; Thu, 11 Jun 2015 05:31:40 -0700 (PDT)
Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id F2D181B001AB; Thu, 11 Jun 2015 13:31:38 +0100 (BST)
Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Thu, 11 Jun 2015 13:30:37 +0100
Message-ID: <2e1ca6a7e239e671b7516431ad5db93c.squirrel@erg.abdn.ac.uk>
In-Reply-To: <5579768E.5060402@tik.ee.ethz.ch>
References: <5579768E.5060402@tik.ee.ethz.ch>
Date: Thu, 11 Jun 2015 13:30:37 +0100
From: gorry@erg.abdn.ac.uk
To: "\"Mirja Kühlewind\"" <mirja.kuehlewind@tik.ee.ethz.ch>
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/c23qCisA7Fufz7ZPsUeYb2D-EDE>
Cc: Brian Trammell <ietf@trammell.ch>, "taps@ietf.org" <taps@ietf.org>
Subject: Re: [Taps] TCP components
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2015 12:32:10 -0000

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
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>