Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shouldn't the AccessEndpoints also contain the protocol #271

Open
gunjald opened this issue Jun 18, 2024 · 14 comments
Open

Shouldn't the AccessEndpoints also contain the protocol #271

gunjald opened this issue Jun 18, 2024 · 14 comments
Labels
Edge Application Management API enhancement Suggesting ideas for new API features or questions on directions for API evolution

Comments

@gunjald
Copy link
Collaborator

gunjald commented Jun 18, 2024

The access points should have the protocol parameter along with the IP address and port. Or, is there anything I am missing?

@gunjald gunjald added the enhancement Suggesting ideas for new API features or questions on directions for API evolution label Jun 18, 2024
@javierlozallu
Copy link
Collaborator

javierlozallu commented Jun 25, 2024

In AccessPoints the information retrieved from the Edge Platform is: fqdn:port, ip:port What you are saying is that we need the protocol to complete the URI: protocol:fqdn:port, protocol:ip:port where protocol could be http or https, is this correct?

If that is the case, I totally agree with you

@gunjald
Copy link
Collaborator Author

gunjald commented Jun 25, 2024

Yes that is correct. Just going by the standard approaches it could be "ip:port:protocol or fqdn:port:protocol" in my view. Also we may keep protocol at the transport level like TCP or UDP or can also add HTTP/HTTP for application level protocol.

@Kevsy
Copy link
Collaborator

Kevsy commented Jun 25, 2024

I support mandating HTTPS for application endpoints - I suspect they are mandated by the cloud provider in most cases, but worth making it explicit.

Note https indicates "HTTP over TLS", but does not itself specify the version of the application protocol. The version of HTTP (1.1, 2, 3) is negotiated via RFC 7301

Regarding the transport protocol (TCP, UDP, QUIC/UDP etc.): this does not need to be specified, as that is incorporated in the handshake negotiation between client and server.

@gainsley
Copy link
Collaborator

HTTP runs over TCP and QUIC runs over UDP. I think it is too limiting to only support HTTP(S). At a minimum we should allow TCP or UDP options. Also specifying HTTPS is an optimization that allows for ingress switching based hostname/path. For example we may want to share multiple applications on the common HTTPS port 443 by switching based on fqdn, so I think it would be useful to also allow HTTPS as one of the protocols.

@Kevsy
Copy link
Collaborator

Kevsy commented Jun 25, 2024

HTTP runs over TCP and QUIC runs over UDP

HTTP runs (over TLS) over TCP, and HTTP runs over QUIC which runs over UDP (with TLS as part of the QUIC 'layer').

Google developed both HTTP/2 (formerly 'SPDY') and QUIC to overcome various limitations of HTTP over TCP, and the latest standard version of HTTP (HTTP/3 ) is a binding of HTTP/2 semantics to QUIC, to make the most of their shared deign principles (binary format, multiplexed streams).

@gunjald
Copy link
Collaborator Author

gunjald commented Jun 25, 2024

So shouldnt we just leave it to TCP or UDP which could server most of the use cases?

@Kevsy
Copy link
Collaborator

Kevsy commented Jun 25, 2024

So shouldnt we just leave it to TCP or UDP which could server most of the use cases?

Correct, the API definition does not need to worry about the transport protocol supported by the Application Endpoint.. But including the scheme (e.g. https) in the Application Endpoint URL is good practice.

@gainsley
Copy link
Collaborator

So I assume this issue is in reference to the Discovery APIs since it's not clear from the issue summary. Right now I don't see any URL field in the AccessEndpoints model, is the suggestion then to add one or change existing fields to a URL?

Also do we want to support a case where the application is listening on both TCP and UDP (non-http) protocols on the same port, or are we explicitly not allowing that?

Also, do we support applications with their own custom protocols running on top of TCP/UDP? In that case relying on a URL schema may be confusing.

@Kevsy
Copy link
Collaborator

