Subject: [multipathtcp] Comments on draft-ford-mptcp-multiaddressed-03

From: <[email-masked]>
Date: Mon, 29 Mar 2010 22:55:21 +0100

Comments on draft-ford-mptcp-multiaddressed-03

There is rather a lot of inconsistent terminology [flow, session...]

Don't know whether it's worth agreeing terms for initiator, sender... - using one to refer to the connection and one to subflows [it gets quite confusing when new subflows can be started from either end...]

Abstract

Last 1.5 lines => Splits a TCP connection into multiple sub-flows that travel over paths which are hoped, but not guaranteed, to be disjoint

Intro

This document presents the protocol changes required by multipath TCP => changes required to TCP

Architecture bullet - the doc does more than this - it gives the high level design which the protocol doc implements

1.3 think it would be useful here to add a second pic, similar to the existing one but with a summary of the msgs [Join etc]. it would help people like me with a bad memory, or who find "Add" a very confusing name!

3 

"address list" - do you mean this? "adding an address" - "joining" as well? It seems logical to share this kind of info between other connections between the same pair of hosts. Perhaps, this is something for the extended api?

"5-tuple" "These API issues..." not clear what "These" refers to.

S4

I think it would be better, in the protocol section, to describe the protocol [the MUST/SHOULD/MAY stuff] and put the explanations about the design of the protocol into an appendix. 

4.1

The stuff about "locally unique tokens" is quite difficult to follow [locally unique at which end? - Fig 5 helps]. But I guess there's no point changing this whilst he consensus call on security is happening. (won't bother with other comments on related text]

The doc includes 5 different names for the multipath capable option!! Personally would prefer a 6th(!) MP_CAPABLE.

Fig 3 title - think you could add "(only valid on SYN pkts)"

4.3

It would be nice to explain how Path mgt helps with NATs [or add a ref to where it's explained]

4.3.1

"NB by having a IPver field..." re-phrase. The point is that you have reserved bits. 

"eg one bit for.." => one codepoint

4.3.1 - last line

"address index" = ?

4.4.1 absolute vs relative sequence numbering could do with some explanation?

4.5 - stuff about closing connection was very hard to follow. 

S6

"implementation errors" - I don't think it's reasonable to expect to cope with implementation errors in middleboxes in general. There may be the odd rare exception [eg causes a crash]