Re: New Version Notification for draft-miao-rtgwg-hpccplus-00.txt

["Miao, Rui" <[e-mail]>]

Thanks Greg and Acee for the comments. 

We will iterate your concerns and address them in our updates. 

Thanks,
Rui


------------------------------------------------------------------
From:Greg Mirsky <[e-mail]>
Sent At:2022 Mar. 21 (Mon.) 08:16
To:Rui <[e-mail]>
Cc:Acee Lindem (acee) <[e-mail]>; rtgwg <[e-mail]>
Subject:Re: New Version Notification for draft-miao-rtgwg-hpccplus-00.txt

Dear Authors,
thank you for the presentation at RTGWG meeting. I have several further comments for your consideration:

I agree with Dean's comment that waiting for the congestion to occur and acting on the notification with unbounded latency will likely cause further degradation of the network condition because of the reactive mechanism. Polling, proposed by Dean, is one way to use telemetry data in a proactive manner. I would refer to the work on Precision Availability Metrics in Multi-SLO services we've presented earlier at the IPPM WG meeting. Monitoring the network and reporting crossed SLO thresholds may be the path to proactively detecting degradation in the network and avoiding congestion altogether.
Overall, it appears that there are two drafts in one - one describing HPPCC++ itself, and another on what telemetry data are required for HPPCC++. It seems like separating these might help the discussion and finding proper places to continue the work.
The draft and presentation emphasize the use of "in-band" OAM methods. Is the intention to collect telemetry information on each data packet? It could be helpful to generalize document and define not how information is obtained (hybrid, active, passive methods) but which information is required to enable HPPCC++.
Regards,
Greg
On Tue, Mar 15, 2022 at 7:25 PM Greg Mirsky <[e-mail]> wrote:

Hi Rui,
thank you for the expedient responses to my questions. I think that there are some aspects of how to obtain the information used to detect the congestion that I'd like to clarify with your help:

From its description, HPCC++ depends on the high-precision information collected along the path, including timestamps. All methods listed in the Section 6.1 collect information into the trigger packet. But such a collection method negatively affects the accuracy of a timestamp because the time value cannot be taken in the course of physical transmission of the packet. What methods and techniques could be used to improve the accuracy of time values recorded?
As I understand it, HPCC++ relies on the collection of telemetry data on all nodes traversed by the packet. If that is true, then that would require that all nodes have their clocks synchronized. And to provide the high precision time values, the accuracy of clock synchronization in the domain must be at least 10 times higher then the required accuracy of time measurements. Hence my next question, What should be the accuracy of clock synchronization for HPCC++?
If I understand your answer #3 correctly, you consider IOAM as an active OAM method. According to draft-ietf-ippm-data and RFC 7799, IOAM is an example of hybrid type 1 measurement method. And since a useful active OAM protocol is always in-band with the monitored flow, I think that the list of protocols in Section 6.1 can be significantly expanded to include other known measurement protocols. What are your thoughts?
Regards,
Greg
On Tue, Mar 15, 2022 at 6:40 PM Miao, Rui <[e-mail]> wrote:
Thanks Greg for the comments.

1. ``inband'' here means the host queries the network telemetry information along the path where its traffic traverses through in real time.
2.  Although the "out-of-band telemetry" may provide feedback-based control via management plane, the target scenario achieves congestion control for low latency (~10 us round trip time) where inband fits better.
3. I would think so. In fact, IOAM (draft-ietf-ippm-ioam-data-17) is part of our implementation examples. 


-Rui




------------------------------------------------------------------
From:Greg Mirsky <[e-mail]>
Sent At:2022 Mar. 15 (Tue.) 16:23
To:Rui <[e-mail]>
Cc:Acee Lindem (acee) <[e-mail]>; rtgwg <[e-mail]>
Subject:Re: New Version Notification for draft-miao-rtgwg-hpccplus-00.txt

Hi Rui,
it seems that the proposed congestion control mechanism is dependent on "inband telemetry". If my understanding is correct, I have several questions:

