Re: [tsvwg] signaling packet importance [was Re: New Version Notification for draft-herbert-fast]

[Tom Herbert <[e-mail]>]

On Tue, Aug 15, 2023, 11:18 PM Huangyihong (Rachel) <rachel.huang=
[e-mail]> wrote:

> Hi all,
>
> BR，
> Rachel
>
> > -----邮件原件-----
> > 发件人: tsvwg <[e-mail]> 代表 Tom Herbert
> > 发送时间: 2023年8月16日 4:36
> > 收件人: Sri Gundavelli (sgundave) <[e-mail]>
> > 抄送: [e-mail]; TSVWG <[e-mail]>
> > 主题: Re: [tsvwg] signaling packet importance [was Re: New Version
> > Notification for draft-herbert-fast]
> >
> > On Mon, Aug 14, 2023 at 9:35 PM Sri Gundavelli (sgundave)
> > <[e-mail]> wrote:
> > >
> > > Hi Tom,
> > >
> > > Thank you for your response.  The focus of the draft
> (media-hdr-wireless) is
> > on the meta-data elements, their definitions, and the related semantics.
> How
> > we show the relationships between different frames that are part of the
> same
> > IP flow, so elements in the network (e.g., RAN) can make certain choices
> when
> > there are limiting forwarding resources at its disposal.  The mechanics
> around
> > how we transport them is not the primary focus, as such any decent
> transport
> > would meet the goals.
> >
> > Yes, I agree with that. FAST is about the mechanics of signaling.
> >
> > >
> > > Also, "Signaling" is a very broad term.
> >
> > This is specifically about host to network signaling where packets to
> some
> > destination are annotated with information intended for consumption by
> > intermediate nodes in the packet's path. It's not intended to mean
> signals that
> > are explicitly sent in packets directly to network elements. Perhaps, we
> should
> > use the term "inband host to network signaling" or something like that
> to be
> > clear.
>
> [Rachel]: I think the signaling should be bi-directional, not only about
> host to network, but also network to host where information (usually are
> network configuration or network conditions) could be signaled for host to
> consume. This would facilitate the application to make good decisions. So
> if we wanna talk about a general enough mechanism, personally I prefer it
> to include both.
>

Hi Rachel,

I believe that's covered by IOAM. Besides that, a reason not to combine
these too quickly is that network to host signaling has very different
security characteristics than host to network signaling-- in flight
modification of data, attribution, and how to authenticate with multiple
writers.

Tom


