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

Brian Trammell <ietf@trammell.ch> Thu, 12 November 2015 14:47 UTC

Return-Path: <ietf@trammell.ch>
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 88B861B2F92 for <taps@ietfa.amsl.com>; Thu, 12 Nov 2015 06:47:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 ggX33aCKoQIJ for <taps@ietfa.amsl.com>; Thu, 12 Nov 2015 06:47:43 -0800 (PST)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 16E1E1B2F8A for <taps@ietf.org>; Thu, 12 Nov 2015 06:47:42 -0800 (PST)
Received: from nb-10604.ethz.ch (nb-10604.ethz.ch [82.130.102.91]) by trammell.ch (Postfix) with ESMTPSA id B2DAF1A0592; Thu, 12 Nov 2015 15:47:11 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_692F914F-9855-4670-BCE7-C95136619FD0"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <172925b64087d68c0c9f4a1de58daec5@mail.gmail.com>
Date: Thu, 12 Nov 2015 15:47:10 +0100
Message-Id: <8F199E14-31D8-4647-B025-BAAA15B1953F@trammell.ch>
References: <20151007104314.19878.21283.idtracker@ietfa.amsl.com> <172925b64087d68c0c9f4a1de58daec5@mail.gmail.com>
To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/WULQxlco_WZ_cS8ZFhjllcMdvwQ>
Cc: Michael Tuexen <tuexen@fh-muenster.de>, =?utf-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, taps@ietf.org
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: Thu, 12 Nov 2015 14:47:45 -0000

hi Karen,

Thanks for the comments and review! Commentcomments inline, anything not remarked on is accepted into -08 as-is.

> On 28 Oct 2015, at 13:16, Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> wrote:
> 
> 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].

It does seem to me that CC algorithms as deployed in the Internet are somewhat orthogonal to the mechanics of the underyling transport protocol, so this is probably not a bad idea... I'll have a look at how this could be easily refactored out of the document, probably into a new section 4 (before the present section 4)...

> 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 ?

I've never seen it treated as one; to my knowledge inconsistent treatment has led to PSH being largely ignored/ignorable, but there are probably people with more thorough knowledge on this list...

> The urgent flag is not recommended ... so does it belong here ?

It does provide a (not very functional) out of order delivery mechanism, though its deprecation should be referenced here here. Will do so in -08.

> Section 4.1:

Section 4.1 has been removed, in the interests of getting the document out the door. The hierarchical list in Section 4 replaces it.

> I wonder if SCTP Reliability could be Full/Partial/None

This is captured in the present (GitHub) revision of the list.

> I wonder if unordered delivery should be added as a row.

Unordered delivery is an entry in the list.

> I am not sure if ECN for SCTP should be marked as TBD. Applicability of
> RFC3168 to SCTP is described in RFC4960.

We don't have a line item for ECN in the list yet, perhaps we should.

> I personally don’t know of any deployment of this.


By "no deployment" you mean "no implementation" or "it's not turned on"?

Thanks again, cheers,

Brian