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>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <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'.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