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

[Mahesh Jethanandani <[e-mail]>]

Hi Alex,

The question really should be for Micheal, I was chiming in because I tended to agree with his concerns. But since you are asking ...

> On Jan 23, 2024, at 9:46 PM, Alex Huang Feng <[e-mail]> wrote:
> 
> Hi Mahesh,
> 
> See inline,
> 
>> On 23 Jan 2024, at 06:36, Mahesh Jethanandani <[e-mail]> wrote:
>> 
>> Hi Michael, thanks for your review.
>> 
>> Alex,
>> 
>> See inline.
>> 
>>> On Jan 21, 2024, at 11:40 PM, Alex Huang Feng <[e-mail] <mailto:[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.
> 
> AHF: Would this text help? (To be added at the end of Section 2)
> 
> "Note also that the receiver nodes can be different from the nodes managing the subscription. Therefore, publishers MAY NOT be aware of the capabilities supported by the receivers."

[mj] This text is fine, but it should specifically address the question of what happens in an error case.

> 
> Regarding managing capabilities and errors at the sender, I don’t think it should be part of UDP-notif given that:
> 1) it is the operator who configures it and therefore knows what is supported and what not in their publishers and receivers.
> 2) the receiver (collector) can be a different node/process from the management node (see https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-08#name-solution-overview <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-08#name-solution-overview>). And given that it is UDP, the only options between the publisher and the receiver would be receiving or dropping the packets. I don’t expect the sender to receive feedback from the collector.
> 
> Errors should be managed at NETCONF independently from the transport, IMO.

[mj] But errors are at the transport level. How would NETCONF or the node managing the subscription be able to help?

Also, I think it a stretch to assume that all the operator would know what is supported down to the capabilities level. Worse still, how will they debug it, if the receiver does not receive the messages. Also, if there is no feedback, does it continue to send notifications regardless of whether the receiver is able to receive it?

> 
>> 
>>> 
>>> * 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?
> AHF: We have section 5.1: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-12#name-congestion-control <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-12#name-congestion-control>
> Is this sufficient?

[mj] I am good with this, but I will let Michael comment on his original comment.

Thanks for addressing my comments.

> 
> Cheers,
> Alex
> 
>> 
>> 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] <mailto:[e-mail]> wrote:
>>>> 
>>>>> On Nov 16, 2023, at 01:37, Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Nov 15, 2023, at 2:17 PM, [e-mail] <mailto:[e-mail]> wrote:
>>>>>> 
>>>>>>> On Nov 15, 2023, at 22:47, Mahesh Jethanandani <[e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>>>>> 
>>>>> 
>>>>> 
>>>>> Mahesh Jethanandani
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> netconf mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>> 
>> 
>> Mahesh Jethanandani
>> [e-mail] <mailto:[e-mail]>

Mahesh Jethanandani
[e-mail]