Re: [Int-area] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt

[Kiran Makhijani]

Hi Tom,

Section 6, last part is bit garbled.

"A request can be a detailed list of services requested for a flow,
and the provide signal encapsulates the services to be provider."

Do you mean "the provider signal encapsulates the services to be
provided”? Also are you saying that host can ask network what services
it can offer?

"The response to a request is the signal data that the host or
application can attach to its packets."

The response part is unclear to me. Maybe related to the previous
sentence (or not) Is this a response from the network A (in your
dumbbell topology)?

Had additional questions from requirements perspective:

1. Will the intermediate nodes processing these signals end up doing
decrypt-process-encrypt again?

2. Should there be a requirement on mutability of signal data? E.g.
Are nodes authorized/permitted to modify metadata or parameters for a
signal?

3. In some cases that interest me, it is sufficient that host
communicates its service request to the network it is attached to.
Intelligent network edges can take care of the service delivery from
then on. Would it make sense to allow edge nodes to map to internal
service construct and remove the signal. I am asking this because it
is one way to not mitigate signal exposure of the packets transiting
through the network. Although encryption will serve the purpose but
thought I should still ask.

Thanks for putting the requirements together.
Cheers,
Kiran



On September 27, 2023 at 4:11:39 PM, Tom Herbert
(tom=40herbertland@dmarc.ietf.org
(mailto:tom=40herbertland@dmarc.ietf.org)) wrote:

> Hi,
>
> I've posted a use case and motivation document for Host to Network Signaling.
>
> I apologize for cross posting, but I believe this most likely falls in
> the intarea, however we've seen some proposals that could use a common
> protocol framework being presented in tsvwg.
>
> The goal of this document is to motivate discussion on the topic, and
> I believe that it may be significant enough to warrant work on this in
> IETF.
>
> Please review and comment!
>
> Thanks,
> Tom
>
> -- Forwarded message -
> From:
> Date: Wed, Sep 27, 2023 at 4:09 PM
> Subject: New Version Notification for draft-herbert-net2hostsig-00.txt
> To: Tom Herbert
>
>
> A new version of Internet-Draft draft-herbert-net2hostsig-00.txt has been
> successfully submitted by Tom Herbert and posted to the
> IETF repository.
>
> Name: draft-herbert-net2hostsig
> Revision: 00
> Title: Host to Network Signaling
> Date: 2023-09-27
> Group: Individual Submission
> Pages: 22
> URL: https://www.ietf.org/archive/id/draft-herbert-net2hostsig-00.txt
> Status: https://datatracker.ietf.org/doc/draft-herbert-net2hostsig/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig
>
>
> Abstract:
>
> This document discusses the motivations, use cases, and requirements
> for Host to Network Signaling. In Host to Network Signaling, a hosts
> annotate packets with information that is intended for consumption by
> on-path elements. Signals may be used to request services on a per
> packet basis from on-path elements to request admission into the
> network or to provide diagnostics and tracing information.
>
>
>
> The IETF Secretariat
>
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [tsvwg] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt

[Tom Herbert]

On Fri, Sep 29, 2023 at 8:49 AM Robinson, Herbie
 wrote:
>
> OK, I see where you are coming from and it makes sense.  Hopefully that will 
> become clear when the IANA Considerations section gets completed.
>
> Just out of curiosity, how would key distribution and updating work for the 
> encryption?

Herbie,

That's a very good question, and probably one of the more interesting
sub-problems of host networking that we'll have to solve! That is: How
do we implement distributed security with potentially multiple nodes
performing decryption of the data in the high performance datapath?

Tom

>
> From: Int-area  On Behalf Of Tom Herbert
> Sent: Friday, September 29, 2023 11:12 AM
> To: Robinson, Herbie 
> Cc: Tom Herbert ; int-area 
> ; tsvwg 
> Subject: Re: [Int-area] [EXTERNAL] Fwd: New Version Notification for 
> draft-herbert-net2hostsig-00.txt
>
> [EXTERNAL SENDER: This email originated from outside of Stratus Technologies. 
> Do not click links or open attachments unless you recognize the sender and 
> know the content is safe.]
>
> On Thu, Sep 28, 2023 at 9:32 AM Robinson, Herbie
>  wrote:
> >
> > I have a couple of observations
> >
> >
> > In section 2.2, you make the claim that the actual host to network services 
> > should be vendor specific. Yet in section 2.3, the example services you 
> > mention are all things that should, in fact, be standardized.
>
> The relevant text is: "An outcome of this design is that there is no
> requirement for a standard set of signals that all networks must
> support; signals can be defined in each provider network per their
> needs and the network services they offer."
>
> It's not so much about being vendor specific, it's more about avoiding
> a "one size fits all" approach. An automotive network may offer very
> different services than a mobile network which may be different than a
> cloud provider. There may be a common set of signals for each of these
> types of networks, but I think we want to avoid mandating that the
> services and their signals have to be used by everyone.
>
> > While I am willing to accept that there are examples where vendor specific 
> > services should be supported, the main focus should be a model for 
> > describing standard services as well. I am speaking as the maintainer of 
> > host networking software and by extension the applications that use it. 
> > Asking applications to interface to potentially hundreds of different 
> > vendor protocols is unmanageable (from the standpoint of the application 
> > developer) and will most like result in none of them using any of it.
>
> Yes, applications should only need one protocol. For the actual
> signals, they only have to support the carrier in packets. For
> requesting signals, I would envision that applications contact an
> agent in the network that makes their request. Maybe something like
> REST with some XML description of parameterizations. Since these
> requests are not inline with the data path, the requests for services
> could be a rich set of parameters (frame rate, latency,
> anti-censorship, etc.). The set of possible parameters could be
> standard, but it becomes a network specific thing to turn these
> parameters into a signal for the services they support in the network
> the host can use with its packets.
>
> > Re:
> >
> > |Name: draft-herbert-net2hostsig
> > |Revision: 00
> > |Title: Host to Network Signaling
> > |Date: 2023-09-27
> > |Group: Individual Submission
> > |Pages: 22
> > |URL: https://www.ietf.org/archive/id/draft-herbert-net2hostsig-00.txt
> > |Status: https://datatracker.ietf.org/doc/draft-herbert-net2hostsig
> > |HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig
>

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt

