Re: [iccrg] Disadvantages of TCP connection splitters

Yuchung Cheng <> Fri, 10 January 2020 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB2351200FF for <>; Fri, 10 Jan 2020 11:52:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iqc72Z5kiXy2 for <>; Fri, 10 Jan 2020 11:52:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B38A1200FA for <>; Fri, 10 Jan 2020 11:52:23 -0800 (PST)
Received: by with SMTP id f7so1174047uaa.8 for <>; Fri, 10 Jan 2020 11:52:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oeP0dRVcwdwnltekRMcROFJYZ070JPcdrgQNzmpgvQo=; b=H2WKkkg7o7hfxFlT0IQBhFyRtvNvMLxWxV7Aczir2It42qwHvGXMg2F37LlwBzeG00 Q9NiQKndutlB+p6ofih4XxZk+Q9h8cRi4CCuH7flhfP5TPq5H1ZBGMsfxcTO5+828HMt R7pFGDBn/LiHfyxVO/AH1dMCvfP+87fOhyr9RxeAyCi6DwLurLX2AKkLr7oHUGtyLkgR EmZrEz8ulURHQOD7cLn67E0YWBfaYbqSYIs8uFxl55d3aHdK56YymZmXTo29KOKDfMEp wyOg9qlPXvmsLOknXmQNGjijN19qgOpGdCoVx2EEqd5pKu8RkEG621WEpXSSbxZQqVdq TgBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oeP0dRVcwdwnltekRMcROFJYZ070JPcdrgQNzmpgvQo=; b=Tk9o4qTsKHijkbkLuFNEnoT0k902KNZ9294UmXNZL/NfQdVWSfKCOIOFnMNtkMKt9q c3HIJEN82ednal8Phex0L4jwC642nL771CELZQNLeAI7nZeLfdqfoibxd0QVXGs2VhCP 6gPsm81ItxTk2VJXtBmVWKGOqn3emgb5+39qLMEE6jjKWYkzkdH5FADW475svDrYFgtE VXBCZrpW5KgFF9nsKmarb+XO2XBgTOc4IEi86uT74M00dqyZJ6cHph4ffsim7EmLQPGs m1AfUuTTkU8Gf54Fso691gqv2XjaiTeXDJSoIPSjXhlU0i92VbnRtydsdakrkCsc+zRE yxvQ==
X-Gm-Message-State: APjAAAXu3tcPePbOaEzs5vDtBSlW2x/DIlfpVJo1UaW+0FmNrfiCmSzM cYwP7eYozG62sahKu8gDMnhuwsXjiFbGMQGdogsZ3Q==
X-Google-Smtp-Source: APXvYqwbk8zSrrFqAjtKuYmFJV0j4fS2JEbUf3VWAqPzwqaVRtXMO8EwVOSyy9D+xGMj81o8/PMCjAjX6VgIP2CiQZo=
X-Received: by 2002:ab0:69c9:: with SMTP id u9mr196916uaq.80.1578685942208; Fri, 10 Jan 2020 11:52:22 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Yuchung Cheng <>
Date: Fri, 10 Jan 2020 11:51:45 -0800
Message-ID: <>
To: Keith Winstein <>
Cc: Michael Welzl <>, iccrg IRTF list <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [iccrg] Disadvantages of TCP connection splitters
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jan 2020 19:52:27 -0000

On Fri, Jan 10, 2020 at 11:41 AM Keith Winstein <> wrote:
> In practice, I suspect some of the main downsides to these TCP (transparent) connection splitters are probably the ones cited by Google in their QUIC paper at SIGCOMM 2017: they have led to ossification of the TCP protocol by enforcing various assumptions about transport behavior on traffic that passes through.
> See, e.g., "Is it Still Possible to Extend TCP?" (IMC 2011), "Fitting Square Pegs Through Round Pipes" (NSDI 2012), or "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP" (NSDI 2012).
> A whole bunch of interesting TCP behavior seems to be frustrated by a non-negligable percentage of these middleboxes. I've personally experienced several middleboxes (for me, I've seen this on local virus scanners and airplane WiFi services) that will kill a connection as soon as one side sends FIN. This frustrates any application that uses half-open connections in an interesting way. Middleboxes will forget about an idle connection even if the endpoints still have the state. Middleboxes will freak out if there is payload alongside SYN or SYN/ACK. SomemMiddleboxes will freak out if they see TCP options they don't know about (including ENO/tcpcrypt). Middleboxes will freak out if a segment appears unacked to them but never gets retransmitted, or if a segment is acked but they didn't see it on the forward path. And, as you say, the TCP connection splitters frustrate any attempt by the endpoints to deploy newer/better/more path-appropriate congestion-control schemes.
> Just the FUD itself about what some lazy middlebox might freak out about probably contributes substantially to the ossification of TCP.

Similar sentiments here on real practical disadvantages as a TCP
developer dealing with Internet issues over a decade.

There are good PEPs. The real disadvantages are the poorly implemented
ones and the upkeep. In my personal experience I've worked with a
cellular provider to disable their PEPS that ended up delivering much
better (YouTube video) performance. They were very happy to get rid of
those boxes to save both latency and money.

> -Keith
> On Fri, Jan 10, 2020 at 12:54 AM Michael Welzl <> wrote:
>> Hi,
>> I’ve been thinking a lot about TCP connection splitters lately ( ).
>> 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 mailing list