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