Re: [Banana] [flow/congestion-control behavior for different solutions]

[Mingui Zhang <[e-mail]>]

Hi Bart,

> -----Original Message-----
> From: PEIRENS Bart (TSI/MST) [mailto:[e-mail]]
> Sent: Thursday, July 28, 2016 7:52 PM
> To: Olivier Bonaventure; Mingui Zhang; Sri Gundavelli (sgundave)
> Cc: SungHoon Seo; [e-mail]; Henderickx, Wim (Nokia - BE);
> [e-mail]; Michael Menth
> Subject: [flow/congestion-control behavior for different solutions]
> 
> Hi Mingui
> 
> On:
> 
> >> I have a confusion about the plain-mode MPTCP proxy. Olivier told me the
> transparent-mode does not suffer from TCP-over-TCP issue.
> >>Then what about the plain-mode? From the text of the plain-mode draft, I can
> see the user's TCP session is converted into a MPTCP session rather than
> terminated.
> >
> >I don't expect that it would be possible to efficiently implement the
> >plain-mode option and support all the issues with  retransmission
> >without terminating TCP connections on the proxies. For me, both
> >plain-mode and transparent mode rely on TCP proxies that terminate TCP
> connections. A naive implementation might try to rewrite TCP packets without
> terminating the  connections, but it would have problems to support all the
> recovery mechanisms that exist in TCP correctly.
> >
> >> If the TCP-over-TCP issue exists, will retransmission function of the MPTCP
> stack be waived from the MPTCP proxy?
> >
> >The TCP over TCP issues does not exist since connections are terminated.
> >The MPTCP retransmission mechanisms are required to cope with
> >congestion and failures on the DSL/LTE links
> >
> 
> You actually touched an interesting point that would be interesting to better
> understand while comparing the different solutions.
> The concern raised above is not really 'tcp in tcp'  but the potential effects of
> 'stacked flow/congestion-control', as Olivier clarified,  for the network assisted
> MPTCP solutions proposed (both) this is a non-concern as this is actually not
> stacked.
> 
> At IETF 95 a draft you co-author has been presented proposing flow-control
> extensions for GRE to overcome some of the current limits of the
> solution(draft-zhang-banana-tcp-in-bonding-tunnels-00.txt) where 'tcp-alike'
> flow-control with some adaptations (no-retransmission etc) is implemented on
> each individual GRE tunnel leg (not per encapsulated flow within the tunnel).
> How do  you see the interaction of the inner TCP  mechanisms and the outer
> GRE flow control that adapts the rate of traffic pushed over a  specific leg? Also
> the way I read the draft it does not provide a direct solution to the throughput
> impact on both legs of a single TCP  session/flow split over multiple GRE tunnels
> when packet loss is only happening on a single leg (e.g. changing mobile
> conditions/load).
> I have difficulties to understand how these mechanisms will not start heavily
> fighting with each other and create a highly oscillating traffic split between the
> different bearers.  If you have some data you could share to clarify this it would
> be highly welcome.

[Mingui] Very good comments! Frankly speaking, that draft is just a starter. It is not implemented yet so I do not have the data. I actually have the same doubts as you.

Thanks,
Mingui

> 
> Similar a lot of work is ongoing today in the transport area that is based on ECN bit
> usage, and we see an increase of deployments  of ECN enabled stacks in the
> field, and there is also other ongoing work that proposes guidelines on how to
> deal with ECN when  encapsulating packets
> (draft-ietf-tsvwg-ecn-encap-guidelines-07), would it not make sense to work on
> defining ECN for  GRE to  make such rfc6040 behaviour working as well?
> 
> Not clear how the MIP solution that was mentioned by some during the meeting
> deals with this either? If someone can fill in for that as well.
> 
> Regards
> Bart
> 
> 
> 
> ________________________________
> 
> ***** Disclaimer *****
> http://www.proximus.be/maildisclaimer