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

From: "PEIRENS Bart (TSI/MST)" <[email-masked]>
Date: Thu, 28 Jul 2016 11:51:33 +0000

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.

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

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 29 Jul 2016 08:51:53 +0000

Hi Bart,

> -----Original Message-----
> From: PEIRENS Bart (TSI/MST) [mailto:[email-masked]]
> Sent: Thursday, July 28, 2016 7:52 PM
> To: Olivier Bonaventure; Mingui Zhang; Sri Gundavelli (sgundave)
> Cc: SungHoon Seo; [email-masked]; Henderickx, Wim (Nokia - BE);
> [email-masked]; 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.
> >
> >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
> 
> 
>