Re: [netconf] Tsvart early review of draft-ietf-netconf-udp-notif-11

[Mahesh Jethanandani <[e-mail]>]

Hi Michael, thanks for your review.

Alex,

See inline.

> On Jan 21, 2024, at 11:40 PM, Alex Huang Feng <[e-mail]> wrote:
> 
> Dear Michael,
> 
> Thanks for all the comments and raised issues. 
> Thanks Mahesh for arranging the tsvdir review.
> 
> We have submitted a new version of the draft addressing the raised issues: 
> - https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-12 <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-12>
> - Diff: https://author-tools.ietf.org/iddiff?url1=draft-ietf-netconf-udp-notif-11&url2=draft-ietf-netconf-udp-notif-12&difftype=--html <https://author-tools.ietf.org/iddiff?url1=draft-ietf-netconf-udp-notif-11&url2=draft-ietf-netconf-udp-notif-12&difftype=--html>
> 
> We also have some comments regarding some raised points:
> 
> * I wonder how the sender side knows, what the receiver is able to process.
>   It might make sense to exchange this information at the beginning of
>   the communication.
> AHF: UDP-notif is designed for “Configured Subscriptions”, meaning it is expected that the operator configures transport in the exporter node and the collector.

[mj] We had a similar issue brought up in HTTPS Notif draft also. I think it would be helpful to have some text that explains that the idea of UDP notif is a lightweight process that can start sending notifications without knowing too much about what the receiver is capable of. This is being done primarily to distinguish from current mechanisms where a session has to be established before the first notification can be sent. However, at the same time, the sender has to be prepared to deal with any errors that it might receive, if the receiver does not like what it is getting, and wants to push back.

> 
> * Using the suggested protocol results in a high bandwidth using UDP based
>   communication. It is really suggested to use some sort of congestion
>   control. However, the document arguments that this is not needed, since
>   the protocol is used only on "managed networks" as stated in Section 5.1.
>   What confuses me is that in Section 6, the document discusses the use
>   of the protocol in "open or unsecured" networks. How does this relates
>   to "managed networks"? In my understanding, this does not fit. Do you
>   really not need some congestion controller?
>   I would expect to see some sort of circuit breaker, but have not seen
>   a description of it.
> AHF: We have removed “open networks” from the draft. UDP-notif is designed to be deployed in controlled environments provisioned for the purpose of monitoring, not the General Internet as defined in https://www.rfc-editor.org/rfc/rfc8085.html#section-3.6 <https://www.rfc-editor.org/rfc/rfc8085.html#section-3.6>
[mj] The section you cite says:

      The application traffic may then be managed to avoid
      congestion, rather than relying on built-in mechanisms, which are
      required when operating over the general Internet.

Where in document do you talk about managing congestion?

Thanks.

> 
> * Section 4.2
>   What should happen if the Private Encoding Option is present, but the S-bit is
>   not set? What should happen if the S-bit is set, but the Private Encoding Option
>   is not present?
> AHF: The private Encoding Option is informative, the operator can configure the collector anticipating the collection of a private encoding.
> We have added that when S is set, the private option SHOULD be present.
> 
> Cheers,
> 
> Alex, on behalf of the authors
> 
> 
>> On 17 Nov 2023, at 17:52, [e-mail] wrote:
>> 
>>> On Nov 16, 2023, at 01:37, Mahesh Jethanandani <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>>> On Nov 15, 2023, at 2:17 PM, [e-mail] wrote:
>>>> 
>>>>> On Nov 15, 2023, at 22:47, Mahesh Jethanandani <[e-mail]> wrote:
>>>>> 
>>>>> Hi Michael,
>>>>> 
>>>>> Thanks for your review of the document.
>>>>> 
>>>>> One of the discussions before the WG was on what the draft calls out as “segmentation”. The draft proposes this solution to deal with UDP packets that are larger than the path MTU, and will result in fragmentation at the IP level. Note, the end application requires that packets be received in sequence and be complete for the application to process. Otherwise, the packet needs to be discarded. Also to note is that there is no retransmission of the frame if the packet is discarded for any reason.
>>>>> 
>>>>> Did you have any comments from a transport perspective, on applications that run over UDP, and propose to use fragmentation (segmentation in this draft) and reassembly logic at the application level with no retransmission?
>>>> Hi Mahesh,
>>>> 
>>>> what user message sizes or number of fragments per user message do you expect?
>>> 
>>> The discussion was for max-size UDP message - 64K.
>> I updated the review. Sorry for missing to read the comment in the review request.
>> 
>> If you have further questions, please let me know.
>> 
>> Best regards
>> Michael
>>> 
>>> Thanks
>>> 
>>>> 
>>>> Best regards
>>>> Michael
>>>>> 
>>>>> Thanks.
>>>>> 
>>>>>> On Nov 15, 2023, at 7:14 AM, Michael Tüxen via Datatracker <[e-mail]> wrote:
>>>>>> 
>>>>>> Reviewer: Michael Tüxen
>>>>>> Review result: Not Ready
>>>>>> 
>>>>>> Major issue:
>>>>>> Using the suggested protocol results in a high bandwidth using UDP based
>>>>>> communication. It is really suggested to use some sort of congestion
>>>>>> control. However, the document arguments that this is not needed, since
>>>>>> the protocol is used only on "managed networks" as stated in Section 5.1.
>>>>>> What confuses me is that in Section 6, the document discusses the use
>>>>>> of the protocol in "open or unsecured" networks. How does this relates
>>>>>> to "managed networks"? In my understanding, this does not fit. Do you
>>>>>> really not need some congestion controller?
>>>>>> I would expect to see some sort of circuit breaker, but have not seen
>>>>>> a description of it.
>>>>>> 
>>>>>> Minor issues:
>>>>>> * Section 3.2
>>>>>> I guess all binary fields in the header shown are expected to be transmitted
>>>>>> and received in network byte order (big endian), but I would prefer to make
>>>>>> this explicit.
>>>>>> * Section 3.2
>>>>>> Is it allowed that the Message ID wraps around? It seems so, but I think it is
>>>>>> better to make that explicit.
>>>>>> * Section 4.1
>>>>>> The length field in the UDP header is limited to 65535 bytes, therefore the
>>>>>> UDP payload is limited to 65535 - 8 bytes, which is 65527 bytes. This is smaller
>>>>>> than stated in the first sentence. In addition to that, when using IPv4, the size
>>>>>> is even 20 bytes smaller, since the IPv6 header contains a 16-bit field holding
>>>>>> the total length of the IPv4 packet.
>>>>>> * Section 4.2
>>>>>> What should happen if the Private Encoding Option is present, but the S-bit is
>>>>>> not set? What should happen if the S-bit is set, but the Private Encoding Option
>>>>>> is not present?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> Mahesh Jethanandani
>>>>> [e-mail]
>>> 
>>> 
>>> 
>>> Mahesh Jethanandani
>>> [e-mail]
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
> 


Mahesh Jethanandani
[e-mail]