search

mjoras / SCONE-PROTOCL

Repository for files related to the topic formerly known as SADCDN.
Other
7 stars 6 forks source link

Associativity requirement #79

Open mnot opened 3 weeks ago

mnot commented 3 weeks ago

The draft charter lists this requirement (as a "property of this mechanism"):

Associativity with an application. The network properties must be associated with a given application traversing the network, for example a video playback.

However, unlike most of the other requirements, this isn't motivated. Why is this a "must"?

SpencerDawkins commented 2 weeks ago

@mnot - good catch.

The intention was that this is not UE-level information. The current charter text is intended to resolve Issue #5. @SpencerDawkins, @mjoras, and @ihlar are huddling about this now, but we'll almost certainly need to get input from others.

It seems important to say "this isn't a generic transport mechanism for network properties". We don't think there's an implicit relationship between this information and a UE.

@SpencerDawkins wonders if this should be described in the charter text, and not just listed as a mechanism property.

@mjoras and @ihlar wonder if this point is already covered in other text - it's QUIC-only, so transport-layer-only. We're looking at this text:

The working group will initially focus on a solution that communicates the maximum achievable throughput for a video delivered from a server to a client, using QUIC connections carrying the application signaling traffic.

We THINK we can just delete this property, but if we keep it, we should change it to

Associativity with an application. The network properties must be associated with a given QUIC connection traversing the network to provide video playback.

@fluffy and @martinthomson - do you have thoughts about this?

martinthomson commented 2 weeks ago

I think that this needs to be about flows, not applications. I tend to think that the property is useful, but the lack of motivation is a concern. The motivation - at least for me - is that the authorization system we use (i.e., how we determine which network signals to pay attention to) is flow-based, not application or connection-based. Where QUIC comes in is that this is going to be limited to QUIC flows (at least initially).

Flow associativity. The network communications the properties as they relate to specific (QUIC) flows. This ensures that applications can authorize and apply actions on a per-flow basis.

mjoras commented 1 week ago

I would be happy with this flow text. The application part really doesn't need to come into it here since we have already said elsewhere that this is specific to video and thus specific to video flows as determined by the client.

SpencerDawkins commented 1 week ago

We like the text @mnot proposed, and we'll PR it.

fluffy commented 1 week ago

MT's text looks reasonable

mnot commented 1 week ago

I didn't write nothin'.

MT's text looks better. However, given that it's likely to justify some pretty major design decisions, it seems pretty thin.

For example, it would rule out an ambient signal on the network about its own properties, or a client-specific (as opposed to flow-specific) mechanism. If that's going to be baked into the charter, why it's so critical needs to be spelled out in much greater detail.

danwing commented 1 week ago

Yes, what @mnot says. if a client-specific signal doesn't meet requirements and desire is to prohibit by charter, the requirements need refinement and more motivation. The existing SCONEPRO requirements are met with a client-specific signal, as we wrote in https://datatracker.ietf.org/doc/draft-brw-sconepro-rate-policy-discovery.