Subject: [multipathtcp] Comments on draft-bonaventure-mptcp-experience-00

From: <[email-masked]>
Date: Fri, 25 Jul 2014 15:31:02 +0100

Olivier,
thanks for this draft, i think it's very useful
https://tools.ietf.org/id/draft-bonaventure-mptcp-experience-00.txt
Here are a few brief comments

Is there any data about the use case of a campus network with multiple providers (or something similar) ? – as this use case is mentioned in the charter
P3 “captive portals” – is the term widely known?
p5 “load balanced Internet paths between the same pair of hosts can have huge delay differences” – this seems like an important case that we should highlight where mptcp doesn’t help (or should we used with caution). I suppose the recommended action is simply to use the shorter delay path, or to use MPTCP in fall-back mode only.
P6/7 –we should remember to discuss whether should modify rfc6824bis (in the way that the paper proposed)
S7 – this seems a key issue for mptcp, so it would be worth discussion whether the EDNS approach is the best /only way of handling, or if anyone has ideas that would need mods to mptcp.
thanks
phil

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 29 Jul 2014 20:32:59 +0200

Phil,

> Here are a few brief comments

Thanks for your comments.

> Is there any data about the use case of a campus network with multiple
> providers (or something similar) ? – as this use case is mentioned in
> the charter

Not that I'm aware of. We could do some tests with two providers but one 
is a simple ADSL link. Maybe Nornet could report their experience with 
multiple providers

> P3 “captive portals” – is the term widely known?

If someone knows and alternative, I can update the draft

> p5 “load balanced Internet paths between the same pair of hosts can have
> huge delay differences” – this seems like an important case that we
> should highlight where mptcp doesn’t help (or should we used with
> caution). I suppose the recommended action is simply to use the shorter
> delay path, or to use MPTCP in fall-back mode only.

Not always. Some low delay paths my have lower bandwidth than the high 
delay ones.

> the way that the paper proposed)

Alan noted that some of the points in the draft could be a direct input 
for rfc6824bis

> S7 – this seems a key issue for mptcp, so it would be worth discussion
> whether the EDNS approach is the best /only way of handling, or if
> anyone has ideas that would need mods to mptcp.
>

This is broader than mptcp, I'd need to look at what MIF is discussing

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be