Re: [multipathtcp] Submitted drafts

[Alan Ford <[e-mail]>]

Hi Olivier, all,

Inline...

On 9 July 2015 at 16:04, Olivier Bonaventure <
[e-mail]> wrote:
>
> During the last week we have written and submitted several drafts that
> could be of interest for the working group :
>
> *
> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-option-00.txt
>
> This draft proposes a standard encoding for experimental MPTCP options.
> Given the small number of MPTCP options, it is important to allow
> experimenters to use MPTCP options without wasting this limited ressource.
>
>
This met with consensus in the WG session yesterday and I'll wrap it into
the next version of the bis draft.

However, do we really need to use 2 bytes on the experiment ID? That seems
like a lot when we have very limited TCP option space. Surely we want to
minimise the overhead? Could we make do with a single byte here?


> * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr-00.txt
>
> This draft discusses some issues with the advertisement of addresses in
> Multipath TCP and proposes a small modification to the handling of the
> address identifiers of the initial subflow to simplify implementations. It
> also shows how the reverse DNS can be used as an alternative to ADD_ADDR to
> announce the addresses of servers. This technique is already used for
> multipath-tcp.org


(I'll reply later in the thread re this)


>
> *
> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-backup-00.txt
>
> This draft discusses some issues with the support of backup subflows in
> the existing Multipath TCP specification. In RFC6824 backup subflows work
> well when a subflow completely stops, but not when a subflow experiences
> huge losses.
>
>
As I mentioned in the WG session yesterday, I am not sure this needs any
protocol changes, but maybe some improvements to advice in the heuristics
section. It was always the intention that end hosts could use any kind of
indication they had available to trigger a change between subflows, so if
an implementor could shorten timeouts, or use some out-of-band triggers,
that would achieve the desired result.

Regards,
Alan