Re: [Taps] I-D Action: draft-ietf-taps-transports-07.txt
Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> Wed, 28 October 2015 12:40 UTC
Return-Path: <karen.nielsen@tieto.com>
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 4D26E1A876B for <taps@ietfa.amsl.com>; Wed, 28 Oct 2015 05:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.079
X-Spam-Level:
X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 eJApKvFaFnnh for <taps@ietfa.amsl.com>; Wed, 28 Oct 2015 05:40:27 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA931A8767 for <taps@ietf.org>; Wed, 28 Oct 2015 05:40:27 -0700 (PDT)
Received: by igbdj2 with SMTP id dj2so5841806igb.1 for <taps@ietf.org>; Wed, 28 Oct 2015 05:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type:content-transfer-encoding; bh=i1YhqeFqJfrKTwbH6/YInGi5iCVTYTbMjtyeAaPIoy4=; b=5wmM7DqM5fH04DJ8vjjTKZisK7uanQBauDmkS+KVkbM3KNBSSiyCeesw2/BAkU+okk /0LHDTM1dcY0QXZ6VxppEy0qKcJHfGEy7EaQ/0HIRQaIRHr/Qdn4RM5rsPEgZnl343Md H+Amexnk/VOlgjlFcZkEWnW33HYd/MCuYGEOU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type :content-transfer-encoding; bh=i1YhqeFqJfrKTwbH6/YInGi5iCVTYTbMjtyeAaPIoy4=; b=N/yAvJL2Jo7eopyZeEP4EuMBConGSAGxuiO0rv/axDdavj54F4z8TAthPnOWuBrCMW kwpAg8ulSmQFNRe1T6iH7BLbwz+flEZ5IS3RJY4FHxHmf47Nx9h7MYakn1riPXS1LHXD Nr5aML6jpGtE0S7+yTfIXsKuZFPOvzv1PlrW5xmXSG5JdBGaVbCzYzedZ4Uq4kyV6KxA 6z3rD7RFx76kIp4BH0v74CMbP1M7emkU2k4pbF4/jExpu36ukm2nKKcQ3wBNGSt0k/Z5 IA2uJqbHUG4Fy96RVEdoUx016Evvtis2xa1W3vIFNt+0l0rDM9JVbDLBHwouwQR+rtpd ZAwQ==
X-Gm-Message-State: ALoCoQliN3sJHlx42tYSIyMenIEQlFo6zzAnW5ymVZ0Swflp80y9A8oj1uHpC2gxhlblDoTMxoAaFymY/brZ2NQkxG+nsHaZTnH0OLUvbmr6bhSiehwEO7Y=
X-Received: by 10.50.43.129 with SMTP id w1mr2739030igl.96.1446036026842; Wed, 28 Oct 2015 05:40:26 -0700 (PDT)
From: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
References: <20151007104314.19878.21283.idtracker@ietfa.amsl.com> 172925b64087d68c0c9f4a1de58daec5@mail.gmail.com
In-Reply-To: 172925b64087d68c0c9f4a1de58daec5@mail.gmail.com
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFZLlo63tGRXuxbUdNMPdEANZ+3J59wbm6wgAAutoA=
Date: Wed, 28 Oct 2015 13:40:25 +0100
Message-ID: <8d277b9e34b04d4f25758383e6f1429f@mail.gmail.com>
To: taps@ietf.org, Brian Trammell <ietf@trammell.ch>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Michael Tuexen <tuexen@fh-muenster.de>, Michael Welzl <michawe@ifi.uio.no>, gorry@erg.abdn.ac.uk
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-DomainID: tieto.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/a7_YLk04XjawXR58TUrYK9skOAQ>
Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-07.txt
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: Wed, 28 Oct 2015 12:40:29 -0000
BTW, My personal opinion is that this document, in this version, is very good and serves well the purpose of providing a comprehensive survey of the services provided with a number of the IETF transport protocols. I do note, however, that the title of the document puts bigger emphasis on congestion control than the document content as such. I further, personally, consider the document draft-welzl-taps-transport as a good, and necessary, supplement going more into the details of the existing transport service interface(s). Thanks. BR, Karen > -----Original Message----- > From: Karen Elisabeth Egede Nielsen [mailto:karen.nielsen@tieto.com] > Sent: 28. oktober 2015 13:16 > To: 'taps@ietf.org'; 'Brian Trammell'; 'Mirja Kühlewind'; Michael Tuexen > (tuexen@fh-muenster.de) > Subject: RE: [Taps] I-D Action: draft-ietf-taps-transports-07.txt > > HI, > > Please accept the following comments. > Use them as/if you see fit. > (Given my wretched, non-twistable, arms you are allowed not to take them > too seriously) > > Section 3.1.1: > > 6'th paragraph: > > " In addition, a congestion control > mechanism may react to changes in delay as an early indication for > congestion." > > I think one will need to give a reference to this as it is not covered by the > reference to RFC5681. > Possibly this statement is better given in the context of the next paragraph > referring to extensions. > > [I am aware that I have given this comment before. The reason that this > continues to be an issue for me is that > delay based CC alg's also are applicable to, e.g., SCTP (and have been applied > there, though I don't know much > about real deployment of them for SCTP). > I am not sure if the solution to this is to have a special common section about > congestion control algorithms - referring possibly > to that these special CC als mostly are in deployment for TCP]. > > 9'th paragraph: > > Reference to push flag: > > The sentence: > > "TCP provides a push and a urgent function to enable data to be > directly accessed by the receiver without having to wait for in-order > delivery of the data." > > Should be revised I think. It is not very clear what the push flag contribute > with in this sentence. The PUSH flag helps to release a "tail" > packet from a TSO/GRO function/temporary packet buffering function. This > feature of TCP might be significantly enough to describe the > PUSH flag function as an implicit and internal protocol implementation > optimization making TCP "push" tails through > intermediate buffering functions. But the PUSH function is not really a > "function" that TCP stacks provide to the ULP today > (even if this is described as an optional possibility in RFC1122) - Or is it ? > > The urgent flag is not recommended ... so does it belong here ? > > Section 3.3: > > 1'st Paragraph: > > I propose to remove the sentence: > > "It also optionally supports path failover to > provide resilience to path failures." > > There is no optionality about it and I think it is covered in the sentence > before on supporting MH > to handle path failures. > > In sentence: > > "An SCTP association has > multiple unidirectional streams in each direction and provides in- > sequence delivery of user messages only within each stream." > ^^^ > I propose to remove the word "only". > > I suggest to add the following sentence: > > "SCTP supports multiple stream scheduling schemes controlling the > multiplexing of the streams > into the transmission channel. Including priority as well as fair weighting > schemes." > > Section 3.3.1: > > I propose to add the following sentence in the end of the paragraph on > multi-homing below the bulleted list: > > "[I-D.ietf-tsvwg-sctp-failover] specifies a quicker failover operation reducing > the latency of the failover". > > Inserted before the last sentence as follows: > > "If a remote > address becomes unreachable, the traffic is switched over to a > reachable one, if one exists. [I-D.ietf-tsvwg-sctp-failover] specifies a > quicker failover operation > reducing he latency of the failover. > Each SCTP end-point supervises > continuously the reachability of all peer addresses using a heartbeat > mechanism." > > Section 3.3.2: > > First bullet: > > "In case of send failures that application .. " --> propose to replace with > > "In case of send failures, including drop of messages sent unreliably, the > application " > > Third last paragraph: > > snet --> sent > > Section 3.3.3. > > Suggest to replace: > > fully reliable or partially reliable delivery --> with --> > > fully reliable, partially reliable and unreliable delivery > > Section 4.1: > > I wonder if SCTP Reliability could be Full/Partial/None > > I wonder if unordered delivery should be added as a row. > > I am not sure if ECN for SCTP should be marked as TBD. Applicability of > RFC3168 to SCTP is described in RFC4960. > I personally don’t know of any deployment of this. > > > BR, Karen > > > > > -----Original Message----- > > From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: 7. oktober 2015 12:43 > > To: i-d-announce@ietf.org > > Cc: taps@ietf.org > > Subject: [Taps] I-D Action: draft-ietf-taps-transports-07.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Transport Services Working Group of the > IETF. > > > > Title : Services provided by IETF transport protocols and > congestion > > control mechanisms > > Authors : Godred Fairhurst > > Brian Trammell > > Mirja Kuehlewind > > Filename : draft-ietf-taps-transports-07.txt > > Pages : 53 > > Date : 2015-10-07 > > > > Abstract: > > This document describes services provided by existing IETF protocols > > and congestion control mechanisms. It is designed to help > > application and network stack programmers and to inform the work of > > the IETF TAPS Working Group. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-taps-transports-07 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-07 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps
- [Taps] I-D Action: draft-ietf-taps-transports-07.… internet-drafts
- Re: [Taps] I-D Action: draft-ietf-taps-transports… Karen Elisabeth Egede Nielsen
- Re: [Taps] I-D Action: draft-ietf-taps-transports… Karen Elisabeth Egede Nielsen
- Re: [Taps] I-D Action: draft-ietf-taps-transports… Brian Trammell
- Re: [Taps] I-D Action: draft-ietf-taps-transports… Karen Elisabeth Egede Nielsen