IETF Logo Mail Archive

Re: [Masque] HTTP DATA frames for HTTP CONNECT?

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 21 October 2020 10:12 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9923A15A7; Wed, 21 Oct 2020 03:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rgXXy4HQkdMX; Wed, 21 Oct 2020 03:12:16 -0700 (PDT)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 1047C3A116D; Wed, 21 Oct 2020 03:12:15 -0700 (PDT)
Received: by mail-yb1-xb34.google.com with SMTP id l15so1317449ybp.2; Wed, 21 Oct 2020 03:12:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=4pEdoHzE+4CWRsUBsqAiHXxW+RKXV4DNDnYn6nMYtd0=; b=pswUWF5um1/bjLHSqco0ZkQL90a3oQi0vFsvGsXL4HqK3s4Qk8nEtQZK22E620s9RZ fotLWx3zvzVL7qH7hZRTeV8sTSuDgd6LU70uDRntm8PLcRTRnaT3do986b9diDG36ch9 kuRmu7cerbpsztOPGJWeGy8qq5HPSdNUCbEol9AiHtvHmMx+vV5J2HsXn8Hf1QIWlVnr eqGLpToIhdE+e4MuZAtlhi+OdV1onUVuNjgUT2PTBAAWB/4amF9MseXSBbMQ9W8saBm5 ARV7+95s/EN6dC+RTVHA/cL6NPfVGwFIk9aswXBg8xfkjJaDUDDL9r+Zs466nOio/cdX GwcQ==
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=4pEdoHzE+4CWRsUBsqAiHXxW+RKXV4DNDnYn6nMYtd0=; b=pnqpbMQq5ZaPZTgR43VK5HEXDwZ2cLAH/1INgNLjEpEhAU1MYdokAFX995xxBcY5la 7bgo2ZZFS0xd8TZvsdPooDj1zPykQizz1qtbgxf676q4jnu47DgjFr8TUY3Ac3hRz8fy PdIeopAhd9HC/lrnnivUbNNBSr2f4oJx/Ek/BRPawaRecZZBkR6P9pOvWeHlgQxDP1RJ 4ulf/qDCPKjhPkBjQ0POPOrXLiqcxscHosn2ZoScbR8mByPk6tH4dZmc3MuHpBHF0Krl Rl4/KZWE3fygloQB8gxj9ud6zKcU8lORjPSnm/QMJqcv17+aWxn5nng0urjaVcK9cB4k jYgw==
X-Gm-Message-State: AOAM531EAZLNkqBVkuqxIhsgJLFmSx8Wwnl/mFCPpp3nJEovemR13RTn ONQQ8pFukpuFa8rr6bd1V+6VdeqcddyuEJ7GAgw=
X-Google-Smtp-Source: ABdhPJyMnh0hqWSZSAapOebvm6cHVHt4RJkJdK6ZmXDG+qNV32bdnfFt1lg3BSQeI8GqxrbVqjg7GfVbiefkwWBcxpA=
X-Received: by 2002:a05:6902:72d:: with SMTP id l13mr4202276ybt.378.1603275134985; Wed, 21 Oct 2020 03:12:14 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 21 Oct 2020 03:12:14 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CANatvzwPT3gVu0kg6oRkuCMrkU6RwWEXwkZsfvWZe_2qwGDHAg@mail.gmail.com>
References: <A92255DF-F477-4DE6-9AA2-33373959E792@ericsson.com> <MN2PR22MB20934245C43D7DDA5BC8F5D4DA020@MN2PR22MB2093.namprd22.prod.outlook.com> <MN2PR22MB20933D2E25F5425EA848E0D7DA020@MN2PR22MB2093.namprd22.prod.outlook.com> <CAPDSy+62-q83vK0zuPs9kQXP4Akm6KX5Khp1q4PD_2wDpacKNw@mail.gmail.com> <A50ACE49-E067-44ED-988D-B70E261482ED@ericsson.com> <CALGR9oa9_OapmpK721SQG4iOboJiTgnmNfSEO9Rwb4Mq110bNA@mail.gmail.com> <2CEC578A-32A5-45C4-B3A9-F615C9EB9DBE@ericsson.com> <CALGR9obHNAvKgTM97uhK+KAEf1ua6D3dW5x2HUOoV0QVUROY9w@mail.gmail.com> <B92228CD-6AA0-40BE-AFA3-223AD17285F2@ericsson.com> <CALGR9oZKJ7vbmZDh74k0gsX2r4nkeEE3VRrrywozT0iqQRGfGA@mail.gmail.com> <CAKcm_gNeRs9zCyEFweiwPFV_wYXf4LAjYE9q+AoGEnqnTjeq=w@mail.gmail.com> <CAKcm_gPBjs1Dwx8L8=9g_gK79Ey29LX6Y-nFBYhfspP66VJ06Q@mail.gmail.com> <CALGR9oZERzWy6si5dtrgdcbMv4WGhAGTzV7TzjNfT_J_XKHApw@mail.gmail.com> <CANatvzwPT3gVu0kg6oRkuCMrkU6RwWEXwkZsfvWZe_2qwGDHAg@mail.gmail.com>
MIME-Version: 1.0
Date: Wed, 21 Oct 2020 03:12:14 -0700
Message-ID: <CAN1APdczL8+ib2q_VJby6LMSMDArfYzOdgGMjMuYUbru_XB6Hw@mail.gmail.com>
Subject: Re: [Masque] HTTP DATA frames for HTTP CONNECT?
To: Lucas Pardue <lucaspardue.24.7@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, Mike Bishop <mbishop@evequefou.be>, QUIC WG <quic@ietf.org>, Ian Swett <ianswett@google.com>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, MASQUE <masque@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e5e85e05b22b94af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/XQEKo4dn8favLuyPqPfJWebI7AU>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2020 10:12:17 -0000

So I am new to this concept of masque, but why do you need to have H3
involved in proxying if the objective is to proxy arbitrary applications as
opposed to acting as as replacement for existing HTTP tunnels?

There is a quite a bit of complexity in H3 that is not necessary when using
QUIC for general purpose proxying.

As to the DATA frame, my intuition tells me that it is probably useful to
retain a concept of tunneling over a single HTTP connection for semantic
reasons, such as an endpoint that is written for HTTP and not for QUIC, but
this need not be related to MASQUE.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 21 October 2020 at 03.32.22, Kazuho Oku (kazuhooku@gmail.com) wrote:

I agree with others that we do not need to revisit the issue we discussed
in #1885. The conclusion there was that HTTP/3 will always use
application-layer framing.

Regarding how we might fix the issue *in the future*, my preferences goes,
as stated in one of the issue comments, to adding a transport-level
extension that allows "messages" (instead of bytes) to be sent over a QUIC
stream, then use that to send frames in HTTP/3. Doing so reduces the wire
overhead for any frame being sent, reduces the total complexity.

But what we should do *now* is ship QUIC and H3, they do not have to be
changed.


2020年10月21日(水) 8:07 Lucas Pardue <lucaspardue.24.7@gmail.com>:

> An extension seems entirely reasonable to me.
>
>
>

-- 
Kazuho Oku

v2.23.0 | Report a Bug | By Email