[Robinson, Herbie]

OK, I see where you are coming from and it makes sense.  Hopefully that will 
become clear when the IANA Considerations section gets completed.

Just out of curiosity, how would key distribution and updating work for the 
encryption?

From: Int-area  On Behalf Of Tom Herbert
Sent: Friday, September 29, 2023 11:12 AM
To: Robinson, Herbie 
Cc: Tom Herbert ; int-area 
; tsvwg 
Subject: Re: [Int-area] [EXTERNAL] Fwd: New Version Notification for 
draft-herbert-net2hostsig-00.txt

[EXTERNAL SENDER: This email originated from outside of Stratus Technologies. 
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.]

On Thu, Sep 28, 2023 at 9:32 AM Robinson, Herbie
 wrote:
>
> I have a couple of observations
>
>
> In section 2.2, you make the claim that the actual host to network services 
> should be vendor specific. Yet in section 2.3, the example services you 
> mention are all things that should, in fact, be standardized.

The relevant text is: "An outcome of this design is that there is no
requirement for a standard set of signals that all networks must
support; signals can be defined in each provider network per their
needs and the network services they offer."

It's not so much about being vendor specific, it's more about avoiding
a "one size fits all" approach. An automotive network may offer very
different services than a mobile network which may be different than a
cloud provider. There may be a common set of signals for each of these
types of networks, but I think we want to avoid mandating that the
services and their signals have to be used by everyone.

> While I am willing to accept that there are examples where vendor specific 
> services should be supported, the main focus should be a model for describing 
> standard services as well. I am speaking as the maintainer of host networking 
> software and by extension the applications that use it. Asking applications 
> to interface to potentially hundreds of different vendor protocols is 
> unmanageable (from the standpoint of the application developer) and will most 
> like result in none of them using any of it.

Yes, applications should only need one protocol. For the actual
signals, they only have to support the carrier in packets. For
requesting signals, I would envision that applications contact an
agent in the network that makes their request. Maybe something like
REST with some XML description of parameterizations. Since these
requests are not inline with the data path, the requests for services
could be a rich set of parameters (frame rate, latency,
anti-censorship, etc.). The set of possible parameters could be
standard, but it becomes a network specific thing to turn these
parameters into a signal for the services they support in the network
the host can use with its packets.

> Re:
>
> |Name: draft-herbert-net2hostsig
> |Revision: 00
> |Title: Host to Network Signaling
> |Date: 2023-09-27
> |Group: Individual Submission
> |Pages: 22
> |URL: https://www.ietf.org/archive/id/draft-herbert-net2hostsig-00.txt
> |Status: https://datatracker.ietf.org/doc/draft-herbert-net2hostsig
> |HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt

[Tom Herbert]

On Thu, Sep 28, 2023 at 9:32 AM Robinson, Herbie
 wrote:
>
> I have a couple of observations
>

Hi Herbie,

Thanks for the comments!

> There is a desire to make host to network signals processable in fast router 
> paths without variable length packet processing.  Yet at the same time, there 
> is a requirement for encryption.  Processing variable length packets is going 
> to be a lot easier in the fast path (all it takes is a barrel shifter) than 
> decrypting parts of a packet; so, it would appear that these are conflicting 
> requirements.  Both are, of course, implementable with the appropriate 
> hardware resources, but I suspect it will take a lot of persuading to get any 
> vendors to do that.

I think variable length headers and decryption have different
motivations and are orthogonal.

Encryption is needed to hide sensitive data from observers. Host to
network signals needed to be encrypted (or at least obfuscated) to
prevent abuse of the signals. I suppose if the signals were restricted
in a limited domain maybe the requirement for encryption. But, given
that there's a need for hosts to network signaling in public networks,
I think we need a good solution and it will have to be efficient
(maybe network nodes  can maintain some sort of cache of signal being
received so they only have to decrypt once or something like that)

