[multipathtcp] MPTCP proxy work - proposed assessment Criteria - for discussion

[<[e-mail]>]

For the MPTCP proxy work, we now have a 'call for proposals' (see email sent in parallel). As part of seeing which proposal may have consensus, we will assess them against Criteria.
This list of criteria is an initial suggestion for discussion.

*             Note:  since we want RFC6824bis to be on the STDS track, we will eventually need to have prototype implementations tested in an appropriate range of conditions
*             Prefer solution that doesn't require major changes to the protocol's semantics or additional functionality or security requirements (ie an application of RFC6824bis or a simple extension)
*             Prefer solution where the proxy is simple to operate and where the assumptions and requirements imposed on the operator's network are simple to meet
*             A session can be initiated from either end (presumably this is inherent for solutions to the dual proxy scenario, since it is symmetric)
*             the set-up time is minimised. Comment: arguably MPTCP is most interesting for long-running flows, when the time to set up the extra subflow(s) is less important. But it still seems worthwhile keeping the set up time down - prefer solutions that have 1 round trip to those that have 10, but reducing the last half round trip is not critical?
*             get MPTCP's usual benefits of resource pooling and resilience
*             minimise the amount of overhead on data traffic (such as delay, data overhead, potential packet fragmentation)
*             the solution needs to work if end to end encryption is in use

Criteria specific to solutions for the single-ended proxy scenario:
*             the scenario means that the proxy is unlikely to be on both default paths
*             clarify whether the proxy simply forwards packets (towards the MPTCP end host) - or does it also perform packet re-ordering?
*             prefer solution that allows hosts to have TCP (& MPTCP?) traffic that doesn't get proxied (creates requirements if end host can control whether upstream traffic (ie towards the end host) is MPTCP-proxied)
*             the end host and proxy need to authenticate each other
*             ? this scenario creates an increased threat of DoS & other attacks, since the proxy hides the attacker's address?

Criteria specific to solutions for the two-ended proxy scenario:
*             the scenario means that the proxies are assumed to know how to communicate directly
*             the operator can interpose the MPTCP proxies on TCP traffic without informing the end hosts, and without them being able to request that such action is, or is not, taken (?)
*             the solution explains how the address of the remote server is signalled to the proxy
*             the solution can build on security configuration etc known outside of MPTCP

Best wishes,
Phil & Yoshi