Re: [Last-Call] Tsvart last call review of draft-ietf-lpwan-schc-compound-ack-14

[Sergio Aguilar Romero <sergio.aguilar.romero@xxxxxxx>]

Hello,

Thanks for your review.

Please find some comments inline.

Best regards,

Authors Compound ACK draft

On Mar 14, 2023, at 4:13 PM, Wesley Eddy via Datatracker <noreply@xxxxxxxx> wrote:

Reviewer: Wesley Eddy
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.

In general, the document seems to be clear and well written.  I did not find
any technical issues or corrections to note.

Comments:
- The reason for using this is explained as reducing the number of ACK
transmissions.  Is there a corresponding cost (e.g. slower recovery from
losses) that should also be mentioned so that the tradeoffs are clear?

The SCHC Compound ACK not only offers the application the option to reduce the number of ACKs, but also it increases the downlink opportunities, as now after the All-0 fragment an ACK can be received, providing flexibility on when the ACK can be received. This flexibility also allows the receiver to increase or reduce the size of the ACK (by having one or more windows notified). However, depending on how the application is configured, the reduction can actually have a positive impact on application delay, buffer sizes and timers. 

Note that in RFC8724, the receiver has to wait to the All-1 fragment to send an ACK notifying just one window of tiles. Now, the receiver (and application) can have notifications before, as the Compound ACK can be send after the All-0 fragment. Moreover, if the receiver (and application) decide to wait for the All-1 fragment, the number of ACKs may be reduce (it depends if there are fragment losses in intermediate windows) and delay, buffer size and timer are not modified with respect RFC8724.

In introduction and section 3.2 is stated:

Introduction: 
"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."

Section 3.2:
“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."

- The
shepherd writeup mentions a Sigfox implementation.  It would be of interest to
note whether compound ACKs have been found to be beneficial in practice or note
any quantification of the expected benefits.  Of course these are heavily
dependent on the specific LPWAN and configuration, so it would just be
anecdotal data.

The SCHC over Sigfox draft uses the SCHC Compound ACK, therefore, implementation started over Sigfox. In terms of benefits, note that in the SCHC over Sigfox draft, the Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 1 is optimized so that all windows can be notified in a single SCHC Compound ACK. This allows for a single ACK to provide feedback from all SCHC Fragments sent, for example, during the day.  
In section 3.5.1.4.1 of the SCHC over Sigfox draft is stated:
“ Note that WINDOW_SIZE is limited to 12.  This because, 4 windows (M =
  2) with bitmaps of size 12 can be fitted in a single SCHC Compound
  ACK."

Therefore, this optimization actually help reduce the needed number of ACKs to notify losses around the complete day, and provide options to obtain feedback before, by sending an ACK after the All-0.

- There are older RFCs from the PILC working group that provide
advice for subnetwork design (e.g. RFC 3819).  I was surprised not to find that
cited here as a reference, as it might be important regarding tuning of
configuration parameters.

This draft updates RFC8724 and RFC9363, which did not mention older RFCs.

Very minor comments:
- Section 4 has "Examples" (plural) in the title, however, it really only
contains a single example.  It could be "Example" instead.

Fixed, thanks.

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call