Hello, Thanks for your review. We have published a new version of the draft (-13). Also, we have added some comments below. Please let us know any other comments. Cheers, Author Compound ACK draft > On Mar 2, 2023, at 10:14 AM, Tianran Zhou via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Tianran Zhou > Review result: Has Issues > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects of > the IETF drafts. Comments that are not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs should > treat these comments just like any other last call comments. > > This draft introduces an SCHC Compound ACK message, which is intended to reduce > the number of SCHC ACKs in the ACK-on-Error mode. > >> From the operation point of view, there are several concerns. > 1. What's the interaction with legacy devices? I.e., what if the sender does > not support the Compound ACK message? Version -12 has the following text indicating that the Compound ACK is backwards compatible, in the sense that if a SCHC receiver supports Compound ACK and the SCHC sender does not, the receiver can send a Compound ACK with only one window and one bitmap, which is the format of the ACK in RFC8724. Original text in version -12 Section 3.2. Paragraph 2. The SCHC ACK format, as presented in [RFC8724], can be considered a special SCHC Compound ACK case, in which it reports only the tiles of one window. Therefore, the SCHC Compound ACK is backwards compatible with the SCHC ACK format presented in [RFC8724]. To make it more clear, we added the following text to the introduction of version -13. The SCHC Compound ACK is backwards compatible with the SCHC ACK as defined in [RFC8724], and introduces flexibility, as the receiver has the capability to respond to the All-0 SCHC Fragment, providing more downlink opportunities, and therefore adjusting to the delay Requirements of the application. > 2. Combining several ACKs to one Compound > ACK will introduce more response delay(no?). What's the impact to the sender? > For example, more buffer/cache for re-sending messages. For example, the > setting of timer expiration, etc. > The Compound ACK draft actually provides flexibility as it is possible to send an ACK after each window of tiles, therefore the application can select when to send the Compound ACK, allowing for smaller ACKs, e.g., with just one window or larger ACKs notifying more than one window. In case the application wants larger ACKs, and therefore reduce the total number of ACKs, it has to consider the buffer/cache and timer values. We have added more information in version -13 to clarify that a delay may be introduced. Text from version -13 found in section 3.2. paragraph 3. Also, some flexibility is introduced with respect to [RFC8724], in that the receiver has the capability to respond to the All-0 with a SCHC Compound ACK or not, depending on certain parameters, like network conditions. Note that even though the protocol allows for such flexibility, the actual decision criteria is not specified in this document. New text of section 3.2. paragraph 3 in version -13. Also, some flexibility is introduced with respect to [RFC8724], in that the receiver has the capability to respond to the All-0 with a SCHC Compound ACK or not, depending on certain parameters, like network conditions, sender buffer/chache size, supported application delay. Note that even though the protocol allows for such flexibility, the actual decision criteria is not specified in this document. The application MUST set expiration timer values according to when the feedback is expected to be received, e.g., after the All-0 or after the All-1. New text added in introduction of version -13: The SCHC Compound ACK is backwards compatible with the SCHC ACK as defined in [RFC8724], and introduces flexibility, as the receiver has the capability to respond to the All-0 SCHC Fragment, providing more downlink opportunities, and therefore adjusting to the delay Requirements of the application. > I do not think these are big issues, but I hope there are texts to clarify in > the document. > > We added some text to clarify the different points. Let us know if it more clear now. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
