Re: [iccrg] Disadvantages of TCP connection splitters

Keith Winstein <> Fri, 10 January 2020 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BA591200F6 for <>; Fri, 10 Jan 2020 11:41:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ydX7t69Jhn7p for <>; Fri, 10 Jan 2020 11:41:38 -0800 (PST)
Received: from smtp3.cs.Stanford.EDU ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E1851200F1 for <>; Fri, 10 Jan 2020 11:41:38 -0800 (PST)
Received: from ([]:36213) by smtp3.cs.Stanford.EDU with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from <>) id 1iq0A4-0003lN-Nw for; Fri, 10 Jan 2020 11:41:37 -0800
Received: by with SMTP id d15so3336811iog.3 for <>; Fri, 10 Jan 2020 11:41:36 -0800 (PST)
X-Gm-Message-State: APjAAAWR5SrAplLQv4epuWW2XxnjHT6L10jQNAk2wm6hkwTWVSsWSBs6 kXmfvlHuzqn6nPSJZ1ObPTqNSjroX5sECs/agA==
X-Google-Smtp-Source: APXvYqxQnTDQ0yjid5p86s9z3VL0bd6/jA/D2KaUiwEQ5R60EpCBrCoDTLqTJEfC4EDfkVF6VLwNQt5+vFTEcS8xniU=
X-Received: by 2002:a5e:860e:: with SMTP id z14mr3786508ioj.10.1578685296234; Fri, 10 Jan 2020 11:41:36 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Keith Winstein <>
Date: Fri, 10 Jan 2020 11:41:00 -0800
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Michael Welzl <>
Cc: iccrg IRTF list <>
Content-Type: multipart/alternative; boundary="0000000000004b56e2059bce5039"
X-Scan-Signature: 25a6791de6f4ae323969ef66fe3dfbb7
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:41:42 -0000

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.


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