Variable length headers provide extensibility. For variable length
header processing, I tend to agree that this problem is being solved
(hopefully, we can move past this as being a "headache" in high
performance datapath processing). We should be able to leverage
constructs like TLVs in network layer protocols but with some
judicious limits for practicality (see draft-ietf-6man-eh-limits for
example). There's another option here also, just because a protocol
allows something to be variable length doesn't mean the length *has*
to be variable length. For instance, suppose we define a host to
network signal in a Hop-by-Hop Option that has a fixed size. If that's
the only HBH option being used in the network, then the option is not
only fixed length, it's also always at the same offset in packets.
Network devices can process the signal without any variable length
processing. Effectively, it's a means to extend the IP header with a
fixed length. It's an opportunistic optimization that would never
apply in the open Internet, but inside a limited domain where the
admin has control over the network infrastructure it is feasible.

>
> In section 2.2, you make the claim that the actual host to network services 
> should be vendor specific.  Yet in section 2.3, the example services you 
> mention are all things that should, in fact, be standardized.

The relevant text is: "An outcome of this design is that there is no
requirement for a standard set of signals that all networks must
support; signals can be defined in each provider network per their
needs and the network services they offer."

It's not so much about being vendor specific, it's more about avoiding
a "one size fits all" approach. An automotive network may offer very
different services than a mobile network which may be different than a
cloud provider. There may be a common set of signals for each of these
types of networks, but I think we want to avoid mandating that the
services and their signals have to be used by everyone.

> While I am willing to accept that there are examples where vendor specific 
> services should be supported, the main focus should be a model for describing 
> standard services as well.  I am speaking as the maintainer of host 
> networking software and by extension the applications that use it.  Asking 
> applications to interface to potentially hundreds of different vendor 
> protocols is unmanageable (from the standpoint of the application developer) 
> and will most like result in none of them using any of it.

Yes, applications should only need one protocol. For the actual
signals, they only have to support the carrier in packets. For
requesting signals, I would envision that applications contact an
agent in the network that makes their request.  Maybe something like
REST with some XML description of parameterizations. Since these
requests are not inline with the data path, the requests for services
could be a rich set of parameters (frame rate, latency,
anti-censorship, etc.). The set of possible parameters could be
standard, but it becomes a network specific thing to turn these
parameters into a signal for the services they support in the network
the host can use with its packets.

>
> In section 6, I would also claim that it's a requirement that any vendor 
> specific services must be registered with the IANA and fully described in 
> documentation provide free of charge by the vendor.

Per above, I think it might be the service parameters they used should
be registered. The actual services provided are derived from requests
containing the parameters.

Tom


>
> Re:
>
> |Name: 

Re: [Int-area] New Version Notification for draft-herbert-net2hostsig-00.txt

[Tom Herbert]

On Wed, Sep 27, 2023 at 8:10 PM to...@strayalpha.com
 wrote:
>
> I’ve already commented on other lists, but to state here, IMO, UDP options 
> exist in a space that the UDP header makes available. I do not think it is 
> ever appropriate to use transport headers or signals to communicate with 
> network devices.

Joe,

I tend to agree, but there are a couple of proposals in tsvwg for this
so it is referenced in the draft for completeness trying to cover as
much as possible.

Tom

>
> Joe
>
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com
>
> On Sep 27, 2023, at 4:10 PM, Tom Herbert 
>  wrote:
>
> Hi,
>
> I've posted a use case and motivation document for Host to Network Signaling.
>
> I apologize for cross posting, but I believe this most likely falls in
> the intarea, however we've seen some proposals that could use a common
> protocol framework being presented in tsvwg.
>
> The goal of this document is to motivate discussion on the topic, and
> I believe that it may be significant enough to warrant work on this in
> IETF.
>
> Please review and comment!
>
> Thanks,
> Tom
>
> -- Forwarded message -
> From: 
> Date: Wed, Sep 27, 2023 at 4:09 PM
> Subject: New Version Notification for draft-herbert-net2hostsig-00.txt
> To: Tom Herbert 
>
>
> A new version of Internet-Draft draft-herbert-net2hostsig-00.txt has been
> successfully submitted by Tom Herbert and posted to the
> IETF repository.
>
> Name: draft-herbert-net2hostsig
> Revision: 00
> Title:Host to Network Signaling
> Date: 2023-09-27
> Group:Individual Submission
> Pages:22
> URL:  https://www.ietf.org/archive/id/draft-herbert-net2hostsig-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-herbert-net2hostsig/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig
>
>
> Abstract:
>
>   This document discusses the motivations, use cases, and requirements
>   for Host to Network Signaling.  In Host to Network Signaling, a hosts
>   annotate packets with information that is intended for consumption by
>   on-path elements.  Signals may be used to request services on a per
>   packet basis from on-path elements to request admission into the
>   network or to provide diagnostics and tracing information.
>
>
>
> The IETF Secretariat
>
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>
>

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area