[Taps] TCP connection grouping

Michael Welzl <michawe@ifi.uio.no> Fri, 14 September 2018 11:51 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9247130EBD for <taps@ietfa.amsl.com>; Fri, 14 Sep 2018 04:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 PUPJSt5ikNZ2 for <taps@ietfa.amsl.com>; Fri, 14 Sep 2018 04:51:55 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 B6BCD130EAC for <taps@ietf.org>; Fri, 14 Sep 2018 04:51:55 -0700 (PDT)
Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1g0mdd-000COL-9D; Fri, 14 Sep 2018 13:51:53 +0200
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1g0mdc-0007Ff-II; Fri, 14 Sep 2018 13:51:53 +0200
From: Michael Welzl <michawe@ifi.uio.no>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <2B2155D7-DD12-4637-9CB4-16E14CBF1831@ifi.uio.no>
Date: Fri, 14 Sep 2018 13:51:51 +0200
Cc: taps WG <taps@ietf.org>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no;
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: CA698ACB37F6A07987208B54A1C6507C21EC1936
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/b8_muz2gHttJkR2cWL_ahzimKLk>
Subject: [Taps] TCP connection grouping
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Sep 2018 11:52:12 -0000

Hi,

Ekr asked for it, but I think this could be of interest to more in TAPS, even though it's nothing that today's protocols can do:

Ekr's question was "how do you group TCP connections?".

Safiqul and I worked on this - with lightweight code that combines the congestion controls of multiple TCP connections, we were able to get a behavior that resembles a single transport connection with multi-streaming: it acts as if it's one connection in terms of congestion control, and allows to assign a precise share of the used capacity to the individual connections in the group.

The algorithm is described here:
http://safiquli.at.ifi.uio.no/paper/tcp-ccc-techrep.pdf

An obvious issue with the idea is that the TCP connections can take different paths, while we assume that they _always_ share the same bottleneck (*). One idea, described in the document above and implemented and tested by us, was to encapsulate multiple TCP connections within one UDP 5-tuple.

More documents, and code are available at:
http://safiquli.at.ifi.uio.no/tcp-ccc/

We also once presented a draft about this:
https://tools.ietf.org/html/draft-welzl-tcp-ccc-00
... to ICCRG, but then dropped this work due to lack of interest. If interest would pick up again, we'd be quite happy to continue this.

Cheers,
Michael

--

(*) Note the subtle difference with MPTCP, which is designed with the assumption that they *might* share a bottleneck - this leads to quite a different coupling algorithm).