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

[Mahesh Jethanandani <[e-mail]>]

> 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.

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]