Re: Should the specifications hard-refer to UDP?

Behcet Sarikaya <sarikaya2012@gmail.com> Fri, 04 September 2020 15:36 UTC

Return-Path: <sarikaya2012@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 BEF843A0D9D for <quic@ietfa.amsl.com>; Fri, 4 Sep 2020 08:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 0zSdzqudL8w8 for <quic@ietfa.amsl.com>; Fri, 4 Sep 2020 08:36:49 -0700 (PDT)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 913B13A0DDE for <quic@ietf.org>; Fri, 4 Sep 2020 08:36:48 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id 195so4709775ybl.9 for <quic@ietf.org>; Fri, 04 Sep 2020 08:36:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=y5UcXh2yHGNPeS8AJcdkmVrVnwLuHRmSNfZ0ntuNDbM=; b=Sq1jllJ4fb0k3+hkhkvBi4zCZjlGEyaqQN6O9OKVMFNlL0EJmDwegUN9Zus80ND7Yk yxFFXoEawpR5Zh+5DqyAtQY+hinsqPYdbqiWWYPVu0FEWRTZ1NL0ZNd7EU0/mNv70Ayr 3xTTkH1gURUYzU0HRjP+WzQ4Blq7Xr1M8HqDZpo9bb7w778Vr4GOrklnRj/1fnMjT8ky n9nZ4EIT33HjwHLFG/AP8mQXV/I9ZiLvBxnayZRVNJX2FNxeqvECDnrJ/STmffjhm1qz Upf2FsbIqBA5Dw2p115/TF3D8+PYd6dSEYKL9RnmkybVuMh9cthCblyQ0RULw+FxJwpC Oa7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=y5UcXh2yHGNPeS8AJcdkmVrVnwLuHRmSNfZ0ntuNDbM=; b=CIG3D2fPPzY8du/F2VX8/Y9VTdYVQNRKs0gCcF0xvViQMbu0VBh6gmHNJbiGVAQ9Ur baZQfjLZXaag2nE1R95EPNcQOSGW4FG7+oefCpRK6Ky6Dlm2jhvNJHyIBO+ZZWxlxPAy JoB4Nx7gi0bRlJYSs14/Z84upODi1vF2wY4frViQQGEHe3L874UbH8h8Nh7nC58PAjnv qBqrS36vSFdCz8drBYlzuDsgKpyfRC3Pb8xHCDo3Duhc351pKpc069/RTOVndKV4C7pI tR0Z8rVkm6DlAJyyIfT7oWe3fFsP4uHVyp4ixVs56GVr7FUTyjNxDlI+m5nT0sjFwDSb S3MA==
X-Gm-Message-State: AOAM530gc3DMxSDgOhrJa2XpM/9Bk708X1pxEj5rNAsBp45t2bcDOid0 hhY2g0ZEyzpWqMT9i/jDzBdrYOA6K5wa7q20m6glLJMTl6Q=
X-Google-Smtp-Source: ABdhPJwJwwzL+2L03DH/wCWw1yOvA21jHfbHdIUrx7ArClHHi3rSeHrJ8UOEiwrRBlc2pz59hDxbTPS/o0ChfDAg8+E=
X-Received: by 2002:a25:3f83:: with SMTP id m125mr10537990yba.324.1599233807559; Fri, 04 Sep 2020 08:36:47 -0700 (PDT)
MIME-Version: 1.0
References: <1ce1b329-78c0-42c4-aec7-db19b74742eb@www.fastmail.com> <2bac14c6-a543-454f-a0f3-d77258c2428b@www.fastmail.com> <CALGR9oa1y59huKSx+AY3OnMveN1Bm2xChZ=cbgaw+7jxvxQG5A@mail.gmail.com> <02060b294609539c1be54e89b1510ceb64ce87b2.camel@ericsson.com>
In-Reply-To: <02060b294609539c1be54e89b1510ceb64ce87b2.camel@ericsson.com>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Fri, 04 Sep 2020 10:36:36 -0500
Message-ID: <CAC8QAcfYtS0wDv3nr5Q6rC_ROx2tmTk09WEJ5sU9KYS+3M+4sA@mail.gmail.com>
Subject: Re: Should the specifications hard-refer to UDP?
To: "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000003301805ae7ea3d1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/z93uJj3pdY-2HaOuJ-wWxms23mA>
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: Fri, 04 Sep 2020 15:36:51 -0000

Hi all,

I had a somewhat related question/comment on UDP/QUIC relationship.

QUIC draft mentions UDP in many places, it says QUIC is UDP-based but in
the draft RFC 768 is not listed as a reference informative/normative.

Second, probably more importantly, UDP header has the fields
source/destination port and checksum. These are not mentioned in the draft.
I wonder why?

If these issues were discussed before please give me a link so I can check.

Regards,
Behcet

On Fri, Sep 4, 2020 at 3:35 AM Magnus Westerlund <magnus.westerlund=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi,
>
> (Without my AD hat, instead as a contributor to MASQUE)
>
> On Tue, 2020-08-18 at 11:19 +0100, Lucas Pardue wrote:
> > However, there is a concrete use case in the IETF for exchanging QUIC
> packets
> > not in plain old UDP datagrams - MASQUE [1]. Perhaps that could be a
> suitable
> > venue for some of the things you have in mind?
>
> But, MASQUE will provide UDP/IP semantics for a end-to-end QUIC connection
> over
> MASQUE. As mentiond by Martin, QUIC is dependent on some lower layer
> functions
> and that is why I am trying to start a discussion about the need to
> preserve
> these services/functions in MASQUE. See
> https://datatracker.ietf.org/doc/draft-westerlund-masque-transport-issues/
>
>
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>