Re: [iccrg] Disadvantages of TCP connection splitters

Michael Welzl <michawe@ifi.uio.no> Fri, 10 January 2020 10:21 UTC

Return-Path: <michawe@ifi.uio.no>
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 B6243120889 for <iccrg@ietfa.amsl.com>; Fri, 10 Jan 2020 02:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 qRMtqF5Jm1jm for <iccrg@ietfa.amsl.com>; Fri, 10 Jan 2020 02:21:33 -0800 (PST)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF136120096 for <iccrg@irtf.org>; Fri, 10 Jan 2020 02:21:32 -0800 (PST)
Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <michawe@ifi.uio.no>) id 1iprQ2-0006hf-9D; Fri, 10 Jan 2020 11:21:30 +0100
Received: from ti0182q160-4250.bb.online.no ([82.164.31.203] helo=[10.0.0.14]) by mail-mx11.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92.3) (envelope-from <michawe@ifi.uio.no>) id 1iprQ1-000GGe-EW; Fri, 10 Jan 2020 11:21:30 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <20200110101457.GB8801@faui48f.informatik.uni-erlangen.de>
Date: Fri, 10 Jan 2020 11:21:28 +0100
Cc: iccrg IRTF list <iccrg@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F8CD286E-078D-4F83-8A2E-7085317B6179@ifi.uio.no>
References: <7FFBC144-5F59-41BD-A47D-D4AFEFA2BE4D@ifi.uio.no> <20200110101457.GB8801@faui48f.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3445.104.11)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 82.164.31.203 is neither permitted nor denied by domain of ifi.uio.no) client-ip=82.164.31.203; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.14];
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: A3EC11E78AA0DF902216F0845AF70D63D9994EBB
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/zjjxntO7W1P6YVdNes9m0vShE9Y>
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:21:35 -0000


> On Jan 10, 2020, at 11:14 AM, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> 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.

Sure, you’re obviously right, but that’s also potentially solvable with app-level proxying (see draft-kuehlewind-quic-substrate, for example) - I’m more interested in the general congestion control & transport aspects of this.


> 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.

“run your own congestion/retransmission” -  yes, the added flexibility is a big plus here, that’s the plus that I’m trying to weigh against a minus…

Cheers,
Michael



> 
> 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