Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <11187BAE-5E91-410D-9BDA-33F8A60D2458@kuehlewind.net>
Date: Tue, 16 Apr 2019 16:08:20 +0200
Cc: multipathtcp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E9C7AF5D-BFFB-4D09-9F83-5FFC1FB03E84@kuehlewind.net>
References: <11187BAE-5E91-410D-9BDA-33F8A60D2458@kuehlewind.net>
To: draft-ietf-mptcp-rfc6824bis.all@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/VK9o5rFrl9Sgt07WfpC3MOdJsPw>
Subject: [multipathtcp] AD review detailed comments [was: Re: AD review is
 coming]
Precedence: list

Hi again,

Here are the more detailed comment of my review as promised. Most of =
these comments are editorial, however, there are a few comments on use =
of normative language as well as clarifications and also one point about =
specifying the registration policy for the new registry (comment 13 =
below) which really must be address in the next version.

Thanks!
Mirja

----------------------------

1) Sec 3.1: =E2=80=9CIf a responder does not support (or does not want =
to support)
   any of the initiator's proposals, it can respond without an
   MP_CAPABLE option, thus forcing a fallback to regular TCP.=E2=80=9D
   I wonder if this should be normative: =E2=80=9C=E2=80=A6it MUST =
respond without an MP_CAPABLE option=E2=80=A6=E2=80=9D..?

2) Sec 3.3.1: =E2=80=9C=E2=80=A6 and any later data for that sequence =
space should be ignored.=E2=80=9D
   Maybe SHOULD?

3) Sec 3.3.2: =E2=80=9CIf the DSN received is
   32 bits, it is valid for the implementation to choose whether to send
   a 32-bit or 64-bit Data ACK.=E2=80=9D
  Maybe =E2=80=9C=E2=80=A6 the implementation MAY choose whether to =
send=E2=80=A6=E2=80=9D

4) Sec 3.3.3: I guess if there is only one subflow it is probably safe =
to send the TCP FIN together with a DATA_FIN (as an optimisation), or =
would there be a reason to not do that? Should that be mentioned in the =
text?

5) Sec 3.3.8: Is the reference to ECN really needed? I feel that this =
idea is hard to understand without further context.

6) Sec 3.6: Maybe I missed it that but it seems that the error codes =
=E2=80=9CUnacceptable performance=E2=80=9D is not further used in the =
document while I would think further guidance might be needed.=20

7) Sec 3.7: Minor editorial point I noticed here but there might be =
other cases:
=E2=80=9CIf lost options on data packets occur on any other subflow =
apart from the initial subflow=E2=80=A6=E2=80=9D
Not sure if =E2=80=9Cinitial=E2=80=9D is correct here because if you =
move you may not have the initial subflow anymore=E2=80=A6 I guess it =
would be something like =E2=80=9Call expect one=E2=80=9D here=E2=80=A6

8) Sec 3.9.2: I wondering about this text, given this is a bis doc and =
we have an deployment experience report:
=E2=80=9CWe expect that experience gathered from deployments will =
provide further guidance on this, and will be affected by particular =
application characteristics (which are likely to change over time).  =
[=E2=80=A6] Results from experimental deployments are needed in order to =
verify the correctness of this proposal.=E2=80=9D
Maybe just rephrase it say something like =E2=80=9CWe got some =
experience but more is needed/there is no generics solution.=E2=80=9D.. =
or just remove=E2=80=A6

9) Maybe section 3.9.2 should also say again that receiving a second =
ADD_ADDRESS (with the same ID) is a request from the other end to open a =
subflow immediately?

10) Sec 3.9.3: Should learned information really be cached =
=E2=80=9Cforever=E2=80=9D, or should the text maybe says also something =
about retrying after some time=E2=80=A6?

11) Sec 8.1: =E2=80=9CThis document defines one additional subtype
   (ADD_ADDR) and updates the references to this document for all sub-
   types except ADD_ADDR, which is deprecated.=E2=80=9D
   What?

12) Also sec 8.1: RFC6824 also has this half-sentence:
=E2=80=9Cfuture assignments are to be defined by Standards Action as =
defined by [25].=E2=80=9D
which got lost in this document. However, given this document obsoletes =
RFC6824 it should probably also mention the assignment policy for this =
registry.

13) Sec 8.3. doesn=E2=80=99t specify an assignment policy.

14) Given RFC6824 will be obsoleted by this spec, it does not to be =
listed in the reference section.

Nits:
- Sec 3.3.6: s/if it so desired for reliability reasons./if it is =
desired for reliability reasons./
- Sec 3.3.&: s/Multiple retransmissions are triggers that/Multiple =
retransmissions are triggered that/ or actually
                         s/Multiple retransmissions are triggers that/If =
multiple retransmissions are triggered that/
- Sec 3.7: s/Middlebox interferance/Middlebox interference/
- Sec 3.9.2: s/If the the same ports are used on all subflows/If the =
same ports are used on all subflows/



> On 12. Apr 2019, at 18:40, Mirja Kuehlewind <ietf@kuehlewind.net> =
wrote:
>=20
> Hi authors, hi shepherd/Phil,
>=20
> Just wanted to quickly let you know that I=E2=80=99ve started the IETF =
last call just now in order to hopefully get this document on the =
telechat in 3 weeks.=20
>=20
> I=E2=80=99ve not finished my AD review completely but I am nearly done =
and convinced that this doc is ready to start IETF last call. So far I =
have only some editorial or smallish comments and nits which I will send =
in detail beginning of next week and can be address during or after IETF =
last call.
>=20
> Only one request for now (mostly with an eye on the IESG evaluation): =
The draft says that changes are made which are not backward compatible =
(see sec 3.1). That=E2=80=99s fine, however, it would be good to also =
explain a little bit in the draft as well as in the shepherd write up =
(!) why this is okay. My understanding is that in case of a v0 server =
the connection will =E2=80=9Cjust" fall-back to non-MPTCP capable and =
that this is acceptable in current deployment situation. Please confirm =
and at least update the write-up accordingly as soon as possible!
>=20
> Thanks!
> Mirja
>=20
>=20
>=20