Subject: [multipathtcp] some comments/questions on draft*multiaddressed-03

From: [email-masked]
Date: Tue, 12 Apr 2011 15:26:56 -0400

- Section 3.1, the description in paragraph 2 of pg 12 is ambiguous:
  > Furthermore, in order to ensure reliable delivery of the ACK
  > containing the MP_CAPABLE option, a server MUST respond with an ACK
  > segment on receipt of this, which may contain data, or will be a pure
                          ^^^^ which (ACK?)? There are multiple ACKs
  in this paragraph, and some clarity would be helpful. Also, is this
  something that needs a note in Section 4?

- I realize that the 4 vs 8 octet DSN/Data ACK was done in an effort to
  conserve option space, but is it worth the complexity? Would it be
  simpler to just keep both DSN/DACK at 8 octets?

- Editorial: first line of Section 3.3.3 needs a "to".
  > In regular TCP a FIN announces (to) the receiver that the sender has no
  >  more data to send.

- Section 3.3.4 pg 26 the first paragraph does not parse:
  > ... a segment is
  > placed in the connection level in-order or out-of-order queue if it
  > is in-window at both connection and subflow level.  The stack still
  > has to remember, for each subflow, which segments were received
  > succesfully so that it can ACK them at subflow level appropriately.
  > Typically, this will be implemented by keeping per subflow out-of-
  > order queues (containing only message headers, not the payloads) and
  > remembering the value of the cumulative ACK.

  I think what's intended is that a segment would be placed in the in-order
  queue if it is in-widnow at both connection and subflow level, and the
  remainder of the paragraph applies for the out-of-order queue?

- Cross-referencing the api draft, per the mptcp-api draft, MPTCP will
  only be enabled if the application binds to INADDR_ANY. Per Section 3.7.1
  of the mptcp-multiaddressed draft we're not mandating that the same
  port number be used. If different port numbers are used, then what
  would be returned as the port number by, say, rpcbind/portmapper? 
  It might be simpler to make the same port number requirement a MUST.

- Section 4 (pg 40) - I recognize that the note about duplicate ACKs is
  related to the discussion about fitting in options from Section 3.
  But what if the duplicate ACK with mptcp signalling is actually
  triggered by congestion? Do we need some more specific heuristics for
  identifying dup acks due to lost packets?

--Sowmini

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 14 Apr 2011 17:56:32 -0700

Hi sowamini,

2011/4/12  <[email-masked]>:
>  > Furthermore, in order to ensure reliable delivery of the ACK
>  > containing the MP_CAPABLE option, a server MUST respond with an ACK
>  > segment on receipt of this, which may contain data, or will be a pure

Hmm.. but, option space might be scarce resource..
One possible way I can think is to make 4 octets DSN/DataACK as an
optional feature
so that some implementations can choose to not support this
feature.(just like DCCP's short seqnum)
In order to do this, we will need to use one reserved bit in
MP_CAPABLE option to
indicate that it supports 4 octets DSN.

>  > In regular TCP a FIN announces (to) the receiver that the sender has no
>  >  more data to send.
>
>  > ... a segment is
>  > placed in the connection level in-order or out-of-order queue if it
>  > is in-window at both connection and subflow level.  The stack still
>  > has to remember, for each subflow, which segments were received
>  > succesfully so that it can ACK them at subflow level appropriately.
>  > Typically, this will be implemented by keeping per subflow out-of-
>  > order queues (containing only message headers, not the payloads) and
>  > remembering the value of the cumulative ACK.
>

In legacy applications, MPTCP will only be enabled if the application
binds to INADDR_ANY.
But, in case of MPTCP-aware applications, I think apps might want more
flexibility and
port numbers will be returned by mptcp-specific APIs.

>  identifying dup acks due to lost packets?

I guess that the authors also meant that receivers should not include MPTCP
options in dupACKs when they have seen gaps in seqnums.

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: "Ford, Alan" <[email-masked]>
Date: Fri, 15 Apr 2011 09:15:46 +0100

Hi Sowmini,

Sorry for the delay in replying; clarifications inline...

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: 12 April 2011 20:27
> To: [email-masked]
> Subject: [multipathtcp] some comments/questions on
draft*multiaddressed-03
>   something that needs a note in Section 4?

This refers to receipt of the first pure ACK packet in the connection
(i.e. the third packet in the SYN, SYN/ACK, ACK exchange). This contains
the MP_CAPABLE option with both keys, and a receiver must ACK this in
order to allow stateless operation at the sender.

>   simpler to just keep both DSN/DACK at 8 octets?

We'd rather not mandate the use of this extra option space if we can
avoid it.

However, implementation feedback is interesting: is it really
excessively complicated? The values must be stored in the 64-bit version
internally, so it's only the mapping to/from the wire format where this
matters. (Logic to ensure wrapping is handled correctly is fairly
standard stuff, I would have thought.)

>   remainder of the paragraph applies for the out-of-order queue?

Yes. We will look at improving that text, thanks.

>   It might be simpler to make the same port number requirement a MUST.

In almost all circumstances I believe that will be the case. And indeed,
for a listener, if you bind to INADDR_ANY today on some systems (e.g.
Windows) you will have the same port reserved on all addresses (even
those that appear later in a connection).

The main reason it is a SHOULD is that there may be circumstances,
either due to load balancing, or somehow a port is already in use on one
address, where this is not possible.

We could strengthen the text, thanks.

>   identifying dup acks due to lost packets?

If there is real congestion, the expectation is that the dup ACKs will
not contain MPTCP options since there is no new information to signal at
the connection-level.

Many thanks for your feedback!

Regards,
Alan

---

From: [email-masked]
Date: Fri, 15 Apr 2011 15:59:20 -0400

> standard stuff, I would have thought.)

yes, but it's just additional logic to check the flags and then map
to/from the option both for parsing the options or even for debugging 
the snoop traces. It's not actually a big deal, but I was wondering how
much of a tradeoff the simpler "always 64" was.

Regarding rpcbind/portmapper return values for the port number for a service..

> We could strengthen the text, thanks.

Ok. I guess this is somewhat related to the other questions around
getsockname/getpeername when the first subflow itself is lost. At least
for the service's port number case, things would be more
straightforward if the port number is common to all subflows.

> not contain MPTCP options since there is no new information to signal at

Yes, I think Yoshifumi also mentioned the same thing.

--Sowmini