Re: [Taps] Comments on draft-gjessing-taps-minset-00
gorry@erg.abdn.ac.uk Fri, 26 June 2015 10:15 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 89D4A1A8BBD for <taps@ietfa.amsl.com>; Fri, 26 Jun 2015 03:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vf9uqKTVa_cF for <taps@ietfa.amsl.com>; Fri, 26 Jun 2015 03:15:32 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 86EAA1A8AFE for <taps@ietf.org>; Fri, 26 Jun 2015 03:15:32 -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 401BA1B00139; Fri, 26 Jun 2015 11:14:52 +0100 (BST)
Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Fri, 26 Jun 2015 11:14:23 +0100
Message-ID: <c578df4811331b36948361fb6afcd358.squirrel@erg.abdn.ac.uk>
In-Reply-To: <B12A213E-FA7E-414B-84AF-F3E94CB0AA34@ifi.uio.no>
References: <734fb5eae22df80e67a71fde5ad74204.squirrel@erg.abdn.ac.uk> <B12A213E-FA7E-414B-84AF-F3E94CB0AA34@ifi.uio.no>
Date: Fri, 26 Jun 2015 11:14:23 +0100
From: gorry@erg.abdn.ac.uk
To: Stein Gjessing <steing@ifi.uio.no>
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/601gL2OGi2H54OoHkxP9stpfmew>
Cc: gorry@erg.abdn.ac.uk, Stein Gjessing <steing@ifi.uio.no>, Michael Welzl <michawe@ifi.uio.no>, taps@ietf.org
Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-00
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 26 Jun 2015 10:15:34 -0000
See in-line, Gorry > Hi Gorry, > > Thank you very much for your feedback. > We will add what you point out that we have missed in Section 3. > > Some more comments in-line. > > On 26 Jun 2015, at 11:21, gorry@erg.abdn.ac.uk wrote: > >> >> Thanks for submitting this. I like the idea of trying to get a handle on >> the minimal transport services that TAPS can support. >> >> Detailed comments on: >> https://tools.ietf.org/html/draft-gjessing-taps-minset-00 >> >> In Section 1: >> >> I think the word "non-functional" is a little awkward, since it suggests >> "dysfunctional" and we probably should seek a different word for >> clarity. > > You are the english speaking person her, so you are probably right. > However non-functional has a technical meaning in software design, and > that is what I > meant here. See e.g.. > https://en.wikipedia.org/wiki/Functional_requirement > Yes I see this use, but still wonder if this is the best word. >> >> In Section 3: >> >> My initial comments are on the list of features (this may have to be fed >> back to the 1st TAPS ID, but it is more clear here at the moment, so >> I'll >> comment here and see what people think: >> >> o unicast: TCP SCTP UDP-Lite DCCP NORM >> - Add UDP-Lite >> >> o IPv6 multicast and anycast: UDP >> - Add UDP-Lite >> >> o multicast: NORM >> - ??? Is this reliable, the multicast part includes UDP, UDP-Lite (as >> non-reliable) > > I am not sure what you mean here. Does not NORM implement multicast? > There is no statement about it being reliable or not (but may be it > should?) > What I intended to say was: The set of transports supporting multicast IPv4 or IPv6 is {UDP, UDP-Lite, NORM} And hence NORM supports this over UDP, and adds reliability (in various forms). >> >> o unidirectional: UDP >> - Add UDP-Lite >> >> o bidirectional: TCP >> - Add DCCP, SCTP >> >> o IPv6 jumbograms: UDP >> - Add UDP-Lite >> >> o 2-tuple endpoints: UDP >> - Add UDP-Lite >> >> o error detection (checksum): TCP UDP >> - Add UDP-Lite, DCCP >> >> o error detection (UDP checksum): NORM >> -??? I see this is via UDP, but is it a real difference, NORM is only >> specified over UDP > > Yes, so if we want to include NORM (or may be we should not in the initial > minimal version?) > then we must include that it supports error detection as in UDP (?). > Yes - NORM is over UDP, and hence I think its error *detection* model is the same as UDP. >> >> o strong error detection (CRC32C): SCTP >> - Possible with TCP option, or AUTH or TLS (and possible with >> UDP/UDP-Lite/DCCP using DTLS >> >> o congestion control: TCP SCTP NORM >> - Add DCCP >> >> o no congestion control: UDP >> - Add UDP-Lite >> >> On section 4 >> >> I can offer more comments later, but initially I just note that I think >> the Service Code in DCCP *IS* specified by the Application in the same >> way >> that the port is chosen. > > OK, so we have to include this. > > Cheers, > Stein > >> >> Gorry >> >> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >