Subject: [multipathtcp] Reviewing draft-ietf-mptcp-multiaddressed-03

From: Stein Gjessing <[email-masked]>
Date: Mon, 16 May 2011 09:16:14 +0200

Hi,

All in all I think this is a quite clear and precise specification. I have not found any real problems with any of the technical contents. However, I do not have particularly good knowledge in the field of security, so  I can not tell if this part of the draft is correct.

I have divided this feedback in two: First the more important comments, then a list of typos.

For new readers, some parts of section 2 is hard to understand. The use of TCP options is imprecise (see below), and for me that was confusing. 

HMAC (and MAC) is used from page 8 onwards. I think the full name should be spelled out the first time these abbreviations are used.  A reference should be given before page 16.

The use of the optional TCP header field is introduced in section 3.  It is hard from this text to understand  that there is ONE TCP option for all MPTCP segments.  and that eg. MP_CAPABLE and MP_JOIN are sub-options or subtypes.  Not until section 6, on page 42 you state: "MPTCP uses a single new TCP option "Kind", and all message types are defined by "subtype" values (see Section 8)". 
Throughout the document you use the phrasing XXX option, really meaning a subtype of the MPTCP option. You should clarify this initially.  DSS (Data Sequence Signal) is defined in line 4 on page 19, but is used several times before in the document (eg. section 2).

I have a problem with the use of the concept of a mapping. On page 20:
" The Data Sequence Mapping specifies a full mapping from subflow sequence space to data sequence space, for the specified length (number of bytes of data) starting at the specified Subflow and Data Sequence Numbers."
Why do you call this a "full" mapping?   How is the maping defined.  As it turns out, it is very simple and intuitively obvious, but I believe you never really say.

Also on page 20:  "A mapping is unique, in that the subflow sequence number is bound to the data sequence number after the mapping has been processed. It is not possible to change this mapping afterwards;"  What is a unique mapping? MUST an implementation check that this mapping has not changed?

=========================

Misprints etc.:

Be consistent with "a" and "an" before capital letters, eg. on page 11 "a MP_CAPABLE" should probably be "an".
Bottom of page 12: ". . .  so may wish to choose an algorithm with minimal computational complexity, depending on load."  Insert "it" as the second word, and "the" as the second last word here.
Page 13, section below Figure 4: Twice I would like to add an "a" to get: "as a regular, single-path TCP".
Page 18, end of 3. paragraph, suggest to rewrite to: "and they have agreed to which connection this subflow will become a part of."
The abbreviation "DSM" is only used on page 19. I suggest you remove it.
Page 22: What does  MSL stand for ?
Page 32, 3. line from top: Add a "the" before "same port".
Page 32, 3. line below Figure 12: The word "blanket" is probably not the right word here.
Page 39, paragraph 3: "than an implementer" -> "that and implementer"
Page 44, second bullet: "of if the receiver" -> "or if the receiver"
Page 50, MPTCP.Checksum: "the C bit the" -> "the C bit in the"

Cheers,

Stein

On May 13, 2011, at 5:19 PM, <[email-masked]> <[email-masked]> wrote:

> Just a gentle ping to see if you’ve had time – or can estimate when you might be able to
> Thanks,
> Best wishes
> phil
>  
> From: Eardley,PL,Philip,DES8 R 
> Sent: 08 April 2011 19:48
> To: 'Stein Gjessing'; 'Andrew McGregor'
> Cc: Yoshifumi Nishida; [email-masked]'
> Subject: Reviewing Multipath TCP protocol document
>  
> Stein, Andrew,
>  
> Thank-you very much for agreeing to review http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed
>  
> If possible, please could you review within a month, ie by early /mid May. This would give us a chance of handling the comments and getting through WG last call well before the next IETF (we’re trying to complete before Quebec)
>  
> Thanks,
> Best wishes,
> Phil & Yoshifumi.
>  
>