Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Per Hurtig <per.hurtig@kau.se>
In-Reply-To: <38DA60FD-7629-4FCB-BD19-830FC7F5232C@netapp.com>
Date: Thu, 15 May 2014 12:00:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CEBB7AD-88F3-45CA-A1C6-D5306EEE02B3@kau.se>
References: <38DA60FD-7629-4FCB-BD19-830FC7F5232C@netapp.com>
To: "Zimmermann, Alexander" <Alexander.Zimmermann@netapp.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/KKN2FUad0z1IMS5XAguTRJsoNQQ
Cc: "draft-ietf-tcpm-rtorestart@tools.ietf.org"
 <draft-ietf-tcpm-rtorestart@tools.ietf.org>,
 "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Subject: Re: [tcpm] Review of draft-ietf-tcpm-rtorestart-02.txt
Precedence: list

Hi Alexander

thanks for the review, please see my comments inline=85


On 13 May 2014, at 11:57, Zimmermann, Alexander =
<Alexander.Zimmermann@netapp.com> wrote:

> Hi folks,
>=20
> first of all thank you for writing this draft. The draft is clearly =
written: the
> problem is well described, the doc is self-contained (it=92s not =
necessary to read
> dozens of other RFCs to understand the problem), and the authors state =
why the
> doc is experimental and what further experiments are needed for being =
a STD.
> However, on the technical side I see some open points. In detail:
>=20
> * Sec 1, 4. para: =84a considerable number of flows have such =
properties=93
>  Can you backup this with some numbers? This is exactly the point I =
raised at the
>  (last?) IETF. I would like to see some data on how severe the problem =
is we would
>  like to fix.
>=20

For short flows (e.g. web) there are a number of references in the =
draft. These are
the primary target for the mechanism. We=92ll elaborate some more on the =
importance
for other types of traffic.=20


> * Sec 1.1: please change this subsection to a section (1.1 =3D> 2) and =
also
>  introduce your new state variable rrthresh here
>=20

I don=92t get why the section should be renumbered. The =93terminology=94 =
is often the
last subsection of the introduction of most drafts and RFCs. =
Furthermore, it seems=20
slightly overkill to introduce the variable there. RFCs that manages =
many more=20
variables, e.g. RFC6298 does not explicitly introduce any variable in =
this section.

> * Sec 1, 5. para: =84Spurious timeouts typically degrade the =
performance of flows
>  with multiple bursts of data, as a burst following a spurious timeout =
might
>  not fit within the reduced congestion window (cwnd)=93
>=20
>  This is (only) true with respect to your algo, not in general. The =
general
>  problem of a spurious timeout is the cwnd reduction, the go-back-N
>  retransmissions, =85 See RFC 3522. After reading section 4.2 of your =
draft I
>  understand what you want to see here. Please rephrase the section and =
maybe
>  add the spurious RTO RFC as reference.
>=20
What is meant is the actual cwnd reduction. We should clarify this.


> * Sec 3: Suppose FlightSize is 2 and you have exactly one segment to =
send,
>  your algo doesn=92t trigger since step 2.b isn=92t true. Bug? I would =
say yes.
>=20
Good catch! The question is if it=92s worth fixing since the algorithm =
will
become more complex and the situation you mention is really a corner =
case that
requires either (i) the cwnd to be exactly 3 segments large; or (ii) =
having a
packet written to the socket just between previous data transmission and =
the
arrival of the acknowledgment.

Furthermore, this mechanism is only an optimization to the standard =
timer. So
if it doesn=92t work in this particular scenario it won=92t break =
anything. It will
just not be triggered.=20

> * Sec 3: Why the condition 2.b is different from the early =
retransmission
>  condition 2.b or 3.b? Is there any specific reason why we exclude the
>  advertised receive window part from the condition?
>=20
Because the advertised window can be small in situations where it=92s =
not
preferable to use RTO restart. For instance, in the middle of a transfer =
where
it=92s better to wait for fast/early retransmit to kick in.

> * Sec 3: IMO the algo/doc is too much Linux driven. I would like to =
see a
>  segment-based *and* byte-based version of the algo, like RFC 5827.
>=20
Yes, this comment was given by several people at the last IETF. We will =
update
the draft to address this.

> * General: IMO I would be a little bit easier to read the doc if you =
give the
>  algo a proper name. By reading =84RTO restart=93 I had sometimes =
trouble to
>  know if mean your algo or the =84action=93 of restarting the RTO.
>=20
Agreed, this will be fixed.



Thank you,
Per Hurtig

>=20
> Alex
>=20
>=20
>=20