Re: [tsvwg] New Version Notification for draft-herbert-tcp-in-udp-00.txt

Tom Herbert <tom@herbertland.com> Mon, 14 August 2023 15:37 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC24C1519AB for <tsvwg@ietfa.amsl.com>; Mon, 14 Aug 2023 08:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5d0OwRScACc for <tsvwg@ietfa.amsl.com>; Mon, 14 Aug 2023 08:37:52 -0700 (PDT)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19447C14CE4F for <tsvwg@ietf.org>; Mon, 14 Aug 2023 08:37:52 -0700 (PDT)
Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2680a031283so2502433a91.3 for <tsvwg@ietf.org>; Mon, 14 Aug 2023 08:37:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1692027471; x=1692632271; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GUvaqA/TctuRlfsAVfGNHMseCKkTuj4xBAGRSLElXw8=; b=OmNi2YM9BElKuL6KPgR8P2u5ohiDbJn73xOOFOEsFrC8rSYPV5WBciyvsPGcNhgKmV XX6ilBfyeCJtPb+ZXbJc94oiC1BnJAMA6gwYcM3bfWKF9ki+uYLB0KK8+cHwslhUU/Yr IzhmuSha/bCo04kSZALTMSmMVkh2Jg1S1gd/KXOcnCXJ2jUbIPm49vLiAzZWeb1r5GhB GsVxLQ1RLNNS+Nx6PUI3uL4TsM5a+7Cc/WXJ88zZGFLFpREXaG0lmvjL2jipjTR3ez/A a2A4oY4QTm9AzlrKIYJxobuQmN9Rn0XnkBgZQWnXIeYhrHG8ynMfIKs1Dy/4UrlRCXTG 5vkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692027471; x=1692632271; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GUvaqA/TctuRlfsAVfGNHMseCKkTuj4xBAGRSLElXw8=; b=jb4fT9tx52tB5rm395jsFi81zxdoJ/hbtvalei4Nh74ZI3065SasBiVHcZFSdb/Ya1 3z1Ybohmr8SmUrER2CFcYcq8cSoh+FWTqVlHcgbw1Iacfm8AeWgTzjLSNLZd3h8dEDZY JK5GL36kd9gSOdgYx8xKvTmMzZO8kBI5riD6NCTpYGxsaeEZwF0yXrETbXvNSKs8hFeo UhCegVOq7smg/YQUtnjel4WeuKybbGoweAXX/hvztxNGEe0ry8TYRue0NOptgKYOC6SA CdfFhum95OkDgD6lMI/lBXOa05UqqZjMDDWVQ2LNTVfVVJz+bW/ZfHMc7njrhsmSBhnU 3mvg==
X-Gm-Message-State: AOJu0Yzwb0Yr28vqyv638A07GvC/aRkOsyZs/CHhZWSrkeu1d2SZZ8US gekswnEkZthqGgU5GI74qWS0o1ZW84RvXOQCj8WoOA==
X-Google-Smtp-Source: AGHT+IHiOgDjxw3bCHmdq0MoC7sOQaOFduyIXOWjmuIOY5KxrkotBF0GhTZfAAD6Zg5GhDUOhUoinK9iFzK1RKKdkI4=
X-Received: by 2002:a17:90a:fee:b0:262:dd2c:54fc with SMTP id 101-20020a17090a0fee00b00262dd2c54fcmr6352396pjz.42.1692027471409; Mon, 14 Aug 2023 08:37:51 -0700 (PDT)
MIME-Version: 1.0
References: <169179236696.36797.6075120394432124931@ietfa.amsl.com> <CALx6S36-4d=48UMKusabbRnQiZ7B=0uTvd-Oksrnwj9bxN7xmg@mail.gmail.com> <F3861EFB-4982-48BB-9C2C-4FC200DBD4E5@ifi.uio.no>
In-Reply-To: <F3861EFB-4982-48BB-9C2C-4FC200DBD4E5@ifi.uio.no>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 14 Aug 2023 08:37:40 -0700
Message-ID: <CALx6S36r3U0z-_8LjagQZNXK-ndQRFw+SS9mZxo6VM170uCGZw@mail.gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
Cc: tsvwg <tsvwg@ietf.org>, safiqul.islam@oslomet.no
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/BeVL1dRB_T8mKD5N1FXDZ6mcd2Q>
Subject: Re: [tsvwg] New Version Notification for draft-herbert-tcp-in-udp-00.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Aug 2023 15:37:56 -0000

