Re: [Tsv-art] Tsvart last call review of draft-ietf-core-new-block-11

[Colin Perkins <[e-mail]>]

That’s all fine – thank you!
Colin



> On 30 Apr 2021, at 14:13, <[e-mail]> <[e-mail]> wrote:
> 
> Hi Colin, 
> 
> Please see inline. (removed items that are addressed)
> 
> Cheers,
> Med
> 
> PS: The changes can be tracked here: https://tinyurl.com/new-block-latest <https://tinyurl.com/new-block-latest> 
> 
>> -----Message d'origine-----
>> De : Colin Perkins [mailto:[e-mail] <mailto:[e-mail]>]
>> Envoyé : vendredi 30 avril 2021 13:02
>> À : BOUCADAIR Mohamed TGI/OLN <[e-mail] <mailto:[e-mail]>>
>> Cc : [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; draft-ietf-core-new-
>> [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>> Objet : Re: Tsvart last call review of draft-ietf-core-new-block-11
>> 
>> Hi,
>> 
>> [inline]
>> 
>> On 29 Apr 2021, at 7:52, [e-mail] wrote:
>>> Hi Colin,
>>> 
>>> Thank you for the review.
>>> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : Colin Perkins via Datatracker [mailto:[e-mail]]
>> Envoyé :
>>>> mercredi 28 avril 2021 23:55 À : [e-mail] Cc :
>> [e-mail];
>>>> [e-mail]; last- [e-mail]
>> 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 donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a 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.



-- 
Colin Perkins
https://csperkins.org/