Hello,
First of all, sorry for my delayed answer.
Please see my remaining comments inline prefixed by [AFT2]. Overall, I am ok with the proposed comments, and agree with Eric on his positioning on version -43 of your document (even if my agreement is by no means necessary).
Best regards,
Antoine
In section 11.4, the document mentions that "The Identification field SHOULD be
generated in a manner similar to that of the IPv6 Fragment ID [RFC8200].". I
think it would be beneficial to give a bit more details about this generation
method to add clarity. In the same section, the document mentions that "2.
Identify the desired fragment size, which we will call "S". This value is
calculated to take the path MTU into account (if known) and to allow space for
per-fragment options.". I would give a better idea about the size of said space
for per-fragment options.
We think that pointing to RFC 8200 without prescribing specific algorithms
(as is done, e.g., in RFC 1948 and RFC 6528), is more than sufficient. That
being said, if you wish to propose specific text, we are all ears.
[AFT] I noted your answer to the first comment in this paragraph. Regarding the second part of the comment, by memory, RFC 3261 mentions that a packet containing a SIP header and body should not be larger than the MTU minus 200 bytes to give enough space for on path additions to the header. I was having similar recommendations in mind regarding the desired fragment size.
[JT] If I understand correctly, you want to “de-rate” the IP reported MTU to allow IP more space to add or increase the size of headers on the path. That has been discussed in INTAREA and the consensus I recall was that IPv6 options should never become larger (as a set), precisely because it interferes with path MTU mechanisms (both PMTUD and PLPMTUD). De-rating for IP tunnels and the like would already have been done at the IP layer.
I.e., UDP, like TCP, determines its max transport MTU based on what IP reports. I don’t understand why SIP has any different recommendation, FWIW.
[AFT2] My point here was that, if you are fragmenting the UDP header + payload in several fragments and that you allow per fragment UDP options, then you should make sure in your fragmentation strategy that you leave some space to add UDP options between the end of the UDP fragment and the IP packet’s MTU. My intention when citing SIP was to mention that SIP gives a limit to its size by retracting some bytes to the MTU. Translating to UDP fragmentation, it would mean that, when fragmenting UDP in fragments, the fragment should be less that the size allowed by the MTU to allow some UDP options to be added without exceeding the MTU. I didn’t mean to allow middle nodes to add options on the fly.
2. Identify the desired fragment size, which we will call "S". This
value is calculated to take into account the path MTU (if known)
and to allow space for per-fragment options.
Please let us know if you do not agree.Mike
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
