[tsvwg] draft-ietf-tsvwg-udp-options-13: Comments concerning Fragments

[Gorry Fairhurst <[e-mail]>]

I reviewed the latest revision (13) of the draft and have the following 
questions relating to the use of Fragments.

Best wishes,

Gorry

(as an individual)
===
In section 5.5

“   Legacy receivers interpret FRAG messages as zero-length payload
    packets (i.e., UDP Length field is 8, the length of just the UDP
    header), which would not affect the receiver unless the presence of
    the packet itself were a signal.”
- can you supply a reference here? (If no other then sect 5 of RFC8085).
===
“ This allows either pre-reassembly or post-reassembly
    UDP option effects.”
- I think I understand a use case and it would be nice to have an 
example of using both per-fragment and per-datagram options: could this 
be used with fragments req/res options to determine a suitable PMTU, and 
the time options used per reassembled datagram (since in many case this 
needs to measure the time across the reassembled end-to-end datagram path).
===
    >> UDP reassembly space limits SHOULD NOT be implemented as an
    aggregate, to avoid cross-socketpair DOS attacks.
- Please explain “aggregate” (is this across multiple socket-pairs?)
===
    Any additional UDP options, if used, follow the FRAG option in the
    final fragment and would be included in the reassembled packet.
- I don’t like the word “additional” here, can you find a better word 
(per-datagram?)
===
5.7. Maximum Reassembled Segment Size (MRSS)
- I’m going to make a suggestion here, that was earlier brought up by 
Tom Jones: Why don’t we fix the DEFAULT MRSS to 2 packets when MRSS is 
supported. Larger values might be supported, which would be fine, but 
the case of 2 might have some immediate benefit:
- A receiver can then fragment a UDP packet to tunnel of include UDP 
options, likely in many current cases a second fragment will be enough.
- A receiver can greatly simplify its processing if it tries to 
reassemble whenever it receives a second fragment of the same datagram. 
The simplification here mitigates some worry about attacks that target 
reassembly buffers or processing costs. He previously had not 
implemented fragment support because it was cumbersome to include in the 
OS he worked with.
- Thoughts?
===