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 >
- [Taps] TCP components Mirja Kühlewind
- Re: [Taps] TCP components gorry
- Re: [Taps] TCP components Mirja Kühlewind
- Re: [Taps] TCP components gorry
- Re: [Taps] TCP components Mohamed Oulmahdi
- Re: [Taps] TCP components Mirja Kühlewind
- Re: [Taps] TCP components Joe Touch
- Re: [Taps] TCP components Michael Welzl
- Re: [Taps] TCP components Mirja Kühlewind
- Re: [Taps] TCP components Michael Welzl
- Re: [Taps] TCP components Brian Trammell
- Re: [Taps] TCP components Erik Nygren
- Re: [Taps] TCP components Joe Touch
- Re: [Taps] TCP components Aaron Falk
- Re: [Taps] TCP components Mirja Kühlewind
- Re: [Taps] TCP components Michael Welzl
- Re: [Taps] TCP components Michael Welzl
- Re: [Taps] TCP components Mirja Kühlewind
- Re: [Taps] TCP components Michael Welzl
- Re: [Taps] TCP components Joe Touch
- Re: [Taps] TCP components Brian Trammell
- Re: [Taps] TCP components Michael Welzl
- Re: [Taps] TCP components Mirja Kühlewind
- Re: [Taps] TCP components Brian Trammell
- Re: [Taps] TCP components Michael Welzl
- Re: [Taps] TCP components Michael Welzl
- Re: [Taps] TCP components Mirja Kühlewind
- Re: [Taps] TCP components Joe Touch
- Re: [Taps] TCP components Joe Touch
- Re: [Taps] TCP components Mohamed Oulmahdi
- Re: [Taps] TCP components Joe Touch
- Re: [Taps] TCP components Mohamed Oulmahdi
- Re: [Taps] TCP components Joe Touch
- Re: [Taps] TCP components Michael Welzl
- Re: [Taps] TCP components Jon Crowcroft
- Re: [Taps] TCP components Joe Touch
- Re: [Taps] TCP components Wesley Eddy
- Re: [Taps] TCP components Karen Elisabeth Egede Nielsen
- Re: [Taps] TCP components Michael Welzl
- Re: [Taps] TCP components Karen Elisabeth Egede Nielsen
- Re: [Taps] TCP components Michael Welzl
- Re: [Taps] TCP components Joe Touch
- Re: [Taps] TCP components Karen Elisabeth Egede Nielsen
- Re: [Taps] TCP components Joe Touch