Re: [Taps] I-D Action: draft-ietf-taps-transports-07.txt

Karen Elisabeth Egede Nielsen <> Wed, 28 October 2015 12:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 751481B540B for <>; Wed, 28 Oct 2015 05:16:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.079
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PRrTxEEYQyLF for <>; Wed, 28 Oct 2015 05:16:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CFFC91B5408 for <>; Wed, 28 Oct 2015 05:16:17 -0700 (PDT)
Received: by iody8 with SMTP id y8so7918213iod.1 for <>; Wed, 28 Oct 2015 05:16:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type:content-transfer-encoding; bh=qsJ1ixVXORyvQ6O9f9acJDo6ziJnO2lFjg+unt8Cllg=; b=HESHH6J6J5J6KrgO6YeTD2UHAQJlufvXf0PKOTuVANzU7DGApvTpmOotLv111hssoO G4TJIwvLgcATkmFC+qT+znNoKnZqqHpkQdhTrkNiI2yHxPkwoOLaCqVWbIyO4w7FSDGN 1dWTSfTYTT7q55r3/nCW1SbnVh0czlRpJ1fBk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=qsJ1ixVXORyvQ6O9f9acJDo6ziJnO2lFjg+unt8Cllg=; b=SeRusMg0J/P/LAGvkfGurekSovuNhI8+58DvVorcXXOuxXdnxgYn6n3SLgeoSx9G7k sO9mSGgkjAEMHvSK6QY6o1xT1TaFzRCJqIZWrwfPnMRoW3ga+6pGXIU034qz/KH6cTf2 gPwtEEdOw8ok2EV64vE7iXACzELqSY69zDKASUwfddTiK9aGZt0dob69QmHba+R1r9a4 Xfu9/mrFZttmitGpJUyyrFCWTh+nywZm6GwEsq7AXdrZhINKd1oYosvfcCrpdyPGKCE9 WPB0wxfoTy8fQW23OdT+ziTHhotcRhor2mGiIubWSlOiSIVZo0flnmKErB1AEennwCep FElg==
X-Gm-Message-State: ALoCoQnbntLDkggzkBuVGGBgDFQE+WPbcCJeHaJen5Mq5t/6uP0AX/op0kadYO6X/CGLgmERgqFFy4J+DGj4BaWwbBaNneQ5+dzjJuym5wRqQRoSkrFN1xE=
X-Received: by with SMTP id d16mr34182492ioe.38.1446034577153; Wed, 28 Oct 2015 05:16:17 -0700 (PDT)
From: Karen Elisabeth Egede Nielsen <>
References: <>
In-Reply-To: <>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFZLlo63tGRXuxbUdNMPdEANZ+3J59wbm6w
Date: Wed, 28 Oct 2015 13:16:15 +0100
Message-ID: <>
To:, Brian Trammell <>, Mirja Kühlewind <>, Michael Tuexen <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-07.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Oct 2015 12:16:21 -0000


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

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

Section 3.3.2:

First bullet:

"In case of send failures that application .. " --> propose to replace

"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 [] On Behalf Of internet-
> Sent: 7. oktober 2015 12:43
> To:
> Cc:
> Subject: [Taps] I-D Action: draft-ietf-taps-transports-07.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
>  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:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> Taps mailing list