Re: [tcpm] draft-ietf-tcpm-rtorestart-07
Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> Mon, 01 June 2015 09:15 UTC
Return-Path: <karen.nielsen@tieto.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906201A90D2 for <tcpm@ietfa.amsl.com>; Mon, 1 Jun 2015 02:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.52
X-Spam-Level:
X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 DNLC_jjhIIpp for <tcpm@ietfa.amsl.com>; Mon, 1 Jun 2015 02:15:25 -0700 (PDT)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (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 023A81A90CF for <tcpm@ietf.org>; Mon, 1 Jun 2015 02:15:24 -0700 (PDT)
Received: by ieclw1 with SMTP id lw1so8928861iec.3 for <tcpm@ietf.org>; Mon, 01 Jun 2015 02:15:24 -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:cc:content-type:content-transfer-encoding; bh=9DB3yMtgMWfah3MsChqCQxQZDPOvM9d/d0u0luz01/k=; b=dwandKqoaGYDis9ZR4AZmqm35pYRpSThVZmIGqWiC/cYCpuefQJBPeMqqjyWYRM953 JbN7td0JcVfaG8UwT0g/DllHsSCNp4AXiJfy1oBhm9YMbKugAg9o8o6bx3t1ZXWDoMQs csOBDa82kgxecqcvtAe5tz9AVEM6/c8IFChqc=
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=9DB3yMtgMWfah3MsChqCQxQZDPOvM9d/d0u0luz01/k=; b=SjL32mcjhJi/ePpAR/HhE8y5U34Bcrqy/biiVMyykqx+CHzJBaYBvBXDH5uALnnOBL x1q7+GYoIM+UhzNkcrrvGUlFmVqg3AKF4ZKYdNkVGrk5XhtVfx2lSaIaosNG0yeUCFyQ Hztsirl+i1YQcP62D29tL/Jtz2GubuKjpliVMn6wNufpAQCgNAeqq1l63Egxjm159Ayz vm+zBTsgFKP4fc02CKvPvlmftdDWCpETcVG0eYN4Vu3AFYeRuySGWWYek+HB6gjtJP0i xmwKX+cz6dQpA+za4YOsXLIYXAvnkVS11uKJFr7Af+YvQZVBe3h3sZkKkmLAcuozEhIY bdmg==
X-Gm-Message-State: ALoCoQkW3v2JOuaLKc0hRXxjSkZ/+qj5eZw6bOk+e8W5QXG0aEwKFnhY5EA2FMGvnnmVXzM/yzPlFPRpPea4NqyutMT8SksxfaOJ9Sg/PA5HL6cCxhp7S1Q=
X-Received: by 10.50.79.196 with SMTP id l4mr12225183igx.48.1433150123922; Mon, 01 Jun 2015 02:15:23 -0700 (PDT)
From: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
References: <882B8BE8-D02D-4E46-90B0-FE9CB2E88BF9@telecom-bretagne.eu> <655C07320163294895BBADA28372AF5D483AF02D@FR712WXCHMBA15.zeu.alcatel-lucent.com>
In-Reply-To: <655C07320163294895BBADA28372AF5D483AF02D@FR712WXCHMBA15.zeu.alcatel-lucent.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL7VJwomcXY3mf3wZzSms+lgcAi+gFhiVv/mzbD6AA=
Date: Mon, 01 Jun 2015 11:15:23 +0200
Message-ID: <cc09d18c32d3d31d456c3c933e6a1f41@mail.gmail.com>
To: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>, per.hurtig@kau.se, anna.brunstrom@kau.se, apetlund@simula.no, michawe@ifi.uio.no
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-DomainID: tieto.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpm/21Rr7HfIh9Uq2D3LGbrXPmPUC08>
Cc: tcpm@ietf.org, tsvwg <tsvwg@ietf.org>
Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-07
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2015 09:15:27 -0000
Hi, Please accept the following - overdue - comments: General comments on SCTP applicability of the specification: ------------------------------------------------------------------------------ The document is inconsistent in its description of the SCTP aspects of the proposed algorithm. Section 1 and general: The document does say, in the end of Section 1, that the focus of the document is on TCP "with validity also for SCTP". However if so, then I think this paragraph should have been the first paragraph in section 1 rather than the last. I think that it is confusing that the Abstract (and the title) speaks about TCP and SCTP, but the introduction text speaks about TCP only. I think that it would be better for the text of section 1 to be augmented to speak about TCP _&_ SCTP. With the final paragraph then telling that in the remaining part of the documents, the focus would be on TCP (if this is the intend). (We have the SCTP API section in the end. Not sure how this fits with the notion of only providing details for TCP) Alternatively, if the present "TCP only" introduction is kept, I think that it would be relevant to emphasize in the final paragraph of section 1, that what has been described above in section 1, is common to TCP and SCTP (except possibly for the exact word "dupacks" - but I think one could get around that). Still even with the above clarifications, it is unclear to me what the status of this document is vis-a-vis SCTP. The detailed SCTP socket API description is there, but some of the crucial implementation aspects - e.g. section 5.3., is TCP only. But perhaps such inconsistency is ok for experimental ? Section 3: The contents of this section is common to TCP and SCTP except for the term segment which is TCP particular and which would be a packet in SCTP. Section 4: Here there is a reference to "similar update to RFC4960", but at the same time the word segment is used and further the section 5.3. discussion is TCP only. Detailed on Section 7: --------------------------- As far as I can tell this is exactly what we would like to have for SCTP. Thanks, BR, Karen PS: It turns out that some SCTP implementations may send two packets right after RTO thus applying the "allowed to breach CWND with PMTU-1" logic also immediately following RTO-timeout. This has impact of how delay_ack impacts the loss recovery time (refer to discussion in section 5.1). I believe that the intent is to have this eventually be clarified to be incompliant behavior (also of SCTP), but SCTP then of course has the option to ask for immediate SACK in this situation, which then again changes the impact of delay_ack. There also exist SCTP implementations which rigorously follows TCP semantics and which thus do not breach the CWND right after RTO (only after receipt of first ACK after RTO) and which today does not deploy the Immediate SACK extension. For such the delay_ack impact is the RTO loss recovery as for TCP. The latter behavior is the right RFC4960 implementation (at least I would argue that), but possibly not the "right" future SCTP implementation. >-----Original Message----- >From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael >(Michael) >Sent: Monday, May 18, 2015 11:22 AM >To: per.hurtig@kau.se; anna.brunstrom@kau.se; apetlund@simula.no; >michawe@ifi.uio.no >Cc: tcpm@ietf.org >Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-07 > >Authors, > >These (mostly editorial) comments are the only WGLC comments for draft- >ietf-tcpm-rtorestart-07 that I am aware of. Could you please discuss how to >address them? > >Thanks > >Michael > > > >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Nicolas Kuhn >> Sent: Thursday, May 07, 2015 5:00 PM >> To: tcpm@ietf.org >> Subject: [tcpm] draft-ietf-tcpm-rtorestart-07 >> >> Hi all, >> >> I had a look at this draft-ietf-tcpm-rtorestart-07 draft. >> I have some minor comments on the document. >> >> >########################################################### >## >> >> - "The RTO Restart (RTOR) mechanism described in this document makes >> the >> RTO slightly more aggressive when the number of outstanding segments >> is too small for fast retransmit to work, in an attempt to enable >> faster loss recovery for all segments while being robust to >> reordering." >> >> The RTO is not aggressive ; but the retransmission scheme ruled by RTO >> expirations is. >> I would recommend to rephrase that. >> >> >########################################################### >## >> >> - “ The RTO Restart (RTOR) mechanism described in this document makes >> the >> RTO slightly […] highly varying RTTs, e.g. mobile networks." >> >> This whole paragraph comes to early in the document, as the reader has >> no clear idea about what RTOR is actually doing. I propose to add that >> in a dedicated sub- section in Section 5. >> >> >########################################################### >## >> >> - “ 3 RTO Restart Overview” -> should it not be “3- RTO Overview and >> rationale of RTOR “ or something equivalent ? >> It is confusing, as you do not actually present RTOR. >> >> Also, in this section 3: >> The first paragraph finishes with “Hence, in most situations, the >> time before a retransmission is triggered is equal to "RTO + RTT”.” >> But the example to illustrate it comes after - I think things should >> moved around to: >> 1- introduce the classic RTO >> 2- explain the rationale of classic RTO >> 3- example to show that RTO+RTT is common >> 4- more parameters could affect that (2 outstanding segments; other >> factors) >> 5- conclusion on “hence, RTO+RTT is common for application limited >> traffic" >> >> I would propose to introduce a ToC for this section 3: >> >> 3- RTO Overview and rationale of RTOR >> 3-1. Experienced RTO is RTO+RTT >> 3-2. RTO safety margin >> 3-3. Rationale of RTOR: when fast retransmit is not possible >> >> >########################################################### >## >> >> Section 4 : should focus on the description of the algorithm only. >> >> I would keep >> “ >> This approach makes the RTO more >> aggressive than the standardized approach in [RFC6298] but still >> conforms to the requirement in [RFC6298] that segments must not be >> retransmitted earlier than RTO seconds after their original >> transmission. >> " >> >> for the discussion section (at this stage of the reading, the reader >> still does not know exactly what RTOR is actually doing). >> >> >########################################################### >## >> >> Section 4: "it will prevent RTOR >> from being more aggressive and potentially causing RTOs instead of >> fast retransmits.” >> >> More aggressive than what ? Has the "four" being experimentally >> obtained ? >> I think more discussion is required on this parameter. >> >> Regards, >> >> Nicolas >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] draft-ietf-tcpm-rtorestart-07 Nicolas Kuhn
- Re: [tcpm] draft-ietf-tcpm-rtorestart-07 Scharf, Michael (Michael)
- Re: [tcpm] draft-ietf-tcpm-rtorestart-07 Anna Brunstrom
- Re: [tcpm] draft-ietf-tcpm-rtorestart-07 Karen Elisabeth Egede Nielsen
- Re: [tcpm] draft-ietf-tcpm-rtorestart-07 Per Hurtig
- Re: [tcpm] [tsvwg] draft-ietf-tcpm-rtorestart-07 Karen Elisabeth Egede Nielsen