Re: [icnrg] Some comments on draft-li-icnrg-damc

[Xueting Li <[e-mail]>]

Thanks for the comprehensive responses. I’ll wait to hear from other folks with comments before going through the update.

One quick further point on the classification as Standards Track. I’m pretty sure IRTF Research groups are in fact not allowed to progress Standards Track documents, so you should consider one of:
- re-target the work at the IETF if you intend for this work to actually result in an Internet Standard
- re-classify as Experimental if you intend it to quickly evolve into a protocol specification, or
- re-classify as Informational, which is what the majority of ICNRG documents (other than the few ptorocol things we publish) get processed as.




On 8 Aug 2023, at 23:04, Xueting Li wrote:

> Dear Dave,
>
> Thank you for your valuable suggestions on draft-li-icnrg-damc. We greatly appreciate your input in helping us enhance the quality of our content. The following are responses to some suggestions, please review them.
>
> Template
> Our document approaches the subject matter from an architectural standpoint, aiming to establish a new framework that we believe will have a significant impact in the field. This framework serves as a foundational concept upon which future documents and references will be built. It represents a fundamental shift in the way we approach the challenges in our domain. Given these considerations, we still believe that classifying our document as a Standards Track document aligns with our long-term vision and goals. We view this document as a critical piece that sets the stage for future standards and protocols to be developed within this framework.
> Introduction
> We understand your point, and we will certainly review and adjust our references accordingly. Your recommendation of using RFC7927 or the survey paper you provided seems quite promising, and we will take this into consideration to ensure our document's accuracy and credibility.
>
> Thank you for your thorough analysis of our architecture and your concerns regarding the centralized controller. We greatly appreciate your insights and would like to further clarify our design philosophy.
>
> The issue you raised about the performance bottleneck of a centralized controller is indeed an important consideration. Our architecture is designed with the goal of achieving large-scale deployment, even on a national level. This means that we need to address the challenges of handling systems at such a scale. Consequently, our design philosophy not only encompasses centralized control but also incorporates distributed thinking. For instance, the service gateway is regarded as the first point of contact for microservice communication, rather than a singular centralized component. We deploy a service gateway beside each pod to facilitate more efficient communication.
>
> Regarding the service mesh communication scheduling center, your understanding is accurate. While it serves as a centralized auxiliary component in our architecture to assist with traffic scheduling within the service mesh, it is not a pivotal element for enabling microservice communication. In fact, even without this component, our architecture is still capable of effectively supporting communication between microservices.
>
> We will take your suggestions into careful consideration and further refine our architecture description to more accurately reflect our design philosophy and objectives. Once again, we sincerely appreciate your valuable input, and we look forward to continuing our collaboration to drive further development in our architecture.
> Terminology
> In our document, the primary intent was to introduce a new architectural concept. We recognize the need for further specificity and refinement in terms of the ICN elements we are adopting. Should our architecture gain approval from esteemed experts like yourself, we fully intend to produce subsequent documents that delve into greater detail, offering a comprehensive understanding of our approach.
>
> While the current document serves as an introductory outline, we are committed to producing more comprehensive documentation in the future, elaborating on the specific naming scheme, routing, and security mechanisms we adopt from the ICN framework. Your engagement is invaluable to us as we work towards further refinement.
>
> In our document, a "Pod" refers to a composite unit within a service-oriented network, drawing parallels to the concept of a "Pod" in Kubernetes. Within the context of a service-oriented network, a "Pod" can be comprised of one or multiple services, which collaborate to deliver specific functionalities or business operations.
>
> Drawing an analogy to Kubernetes, each service within a "Pod" can be seen as a functional unit responsible for executing specific tasks or providing designated services. These services have the capacity to share common network contexts, data storage, and other resources, fostering efficient communication and optimal resource utilization.
> Key process / distributed service mesh architecture
> Thank you for pointing out the confusion in our wording. We apologize for the misunderstanding caused. The use of "owned" was a misrepresentation, and the accurate term should indeed be "service located." This phrasing is more precise and aligns with the concept of sharing network namespaces and storage volumes within a "Pod."
>
> Regarding the intricacies of prefix authentication, we understand the need for further clarity. We intend to address this in greater detail through subsequent documentation, where we will provide comprehensive explanations to ensure a complete understanding.
>
> The term "topology link information" refers to the foundational data that contributes to the subsequent creation of the Link State Database. This essential information is broadcast through the interfaces of the Service Gateway. It encompasses the internal topology of pods, the topology between various Service Gateways and pods, and the topology information among pods, Service Gateways, and Service Routers (to be elaborated).
>
> The computation of the Forwarding Information Base (FIB) is a collaborative effort involving both the Service Gateway and the Service Router. In this context, we plan to leverage existing routing protocols for computation, such as ISIS. Detailed documentation regarding this aspect is currently under development.
>
> The term "detection" in this context refers to the process of ensuring the quality and reliability of communication between microservices. To achieve this, the Service Gateway needs to assess the health status and availability of each target microservice. In essence, this "detection" mechanism allows the Service Gateway to monitor and ensure the overall robustness and seamless operation of communication between microservices. A more precise term would be "service availability monitoring".
>
> This monitoring of health status encompasses, but is not limited to, the following aspects:
> Service Liveliness: Verifying if the target microservice is operational and capable of processing requests.
> Resource Utilization: Monitoring the resource usage of microservices to ensure there is no resource depletion or excessive utilization.
> Latency and Response Time: Measuring microservices' response time and latency to ensure there is no significant performance degradation during communication.
> Error Rate: Detecting the error rate of microservices, including request failure rates, abnormal responses, etc., in order to make timely adjustments or take necessary actions.
>
> The Service Gateway gathers this information through regular monitoring mechanisms. This data is then utilized to dynamically distribute traffic and make routing decisions based on the health of microservices. This contributes to a stable service communication environment, ensuring high availability and performance.
> Key communication message types & functions
> In our document, different messages may correspond to different protocols. We plan to continue using existing mature protocols, and specific details will be provided in subsequent documents.
>
> Regarding failure detection, communication, and recovery mechanisms for various components, these critical aspects are part of our ongoing development. We are actively working to define robust processes that ensure timely detection of failures, seamless communication of these events to relevant components, and effective recovery strategies.
>
> As for the instantiation of the initial state defining the structure of a DAMC (Distributed Application Microservices Communication) instance, this is another area of our ongoing refinement. We are carefully considering how to establish the foundational configuration that governs the DAMC instance, incorporating best practices and well-defined procedures.
>
> Regarding service measurement: In our document, service measurement is implemented as follows:
>
> Service Gateway: The Service Gateway assumes the role of traffic proxy within the service-oriented network. Positioned at the forefront of service communication, it not only forwards and processes traffic but also collects data pertaining to communication between services. This encompasses crucial metrics such as traffic data, latency, error rates, and other key indicators.
>
> Service Mesh Communication Scheduling Center: Within the service-oriented network, the Service Mesh Communication Scheduling Center component operates in a manner akin to Istio's Telemetry function. Its responsibility lies in gathering, processing, and storing data generated by the Service Gateway. This data includes access logs, metrics, and information necessary for distributed tracing.
>
> It's important to note that while the general approach is outlined, the precise timescales involved in these measurements are an aspect we are actively developing. The dynamic nature of data center workloads, with rapid and unpredictable evolution over short timescales, is a challenging aspect we are addressing in our ongoing refinement process. We appreciate your insights and recognize the importance of accommodating these dynamic scenarios.
>
> In our document, the composite of multiple microservices forming pods, along with the Service Gateway, Service Router, and Service Prefix Authentication, collectively establishes a distributed microservices communication architecture known as the service mesh.
>
> The service mesh encompasses various pods and their interconnected components, which facilitate communication and coordination among microservices. It is important to clarify that the service mesh does not solely pertain to a single pod; rather, it spans across multiple pods within the architecture.
>
> It's worth noting that the concept of the service mesh addresses challenges and considerations beyond the scope of a single pod, especially in scenarios involving failure domain management within data centers and the distribution of workloads across various data centers or hybrid multi-cloud environments.
>
> While we acknowledge the existence of established approaches such as Istio, Linked, Consul, and others, we are striving to introduce a unique perspective and solution that addresses the specific needs and objectives outlined in our document.
> Operation process…
> The statement may indeed carry ambiguity. Yes, within this architecture, the forwarding plane is responsible for packet error control, flow management, and congestion control.
>
> I understand your concerns regarding the use of authentication/authorization terminology and functions in our architecture. To address this, we are planning to encapsulate authentication signaling as labels within NDN interest packets. We fully acknowledge the need for greater specificity and elaboration on the management of trust, as well as the mechanisms for transitive or delegated authorization. Rest assured, we intend to provide a comprehensive and detailed explanation of these aspects in a separate document.
>
> Thank you for your insight, and you're absolutely correct. In the context of data forwarding, the primary focus is indeed on the Forwarding Information Base (FIB). The reference to the Routing Information Base (RIB) was not accurate in this context.
>
> In our architecture, the Service Gateway ensures that only legitimate Pods with authorized service prefixes are allowed to register within the service mesh and communicate with other pods.
>
> Regarding the categories of signaling, as depicted in Figure Four, I will provide a clearer clarification in the upcoming documentation.
>
> I appreciate your insight and clarification. The term "Link State Database (LSDB)" indeed refers to a well-established concept in IP networks and has received widespread industry support. While I understand that there may be various ways to represent a topology map, including potentially richer alternatives, the use of LSDB has been prevalent and well-recognized.
>
> If there are more widely applicable and convenient methods available, I would greatly appreciate your suggestions. My intention is to ensure the most effective and robust implementation while considering alternative approaches that might enhance our architecture.
>
> Regarding the essential naming question, the association of named entities like "Service B/4" with specific locations is managed through a combination of mechanisms within our architecture.
>
> Service Discovery and Registration: The initial binding of named entities to locations occurs during the service registration process. When a microservice, such as "Service B/4," is deployed or instantiated, it registers its presence and attributes with the service registry or directory. This registration process includes information about the microservice's location, such as IP address, port, or other network-related details.
>
> Service Gateway and Routing: The components of Service Gateway and Service mesh communication center play a vital role in maintaining and updating binding information.
>
> I apologize for the confusion. Thank you for pointing that out. The correct phrasing should be to pass the message to the "pod," not "podcast."
>
> We genuinely appreciate your submission and the candid feedback you've provided. It's evident that our document requires significant refinement, both in terms of its exposition and in the thorough justification of the superiority of our approach compared to existing production systems and research prototypes utilizing ICN protocols.
>
> We acknowledge that our document primarily focuses on the architectural description. If this architectural approach gains recognition, we fully intend to delve into the intricate details through separate documents in the future.
>
> Thank you once again for your valuable insights.
>
> Best regards,
> Xueting Li
>
> From: David R. Oran
> Date: 2023-08-03 23:57
> To: ICNRG
> Subject: [icnrg] Some comments on draft-li-icnrg-damc
> <Chair Hat off>
> I finally got around to reading this. Sorry for the delay - been really busy with NSDI and ICN conference stuff. I have some comments, I hope you find them useful:
> Template
> This doesn’t read as a Standards Track document since it doesn’t define a specific protocol or API. You probably ought to re-classify it as Informational.
> Introduction
> RFC8763 is probably not the best reference to use when describing ICN. Perhaps RFC7927, or better a survey paper like https://ieeexplore.ieee.org/document/6231276
> Could you supply a reference to a paper or material showing the centralized controller as a performance bottleneck? That would be helpful, especially to quantify the problem so alternative distributed approaches could be compared. A couple of the systems I’m familiar with, like Ray (https://rise.cs.berkeley.edu/projects/ray/) don’t exhibit the controller as the prime bottleneck; rather the layout of the microservices done by the controller and how that interacts with the scheduling and congestion control of the network. Other system may of course show the controller as the bottleneck.
> Ditto for scalability and reliability. Often this is ameliorated by having the controller itself be distributed with some coordination via consensus using Paxos or Raft.
> Isn’t the Service Gateway you define centralized? You don’t talk about it as a distributed component. Ditto for the Service Mesh Communication Scheduling Center.
> Terminology
> It would be helpful to be more specific about what parts of ICN you are actually adopting. Specifically:
> What naming scheme? Hierarchical? Flat, Administered how?
> What routing? Is it directly name based or via some NRS (Name Resolution Service) translated to locators?
> Per-object security using packet signatures or something else? You seem to base source origin authentication on Prefixes, which could be fine, but not what the popular extant ICN protocols do.
> ICN is not “defined” in RFC7927. In fact, since here you are defining terminology, a more useful reference would be to RFC8793.
> Similarly, RFC9344 while an important reference for how to instrument and manage an CCNx-based network isn’t the correct reference for a definition of FIB or RIB. In fact, in general those terms apply to just about any routing/forwarding system, and hence likely don’t need a reference, only an expansion of the acronyms.
> In contrast, you probably ought to define what you consider a “Pod”, especially what characteristics you think it has compared to, for example a “rack”, or a “failure domain” in a data center network.
> Key process / distributed service mesh architecture
> Small typo in the section title - missing space “thedistributed”
> I don’t understand why you say “service gateway linked to each of the pods of the service identification information owned by the Pod”. In general I would not think of information as being “owned” by a Pod. Do you mean stored data that is hosted on a particular Pod? Ownership on the other hand is an authentication/authorization concept.
> How are authorizations constructed and communicated? What’s the data structure? What’s the protocol?
> What is “topology link information”? Is that the internal topology graph of a Pod? The connectivity of the Pod to other Pods? Something else? In the same paragraph, it isn’t at all clear who is computing the FIB and how. Is this done by the Service Router, Service Gateway, both? By what routing algorithm/protocol?
> It’s not clear what you mean by “detection”. What are you detecting?
> Key communication message types & functions
> This section is very abstract. Is the intention to evolve this into an actual protocol design? If so, there are lots of open questions:
> what is the transport for these messages? NDN? CCNx? MQTP? HTTPS? something else?
> How are failures of the various components detected, communicated to other components, and recovered from?
> How is the initial state instantiated that defines the structure of a DAMC instance?
> The material on service measurement is very general and it’s very unclear what the timescales it is intended to operate over. In datacenters, workloads typically evolve unpredictably and wildly over timescales as short as a few seconds. That’s why it’s particularly challenging, and it isn’t clear how your general approach deals with that, or whether the existing datacenter measurement tools are not a better choice than something bespoke.
> How does “the entire service mesh” relate to the Pod material above? Is it over a single Pod or many pods, and how does this relate to the existing management of failure domains in a datacenter, not to mention the distribution of workloads across data centers, or even in hybrid multi-cloud scenarios? There are ton of existing approaches for all of these (e.g. Istio - https://istio.io, Linked, Consul); it would really help to reference and cite them to better justify the creation of something new.
> Operation process…
> you say traffic management is a forwarding plane function. That isn’t the normal use of the term. Do you mean packet error control, flow control, and congestion control?
> I’m still befuddled by how you are using authentication/authorization terminology and functions. You need to be a whole lot more specific here, especially in how trust is managed and how things that need transitive or delegated authorization work.
> You say “service gateway, it selects the best path and the next hop according to the rules in the routing information base (RIB) and the Forwarding information base (FIB) to forward the packet to the target Microservices.” Typically individual message/packet forwarding does not require consulting a RIB. If you look at the RIB, why bother computing a FIB in the first place?
> You say “By participating in this authentication process, the service gateway ensures that only legitimate Pods with authorized service prefixes are granted access to the network.” Really? I would expect Pods to need network access for a ton of things unrelated to running a service mesh instance or instances…
> You start here talking about “Class 2” and “Class 3” signaling. Are those the numbered categories in figure 4 or something else? These descriptions confused me.
> Why do you require that you compute a link state database (“Link State Database (LSDB) is generated between the Service Gateway and the Service Router)“ Do you mean a topology map, that could be represented in many ways. An LSDB is one particular form, and not necessarily the best/richest form.
> Coming back the crucial naming question, how are named entities like “Service B/4” bound to locations, and who is responsible for maintaining and updating the binding (ignoring the possibility of things like process or VM or container migration).
> “When the service gateway (SG-4) receives a communication message, it will pass the message to the Podcast” Podcast? What’s that?
> In summary, many thanks for submitting this, but it needs a lot of work in both exposition and in justifying why this approach is in fact better than what we have in production today, or even research prototypes employing ICN protocols like CFN (https://dl.acm.org/doi/10.1145/3357150.3357395).
> DaveO
DaveO

DaveO