Re: [tsvwg] Advance notice on request to poll TSVWG for adoption of draft-kaippallimalil-tsvwg-media-hdr-wireless-03
Tom Herbert <tom@herbertland.com> Sat, 28 October 2023 15:27 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 E9751C151536 for <tsvwg@ietfa.amsl.com>; Sat, 28 Oct 2023 08:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.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_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 jgNeyH6XYCSl for <tsvwg@ietfa.amsl.com>; Sat, 28 Oct 2023 08:27:00 -0700 (PDT)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 07F62C14CE54 for <tsvwg@ietf.org>; Sat, 28 Oct 2023 08:26:59 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-5b9390d6bd3so1547772a12.0 for <tsvwg@ietf.org>; Sat, 28 Oct 2023 08:26:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1698506819; x=1699111619; darn=ietf.org; 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=0/HPoyZXXJeU2OHvBtWDj6/sPhBakkGmpOeyOTYQqEk=; b=JPusFWkCHvE8tUcaLsT5q6UitFRG33E1prsaiHETugmLyiLjFBMWn6hJEhCk8Lv8Er 7C9XQbjz1xnnLl5Q+b7iymtyMXbJRIp2JFIycUWQp6gxfF+plnMksws7atnUYiY/wooe YLm7KaH2qKNNcdMxIDZ2ZGAt5AsJfVSjZsomvP4f9x+6nKsnyhQivqKGBnVB8BaEjYu7 b4GvYlvwUwZTp1ccW9527RhPoZUiXC0y4gNSs4NTn/MRu43lmOx0pnuHnvRnyVAVWNvH nvoGxPD3JWA6Jh4sT6LkZy/xZSM/GmDWtya/OvJ2zu94Gy4OXa/LD7nbreV5JyNqUpDN 3F+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698506819; x=1699111619; 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=0/HPoyZXXJeU2OHvBtWDj6/sPhBakkGmpOeyOTYQqEk=; b=ZIVs9/gyvYFbRgnQ6RfimVmlX2HzLBhY5RYTyz48gLHbqyoc1kPs2LruYub94kXd+O ijHrN/6GgFJrvofbslv85VT8/vwnRVQ2IgHyMGoxHqMp0s39MQUquEOSWojrZUma0l/D Ux1mrrwE9vXohm4bA04GKFVBaOb04vHjFKF0q6Bdnk44ZT/eT2cJZTrhGDLOQcPT5xfy wRX5r5/kWgPBsFU2BpcrQ/c8EqszMjdF17NC1bparGrE0ifiGSI5xQEISQvOYrpA7oeV m8goXX2Yv8/ZSPOyzo4QD/rGWnIoH38cZidOw2PGV4LM2QmXqOXwyH2MclfnYXlTFJud 02fA==
X-Gm-Message-State: AOJu0YyD39lvyUurddvavEnu5/5X4x+Azi5o0CN5HEqLImMyYSN+/6WW slgxxXXOskBj/mTLzNGMGSeQVXe+UwE0XRsFlyo1962Iwv1z/Njbymc=
X-Google-Smtp-Source: AGHT+IEnxO+nPfkBsjTRd4lJKvMlg5H2sctWkWm4w4L4cPgOyiMtBdO/oz4303TjchGTChBfofJcu2GQjZv+3FoeUfk=
X-Received: by 2002:a17:90a:12c5:b0:280:23e1:e4dd with SMTP id b5-20020a17090a12c500b0028023e1e4ddmr2948511pjg.17.1698506818999; Sat, 28 Oct 2023 08:26:58 -0700 (PDT)
MIME-Version: 1.0
References: <CAKKJt-cr7e5pUR=zxaO35Tjn2d=oM-xBvpdyGop+xaLOG-_U9g@mail.gmail.com> <CALx6S34__pK8tTM08fzTAxx=_dAM4MsEwH1-RL7eXGrCdtnR1Q@mail.gmail.com> <7E9754EA-9A11-49F6-A3F2-3F5E630CEBA6@strayalpha.com> <SN4PR13MB5311CF46AF56025360252C3AE8DCA@SN4PR13MB5311.namprd13.prod.outlook.com>
In-Reply-To: <SN4PR13MB5311CF46AF56025360252C3AE8DCA@SN4PR13MB5311.namprd13.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 28 Oct 2023 08:26:49 -0700
Message-ID: <CALx6S378sTLPzis3=qB07OvojjbCTV8St21-31_oZzsUNZ-5vA@mail.gmail.com>
To: Kaippallimalil John <john.kaippallimalil@futurewei.com>
Cc: "touch@strayalpha.com" <touch@strayalpha.com>, tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/_Xkq8DpIldPTK7AxZifH5HvMWj0>
Subject: Re: [tsvwg] Advance notice on request to poll TSVWG for adoption of draft-kaippallimalil-tsvwg-media-hdr-wireless-03
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: Sat, 28 Oct 2023 15:27:04 -0000
On Fri, Oct 27, 2023 at 4:35 PM Kaippallimalil John <john.kaippallimalil@futurewei.com> wrote: > > Hi Tom, Joe, > > > > With regard to the concerns from Tom and Joe, the behavior needed is outlined in slide 3 of: https://datatracker.ietf.org/meeting/118/materials/slides-118-tsvwg-sessa-92-media-header-extensions-for-wireless-networks > > > > IPv6 HBP does not currently provide the capability needed: > > IPv6 HBH (MED in this case) is provisioned in the “Application Provider” (AP) domain. And the service provided in the same domain (AP domain in this case) > But that is not what we want. MED is inserted by AP domain, and read in the wireless provider domain. Hi John, Can you clarify what "inserted" means in this context? (the word has confusingly been used in different contexts). For instance, there are three uses I know of: 1) A packet was created by a hosts with the data ("inserted" probably isn't the best term for this) 2) A packet is encapsulated inflight and the data is attached to the outer headers 3) The data is inserted into a packet while it's inflight with (no encapsulation) #1 and #2 are generally acceptable (technically, in both cases a host is creating the packets so HBH options or UDP options can be set in the packet safely). #3 is a bit more controversial, but there have been proposals for this like inserting a segment routing header in packets in flight. Please also clarify the processing of the wireless node. 1) Is the wireless always the destination endpoint of UDP encapsulation? If so then it would be appropriate for it to process UDP options in the encapsulation since it's the destination of the encapsulated packet 2) Does the wireless node is inspect the UDP options in flight as an anonymous router in the path that forwards packets and isn't the destination of the packet? In that case, I think using UDP Options is problematic (or putting the information into the UDP payload like SPUD proposed) > The data in MED is sent per packet and FAST allows data to be changed on a per packet basis for flow. If the modifiable variant of the FAST HBH option is used then intermediate nodes can change the data inflight. > Every router on path is going to read/process the IPv6 HBH option. This is also not what is intended. RFC8200 has relaxed the requirements of RFC2460 so that routers may or may not process Hop-by-Hop OPtions. draft-ietf-6man-hbh-processing and draft-ietf-6man-eh-limits make further clarifications to make HBH practical. > Only the wireless router acting on behalf on the client, with explicit provisioning (session setup, policy in figure) needs to read. That's the same expectation we have in FAST. Only an ingress router into a network is expected to process a ticket in HBH options. > > > > The difference will be more obvious when (if) we need to consider encrypted metadata. FAST allows for the signal to be encrypted. > > (PS: In this draft, we don’t see the need to encrypt the metadata as the signals are purely advisory and does not leak content or user information.) Maybe, but for a proposed standard you'll need a strong justification if that's the answer :-). > > However, if we decided that encryption was needed: > > With FAST/ IPv6 HBH, the key management is for the Application Domain (AP) to read, not the wireless domain. (otherwise involves complex multi-domain key agreements). Just like UDP Options, FAST and IPv6 HBH are just carriers of information. There's no semantics enforced on the content. So any data that is carried in UDP Options could just as easily be in HBH options. The difference is about who is permitted to process the information: UDP Options can only be processed by the destination, HBH options can be processed by any, all, one, or no nodes in the path. > With MED, the client to Wireless-CP/Policy signaling can install the MED keys in a simple manner (in 3GPP domain, that would just be small extensions) That's independent of the information carrier, so the same infrastructure will work just as easily with HBH options. > > > > But just to be clear, in the draft, the metadata (MED) and its handling is completely separated from the container/transport (UDP options). Exactly, that's why HBH options can be substituted for UDP options in the design with no semantic differences in the content. > > If IPv6 HBH or other transport can evolve to support this kind of handling needed, then the draft can be updated to use MED and that (other) transport. > > The key aspect in the draft is the metadata (MED) and how it should be processed on path. Yes, I like those aspects, and the sentiment that a draft like this should focus on the semantics and processing of the data aligns with my view. This draft is a good use case of host to network signaling, but there are others like draft-reddy-tsvwg-explcit-signal (which also proposes to use UDP options as the carrier) and draft-ravi-ippm-csig (which proposes using L2 to carry the signal). With the potential benefits of collaboration between applications or hosts and the network, I believe we are going to see even more proposals. In host to network signaling, there are two parts: the carrier of the signal, and the content of the signal. IMO, if we define a common generic and extensible carrier for host to network signaling, then the various proposals in the area could focus on the semantics and processing of the content and not worry so much about the carrier protocol. Tom > > > > Regards, > > John > > > > > > From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of touch@strayalpha.com > Sent: Friday, October 27, 2023 5:44 PM > To: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org> > Cc: tsvwg <tsvwg@ietf.org> > Subject: Re: [tsvwg] Advance notice on request to poll TSVWG for adoption of draft-kaippallimalil-tsvwg-media-hdr-wireless-03 > > > > +1 ;-) > > — > > Dr. Joe Touch, temporal epistemologist > > www.strayalpha.com > > > > On Oct 27, 2023, at 2:55 PM, Tom Herbert <tom=40herbertland.com@dmarc.ietf.org> wrote: > > > > On Fri, Oct 27, 2023 at 2:26 PM Spencer Dawkins at IETF > <spencerdawkins.ietf@gmail.com> wrote: > > > Dear TSVWG, > > We have requested a slot during the IETF 118 meeting to propose that the co-chairs poll the working group for adoption of https://datatracker.ietf.org/doc/draft-kaippallimalil-tsvwg-media-hdr-wireless/, as a basis for further work. > > The chairs have given us a 15-minute slot during the Thursday TSVWG session. > > Face-to-face meeting time is precious, so we thought it would be helpful if we invited people to look over the draft, and let us know if you see significant impediments to adopting this draft. That would reduce the time we need in the meeting itself. > > > Hi Spencer, > > I believe that the use of UDP Options to carry information that is > processed by intermediate nodes is a significant impediment to > adoption. > > > From the draft: "The Wireless Node is responsible for forwarding > > packets to the Client over the Wireless Network. The Wireless Node > inspects metadata but does not alter the UDP option." > > There was discussion on the list and I believe that there is general > consensus that UDP Options are neither designed nor intended to carry > network layer information like this. They are for carrying End-to-End > transport layer information. > > IMO the proper alternative for carrying network layer information is > Hop-by-Hop Options like in FAST > (https://www.ietf.org/archive/id/draft-herbert-fast-04.txt). > > Tom > > > > > > > > As a reminder, > > This draft has been presented at IETF 116, 117 and now 118 > We had considerable discussion at previous IETF meetings and on the TSVWG mailing list > That feedback has been uniformly helpful, and we've taken it into consideration in the -03 update. > Adoption has been discussed previously at IETF 117 > > The updated draft (-03) is described in slides that are uploaded at https://datatracker.ietf.org/doc/draft-kaippallimalil-tsvwg-media-hdr-wireless/ > > A diff from version -02, discussed at IETF 117, is here: https://datatracker.ietf.org/doc/draft-kaippallimalil-tsvwg-media-hdr-wireless/ > > Please feel free to follow up on this mailing list, or privately with the document authors. > > Best, > > Spencer > > > >
- [tsvwg] Advance notice on request to poll TSVWG f… Spencer Dawkins at IETF
- Re: [tsvwg] Advance notice on request to poll TSV… Tom Herbert
- Re: [tsvwg] Advance notice on request to poll TSV… touch@strayalpha.com
- Re: [tsvwg] Advance notice on request to poll TSV… Kaippallimalil John
- Re: [tsvwg] Advance notice on request to poll TSV… Kaippallimalil John
- Re: [tsvwg] Advance notice on request to poll TSV… Sebastian Moeller
- Re: [tsvwg] Advance notice on request to poll TSV… Tom Herbert
- Re: [tsvwg] Advance notice on request to poll TSV… Tom Herbert
- Re: [tsvwg] Advance notice on request to poll TSV… C. M. Heard
- [tsvwg] (metadata) RE: Advance notice on request … Kaippallimalil John
- Re: [tsvwg] Advance notice on request to poll TSV… Sebastian Moeller
- Re: [tsvwg] Advance notice on request to poll TSV… Sebastian Moeller
- Re: [tsvwg] Advance notice on request to poll TSV… C. M. Heard
- Re: [tsvwg] Advance notice on request to poll TSV… Tom Herbert
- Re: [tsvwg] Advance notice on request to poll TSV… Alex Burr
- Re: [tsvwg] Advance notice on request to poll TSV… Sebastian Moeller
- Re: [tsvwg] Advance notice on request to poll TSV… Tom Herbert
- [tsvwg] (transport) RE: Advance notice on request… Kaippallimalil John
- Re: [tsvwg] Advance notice on request to poll TSV… Alex Burr
- Re: [tsvwg] Advance notice on request to poll TSV… touch@strayalpha.com
- [tsvwg] (transport) RE: Advance notice on request… Kaippallimalil John
- Re: [tsvwg] (transport) RE: Advance notice on req… C. M. Heard
- Re: [tsvwg] (transport) RE: Advance notice on req… Tom Herbert
- Re: [tsvwg] (transport) RE: Advance notice on req… Kaippallimalil John
- Re: [tsvwg] (transport) RE: Advance notice on req… Bill Gage
- Re: [tsvwg] (transport) RE: Advance notice on req… Tom Herbert