Subject: [multipathtcp] Reducing option number usage

From: "Ford, Alan" <[email-masked]>
Date: Tue, 11 Jan 2011 16:11:33 -0000

Hi all,

Lars commented a few weeks ago about whether we could reduce MPTCP's
requirement on IANA's limited set of TCP option numbers by having a
single MPTCP type and inferring the sub-type by the length of the
option. This itself would likely be difficult to implement and not be
particularly extensible; however, we could use a limited number of
options, with a sub-type field.

I looked again at the TCP options we have in MPTCP, and came to the
following conclusions:

* MP_CAPABLE and MP_JOIN have spare bits; we could use 4 as a sub-type
field.
* ADD_ADDR, REM_ADDR, MP_PRIO and MP_FAIL are signals that can be sent
on duplicate ACKs and so there is sufficient space that we can use
additional bits for a sub-type field, too.
* DATA_ACK and DSN_MAP are often (but not always) seen together. They
can be combined under a different option subtype.
* DATA_FIN is no longer required.

To expand on the last two points: If the DATA_ACK and DSN_MAP were
combined, we could end up with an option that looks a bit like this
("Flags" is a set of bits that define the contents - currently, we'd be
looking at: DSN_MAP present; DATA_ACK present; DSN_MAP is eight bytes
rather than four; DATA_ACK is eight bytes.

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +---------------+---------------+--------------+---------------+
      |  Kind=MPTCP   |    Length     |    Subtype   |     Flags     |
      +---------------+---------------+--------------+---------------+
      |           Data ACK (4 or 8 octets, depending on flags)       |
      +--------------------------------------------------------------+
      |   Data Sequence Number (4 or 8 octets, depending on flags)   |
      +--------------------------------------------------------------+
      |              Subflow Sequence Number (4 octets)              |
      +-------------------------------+------------------------------+
      |  Data-level Length (2 octets) |      Checksum (2 octets)     | 
      +-------------------------------+------------------------------+

In the course of thinking about this, I have realised we don't need an
explicit DATA_FIN option. DATA_FIN can be implied by a DSN_MAP where the
mapping covers the FIN of the subflow.

Thoughts?

Cheers,
Alan

---

From: <[email-masked]>
Date: Tue, 18 Jan 2011 18:32:44 +0000

Any comments?

We would like to do an update soon, including this & the security decision, in order that we can still be on track for our aim of WGLC before Prague.

thanks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ford, Alan
Sent: 11 January 2011 16:12
To: [email-masked]
Subject: [multipathtcp] Reducing option number usage

Hi all,

                           1                   2                   3

Thoughts?

Cheers,
Alan

_______________________________________________
multipathtcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Jan 2011 12:30:35 -0800

Hi, all,

> options, with a sub-type field.

I'm a bit confused by that conclusion. IMO, there is no reason a single 
TCP extension should ever need more than one TCP option type. Can you 
clarify why this would need to be the case here?

Joe

---

From: Lars Eggert <[email-masked]>
Date: Wed, 19 Jan 2011 09:58:37 +0200

Hi,

On 2011-1-18, at 22:30, Joe Touch wrote:
> I'm a bit confused by that conclusion. IMO, there is no reason a single TCP extension should ever need more than one TCP option type. Can you clarify why this would need to be the case here?

MPTCP uses several different kinds of options. That can be expressed by using several TCP option numbers, or by using one TCP option number and an internal "option kind" field. The latter is much cleaner than the former, but makes each MPTCP option a bit longer. One complication is that option space is so limited that option length matters (maybe more so than architectural cleanliness.)

I think the current proposal is a hybrid: use internal "option kind" fields where option length doesn't matter, but still use more than one TCP option number for those MPTCP options where length does matter.

I can live with the hybrid although it's not the cleanest possible approach.

Lars

---

From: "Ford, Alan" <[email-masked]>
Date: Wed, 19 Jan 2011 09:19:06 -0000

Hi Lars, Joe,

Yes, although I never actually specified how many a "limited number"
would be :)

Indeed, having thought about this some more I think we will be fine with
a single option type, so long as we can live with four bits for a
sub-type field. 

The MP_CAPABLE and MP_JOIN options used on the SYNs are sufficiently
space-constrained that we cannot really go beyond four bits there. All
other options could spare up to 8 bits for a full octet of sub-type, but
that would require two TCP option types (one for the SYN packet options
and one for other signals). This is the trade-off we have - anybody got
any strong opinions? At the moment I am favouring the four-bit sub-type
field, with a single allocated TCP option (and deal with any new
problems in a later MPTCP version ;) ).

Regards,
Alan

> From: Lars Eggert [mailto:[email-masked]]
> Sent: 19 January 2011 07:59
> To: Joe Touch
> Cc: Ford, Alan; [email-masked]
> Subject: Re: [multipathtcp] Reducing option number usage
> 
> Hi,
> 
> > I'm a bit confused by that conclusion. IMO, there is no reason a
single TCP
> extension should ever need more than one TCP option type. Can you
clarify why
> this would need to be the case here?
> 
> MPTCP uses several different kinds of options. That can be expressed
by using
> several TCP option numbers, or by using one TCP option number and an
internal
> "option kind" field. The latter is much cleaner than the former, but
makes
> each MPTCP option a bit longer. One complication is that option space
is so
> limited that option length matters (maybe more so than architectural
> cleanliness.)
> 
> I think the current proposal is a hybrid: use internal "option kind"
fields
> where option length doesn't matter, but still use more than one TCP
option
> number for those MPTCP options where length does matter.
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 19 Jan 2011 11:28:27 +0200

On 2011-1-19, at 11:19, Ford, Alan wrote:
> At the moment I am favouring the four-bit sub-type

Sounds good to me.

Lars

---

From: "Khiem Le" <[email-masked]>
Date: Thu, 20 Jan 2011 12:03:06 -0600

Hi all,

Using one TCP option with a subtype is a clean approach, but 4 bits for
the subtype is rather small. It would be prudent to have a hook to
enable possible future MPTCP extensions. 

I would propose we reserve one specific 4-bit code in the subtype, say
0000, for possible future extensions. That is, if the 4-bit subtype
matches the specific 0000 pattern, that will indicate the presence of
additional bits for the subtype. We need to worry about defining the
additional bits only if and when the need arises.

Khiem

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Lars Eggert
Sent: Wednesday, January 19, 2011 3:28 AM
To: Ford, Alan
Cc: [email-masked]
Subject: Re: [multipathtcp] Reducing option number usage

On 2011-1-19, at 11:19, Ford, Alan wrote:
> At the moment I am favouring the four-bit sub-type field, with a 
> single allocated TCP option (and deal with any new problems in a later

> MPTCP version ;) ).

Sounds good to me.

Lars

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.