[6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-6lo-fragment-recovery-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this well written document, however, I have a couple points below
that need further clarification, all mostly related to congestion control. From
an editorial point of view most of this is discussed either in the intro text
of section 6, then some part in 7.1, and some in the appendix C. I would really
recommend you to instead have a separate section that much clearer states what
should be done by default (probably no dynamically window but a small fixed
window with maybe size of 1) and what could be don as further optimisation, and
also to discuss the parameter/variables there before the algorithms are
discussed.

And a bit of a provoking question: wouldn't it be easier to just use a reliable
transport protocol on top? If this mechanism is intended to be used over a
short path with a few hops only (in a local network), I think this should be
stated more clearly at the beginning of the document. In the appendix you state
this: " In addition, deploying such a mechanism requires
   that the end-to-end transport is aware of the delivery properties of
   the underlying LLN,..."
But I'm not sure what you mean...? Can you further explain?

1) Sec 6:
"Upon exhaustion of the retries the
   sender may either abort the transmission of the datagram or retry the
   datagram from the first fragment with an 'X' flag set in order to
   reestablish a path and discover which fragments were received over
   the old path in the acknowledgment bitmap. "
I'm not sure about this "or". Why should the first fragment be more successful
than any other which requests an ACK? Also if you really want to keep this
condition, you need to specify it better. How often do you retry? I guess you
need to set the PTO again...? Further the RTO should also implement an
exponential back-off.

2) sec 6.3:
"Upon an acknowledgment with a NULL bitmap, the sender endpoint
   MUST abort the transmission of the fragmented datagram with one
   exception: In the particular case of the first fragment, it MAY
   decide to retry via an alternate next hop instead."
What's mean with "In the particular case of the first fragment"? And does this
mean it should retry only with the first fragment or the whole transmission.
However, if this signal is from the receiving endpoint why should that endpoint
change it mind only if a different path is used? If the assumption is that this
NULL bitmap is sent by an intermediate node? However, then it would make sense
to  rather signal this information explicitly (e.g. using a flag).

3) Sec 7.1 (and to some extend sec 6)
"   OptWindowSize:  The OptWindowSize is the value for the Window_Size
      that the sender should use to start with.  It is greater than or
      equal to MinWindowSize.  It is less than or equal to
      MaxWindowSize.  The Window_Size should be maintained below the
      number of hops in the path of the fragment to avoid stacking
      fragments at the bottleneck on the path.  If an inter-frame gap is
      used to avoid interference between fragments then the Window_Size
      should be at most on the order of the estimation of the trip time
      divided by the inter-frame gap."
This needs normative language and more explanation. I recommend to even say
that if no congestion control (as discussed in the appendix) is applied, the
Window MUST be set to 1. Further, the assumption that the window can or should
be set to (at maximum) the number of hop does seem correctly to me. No matter
how many hops there are packets are only queued at the bottleneck (the link
where the current rate is smaller than the sending rate) and it depends on the
sending rate of the bottleneck link how many packets need to be queued. This is
completely independent of the number of hops. Further, even if that would be
true, as long as this document does not discuss also away to estimate or know
the number of hops, this advise would unfortunately be useless... Further I
don't think pointing to rfc6298 for RTT calculation is sufficient (as done in
the appendix). rfc6298 assume frequent ACKs and a reasonably large window,
which is both not the case here. All in all, any window adjustments itself are
not described at all. What should be done when a congestion marking is
received? How does the window need to be adjusted based on an RTO? When should
the window be increased again? And how much?

4) Sec 7.1.: Inline with the TSV-ART review (Thanks Collin!), the parameters
need more guidance. Especially for he number of retries it should be possible
to recommend a default value (e.g. 3) and it would be good to also give an
upper limits (MUST NOT be larger than X). Similar for the window size: there
should be also at least a default value (see comment above). And further the
RTO needs further explanation about how to find a reasonable value. If the RTO
is configured (and not estimated dynamically) e.g. it could be set to 3x the
maximum expected RTT in the respective network. And it would be even better to
provide a minimum default (initial) value. Not that TCP is also designed to
work on a large variety of timescales and a minimum initial value of 1s is seen
as safe for all Internet scenarios. It's really important to also provide some
recommendations like this here.

5) Sec 7.2:
"The management system should monitor the number of retries and of ECN
   settings that can be observed from the perspective of both the sender
   and the receiver, and may tune the optimum size of Fragment_Size and
   of Window_Size, OptFragmentSize, and OptWindowSize, respectively, at
   the sender."
This does not see seem correct, as OptFragmentSize and OptWindowSize are the
initial values which are configured and therefore should not be changed
dynamically. Only Fragment_Size and Window_Size are changes. Further the
network should also normatively state somewhere that Fragment_Size and
Window_Size MUST not grow above the configured max value. That seems obvious
but it's better to be explicit and use normative language respectively.

6) Further sec 7.2 says:
"The inter-frame gap is another tool that can be
   used to increase the spacing between fragments of the same datagram
   and reduce the ratio of time when a particular intermediate node
   holds a fragment of that datagram."
However, inter-frame gap is a configuration parameter and this is the first
time that adapting it dynamically is mentioned here. If you want to adapt it
dynamically you need to add more information.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) side comment regarding section 2.2: Note that there is also a working group
draft defining PMTUD for datagram transports: draft-ietf-tsvwg-datagram-plpmtud

2) Sec 6:
"Note that acknowledgments might consume precious resources so the use
 of unsolicited acknowledgments should be configurable and not enabled
   by default."
Maybe SHOULD?

3) Sec 6: Maybe use normative language here?
OLD
"Fragments are sent in a round-robin fashion: the sender sends all the
   fragments for a first time before it retries any lost fragment; lost
   fragments are retried in sequence, oldest first.  This mechanism
   enables the receiver to acknowledge fragments that were delayed in
   the network before they are retried."
NEW
"Fragments MUST be sent in a round-robin fashion: the sender MUST send all the
   fragments for a first time before it retries any lost fragment; lost
   fragments MUST be retried in sequence, oldest first.  This mechanism
   enables the receiver to acknowledge fragments that were delayed in
   the network before they are retried."

4) Sec 6:
"When a single frequency is used by contiguous hops, the sender should
   insert a delay between the frames (e.g., carrying fragments) that are
   sent to the same next hop.
Maybe SHOULD?

5) sec 6.3:
"Until the timer
   elapses, fragments of that datagram may still be received, e.g. if
   the RFRAG-ACK was lost on the way back and the source retried the
   last fragment.  In that case, the router forwards the fragment
   according to the state in the VRB."
Why should a router forward the segment, rather than re-sending/re-generating
the full ACK knowing that all segments have been successfully received?

6) sec 8:
As currently described an off-path attacker could abort the transmission if the
datagram_tag is known. I think it should be mention somewhere that a null
bitmap should only be accepted and forwarded if received on the right
interface. Further it might make sense to not erase state immediately but wait
to see if any further fragments are received from the sender. In any case this
attack should at least be mentioned in section 8.

7) Appendix B:
"The recovery mechanism must support highly
      fragmented packets, with a maximum of 32 fragments per packet."
Where does the 32 come from and shouldn't this be stated normatively in body of
the document?

Nit: you use both "time out" and "time-out". I recommend to change the two
occasions of "time out" to "time-out".