Subject: Re: [multipathtcp] mptcp-multiaddressed: How long beforemultipath starts?

From: <[email-masked]>
Date: Tue, 8 Feb 2011 22:17:56 +0000

Since these issues are for the heuristics section, it seems appropriate to give several possibilities and advice when each one may be right.
----- Original message -----
> Hello Bob,
>
> It's nothing special. My concern is we cannot always presume path
> diversity. So, I just prefer conservative approach.
> If we can have good knowledge about network configuration like data
> center scenarios, I think we won't have to be conservative. But, it
> looks a bit special case to me.
>
> Thanks,
> --
> Yoshifumi Nishida
> [email-masked]<mailto:[email-masked]>
>
> 2011/2/7 Bob Briscoe <[email-masked]<mailto:[email-masked]>>:
> > Christoph, Yoshifumi, Costin,
> >
> > What is the original logic behind this... Why should waiting for
> slow-start
> > to end on one flow be relevant to when to start another sub-flow? I
> don't
> > see why (in general) slow-start on one path should affect slow start
> on
> > another.
> >
> > I would have thought the opposite: that opening more sub-flows would
> be a
> > more friendly way to increase the effective initial window than
> increasing
> > it all on one sub-flow. Because it spreads out the overshoots over
> multiple
> > paths (assuming underlying physical path diversity) and over time
> (assuming
> > RTTs are different).
> >
> >
> >
> > Bob
> >
> > At 09:09 07/02/2011, Christoph Paasch wrote:
> > >
> > > Hi,
> > >
> > > this sounds like a reasonable approach, to avoid creating congestion
> due
> > > to
> > > several subflows being in slow-start.
> > > However, I see one problem:
> > > After the initial subflow enters congestion avoidance, we try the
> next
> > > one.
> > > However the SYN's of this new subflow get blocked somewhere on their
> path.
> > > Then we will be stuck with only the initial subflow for a long time
> (until
> > > the
> > > TCP-stack gives up retransmitting the SYN's of the second subflow).
> And
> > > only
> > > then we will try the third subflow.
> > >
> > >
> > > Cheers,
> > > Christoph
> > >
> > > On Monday, February 07, 2011 wrote Yoshifumi Nishida:
> > > > Hi,
> > > > I personally prefer to initiate another subflow after the preceding
> > > > flow enters congestion avoidance. It looks a simple rule and we can
> > > > avoid multiple subflows to perform slow-start at the same time.
> > > > Or, does it hurt performance?
> > > >
> > > > Thanks,
> > > > --
> > > > Yoshifumi Nishida
> > > > [email-masked]<mailto:[email-masked]>
> > > >
> > > > 2011/1/31 Bob Briscoe <[email-masked]<mailto:[email-masked]>>:
> > > > > Alan Costin, Mark, or ANOther,
> > > > >
> > > > > The large majority of TCP flows are very short. If there will
> only be
> > > > > one
> > > > > or two packets to send, there will be no point sending off loads
> of
> > > > > requests to open sub-flows straight after the first 3-way
> handshake.
> > > > >
> > > > > So I imagined there would be some advice in one of the MPTCP I-Ds
> on
> > > > > how
> > > > > long a MPTCP should wait until it attempts to open sub-flows.
> > > > >
> > > > > I can't find this from a quick scan. I would have expected it to
> be in
> > > > > the heuristics section of draft-ietf-mptcp-multiaddressed:
> > > > >
> > > > >
> <http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-02#section-3.>; >
> > > > > 8>
> > > > >
> > > > > In general, a TCP stack doesn't know how much data the
> application
> > > > > might
> > > > > eventually want to send. So I guess the basic advice might be to
> wait
> > > > > n_1
> > > > > RTTs before opening a second subflow, then n_2 RTTs before
> opening a
> > > > > third and so on.
> > > > >
> > > > > Has anyone done any research on this to find the best tradeoff
> (ie
> > > > > best
> > > > > values of n_1, n_2, etc) between improved performance/resilience
> and
> > > > > wasting signalling packets? I imagine this heuristic would be
> clocked
> > > > > by
> > > > > RTTs, not real-time or bytes, because that would likely be the
> > > > > relevant
> > > > > parameter for the signalling tradeoff.
> > > > >
> > > > > Then, in the API draft, there might be some discussion on whether
> the
> > > > > application can tell the transport how much data it intends to
> send,
> > > > > so
> > > > > the heuristics can be less blind.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > >
> > > > > Bob
> > > > >
> > > > >
> > > > > ________________________________________________________________
> > > > > Bob Briscoe,                                                              BT Innovate & Design
> > > > > _______________________________________________
> > > > > multipathtcp mailing list
> > > > > [email-masked]<mailto:[email-masked]>
> > > > > https://www.ietf.org/mailman/listinfo/multipathtcp
> > > >
> > > > _______________________________________________
> > > > multipathtcp mailing list
> > > > [email-masked]<mailto:[email-masked]>
> > > > https://www.ietf.org/mailman/listinfo/multipathtcp
> > >
> > > --
> > > Christoph Paasch
> > > PhD Student
> > >
> > > IP Networking Lab --- http://inl.info.ucl.ac.be
> > > MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
> > > Université Catholique de Louvain
> > >
> > > www.rollerbulls.be<http://www.rollerbulls.be>
> > > --
> >
> > ________________________________________________________________
> > Bob Briscoe,                                                              BT Innovate & Design
> >
> _______________________________________________
> multipathtcp mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: Mark Handley <[email-masked]>
Date: Wed, 9 Feb 2011 09:57:48 +0000

Would it make sense to separate these, and other
implementation-related issues into a separate "Advice for MPTCP
Implementors" draft?  That way the protocol spec would be
experimental, and the implementation advice would only be
informational.  It reduces the bar for revising the advice as we
learn.

 - Mark

On 8 February 2011 22:17, philip.eardley <[email-masked]> wrote:
> [email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 09 Feb 2011 12:08:16 +0000

Mark,

Works for me - depends whether the w-g wants to 
maintain another doc, but I think there was talk of having this doc anyway.

Bob

At 09:57 09/02/2011, Mark Handley wrote:
> > Since these issues are for the heuristics 
> section, it seems appropriate to give several 
> possibilities and advice when each one may be right.
> >> > > > 2011/1/31 Bob Briscoe 
> <[email-masked]<mailto:[email-masked]>>:
> Briscoe, 
> BT Innovate & Design
> Briscoe, 
> BT Innovate & Design

---

From: Sébastien Barré <[email-masked]>
Date: Wed, 09 Feb 2011 17:09:33 +0100

Hi,

Op 09-02-11 13:08, Bob Briscoe schreef:
> Mark,
>
> Works for me - depends whether the w-g wants to maintain another doc, 
> but I think there was talk of having this doc anyway.
indeed, we are preparing a draft on this, and will try to reflect this 
discussion in it. We will probably discuss that at next IETF.

regards,

Sébastien.
>> > Since these issues are for the heuristics section, it seems 
>> appropriate to give several possibilities and advice when each one 
>> may be right.
>> <http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-02#section-3.>; 
>> >
>> >> > > > > 8>
>> >> > > > >

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre