David>Comments inline … Thanks, --David
From: Jiayuan Hu <[email protected]> Sent: Friday, November 21, 2025 4:30 AM To: Black, David <[email protected]>; RTGWG <[email protected]> Cc: Black, David <[email protected]> Subject: Re: [rtgwg] Credit based flow control (draft-hu-rtgwg-cbfc-rsvp) You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [EXTERNAL EMAIL] Hello David, Sorry for late reply, thanks for your comments. Please see below of the replies marked by [Hugh]. Best Regards Jiayuan Hu ________________________________ Jiayuan Hu （Hugh） From: Black, David<mailto:[email protected]> Date: 2025-11-06 04:24 To: [email protected]<mailto:[email protected]> CC: Black, David<mailto:[email protected]> Subject: [rtgwg] Credit based flow control (draft-hu-rtgwg-cbfc-rsvp) Expanding on my comments in the meeting earlier today on: Credit-based Flow Control Based on RSVP for RDMA transmission in WAN https://datatracker.ietf.org/doc/draft-hu-rtgwg-cbfc-rsvp/ Credit-based flow control is complex and subtle. RSVP is already complex enough - this proposal adds not just credit-based flow control, but flow-based credit-based flow control, which significantly increases complexity. [Hugh] I am considering reducing the number of interactive devices involved, from 'every device involved in the transmission task' to 'partial or critical devices involved in the transmission task'(for example, like only ingree PE and egress PE will involved), which can reduce the frequency of interaction between devices. What do you think? David> I remain unconvinced that RSVP is a good protocol carrier for this functionality and suggest exploration of alternatives. This draft’s proposed mechanism depends on RSVP maintaining credit state. All RSVP state is “soft state” that is dropped if not refreshed - there will be situations (e.g., some error cases) in which RSVP drops state due to lack of refresh, which risks dropping credits. That’s a specific example of an area of complexity and subtlety - the normal operation case of credit-based flow control is easy to specify … but … there are inevitably situations that lose credits … and … if such a situation repeats, enough credits are eventually lost to prevent transmission. A quick read of the draft suggests that no attempt is made to recover credits - any detected credit loss problem causes failover to the backup path. That response is likely to be too aggressive - an attempt should be made to recover credits before making that dramatic a change. [Hugh] Thank you for the reminder. The previous plan did not take into account the solution in case of unexpected loss of credit information. I am considering using the method of slowing down and retransmitting credit information, which can refresh the status of credit in a timely manner without causing flow control failure due to loss of credit messages. David> I agree that RSVP “soft state” refresh could be helpful in detecting/correcting credit loss. Unfortunately, detecting credit loss necessarily races with the current credit state, making the actual detection of credit loss (which can be caused by more than loss of credit messages) subtle. There is some possibly-related IETF credit-based flow control work for the DLEP protocol in the manet WG - see draft-ietf-manet-dlep-credit-flow-control<https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-credit-flow-control/>. Related drafts can be found from the manet WG's documents page<https://datatracker.ietf.org/wg/manet/documents/> . Thanks, --David David L. Black, Sr. Distinguished Engineer, Technology & Standards Infrastructure Solutions Group, Dell Technologies mobile +1 978-394-7754 [email protected]<mailto:[email protected]>
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
