danwing / cidfi

Other
0 stars 1 forks source link

fix AASVG #36

Closed danwing closed 11 months ago

danwing commented 11 months ago

@boucadair, while editing this I had a few questions:

For (1), what is a "proxied connection". Is that a MASQUE-like thing? Or CONNECT UDP? Or what?

For (2), what is "out of band metadata sharing".

For (2), I don't understand how there is optional metadata from client to "Network", but there is non-optional (?) metadata from Server to "Network". The client is always involved in that signaling, but I think the diagram is showing the client has no metadata it would communicate to the "Network"?

For (2), I don't know if my change depicts "Glue CXs" properly because I couldn't figure out the intent of the original diagram.

For all of them, I suppose "Network" the CIDFI-aware Network Element, right? I wasn't confident enough on that assumption to make the change.

boucadair commented 11 months ago

@boucadair, while editing this I had a few questions:

For (1), what is a "proxied connection". Is that a MASQUE-like thing? Or CONNECT UDP? Or what?

This can be MASQUE thing, 3GPP ATSSS, whatsoever. We don't need to call out how this is realized by what the external behavior looks like.

For (2), what is "out of band metadata sharing".

For (2), I don't understand how there is optional metadata from client to "Network", but there is non-optional (?) metadata from Server to "Network". The client is always involved in that signaling, but I think the diagram is showing the client has no metadata it would communicate to the "Network"?

(2) is actually mirroring existing practices marketed, e.g., as RAN-assisted acceleration and the like. The client is not involved in such schemes (to ease deployablity and lower dependency on UEs). Adding a client-network leg is an evolution to these schemes, and hence the "optional" tagging.

We may have a variant of (2) with both legs optional or mandatory, but I thought this would over-complexify the figure.

For (2), I don't know if my change depicts "Glue CXs" properly because I couldn't figure out the intent of the original diagram.

Endpoints will need to correlate the signal with the main communication. Some means to glue the two sessions is thus required. Again we we don't need to explain how, but that is an extra feature at the server side compared to the use of the main communication to share data.

For all of them, I suppose "Network" the CIDFI-aware Network Element, right? I wasn't confident enough on that assumption to make the change.

In practice yes, but we don't have "CIDFI-aware Network Element" introduced at this stage. The intent of the figure is to provide a macroscopic view before diving into CIDFI mechanic.

danwing commented 11 months ago

Thanks for explanation!