Re: [iccrg] Disadvantages of TCP connection splitters

Marie-Jose Montpetit <marie@mjmontpetit.com> Fri, 10 January 2020 23:41 UTC

Return-Path: <marie@mjmontpetit.com>
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 0F8AC120120 for <iccrg@ietfa.amsl.com>; Fri, 10 Jan 2020 15:41:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com
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 Fipimm8jaMkw for <iccrg@ietfa.amsl.com>; Fri, 10 Jan 2020 15:41:10 -0800 (PST)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC376120047 for <iccrg@irtf.org>; Fri, 10 Jan 2020 15:41:10 -0800 (PST)
Received: by mail-io1-xd34.google.com with SMTP id h8so3920522iob.2 for <iccrg@irtf.org>; Fri, 10 Jan 2020 15:41:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=4oMK+1d5HOBXCj2AbDNwqsXEhXgsZDm/DTyWNeUXO0Y=; b=UQiaakGDCOvJswNVG5OJYQrPsQsVP5s2AfhL6q3i0gXQXIUnzy1JaCC0qhBakjeWkh 9hJvprqRKgCN5/d+DdktRvQfLasbuYueyBYfaCm84R+5/XF4UiDp9zDt3BaYj+HxRMBV kV8Sl1aejNxuNl+s/6oKQ27J2M9s9eNNC/wV2opTfhE1/zwBXl5aRsBPsn/CixATMLou lwYsHzPKg2CKWzYpGWvsOfpDJ27FYtv7bnaxtZ4heUwLZkH1e3uNU7tuODd1BckoTKV/ 4Qv1poQk3rqpKfmzrtr+r3LVrOaNAIkmddNQJ5U/2H5SAmAID0N9iMfR1ubM7c0o8vnF +i0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=4oMK+1d5HOBXCj2AbDNwqsXEhXgsZDm/DTyWNeUXO0Y=; b=nSY26KiH0RjzrMJ2aV32klbSQwV/QKNRTofYl2B1N4aaS9vxlAEEkVd3YkBUMQHn3G VZ03HvmTFpZ1kvJ6Z9hHEAaDQ+2mHRNRIMJwsJDt2OmsLqb5qm+WAOUaUjKezosK1smn D0HE7VARPbAwLUjtqSjLXVZHUQYNYZfxmWc7w1j9b/p05qgslxLjRAGAIS2XUooMBRov qxM1ff/RFSxs0souMqaKKgyaE2jyTgD97C2Be0DpOCZvtJWgIXemc5AfM5hw+hyywPSm lxlk6f2Tu5Z5FBUrLDLK+DMNaowhPDpq1LBz0gOJFWxc3EPKQnYIRT6cyIImpkAGtCqA 7o0g==
X-Gm-Message-State: APjAAAWFhjsJJ8UZG6ydt5HW2hZBor+UKfov8jm5Lhde32yXbZQynf8H TA7EBDbDu1NG5Qerzlj0HpwNJOVAWoWIKGYnZSE6uA==
X-Google-Smtp-Source: APXvYqwHhfqyH4RlDcNvkrzGuEyJBrJVyCMPpkncS2jgaF20LHR3LTbKDXNB6EteEcGPj5zdtktAZo5C5v1Icq4wP/A=
X-Received: by 2002:a05:6602:22c5:: with SMTP id e5mr4568349ioe.302.1578699670017; Fri, 10 Jan 2020 15:41:10 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 11 Jan 2020 00:41:09 +0100
From: Marie-Jose Montpetit <marie@mjmontpetit.com>
In-Reply-To: <3B40E9C6-8442-45EE-A9F6-4FD0BF2E2776@ifi.uio.no>
References: <7FFBC144-5F59-41BD-A47D-D4AFEFA2BE4D@ifi.uio.no> <CAMzhQmN1F_c68bFZoQPhOv_ES0i7CzzSVdUuh5vp6xD_Tzrr1Q@mail.gmail.com> <CAK6E8=ewFWYqijoriSfRVsRmwzeh12o3QRfc23JAzKw87kOAxw@mail.gmail.com> <3B40E9C6-8442-45EE-A9F6-4FD0BF2E2776@ifi.uio.no>
MIME-Version: 1.0
Date: Sat, 11 Jan 2020 00:41:09 +0100
Message-ID: <CAPjWiCTNHYjHPeZ45XHX=vsKM0uR_+E_m=DGkhydX6SK6_S4Vg@mail.gmail.com>
To: Yuchung Cheng <ycheng@google.com>, Michael Welzl <michawe@ifi.uio.no>
Cc: iccrg IRTF list <iccrg@irtf.org>, Keith Winstein <keithw@cs.stanford.edu>, "nwcrg@irtf.org" <nwcrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000009fc07059bd1a935"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/1hk3Cj7WKxxZHnKZFRz3ltQ8EbI>
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 23:41:14 -0000

(NWCRG chair off) We did peps years ago when satellite networks were
impacted by TCP - it used to be our main sales pitch for Teledesic that we
did not need it. But of course other networks needed them for like was all
mentioned in this thread.

Open source PEPs now are really rudimentary and application layer PEPs like
in "I am an app needing fast ACK” are more or less non existent.

What should we do to make progress?

Marie-José Montpetit, Ph.D.
Research Affiliate, MIT Media Laboratory
mariejose@mjmontpetit.com
mariejo@mit.edu

On January 10, 2020 at 4:33:51 PM, Michael Welzl (michawe@ifi.uio.no) wrote:

Hi all,

This is all interesting, but it’s not going in the direction that I hoped.
I mean, these problems are well known and obvious due to the nature of PEPs.
Imagine that connection-splitting PEPs would be a part of the architecture
- known, signaled to, and officially doing what they’re doing, rather than
secretly “cheating”.
Think of something more like an application-layer proxy, for example.

Then, some problems would remain, due to the way these devices operate -
what they do with buffering, what they do with congestion control. That’s
what I was interested in.

I’m getting the impression that problems in the style of those mentioned
below are the ONLY types of problems that people have noticed…. is that
true?

Cheers,
Michael


> On Jan 10, 2020, at 8:51 PM, Yuchung Cheng <ycheng@google.com>; wrote:
>
> On Fri, Jan 10, 2020 at 11:41 AM Keith Winstein <keithw@cs.stanford.edu>;
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 <michawe@ifi.uio.no>;
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 mailing list
>> iccrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/iccrg

_______________________________________________
iccrg mailing list
iccrg@irtf.org
https://www.irtf.org/mailman/listinfo/iccrg