Re: [multipathtcp] MPTCP proxy work - call for ideas

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi Phil, Yoshi

I could cover for the session a new scenario related with the application of MPTCP proxy to mobile backhaul / aggregation scenarios. Unfortunately there is not a supporting document for this yet, but I could through a descriptive scenario during the session by now, looking for a way for documenting it (if it is interesting for the people) afterwards.

>From the solution space perspective I foresee this scenario being solved by network-assisted MPTCP.

My only constraint would be that I most probably should leave the session at 18:00 (or even a bit before).

Bets regards

Luis

__________________________________
Luis M. Contreras

Technology and Planning
Transport, IP and Interconnection Networks
Telefónica I+D / Global CTO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

Skype (Lync): [phone]
Mobile: [phone]
[e-mail]<mailto:[e-mail]>


De: multipathtcp [mailto:[e-mail]] En nombre de [e-mail]
Enviado el: jueves, 9 de marzo de 2017 16:28
Para: [e-mail]
Asunto: [multipathtcp] MPTCP proxy work - call for ideas

Hi,

We have two (adjacent) sessions in Chicago - so we have some time to dedicate to MPTCP proxy related discussions.

We'd like to offer time for people to present their proposals. These could be new ideas, or relate to what has already been proposed.
In order to try and make this discussion more fruitful, please read the words below - which frame the scope of the discussion, and suggest how to present your idea.
Please let us know if you want time - we'll divide the available time, and leave plenty of time for discussion.
PS This is MPTCP proxy discussion - there may be some side meeting about banana.
PS This discussion proceeds without changing the charter. Depending on the idea(s) that get consensus, then we work out if it needs a re-charter or not, and about coordinating with other WGs.

Thanks,
Best wishes,
Phil & Yoshi

----
MPTCP is now seeing widespread deployment in networks to bond together two accesses, such as fixed and mobile broadband, by using an MPTCP-specific proxy or proxies. There are two scenarios. The first involves two proxies, one in the home gateway or Customer Premises Equipment and one in the network, both under the control of the operator. The other scenario involves an MPTCP-enabled smartphone, with LTE and WiFi, plus a proxy in the operator's network.
The WG will analyse proposed solutions for both the single and dual proxy scenarios. The solution(s) may require changes to RFC6824bis, and may require a means of configuring set-up information in the proxy, which would be done in coordination with other IETF WGs such as DHC.

Note:
- Single & two ended proxy in scope
- Proxy(s) are under control of operator
- Only TCP traffic considered
- Open for solution proposals. First step is to analyse proposals and reach consensus on one we go ahead with, or perhaps a solution for each scenario
- Hopefully just one solution, but possibly need a different solution for 1 & 2 ended scenarios. Not multiple solutions for each scenario.
- May (but may not) require changes to rfc6284 (for instance, is it an extension to the protocol, or using the existing protocol)
- If it does require a change to 6824, then prefer to include the change in the bis, in order have one version of the protocol.
- "appropriate IETF WGs" includes any WG arising from the banana BoF
- if the solution(s) require a non-MPTCP protocol to exchange information between the two proxies, this presumably wouldn't be in the remit of MPTCP WG

We now have a 'call for solution proposals'. First step is to analyse proposals and reach consensus on one we go ahead with

*                     proposal should be in the form of a "protocol model". See RFC4101, Writing protocol models: <<to present an architectural model for how the protocol operates ...  1. What problem is the protocol trying to achieve? 2.What messages are being transmitted and what do they mean? 3. What are the important, but unobvious, features of the protocol? >>

*                     if your ideas involve multiple possibilities, please either select your favourite, or report them as separate solutions

*                     The WG will consider single and dual proxy separately. But we favour solutions with a lot of "re-use" between the single and dual proxy. This is in terms of effort by the WG, implementers and deployers. We also favour solutions where the single and dual proxied solutions can co-exist

*                     Whilst you may not be ready to present your analysis of your proposal against the (proposed) Criteria (See separate email), it may be worth bearing them in mind.
----