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

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Tom,

> 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.

Do you see any relation to the use-cases captured in draft-herbert-fast and in draft-media-hdr-wireless ?  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.

A router will inspect a packet, validate the ticket and allow the packet to traverse through?  We require a completely new forwarding plane. 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? 

Maybe these are totally different problems and with no relation.

Regards
Sri




On 8/13/23, 10:06 AM, "Tom Herbert" <[e-mail] <mailto:[e-mail]>> wrote:


On Sun, Aug 13, 2023 at 8:48 AM Kaippallimalil John
<[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]>> On Behalf Of [e-mail] <mailto:[e-mail]>
> Sent: Sunday, August 13, 2023 10:07 AM
> To: C. M. Heard <[e-mail] <mailto:[e-mail]>>
> Cc: TSVWG <[e-mail] <mailto:[e-mail]>>; Sri Gundavelli <[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>
>
>
> On Aug 12, 2023, at 6:14 PM, C. M. Heard <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]>> 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
>