Thanks Zongpeng for your comments. Below my replies.
Jordi
---------
Hi, Jordi
Some comments about the draft for discussion.
The service instances should be deployed firstly, and then the instance
selection would take place only if multiple instances exists for the client
request.
[JRG] Correct. Note also that at selection time, even if there is no
service replication, the application can still benefit from exposure of
communication information. For instance, if a host running an application has
multiple air interfaces (5G, 4G, Wi-Fi), it can decide which one to use to
connect to the service instance based on end-to-end bandwidth and latency
information for each interface.
In the deployment procedure, the computer information is more detailed, and I
think that only the operators that has the right are able to obtain the
information.
[JRG] In a data center, service providers can have knowledge of the
available compute resources in a certain region to help them make deployment
decisions. At the edge, service providers are also in need to have some level
of compute information for the same reason.
The process in the Kubernets should be similar. They can manage the cloud,
select a node/place, and deploy a POD.
I notice that in table 1, it says, in the service placement, service providers
need compute and communication information. However, the communication
information perhaps is not E2E, such as latency, unless we know where the
client is connected into the network. Perhaps, it means the "as well as
bandwidth capacity for forwarding the traffic generated in and out of the
corresponding data center." mentioned in the first Section?
[JRG] Correct. For the service placement case, communication refers to
endpoint (and not end-to-end) metrics such as incoming/outgoing bandwidth.
In the service instance selection procedure, it can be decided in the
centralized server such as the ALTO server, or in the CATS ingress. In the
former case, the centralized server (decision point) can be aware of more
information, e.g. multiple metrics, and make a decision. In the later case,
which is called on-path decision, we perhaps need simpler metrics, which is
still under working.
[JRG] I agree.
----------
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