On Mon, Aug 14, 2023 at 12:30 AM Michael Welzl <michawe@ifi.uio.no> wrote:
>
> Dear Tom, dear everyone else @ TSVWG,
>
> I’m (somewhat obviously, if you see what I write below) strongly in favour of this draft - and also happy to help with it.  This idea (in some form) has been proposed multiple times over the years, and never took off; perhaps the time is now right?
> Below is some material.
>
>
> Earlier similar proposals:
> ====================
>
> The first appearance I know of:  https://datatracker.ietf.org/doc/html/draft-denis-udp-transport-00   (likely it isn’t the first to exist!)
> Much later:  https://datatracker.ietf.org/doc/html/draft-cheshire-tcp-over-udp-00
> and finally, our own effort:  https://datatracker.ietf.org/doc/html/draft-welzl-tcp-ccc
> which I presented in ICCRG, at IETF-95:  https://folk.universitetetioslo.no/michawe/research/publications/ietf95-iccrg-tcp-in-udp.pdf
>

Hi Michael,

Thanks, for the references! It's not surprising that it keeps recycling.

>
>
> Work showing benefits:
> ===================
>
> There may be several reasons to do this. Our own interest, back then, was in implementing (single-path!) coupled congestion control in the style of RFC 8699 for TCP.
> Such coupling can only work when we know that the connections traverse the same bottleneck - either via measurement (RFC 8382), or because, as with this encapsulation, they carry the same outer 5-tuple.
> Our coupling is lightweight, as it doesn’t require re-vamping the entire congestion control code like the congestion manager. It still yields all the benefits of a single congestion control instance, just like a multi-streaming transport would have: lower latency and packet loss from less competition, and the ability to execute precise prioritization.
>
> This was done in the context of Safiqul Islam’s Ph.D. thesis. These publications describe the benefits:
>
> Safiqul Islam, Michael Welzl, Kristian Hiorth, David Hayes, Grenville Armitage, Stein Gjessing: "ctrlTCP: Reducing Latency through Coupled, Heterogeneous Multi-Flow TCP Congestion Control", IEEE INFOCOM Global Internet Symposium (GI) workshop (GI 2018), Honolulu, HI, April 2018. DOI 10.1109/INFCOMW.2018.8406887
> https://ieeexplore.ieee.org/document/8406887
> Preprint: https://folk.universitetetioslo.no/michawe/research/publications/ctrltcp-infocom-gi-2018.pdf
>
> and, focusing on the benefit of ramping up cwnd faster when joining other connections:
> Safiqul Islam, Michael Welzl: "Start Me Up: Determining and Sharing TCP's Initial Congestion Window", ACM, IRTF, ISOC Applied Networking Research Workshop 2016 (ANRW 2016), Berlin, Germany, 16 July 2016. DOI https://doi.org/10.1145/2959424.2959440
> https://dl.acm.org/authorize?N16076

Would you like to provide some text for the draft in motivation and
previous work?

Thanks,
Tom

>
>
> Code:
> ======
>
> We have ( ...somewhere. I’ll be happy to dig for it if someone wants it! ) a FreeBSD implementation of both the congestion control coupling and the encapsulation, and it’s described in more detail here:
> https://www.duo.uio.no/handle/10852/51926
>
>
> Cheers,
> Michael
>
>
>
> On 12 Aug 2023, at 00:22, Tom Herbert <tom=40herbertland.com@dmarc.ietf.org> wrote:
>
> Hi,
>
> This is a draft describing how TCP could be encapsulated in UDP. This
> would be useful if UDP really is to be the "new network layer" and we
> want to use UDP Options with TCP to carry network layer options.
>
> Thanks,
> Tom
>
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Fri, Aug 11, 2023 at 3:19 PM
> Subject: New Version Notification for draft-herbert-tcp-in-udp-00.txt
> To: Tom Herbert <tom@herbertland.com>
>
>
>
> A new version of I-D, draft-herbert-tcp-in-udp-00.txt
> has been successfully submitted by Tom Herbert and posted to the
> IETF repository.
>
> Name:           draft-herbert-tcp-in-udp
> Revision:       00
> Title:          TCP-in-UDP Encapsulation
> Document date:  2023-08-11
> Group:          Individual Submission
> Pages:          10
> URL:            https://www.ietf.org/archive/id/draft-herbert-tcp-in-udp-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-herbert-tcp-in-udp/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-herbert-tcp-in-udp
>
>
> Abstract:
>   This document specifies a method of encapsulating TCP protocol
>   packets within UDP headers.  TCP-in-UDP is useful in situations where
>   network capabilities specific to UDP can be leveraged for TCP
>   packets.
>
>
>
>
> The IETF Secretariat
>
>