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

["PEIRENS Bart (TSI/MST)" <[e-mail]>]

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