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