Re: [multipathtcp] MPTCP carrying UDP

[<[e-mail]>]

Christoph, 

I would like to make two comments: 
* The implementers I have in mind are CPE vendors and Carrier-Grade platform manufacturers.
* Implementation does not come for free. 

Cheers,
Med

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]]
> Envoyé : mardi 15 novembre 2016 18:22
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Re: [multipathtcp] MPTCP carrying UDP
> 
> On 15/11/16 - 12:40:01, [e-mail] wrote:
> > Re-,
> >
> > I have one comment about the target applications: QUIC is definitely
> one.
> >
> > For the VoIP case (RTP to be more accurate), there is already a
> candidate solution: Multipath RTP (https://tools.ietf.org/html/draft-ietf-
> avtcore-mprtp-03).
> >
> > I don’t have results to share because we are in a chicken/egg situation:
> implementers are asking for a stable specification to play with.
> 
> I don't buy this argument. Implementors can build a prototype to feed
> information/feedback into the standardization process.
> 
> 
> Christoph
> 
> >
> > Cheers,
> > Med
> >
> > De : [e-mail] [mailto:[e-mail]]
> > Envoyé : mardi 15 novembre 2016 12:51
> > À : [e-mail]; BOUCADAIR Mohamed IMT/OLN;
> [e-mail]; [e-mail]
> > Cc : [e-mail]
> > Objet : MPTCP carrying UDP
> >
> > (I changed the Subject line of the email)
> >
> > Do people have any experimental results /experiences they could share of
> running UDP applications over MPTCP sub-flows?  Would be interested to
> hear about the issues. I guess VoIP and Quic would be the most interesting
> ones. Whether the experiments are with only one path being used at once,
> or multiple. etc
> >
> >
> >
> > From: Robert Skog [mailto:[e-mail]]
> > Sent: 15 November 2016 10:09
> > To: [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> Eardley,PL,Philip,TUB8 R
> <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[e-mail]>
> > Cc: [e-mail]<mailto:[e-mail]>
> > Subject: RE: [multipathtcp] Towards a Multipath TCP Proxy work item
> >
> > +1
> > We see a need to solve UDP in several places, so having a separate
> specification can help this moving forward.
> >
> > Cheers,
> > /Robert
> >
> > From: multipathtcp [mailto:[e-mail]] On Behalf Of
> [e-mail]<mailto:[e-mail]>
> > Sent: den 15 november 2016 09:57
> > To: [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>
> > Cc: [e-mail]<mailto:[e-mail]>
> > Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item
> >
> > Hi Markus, all,
> >
> > I’m on the same page that non-tcp traffic should be considered in scope.
> At least, the UDP case should be investigated. I remember there was
> interest in BA meeting about the UDP part
> (https://www.ietf.org/proceedings/95/minutes/minutes-95-mptcp).
> >
> > An option I see is to consider advancing the use of MPTCP to convey UDP
> flows in a separate EXPERIMENTAL specification that will be cross-reviewed
> with other WGs (intarea, tsvwg). Having that base specification will help
> having interoperable implementations that will be used to carry
> experimentations.
> >
> > Those experiments will help to determine whether the proposed solution
> is complex/simple, viable/non-viable, failed/successful, etc.
> >
> > Let’s give it a try.
> >
> > Cheers,
> > Med
> >
> > De : multipathtcp [mailto:[e-mail]] De la part de
> [e-mail]<mailto:[e-mail]>
> > Envoyé : mardi 15 novembre 2016 08:58
> > À : [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>
> > Cc : [e-mail]<mailto:[e-mail]>
> > Objet : Re: [multipathtcp] Towards a Multipath TCP Proxy work item
> >
> > Phil,
> >
> > If you feel it would take too long and to be too complex to achieve in a
> reasonable timeframe, we are ok with excluding non-tcp traffic, however,
> for our total solution we do requires also non-tcp traffic to be sent over
> multiple paths. We could argue that we can use a different mechanisms
> specifically for UDP and other protocols, but it would be nice to have as
> single MPTCP-based solution. (my gut feeling is that we would need to
> replicate a lot of MPTCP scheduling features into a new mechanism).
> >
> > Marcus
> >
> > Von: multipathtcp <[e-mail]<mailto:multipathtcp-
> [e-mail]>> im Auftrag von
> "[e-mail]<mailto:[e-mail]>"
> <[e-mail]<mailto:[e-mail]>>
> > Datum: Montag, 14. November 2016 um 07:32
> > An: "[e-mail]<mailto:[e-mail]>"
> <[e-mail]<mailto:[e-mail]>>
> > Cc: "[e-mail]<mailto:[e-mail]>"
> <[e-mail]<mailto:[e-mail]>>
> > Betreff: Re: [multipathtcp] Towards a Multipath TCP Proxy work item
> >
> >
> > i think we should move beyond "exploring whether it would be useful".
> >
> >
> >
> > i'd like us to assess proposed solutions. i think we should say this is
> what we're doing - at the moment we've had quite a lot of discussion about
> one proposal. we should give the chance for other proposals, and make the
> discussion more structured (what are the assessment criteria).
> >
> >
> >
> > i also think we should explicitly exclude non-tcp traffic  (i think non-
> tcp traffic is too big a topic for our WG)
> >
> >
> >
> > phil
> >
> >
> >
> >
> >
> > ________________________________
> > From: Alan Ford <[e-mail]<mailto:[e-mail]>>
> > Sent: 14 November 2016 06:11
> > To: Eardley,PL,Philip,TUB8 R
> > Cc: [e-mail]<mailto:[e-mail]>
> > Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item
> >
> > I think this work item is achievable by simply removing references to
> “at least one end” from the existing charter item on the proxy. So the
> item would now read:
> >
> > Finally, the working group will explore whether an MPTCP-aware
> > middlebox would be useful. For example, potentially helping MPTCP’s
> > incremental deployment by allowing only one end host to be MPTCP-enabled
> > and the middlebox acts as an MPTCP proxy for the other end host, which
> runs
> > TCP; and potentially helping some mobility scenarios, where the middle
> box
> > acts as an anchor between two MPTCP-enabled hosts. Alternatively,
> neither
> > end host could be MPTCP-enabled but a pair of proxies could work
> together to
> > bring MPTCP benefits to such connections. The working group will detail
> what real
> > problems an MPTCP-enabled middlebox might solve, how it would impact the
> > Multipath TCP architecture (RFC6182), what proxy approach might be
> > justified as compared against alternative solutions to the problems, and
> > the likely feasibility of solving the technical and security issues.
> >
> > In some ways, the two ended proxy work could even be seen as an
> extension of the previous operational experience work within this WG.
> >
> > Regards,
> > Alan
> >
> > On 10 Nov 2016, at 19:17,
> [e-mail]<mailto:[e-mail]> wrote:
> >
> > Hi,
> > Perhaps this is speaking too soon, but it looks like the very active
> discussion is reaching some common understanding?
> >
> > We’re trying to work out what a work item might look like, so would like
> to understand what assumptions we would make, eg about the scenario, &
> what common agreements we’d assume & restrictions on how the solution
> works. This seems important to frame work by WG. If possible we’d like
> discussion on these points to avoid getting into the fine details of one
> particular existing proposal.
> >
> > What we’d appreciate is a summary of what the assumptions
> /understandings are about:
> > •         The scenario (for instance: the MPTCP-enabled host knows the
> address of the proxy (eg through configuration); and it knows the address
> of the ‘legacy’ host it wants to communicate with)
> > •         If any impact is already envisaged on the current MPTCP
> protocol’s fallback behaviour and coping with middleboxes
> > •         If we can agree that the solution is based on a new MPTCP
> option
> > •         If any impact is already envisaged on the current MPTCP
> protocol’s semantics (other than the new option) eg in terms of
> https://tools.ietf.org/html/rfc6824#section-4
> > •         If any impact is already envisaged on TCP’s semantics, or any
> mods are needed, or assumptions about its behaviour, etc
> > •         If any impact is already envisaged on other existing transport
> protocol’s semantics (presuming people still would like non-TCP in scope?)
> > •         Anything else that you think is needed in order to frame the
> work item
> >
> > It may be clearer to do this for the two use cases (single-ended proxy,
> ie where only one host is MPTCP-enabled; and double-ended proxy, ie where
> neither host is MPTCP-enabled).
> >
> > This may seem like a long list, but most of the answers can be “none” –
> we’ll end up with just a short paragraph or a few bullets in the charter.
> >
> > We’d also have to work out interactions with non-MPTCP WGs, but Mirja
> and IESG will probably want the main input on this.
> >
> > Thanks
> > Phil & Yoshi
> > _______________________________________________
> > multipathtcp mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> >
> 
> > _______________________________________________
> > multipathtcp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/multipathtcp