Hello, Thanks for your comments. We have published a new version of the draft (-14). Please see some comments in line. Please let us know any other comments. Best regards, Authors Compound ACK draft > On Mar 10, 2023, at 9:48 AM, Tianran Zhou <zhoutianran@xxxxxxxxxx> wrote: > > Hi Sergio, > > Thanks for your clarification. Please see in line. > > Cheers, > Tianran > > > -----Original Message----- > From: Sergio Aguilar Romero [mailto:sergio.aguilar.romero@xxxxxxx] > Sent: Sunday, March 5, 2023 1:36 AM > To: Tianran Zhou <zhoutianran@xxxxxxxxxx> > Cc: ops-dir@xxxxxxxx; draft-ietf-lpwan-schc-compound-ack.all@xxxxxxxx; last-call@xxxxxxxx; lp-wan@xxxxxxxx > Subject: Re: Opsdir last call review of draft-ietf-lpwan-schc-compound-ack-12 > > 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. > > ZTR> OK. Is there any mechanism so that the receiver know whether the sender is Compound ACK compatible or not? If the receiver know that the sender is not compatible, I think the receiver behavior makes sense. > There is no such mechanism, however the receiver can suspect that the sender is not reading the extra windows that are notified in the Compound ACK, as another Compound ACK requests retransmissions for the extra windows that were present in previous Compound ACKs. Therefore, the receiver can suspect if the sender is not Compound ACK compatible, however, it cannot be sure, as also it can be that due to link quality the SCHC Fragments are getting lost and the sender is actually sending the tiles from all windows that were notified in the Compound ACK. We added the following text in section 3.2: The receiver can suspect if the sender does not support the SCHC Compound ACK, if the sender does not resend any tiles from windows that are not the first one in the SCHC Compound ACK and more ACKs are needed. > 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. > > > ZTR> I am ok this this clarification. > > >> 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