Kevsy commented Jun 25, 2024

So I assume this issue is in reference to the Discovery APIs since it's not clear from the issue summary. Right now I don't see any URL field in the AccessEndpoints model, is the suggestion then to add one or change existing fields to a URL?

I'll let one of the API authors answer that one :)

Also do we want to support a case where the application is listening on both TCP and UDP (non-http) protocols on the same port, or are we explicitly not allowing that?

If it's non-http then there will be no https scheme in the application endpoint, but another scheme (e.g. rtsp etc.). Otherwise this type of discovery and negotiation can be done between client and server, it doesn't need to be covered by the API definition.

Also, do we support applications with their own custom protocols running on top of TCP/UDP? In that case relying on a URL schema may be confusing.

If it's a custom/non-standard URL scheme then it's up to the application developer to make sure there is a supporting client app, which will be configured to opening URLs from that scheme, and have a callback method to handle it.

@gainsley
Copy link
Collaborator

If this is the discovery API, my suggestion would be to add the same protocol field that is already present in both the EAM and Federation APIs, as both the discovery port information and federation APIs correspond to the access port information set by the app provider in the EAM APIs. If we switch to using a scheme instead of a protocol both the EAM and Federation APIs would also need to be changed.

@Kevsy
Copy link
Collaborator

Kevsy commented Jun 26, 2024

Since at least one other CAMARA Sub-project (QoD) models an Application Server address, I suggest this discussion be brought to Commonalities , e.g. to include the resource model in CAMARA_common.yaml..

@javierlozallu
Copy link
Collaborator

javierlozallu commented Jun 26, 2024

So I assume this issue is in reference to the Discovery APIs since it's not clear from the issue summary. Right now I don't see any URL field in the AccessEndpoints model, is the suggestion then to add one or change existing fields to a URL?

Yes, the AccessEndpoints is an object generated by the Edge Platform, which is returned to the Application Provider when the instantiation is successful using the POST /apps/{appId}/instances and when the Application Provider uses GET /apps/{appId}/instances, in both methods only ip:port is returned so what I understand is that the Application Providers need to also know the protocol to have a complete Endpoint for connectivity as only ip:port might not be enough for a successful connection. This use case assumes that the Endpoint is completely managed by the Edge Platform.

There is another use case/function that can be added and it is similar to what hyperscalers do: Bring your own DNS, in this case we should define a scheme/model for Endpoints that complies with best practices and security.

What do you thing?

Also do we want to support a case where the application is listening on both TCP and UDP (non-http) protocols on the same port, or are we explicitly not allowing that?

About the protocols of the application currently the componentSpec object exists within the AppManifest for the onboarding and contains:

protocol:
type: string
enum:
 - TCP
 - UDP
 - ANY
 description: |
Defines the IP transport communication
protocol i.e., TCP, UDP or ANY

Also, do we support applications with their own custom protocols running on top of TCP/UDP? In that case relying on a URL schema may be confusing.

Maybe the confusion is between app protocol within componentSpec object and endpoint protocol within AccessEndpoints

My understanding of the issue is about protocol://ip:port, protocol://fqdn:port

@javierlozallu
Copy link
Collaborator

The Bring Your Own DNS feature may be another Edge Cloud API.

@Kevsy
Copy link
Collaborator

Kevsy commented Jun 27, 2024

My understanding of the issue is about protocol://ip:port, protocol://fqdn:port

It's scheme in the context of a URI, ref RFC 3986 section 3.1 . Ideally we would further avoid ambiguity by referring to transport protocol when we mean TCP, UDP.

So scheme://ipv4:port ,scheme://[ipv6]:port, scheme://fqdn:port .

Note IPv6 addresses should be escaped with [ ] when specifying a port, ref RFC 2732

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Edge Application Management API enhancement Suggesting ideas for new API features or questions on directions for API evolution
Projects
None yet
Development

No branches or pull requests

4 participants