Re: [Last-Call] Tsvart Last Call assignment: draft-ietf-masque-connect-ip

David Schinazi <dschinazi.ietf@gmail.com> Thu, 23 March 2023 20:37 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346D6C13AE57; Thu, 23 Mar 2023 13:37:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 EaLXsuwgvQn6; Thu, 23 Mar 2023 13:37:23 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 464FDC13AE56; Thu, 23 Mar 2023 13:37:23 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id eg48so91811442edb.13; Thu, 23 Mar 2023 13:37:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679603841; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2Ym63ZsJflRYf+egFjtsxmTBavZBPZz5yQJKvyGYOy8=; b=okHmD40ZDLc1bDpCyOqw6/x/jso2OQQ9K2fAzDNarq6iQY1nFglj7ey7kXFGkuQ2dG eTOZS5sY/KXKMbbemgnIpNY8+SGN01qllXag2xlz74/ADoZsltZXHx8WKLQJ8+BmY8o6 +P99rnrlUOPW0MbXRxHl8jurlgXNKCtOJFp0BI1V6BXGe+EZ0fm2RYFhdVgdQlf+wU+8 peDgji9JjGcWmNCU5HxEncQdEJXBtE4L4B74EESeNdGmazBLMiv0AnxbzVuwRUnWvr19 1QOcRW04qkYOuVEgk5fkhE++ZQSlS7/svcCMuM9MFSTnMSCaiBUY3atvi0R3os4TotlO s7yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679603841; h=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=2Ym63ZsJflRYf+egFjtsxmTBavZBPZz5yQJKvyGYOy8=; b=FPNDIV2+/v0LaY11IULk7WuWHB0VHJA3i1cfP/k3huvhRxpn9rXtotE7s4i2T04sYU FqWUdspw7nihEDqUjE3ef4bH3Z5oKjaSLfbV47a0nMCMGJTuLZO+4Jh5B1qZ0sgbjzyw D+cu3w3HJpKoYlBAu6OwNUk1aWcbTgEYRQ1FG4yeDVVgTIg/js574qeM02qIFA3R22D5 ujLVYZ1Nf+WVvfPfPAe4I76sO/tPxu6JN5VoH0LacCXtUsMbOvxadzZFCV3Zq7x7s5vL Hqlgv1hafEiFksn3CeRueOA1129t0H/y5NEmcqyAn3g0XSGw0yA2GQcHRpzdYATONffc iBKA==
X-Gm-Message-State: AAQBX9eP0s6gYcCGAd+xRzTTFy87SldD6JR9Eno9fSjRJO8v5z2uC/K8 rfGr2i6yUsbqKE1qQp1DzWPY3SvvtrpZ8bDJhSxwPyEyVLg=
X-Google-Smtp-Source: AKy350bchB3+3Fe6lwdr/VDIJ+DFt8AtidN3SBxA7Csca7bnne/Avq6qvEmvaF8skeu0J7N9HLsi2QBWcX4Jj6bWYE8=
X-Received: by 2002:a50:cd47:0:b0:4fc:532e:215d with SMTP id d7-20020a50cd47000000b004fc532e215dmr382614edj.6.1679603841330; Thu, 23 Mar 2023 13:37:21 -0700 (PDT)
MIME-Version: 1.0
References: <167809217700.46817.1953496271912318949@ietfa.amsl.com> <4e76d590-1851-8ed9-a2bf-e1dcb9465188@bobbriscoe.net>
In-Reply-To: <4e76d590-1851-8ed9-a2bf-e1dcb9465188@bobbriscoe.net>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Thu, 23 Mar 2023 13:37:10 -0700
Message-ID: <CAPDSy+5da+mJveohb2gvV=K+_DhPwFgt86t-0XUh4OctZnPF4w@mail.gmail.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: Zaheduzzaman.Sarker@ericsson.com, martin.h.duke@gmail.com, wes@mti-systems.com, "tsv-art@ietf.org" <tsv-art@ietf.org>, draft-ietf-masque-connect-ip.all@ietf.org, last-call@ietf.org, MASQUE <masque@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005371a805f7973e72"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/euiRe4uGOuzEcWjn5mjmHlvSfko>
Subject: Re: [Last-Call] Tsvart Last Call assignment: draft-ietf-masque-connect-ip
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2023 20:37:29 -0000

[ + usual email lists ]

Hi Bob, thanks for your review! Responses inline.
David

On Thu, Mar 23, 2023 at 2:27 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:

> masque-connect-ip authors,
>
> My apologies. I do still intend to send in my tsv-art review of
> masque-connect-ip, but I'm running over a week late now.
> (It seems that my turn for review comes up more often than not just
> before the IETF meeting.)
>
> I've got a number of detailed comments. But the main thing that's taking
> time is thinking through the potential interaction problems there might
> be when running a connectionless protocol as generic as IP through a
> connection-oriented tunnel. Particularly given there might be another
> connection-oriented protocol within the inner IP datagram.


FWIW, the issue here isn't the fact that anything is connection-oriented.
I don't think there is any problem to be had by running connectionless
protocols over connection-oriented ones or vice versa. That said, what
can make things interesting performance-wise is whether there are
nested congestion controllers or nested loss recovery mechanisms.


> This probably
> needs a section akin to §6 of RFC9298, but I'm trying to think more
> widely of problems that might not have been considered when the IP
> packet was constrained to only encapsulate UDP.
>

That's a fair ask. Mentioning what we know about nested loss recovery
and about PMTUD can't hurt. I don't expect there to be much here in
addition to what he had in s6 of RFC 9298 though, since the switch
from UDP to IP won't change much (modulo IPv6 minimum MTU, which
is already covered).

I don't see any place for discussion of this in the draft, so I wondered
> whether there has been ML discussion somewhere that worked through all
> this and decided there were no issues. If you could point me to that it
> would greatly help me.
>

We had some good WG conversations about MTU here:
https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/45
https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/62
The discussions around performance happened around RFC 9298,
but we can copy that text here.

This email was not sent via the review tool, so apologies if I haven't
> got the email distros correct.
>
> Bob
>
> On 06/03/2023 08:42, Magnus Westerlund via Datatracker wrote:
> > Last Call review of: draft-ietf-masque-connect-ip (no specific version)
> > Deadline: 2023-03-15
> > Pages: 36
> > Requested by: (System)
> >
> >
> https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/reviewrequest/17185/login/
> >
> > Magnus Westerlund has assigned Bob Briscoe as a reviewer for this
> document.
> >
> >
> >
> >
> >
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>