[Taps] TCP components

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Thu, 11 June 2015 11:52 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 114771ACD98 for <taps@ietfa.amsl.com>; Thu, 11 Jun 2015 04:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 xJ48XqzRd90y for <taps@ietfa.amsl.com>; Thu, 11 Jun 2015 04:52:50 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811DD1ACD96 for <taps@ietf.org>; Thu, 11 Jun 2015 04:52:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3ED87D9316; Thu, 11 Jun 2015 13:52:47 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BRdBypS48IIs; Thu, 11 Jun 2015 13:52:46 +0200 (MEST)
Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E37F7D9309; Thu, 11 Jun 2015 13:52:46 +0200 (MEST)
Message-ID: <5579768E.5060402@tik.ee.ethz.ch>
Date: Thu, 11 Jun 2015 13:52:46 +0200
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "taps@ietf.org" <taps@ietf.org>, Brian Trammell <ietf@trammell.ch>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/3513zTeQA-k3tAn0HyqXJtrxMCo>
Subject: [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 11:52:56 -0000

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.

Brian and Mirja