Re: [tcpm] [tsvwg] draft-ietf-tcpm-rtorestart-07
Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> Thu, 18 June 2015 07:29 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 D0DA21A07BC for <tcpm@ietfa.amsl.com>; Thu, 18 Jun 2015 00:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.779
X-Spam-Level:
X-Spam-Status: No, score=-0.779 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, J_CHICKENPOX_34=0.6, 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 RuJgoXLdFw3l for <tcpm@ietfa.amsl.com>; Thu, 18 Jun 2015 00:29:02 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 DA1C61A06E9 for <tcpm@ietf.org>; Thu, 18 Jun 2015 00:29:01 -0700 (PDT)
Received: by igbqq3 with SMTP id qq3so8706810igb.0 for <tcpm@ietf.org>; Thu, 18 Jun 2015 00:29:01 -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=i7CQDQ6UVGldvY7wWxspjRNlr5sMMJkDafNGk/AddRU=; b=K/DVSW62ffGiOQyxtp1RWxBfXDE81yc3fgOKatmkcdGEbnaZ8hG2IfrDqYafVEkfrB aWhWaRwnjxZ9FO6XRNruYA5abnP+hLp187ysKYvywnnZD+l8nIbGfJw8+47GFjzn9yBN y1WmGO+BIGhsVGZJugDps1r9jF6LajIl7ZcAU=
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=i7CQDQ6UVGldvY7wWxspjRNlr5sMMJkDafNGk/AddRU=; b=bl5vxQJQC0Fom6IyS0Ap2ZhQZSoLzvFMpwkyjkkLTO168qA+yRvVS4Gp27G9mnZxME SnlnwDTC1N1JIiPhN6eB3tF9i6xf9Hx31M7WvaXZk9Ip4Wpp3mi6VLaJrVyHmQp77heW pExRal4tC4aE/H9ku6UlVY26dOHJqpm+1sONiXUgsOtvUWVsN36a9dYPwIRttR4Gog9i MbmvW9VdtJ1RX3Br7AonCtVDbQ4FbQV/Ozx/Bc7W7jzJGDKjIVNlu7fYeGIQ4iNb1S+M aYCx/uVZm8Tkoliw5nQX/1PpMsm/L3ngISg/bdn3v3zgv34xEI4rQekDsrrvcXdUry2w mzuQ==
X-Gm-Message-State: ALoCoQm3e1Pb/LvgDWuOiZKASzHzrvyCXiXW0wzazBe5pRXKRvVIkNKa6ZQQ+tPrufr4gf0Wi6SwKM3ZYGlpqa6oSH8Jn7LLYT6lOIu1tzKoqw5tAGGpqNc=
X-Received: by 10.107.46.226 with SMTP id u95mr12360326iou.68.1434612541375; Thu, 18 Jun 2015 00:29:01 -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> <cc09d18c32d3d31d456c3c933e6a1f41@mail.gmail.com> <CDDC3A04-3F6B-471D-90C0-1A009D8EC80A@kau.se>
In-Reply-To: <CDDC3A04-3F6B-471D-90C0-1A009D8EC80A@kau.se>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL7VJwomcXY3mf3wZzSms+lgcAi+gFhiVv/AYKNx7sB3lM3Sps2cpMg
Date: Thu, 18 Jun 2015 09:29:00 +0200
Message-ID: <64074bfb5bd45b8b1052f032f07f202e@mail.gmail.com>
To: Per Hurtig <per.hurtig@kau.se>
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/n3n1ZKVveqWCgJ67plbdaW5JgJg>
Cc: tcpm@ietf.org, tsvwg <tsvwg@ietf.org>, Michael Welzl <michawe@ifi.uio.no>, apetlund@simula.no
Subject: Re: [tcpm] [tsvwg] 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: Thu, 18 Jun 2015 07:29:05 -0000
Hi, Thanks for taking my comments into consideration ! I think the described approach with a common TCP&SCTP introduction sounds good and given that I agree that it is viable to leave the SCTP details out. BR, Karen >-----Original Message----- >From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Per Hurtig >Sent: Thursday, June 18, 2015 9:00 AM >To: Karen Elisabeth Egede Nielsen >Cc: tcpm@ietf.org; Scharf, Michael (Michael); tsvwg; Michael Welzl; >apetlund@simula.no >Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rtorestart-07 > >Hi Karen, > >We agree that SCTP seems forgotten in the document. We have now re- >writen the introduction to address both TCP and SCTP. We also end the >introduction saying that the rest of the document will focus on TCP, with >an >exception for Section 7 (the SCTP API). If we were to describe RTOR for TCP >and SCTP without violating any terminology (for any of the protocols) we >believe that the document would be unnecessarily long and very hard to >read. > > >Cheers, >Per > >> On 01 Jun 2015, at 11:15, Karen Elisabeth Egede Nielsen ><karen.nielsen@tieto.com> wrote: >> >> 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