I see that OAM methods listed in Section 6.1 can be classified, based on RFC 7799, as hybrid measurement methods. It is not clear why they are referred to as "inband". Could you please clarify the interpretation of "inband telemetry" in the draft.
Furthemore, do you see the case of using "out-of-band telemetry" as the basis for the proposed congestion control mechanism?
And lastly, in your opinion, can active OAM methods be used to provide the information necessary for the HPCC++?
Regards,
Greg
On Tue, Mar 15, 2022 at 2:18 PM Miao, Rui <miao.rui=[e-mail]> wrote:
Hi Acee, 

Thanks for the comment. 

HPCC++ proposes an approach to leverage the in-band telemetry for traffic admission and path selection, which we think is more relevant to routing decisions. Besides, HPCC++ is orthogonal to any transports and thus we have several example implementations in the draft. 

Thanks,
Rui

------------------------------------------------------------------
From:Acee Lindem (acee) <[e-mail]>
Sent At:2022 Mar. 15 (Tue.) 12:43
To:Rui <[e-mail]>; rtgwg <[e-mail]>
Subject:Re: New Version Notification for draft-miao-rtgwg-hpccplus-00.txt

Why is this draft in the Routing WG? This work is more applicable to the Transport or Internet Area. 
Acee
From: rtgwg <[e-mail]> on behalf of "Miao, Rui" <miao.rui=[e-mail]>
Reply-To: "Miao, Rui" <[e-mail]>
Date: Tuesday, March 15, 2022 at 2:42 PM
To: Routing WG <[e-mail]>
Subject: Fw: New Version Notification for draft-miao-rtgwg-hpccplus-00.txt
Hello All,

We have posted an updated version of HPCC++ at https://datatracker.ietf.org/doc/draft-miao-rtgwg-hpccplus/ .

There are two major changes since the last presentation. First, since HPCC++ is orthogonal to different in-band telemetry formats and transport protocols, we introduce a few reference implementations over those protocols for people to quickly pick up. 
Second, we advocate a better routing scheme for path selection and traffic admission, building on top of HPCC++'s precise link load information.

Please provide any comments you may have on the draft or its extensions.

Thanks,
Rui




------------------------------------------------------------------
From:internet-drafts <[e-mail]>
Sent At:2022 Mar. 7 (Mon.) 14:35
To:Harry <[e-mail]>; Barak Gafni <[e-mail]>; Changhoon Kim <[e-mail]>; Jeff Tantsura <[e-mail]>; Jeongkeun Lee <[e-mail]>; Rong Pan <[e-mail]>; Rui <[e-mail]>; Yuval Shpigelman <[e-mail]>
Subject:New Version Notification for draft-miao-rtgwg-hpccplus-00.txt


 A new version of I-D, draft-miao-rtgwg-hpccplus-00.txt
 has been successfully submitted by Rui Miao and posted to the
 IETF repository.

 Name:  draft-miao-rtgwg-hpccplus
 Revision: 00
 Title:  HPCC++: Enhanced High Precision Congestion Control
 Document date: 2022-03-07
 Group:  Individual Submission
 Pages:  20
 URL:             https://www.ietf.org/archive/id/draft-miao-rtgwg-hpccplus-00.txt
 Status:          https://datatracker.ietf.org/doc/draft-miao-rtgwg-hpccplus/
 Htmlized:        https://datatracker.ietf.org/doc/html/draft-miao-rtgwg-hpccplus


 Abstract:
   Congestion control (CC) is the key to achieving ultra-low latency,
   high bandwidth and network stability in high-speed networks.
   However, the existing high-speed CC schemes have inherent limitations
   for reaching these goals.

   In this document, we describe HPCC++ (High Precision Congestion
   Control), a new high-speed CC mechanism which achieves the three
   goals simultaneously.  HPCC++ leverages inband telemetry to obtain
   precise link load information and controls traffic precisely.  By
   addressing challenges such as delayed signaling during congestion and
   overreaction to the congestion signaling using inband and granular
   telemetry, HPCC++ can quickly converge to utilize all the available
   bandwidth while avoiding congestion, and can maintain near-zero in-
   network queues for ultra-low latency.  HPCC++ is also fair and easy
   to deploy in hardware, implementable with commodity NICs and
   switches.




 The IETF Secretariat
 _______________________________________________
 rtgwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtgwg