| That’s all fine – thank you! Colin
Hi Colin, Please see inline. (removed items that are addressed)Cheers,MedPS: The changes can be tracked here: https://tinyurl.com/new-block-latest -----Message d'origine-----
De : Colin Perkins [mailto:csp@xxxxxxxxxxxxx]
Envoyé : vendredi 30 avril 2021 13:02
À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@xxxxxxxxxx>
Cc : tsv-art@xxxxxxxx; core@xxxxxxxx; draft-ietf-core-new-
block.all@xxxxxxxx; last-call@xxxxxxxx
Objet : Re: Tsvart last call review of draft-ietf-core-new-block-11
Hi,
[inline]
On 29 Apr 2021, at 7:52, mohamed.boucadair@xxxxxxxxxx wrote:
Hi Colin,
Thank you for the review.
Please see inline.
Cheers,
Med
-----Message d'origine-----
De : Colin Perkins via Datatracker [mailto:noreply@xxxxxxxx]
Envoyé :
mercredi 28 avril 2021 23:55 À : tsv-art@xxxxxxxx Cc :
core@xxxxxxxx;
draft-ietf-core-new-block.all@xxxxxxxx; last- call@xxxxxxxx
Objet :
Tsvart last call review of draft-ietf-core-new-block-11
Reviewer: Colin Perkins
Review result: Ready with Issues
In Section 7.2, I’m not convinced by the argument to set
MAX_PAYLOAD
to 10 for similar reasons to RFC 6928. The types of link layer
that
CoAP runs over are very different to those measured to support the
increase in TCP’s initial window. An argument based on typical
properties of links and buffer space in networks used by CoAP
would
be more convincing (I accept that using MAX_PAYLOAD of 10 is not
going to do any significant harm, even if it is higher than
optimal).
[Med] Actually we set it to 10 as the applicability scope of this
spec
is DOTS which runs in environments similar to those of 6928. Please
see Section 3.2.
This would be a lot clearer if Section 3.2 were cross-referenced, and
a reminder of the limited applicability of this specification was
added to Section 7.2.
[Med] Made this change: OLD: Note: The default value of 10 is chosen for reasons similar to those discussed in Section 5 of [RFC6928].NEW: Note: The default value of 10 is chosen for reasons similar to those discussed in Section 5 of [RFC6928], especially given the target application discussed in Section 3.2.Section 7.2 also notes that “PROBING_RATE and other transmission
parameters are negotiated between peers”. It would be appropriate
to
give some guidance on what are the bounds for safe values that can
be
negotiated for these parameters.
[Med] I'm afraid this is out of the scope of this spec. The intent
of
this note is to provide an example of an application that
negotiates
these parameters. Some of these details can be found in in
rfc8782#section-4.5.2 mentioned in the text you quoted.
Makes sense, although I wonder if the text in Section 7.2 might be
more clearly written “The DOTS application uses customised defaults
for PROBING_RATE and other transmission parameters, as discussed in
Section
4.5.2 of [RFC8782], that are negotiated between peers”?
[Med] Thank you, but I prefer the old wording.
and I would suggest that even if there are such issues, backoff
would
be appropriate given persistent congestion.
Finally, is there are mechanism for gradually recovering
MAX_PAYLOADS
to its original value, if persistent loss ceases for some period?
[Med] This is covered by the configuration refresh/negotiation
mechanism. The peers will refresh the configuration parameters
following, for example, I-D.bosh-dots-quick-blocks.
Might be worth stating that in the draft?
[Med] After thinking about this further, we added this NEW text:NEW: Following a period of 24 hours where no packet recovery was required, the value of MAX_PAYLOADS can be increased by 1 (but without exceeding the default value) for a further 24 hour evaluation._________________________________________________________________________________________________________________________Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent doncpas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signalera l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.This message and its attachments may contain confidential or privileged information that may be protected by law;they should not be distributed, used or copied without authorisation.If you have received this email in error, please notify the sender and delete this message and its attachments.As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.Thank you.
|
