Re: [iccrg] Disadvantages of TCP connection splitters

Toerless Eckert <tte@cs.fau.de> Fri, 10 January 2020 10:15 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: iccrg@ietfa.amsl.com
Delivered-To: iccrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D69120889 for <iccrg@ietfa.amsl.com>; Fri, 10 Jan 2020 02:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level:
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNsVv58PSFkP for <iccrg@ietfa.amsl.com>; Fri, 10 Jan 2020 02:15:02 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9029A120096 for <iccrg@irtf.org>; Fri, 10 Jan 2020 02:15:02 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2DEC9548049; Fri, 10 Jan 2020 11:14:57 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 20119440059; Fri, 10 Jan 2020 11:14:57 +0100 (CET)
Date: Fri, 10 Jan 2020 11:14:57 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Welzl <michawe@ifi.uio.no>
Cc: iccrg IRTF list <iccrg@irtf.org>
Message-ID: <20200110101457.GB8801@faui48f.informatik.uni-erlangen.de>
References: <7FFBC144-5F59-41BD-A47D-D4AFEFA2BE4D@ifi.uio.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7FFBC144-5F59-41BD-A47D-D4AFEFA2BE4D@ifi.uio.no>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/rY064rFtFpeoL-PqWXmbicbr8LU>
Subject: Re: [iccrg] Disadvantages of TCP connection splitters
X-BeenThere: iccrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <iccrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/iccrg>, <mailto:iccrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iccrg/>
List-Post: <mailto:iccrg@irtf.org>
List-Help: <mailto:iccrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2020 10:15:04 -0000

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