Re: [iccrg] Disadvantages of TCP connection splitters

Main downside is that its limited to TCP, and i think it might
be easier nowadays to implement split/merge generically for
5 tuple flows and not for TCP alone, and the customer gets
the benefits for TCP, DCTCP, SCTP, QUIC, RTP and any other flow.

In most situations you can't simply split the packets without
encap or NAT anyhow because the alternative paths may likely
require different source or dest addresses (dual SP attachment
via broadband/DSL or the like). Once you do have such encap
its typically easier to run your own congestion/retransmission
between merge/split instead of just trying to passivle
observe and analyze the end-to-end TCP signals and figure
out how to deduce the appropriate load-split from them.

Toerless

On Fri, Jan 10, 2020 at 09:54:07AM +0100, Michael Welzl wrote:
> Hi,
> 
> I???ve been thinking a lot about TCP connection splitters lately ( https://tools.ietf.org/html/rfc3135#section-2.4 ).
> 
> I???m curious: what are the real practical disadvantages of this type of PEPs that people have seen?
> I'll appreciate any kind of feedback, also anecdotes, but pointers to citable papers would be best.
> 
> BTW, let???s keep multi-path apart from this discussion please. My question is about single path TCP.
> 
> Cheers,
> Michael
> 
> PS: I???m not trying to indirectly hint that such devices would be *always good*. However, the scenarios where they are not strike me as surprisingly narrow, so I wonder if I???m missing more.
> 
> _______________________________________________
> iccrg mailing list
> iccrg@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg