Re: [Taps] I-D Action: draft-ietf-taps-transports-07.txt
Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> Fri, 13 November 2015 09:06 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 E4C751A6F77 for <taps@ietfa.amsl.com>; Fri, 13 Nov 2015 01:06:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 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, 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 Q2fISGKC4n1f for <taps@ietfa.amsl.com>; Fri, 13 Nov 2015 01:06:23 -0800 (PST)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 7A8CD1A6F6F for <taps@ietf.org>; Fri, 13 Nov 2015 01:06:23 -0800 (PST)
Received: by igcph11 with SMTP id ph11so11664225igc.1 for <taps@ietf.org>; Fri, 13 Nov 2015 01:06:23 -0800 (PST)
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:cc:content-type:content-transfer-encoding; bh=NagOqNwrQb4WBIwwExIUt7wYosWgDmIxj8Wja4QgiII=; b=h7t01QF5deafPkl3IUDDmoCQrGCLxXpXsa2GVWubdO505GVcT7b0YwTUDtCf46Y1cN HiXDyzCuyVXiCnVFhtEGVIux6L6Wg9iFzGSSvGJFxVJfnQg187rC0+3FuwPuqi9COl6P ciG2seoEXGn+M3Vpl0QLcWNESLlkRiMm/rIDg=
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:cc:content-type :content-transfer-encoding; bh=NagOqNwrQb4WBIwwExIUt7wYosWgDmIxj8Wja4QgiII=; b=WYxBIuxWaf+rQMgxtk6kC7R+xvxa3CY+UHCVEdX/sjWqCCpOI2k6YKpuoXpY+QSydz nJinBJ6IPcXUFby2CMqsQViyFXLpPZfTx8LcpT6+YX9JRlgCG58CQ9V+iTuIKXr4Y4Z4 oL3LrMoZebtiQGgGL4drTse7t1IlQRFK3AqgFY36N2b9HRB/hTxOPNB+kvJk8pIjuxgF P+8pjMHk6TeG3YjcIYBlS7JzAlMisW2EK6pl9nOIR2hbv0ouCB6YprH+l05UGaiMUDr4 +hu0NyfsBahQGGSxmwSeBfr4/NM6f8lkaAkggPrB8lpH4R/njpBdi/hQ4BzFiLzJ90RV DQyQ==
X-Gm-Message-State: ALoCoQmml6Jvk2Es9sj93ovcMIeQ5FN0Ly2TLz5drFgkD3fOF/WX7qfPdrdwyg4+p27s/EkEay82Pl87N1ncI+G64U2IWsVIJS+xpS81vdCi8Nbaxki/W+c=
X-Received: by 10.50.55.72 with SMTP id q8mr2320649igp.2.1447405582892; Fri, 13 Nov 2015 01:06:22 -0800 (PST)
From: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
References: <20151007104314.19878.21283.idtracker@ietfa.amsl.com> <172925b64087d68c0c9f4a1de58daec5@mail.gmail.com> <8F199E14-31D8-4647-B025-BAAA15B1953F@trammell.ch>
In-Reply-To: <8F199E14-31D8-4647-B025-BAAA15B1953F@trammell.ch>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFZLlo63tGRXuxbUdNMPdEANZ+3JwGVAFACAcdBN26fbqKeoA==
Date: Fri, 13 Nov 2015 10:06:21 +0100
Message-ID: <52cf4e311854fc498718a49dc50bd3d6@mail.gmail.com>
To: Brian Trammell <ietf@trammell.ch>
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/UxwcGSI5aa7A5a6v7kzzGIYnDHI>
Cc: Michael Tuexen <tuexen@fh-muenster.de>, Mirja Kühlewind <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: Fri, 13 Nov 2015 09:06:25 -0000
HI, Thanks a lot. Please find inline below. Nothing outstanding as far as I can tell :-) BR, Karen > -----Original Message----- > From: Brian Trammell [mailto:ietf@trammell.ch] > Sent: 12. november 2015 15:47 > To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> > Cc: taps@ietf.org; Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>; > Michael Tuexen <tuexen@fh-muenster.de> > Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-07.txt > > 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)... > [Karen Elisabeth Egede Nielsen] This would be great, _I_ think. > > 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... > [Karen Elisabeth Egede Nielsen] Yes. Unfortunately we have had outtages (killing services in regions - not a small issue..) recently as some applications had put trust into the PUSH bit. That's why I would not like the document to point to this as valid service provided by TCP to ULP. Except for what I wrote above. > > 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. > [Karen Elisabeth Egede Nielsen] super. > > 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. [Karen Elisabeth Egede Nielsen] ok thanks. > > > 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"? [Karen Elisabeth Egede Nielsen] It is not turned on. One of the Ericsson SCTP SW bases (there are two) implements the feature following the "traditional" approach of RFC3168/RFC4960. This is the SCTP SW base with the largest deployment base/footprint. But we don't know of anywhere were it is active. Likely in many nodes the feature has not even made it to the O&M api. I.e., the applications has chosen not to expose the feature to the operators even if it _is_ exposed at SCTP API. Hopefully this will change. [A different issue of course is that the ECN in itself may change] > > Thanks again, cheers, > > Brian
- [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