Hi Marco, All, The draft identifies a gap/problem in 5G systems and the need to (re)select and steer flows. This draft can provide value and insight into a complex area. There are gaps currently as 5G/3GPP does not fully cover the N6/IP segments of the E2E path.
However, the draft describes too much of existing/standards (using different names and terms), and it is not easy for a reader to distinguish the gaps from already specified standards. A couple of suggestions: 1. Since the architecture in section 4 is 5G, why not use the same terminology/refer to TS 23.501. And add concepts that are new. This will make the text shorter and allow readers to see clearly what the gaps are. For example, what part of the architecture in Figure 4 is covered in 23.501, and what isn't (same for many others). 2. Regarding the gaps, there are architectural principles and options in section 5 + but the draft does not outline the tradeoffs or say when one option is preferrable over the other. For example: if services/network require to only maximize bandwidth utilization vs. guarantees on latency/bandwidth. And, resilience, complexity (e.g., O(n^2) vs O (n), scalability, etc. Another aspect is the relation between this draft and CATS. Where are they complementary, or an alternative and the rationale for choosing among these methods of steering. Some detailed comments: 1. Abstract & section 4.1 refer to "two architectural principles" but is not clarified what it is until much later. The reader must read until section 5 to understand what it is about steering. It should be stated much earlier and described later for easier reading. 2. Section 2 / Introduction: discusses " how existing or new IETF technology can serve as enabler to accomplish service continuity for a mobile user in such agile and dynamic system by means of controlled treatment of a mobile user's end-to-end traffic for steering, with an option to extend for advanced treatment policies, such as traffic engineering." Many concepts, and options make it hard to follow: (1) the scope has steering and "advanced treatment policies", and steering policies. What exactly are the differences? (2) does advanced treatment policies refer to QoS aspects? (3) steering and service continuity: does user mobility trigger steering, or does measurement on path trigger steering, or both? (4) The draft has many terms like "flexible deployment", dynamic re-configurability, complexity which can be understood in different ways. 3. Section 4.2. MCS Proactive UPA relocation : "proactive" is a bit confusing and depends on perspective. (1) "Due to mobility, the MCS may relocate the mobile user's UPA from UPA1 to UPA2": that would seem more reactive? (2) "In case the user's IP address needs to continue only as long as the data session with ASF1 takes .." How does UPA know how long the session lasts? 4. Section 4.2 "In order to keep routing paths short and latency low, the ASF may be relocated from ASF1 to ASF2". How does ASF /data network know how to do this? Does MCS proactively relocate the UPA (UPA1 -> UPA2) based on some measurements of the path UPA1 - ASF1 and expect to have better performance after the move UPA2 -> ASF1? 1. Section 4.4: "A MCS provide may deploy distributed UPAs in order to shorten the route and resulting latency for the communication between two mobile users" Why is there a need to move UPA for shorter paths? Isn't it possible to have a routed network (with DPNs) that select the shortest/lower latency path etc. The problem seems to be that the UPA is not distributed enough (that one has to move from UPA1 -> UPA2 to get a shorter path to UPA3) 2. Section 5:/ deployment options. Between the different options what is the trade-off in terms of scale and complexity (of provisioning/maintaining the paths) See overall comments also. Best Regards, John
_______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
