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
- [iccrg] Disadvantages of TCP connection splitters Michael Welzl
- Re: [iccrg] Disadvantages of TCP connection split… Toerless Eckert
- Re: [iccrg] Disadvantages of TCP connection split… Michael Welzl
- Re: [iccrg] Disadvantages of TCP connection split… Toerless Eckert
- Re: [iccrg] Disadvantages of TCP connection split… Keith Winstein
- Re: [iccrg] Disadvantages of TCP connection split… Yuchung Cheng
- Re: [iccrg] Disadvantages of TCP connection split… Michael Welzl
- Re: [iccrg] Disadvantages of TCP connection split… Marie-Jose Montpetit
- Re: [iccrg] [nwcrg] Disadvantages of TCP connecti… lloyd.wood@yahoo.co.uk
- Re: [iccrg] Disadvantages of TCP connection split… Kuhn Nicolas
- Re: [iccrg] Disadvantages of TCP connection split… Joerg Deutschmann