Network Working Group Z. Du Internet-Draft China Mobile Intended status: Informational 4 June 2024 Expires: 6 December 2024 Dynamic QoS Mechanism draft-du-dynamic-qos-00 Abstract This document describes a dynamic QoS (Quality of Service) mechanism. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 December 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Du Expires 6 December 2024 [Page 1] Internet-Draft Dynamic QoS June 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Assumptions for Coordination . . . . . . . . . . . . . . . . 3 3. Coordination Mechanism . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The traffic in the network normally have a QoS type marked in the packet header. For example, the IPv4 packets have a Type of Service (ToS) field, and the IPv6 packets have a Traffic Class (TC) field. A ToS/TC byte includes a DSCP codepoint and precedence bits. It would influence the Hop-by-Hop (HBH) behavior of the packet, and it is used in a DiffServ QoS model as mentioned in [RFC2983] and [RFC4594]. Differentiated Services (DiffServ) is a set of end-to-end QoS capabilities. End-to-end QoS is the ability of the network to deliver service required by specific network traffic from one end of the network to another. However, currently the QoS is static, and is used only within the network. In the Computing and Network Convergence (CNC), it is believed that the delay within the network and the delay caused by the computing is comparable, for example, both at the millisecond (ms) level [I-D.ietf-cats-usecases-requirements]. Some kind of coordination of network and computing can take place in the CNC. However, it is hard to communicate between the two different domains, i.e., the network domain and the computing domain. In this document, we propose a dynamic QoS mechanism to enable a simple coordination of the network and computing. Du Expires 6 December 2024 [Page 2] Internet-Draft Dynamic QoS June 2024 2. Assumptions for Coordination There are two assumptions for the dynamic coordination. 1. The network can provide three kinds of treatment for a traffic flow, for example, the gold level, the silver level, and the bronze level. 2. The computing domain can also provide different kinds of service scheduling, for example, a best service, a better service, or a normal service. In the traditional method, the service marked by a high priority should have a high QoS treatment in all the places, the service marked by a middle priority should have a at least middle QoS treatment, and the service marked by a low priority would have whatever a treatment in all the places. 3. Coordination Mechanism In the proposed method, we add a dynamic value for QoS field in the packet header. For example, we can have a three-bit value for the traditional QoS priority, and another three-bit value for the dynamic QoS (DQoS). The first value is static, and the second value is dynamic and changeable. Some changing principle of the DQoS is listed as follows: 1. The DQoS value is marked as 4 by default. 2. If the packet is treated at a QoS level the same as the marked QoS level, the DQoS value will not be changed. We call it a normal process. 3. If the packet is treated at a QoS level higher than the marked QoS level, the DQoS value can be added. We call it a better process. 4. If the packet is treated at a QoS level lower than the marked QoS level, the DQoS value can be reduced. We call it a worse process. Du Expires 6 December 2024 [Page 3] Internet-Draft Dynamic QoS June 2024 The decision points in the network domain or in the computing domain would try to make the DQoS return to 4 as best as they can if the DQoS is not 4. Of course, if the resource corresponding to a QoS level is not enough, the decision points will treat some traffic flows different from the marked static QoS. Meanwhile, the treatment will be recorded by the DQoS. Hence, the resource of network and computing domain can do some coordination. The decision points in the network domain can be the headend node, which can choose different tunnels/policies to a target. The decision points in the computing domain can be the LB (Load Balancing) equipment, which can schedule a specific Server/vServer for the user traffic. They can both receive and send packets from users. 4. IANA Considerations TBD. 5. Security Considerations TBD. 6. Acknowledgements TBD. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 7.2. Informative References [I-D.ietf-cats-usecases-requirements] Yao, K., Trossen, D., Boucadair, M., Contreras, L. M., Shi, H., Li, Y., Zhang, S., and Q. An, "Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements", Work in Progress, Internet-Draft, draft- ietf-cats-usecases-requirements-02, 1 January 2024, . Du Expires 6 December 2024 [Page 4] Internet-Draft Dynamic QoS June 2024 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, . [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, . Author's Address Zongpeng Du China Mobile No.32 XuanWuMen West Street Beijing 100053 China Email: duzongpeng@foxmail.com Du Expires 6 December 2024 [Page 5]