> >
> > > Signaling in the context of the above drafts is about providing
> additional
> > information about the frame in question. If we make an argument that even
> > though the application is different, but since there involves some form
> of
> > signaling from the host to network and so it should be based on the same
> > protocol approach. Then that’s a very broad brush we are using.   We
> cannot
> > group a solution related to gaining access grant to a network resource,
> with an
> > application that requires meta-data signaling for frame characterization.
> > These are different applications, each requiring different set of
> services from
> > the network.  There is Radio setup signaling, authentication relation
> signaling,
> > and address configuration related signaling, but each use a specific
> protocol.
> >
> > I see grant of admission, QoS parameters like from characterization,
> etc. to be
> > different service attributes. You're highlighting the fact that there
> can't be any
> > single standard definition of service attributes that covers all
> possible use cases.
> > The old TOS bits for Low latency, High throughput, Low monetary cost
> aren't
> > nearly sufficient, and different networks will offer different services
> that need
> > to be characterized and can be requested.
> >
> > > The domain of the application, use-case and the application environment
> > dictate the protocol design choice. IMO, linking these requirements may
> not
> > be a good idea.
> >
> > I agree to that to the extent that communication is application to
> application,
> > so that there are only two participants. However, if packets are tagged
> with
> > ancillary information intended for consumption by intermediate nodes,
> then
> > the communication now involves N parties and the requirements for
> > interoperability and security increase dramatically.
> >
> > Tom
> >
> >
> > >
> > >
> > > Regards
> > > Sri
> > >
> > >
> > >
> > >
> > >
> > > On 8/14/23, 8:01 AM, "Tom Herbert" <[e-mail]
> > <mailto:[e-mail]>> wrote:
> > >
> > > Hi Sri,
> > >
> > >
> > > draft-media-hdr-wireless would be a use case draft-herbert-fast is a
> > > proposal for a common carrier of network signaling,
> > > draft-media-hdr-wireless describes a use case, content, of host to
> > > network signaling as well as a carrier in a UDP options.
> > >
> > >
> > > > The first drafts talks about fundamentally changing the IP networking
> > model by carrying tickets in IP packets for gaining service / forwarding
> access,
> > and whereas the other draft has very specific requirement for carrying
> > meta-data so a transit network (e.g. RAN) can use this meta-data in
> forwarding
> > decisions. Putting them together and finding a generic solution amounts
> to
> > boiling the ocean, and IMHO, we will achieve nothing.
> > > >
> > > > The idea of carrying service tickets in IP Packets (though not a new
> concept)
> > is an interesting idea. That sounds great on paper, but do you think
> that level
> > of orchestration is suited for IP networks? I am not sure.
> > >
> > >
> > > That is fundamentally no different than the orchestration needed to
> > > carry metadata as described in draft-media-hdr-wireless in IP packets.
> > > In fact, I don't see any material difference between "metadata"
> > > draft-media-hdr-wireless in used in and "tickets", their pretty much
> > > different names for the same thing-- they are data sent in IP packets
> > > to be inspected by intermediate nodes to affect QoS or routing.
> > > Similarly, the "wireless node" that is inspecting the UDP options
> > > in-flight is really just an intermediate node in IETF parlance.
> > > >
> > > > A router will inspect a packet, validate the ticket and allow the
> packet to
> > traverse through? We require a completely new forwarding plane.
> > >
> > >
> > > Only edge routers would want to process tickets, it's the same modes
> > > as in draft-media-hdr-wireless where the Wireless Node is probably the
> > > only node that would need to process the UDP options carrying MED
> > > data. No new forwarding plane is needed any more than what's needed
> > > for "a transit network (e.g. RAN) can use this meta-data in forwarding
> > > decisions" as you mentioned above.
> > >
> > >
> > > > Do you think any router vendors will implement such schemes impacting
> > the forwarding performance, looking at some new hop by options requiring
> > crypto resources? This reminds me of RSVP and COPS, how much traction did
> > we find for that in enterprise IP networks, It is not all diff-serv?
> > >
> > >
> > > Yes, securing tickets to prevent forgery or information leakage is a
> > > hard problem, but it's a common problem with host to network
> > > signaling; for instance, draft-media-hdr-wireless states: "When there
> > > are insecure network segments in between, all packets that carry the
> > > metadata in the MED UDP option must be secured with encryption between
> > > these segments". If that solution is sufficient then it could be used
> > > for FAST as well to meet the security requirements.
> > >
> > >
> > > >
> > > > Maybe these are totally different problems and with no relation.
> > >
> > >
> > > I believe it's the exact opposite, they are very related as they are
> > > solving parts of a common problem. Note that
> > > https://datatracker.ietf.org/doc/html/draft-reddy-tsvwg-explcit-signal
> > > <https://datatracker.ietf.org/doc/html/draft-reddy-tsvwg-explcit-signa
> > > l> is also doing this as that draft defines a mechanism for an
> > > endpoint to explicitly signal encrypted metadata to the network. There
> > > are some other drafts in this same area as well. The common problem
> > > is: how do hosts send signals into the network to affect routing or
> > > QoS in a secure fashion. A common solution to a common problem
> > > benefits everyone :-)
> > >
> > >
> > > Tom
> > >
> > >
> > >
> > >
> > > >
> > > > Regards
> > > > Sri
> > > >
> > > >
> > > >
> > > >
> > > > On 8/13/23, 10:06 AM, "Tom Herbert" <[e-mail]
> > <mailto:[e-mail]> <mailto:[e-mail]
> > <mailto:[e-mail]>>> wrote:
> > > >
> > > >
> > > > On Sun, Aug 13, 2023 at 8:48 AM Kaippallimalil John
> > > > <[e-mail]
> > <mailto:[e-mail]>
> > <mailto:[e-mail]
> > <mailto:[e-mail]>>> wrote:
> > > > >
> > > > > > My concern is that endorsing use of UDP options to signal
> in-network
> > devices could cause the same reaction as IP HBH options - that they
> could be
> > seen as unsafe to routers and could cause an over-reaction that causes >
> > deliberate blocking or stripping.
> > > > > >
> > > > > > As the discussion noted, that’s not currently the case, or at
> > > > > > least as best can be determined. I
> > > > > >
> > > > > > It’d be useful to avoid creating new reasons that routers would
> want to
> > interfere. I.e., the question isn’t whether IP options are an
> alternative - they
> > clearly are the appropriate place for draft-kaippallimalil-tsvwg-media->
> > hdr-wireless and draft-reddy-tsvwg-explcit-signal - it’s whether using
> UDP
> > options for those purposes could jeapordize them for everyone else.
> > > > >
> > > > > The procedures in draft-kaippallimalil-tsvwg-media- hdr-wireless
> can in
> > theory be realized by encoding it in IPv6 HBH options (IPv4 is another
> > questions) but I share Mike's concern about the timeline.
> > > > > (-- " Those might bear fruit someday, though the timeline is at
> best
> > uncertain").
> > > > > The authors (of tsvwg-media- hdr-wireless) are primarily looking to
> > providing a viable solution for 3GPP in the short term (end of 2024 or
> so) even
> > if it is an Experimental or Informational one.
> > > >
> > > >
> > > > John,
> > > >
> > > >
> > > > Your desire for an expedited solution is understandable, however it
> > > > is typical in IETF to work on protocols that have broad
> > > > applicability across many use cases. A common host to network
> > > > signaling solution could eventually benefit all Internet users to
> give them
> > improved QoS.
> > > > You might want to consider how
> > > > draft-kaippallimalil-tsvwg-media-hdr-wireless could be generalized
> > > > to that end.
> > > >
> > > >
> > > > Tom
> > > >
> > > >
> > > > >
> > > > > And I acknowledge the issue that Joe has pointed to - of whether
> UDP
> > options will be seen as unsafe, and a corresponding over-reaction.
> > > > > Our attempt in draft-kaippallimalil-tsvwg-media- hdr-wireless to
> avoid
> > this has been that:
> > > > > - the MED option is to be used only within a limited domain that
> > > > > spans an application network and wireless network with
> > > > > pre-established trust (RFC 8799)
> > > > > - if the MED option crosses an "untrusted network" (e.g. , a
> transport
> > network in between), the entire flow should be encrypted such that MED
> is not
> > visible.
> > > > > - if a MED option is visible outside the limited domain with trust
> (set of
> > application, wireless networks), the draft recommends that MED be
> dropped.
> > > > >
> > > > > BR,
> > > > > John
> > > > >
> > > > >
> > > > >
> > > > > From: tsvwg <[e-mail]
> > > > > <mailto:[e-mail]> <mailto:[e-mail]
> > > > > <mailto:[e-mail]>>> On Behalf Of
> > > > > [e-mail] <mailto:[e-mail]>
> > > > > <mailto:[e-mail] <mailto:[e-mail]>>
> > > > > Sent: Sunday, August 13, 2023 10:07 AM
> > > > > To: C. M. Heard <[e-mail] <mailto:[e-mail]>
> > > > > <mailto:[e-mail] <mailto:[e-mail]>>>
> > > > > Cc: TSVWG <[e-mail] <mailto:[e-mail]>
> > > > > <mailto:[e-mail] <mailto:[e-mail]>>>; Sri Gundavelli
> > > > > <[e-mail] <mailto:[e-mail]>
> > > > > <mailto:[e-mail] <mailto:[e-mail]>>>
> > > > > Subject: Re: [tsvwg] signaling packet importance [was Re: New
> > > > > Version Notification for draft-herbert-fast]
> > > > >
> > > > > My concern is that endorsing use of UDP options to signal
> in-network
> > devices could cause the same reaction as IP HBH options - that they
> could be
> > seen as unsafe to routers and could cause an over-reaction that causes
> > deliberate blocking or stripping.
> > > > >
> > > > > As the discussion noted, that’s not currently the case, or at
> > > > > least as best can be determined. I
> > > > >
> > > > > It’d be useful to avoid creating new reasons that routers would
> want to
> > interfere. I.e., the question isn’t whether IP options are an
> alternative - they
> > clearly are the appropriate place for
> > draft-kaippallimalil-tsvwg-media-hdr-wireless and
> > draft-reddy-tsvwg-explcit-signal - it’s whether using UDP options for
> those
> > purposes could jeapordize them for everyone else.
> > > > >
> > > > > draft-daiya-tsvwg-udp-options-protocol-number is of a completely
> > different nature; it aims to be part of the transport protocol in
> chaining the
> > meaning of protocol layers, rather than encoding them all in the
> destination
> > port of the first exchange. In that regard, it’s more like
> draft-touch-tcpm-sno
> > (service number option), except that it would require similar ’next
> protocol’
> > identifiers at all protocol layers, which is (sadly) not the way current
> services
> > and protocol stacks work.
> > > > >
> > > > > Joe
> > > > >
> > > > >
> > > > > —
> > > > > Dr. Joe Touch, temporal epistemologist http://www.strayalpha.com
> > > > > <http://www.strayalpha.com> <http://www.strayalpha.com>
> > > > > <http://www.strayalpha.com&gt;>
> > > > >
> > > > >
> > > > > On Aug 12, 2023, at 6:14 PM, C. M. Heard <mailto:[e-mail]
> > <mailto:[e-mail]> <mailto:[e-mail]
> > <mailto:[e-mail]>>> wrote:
> > > > >
> > > > > On Fri, Aug 11, 2023 at 7:47 PM Joe Touch wrote:
> > > > > Just to be clear:
> > > > > On Aug 11, 2023, at 2:42 PM, C. M. Heard <mailto:[e-mail]
> > <mailto:[e-mail]> <mailto:[e-mail]
> > <mailto:[e-mail]>>> wrote:
> > > > > I've been pushing the idea to co-opt the per-fragment UDP options
> used
> > for host-to-network signaling, and I'd like to make some comments about
> that.
> > > > >
> > > > > This confuses transport options with network options.
> > > > >
> > > > > Not confusion, but rather an explicit proposal to use the
> per-fragment
> > options as network options instead of transport options. It is put
> forward to
> > provide potentially workable solutions to the problems that
> > draft-kaippallimalil-tsvwg-media-hdr-wireless and
> > draft-reddy-tsvwg-explcit-signal are intended to solve.
> > > > >
> > > > > Granted, an architecturally preferable way to accomplish these
> objectives
> > would be to use IPv4 Options or IPv6 Hop-by-Hop Options. Indeed, I myself
> > would prefer for IPv4/IPv6 Options to be used if the issues of high
> discard rates
> > of packets with these options could be solved. There are efforts
> underway to
> > mitigate the problems for IPv6 Hop-by-Hop Options. Those might bear fruit
> > someday, though the timeline is at best uncertain. But as far as I know,
> the
> > discard rates for IPv4 Options are equally dismal, and there are no
> efforts
> > underway to fix that problem. Correction by parties with better
> knowledge of
> > the facts than mine are invited.
> > > > >
> > > > > My take is that the problems that
> > draft-kaippallimalil-tsvwg-media-hdr-wireless and
> > draft-reddy-tsvwg-explcit-signal (and possibly
> > draft-daiya-tsvwg-udp-options-protocol-number as well) could, in
> principle, be
> > solved by what I see as a modest change of direction to the UDP Options
> spec.
> > Whether that would work out in practice is much less certain, for the
> reasons
> > that Tom Herbert has pointed out. IMO it is a judgement call whether the
> > chances are better to get IP Options (in any version) to work within our
> > professional lifetimes. Given that, I don't think it would be right to
> turn
> > draft-kaippallimalil-tsvwg-media-hdr-wireless and
> > draft-reddy-tsvwg-explcit-signal away without a proper discussion.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Mike
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
>