Re: [tsvwg] Alternative version of the UDP FRAG option

[Joe Touch <[e-mail]>]

That is lite alone only AFAICT. And we already know that is the risk CURRENTLY. 

Again, we need to include fixing these errors. If we let every bug persist, nothing would be deployable anymore. 

Joe

> On Mar 12, 2019, at 2:00 AM, C. M. Heard <[e-mail]> wrote:
> 
> Yes, but FRAG+LITE fails the deployability test. That IMHO makes it a
> non-starter.
> 
>> On Mon, Mar 11, 2019 at 9:44 PM Joe Touch <[e-mail]> wrote:
>> 
>> Frag+lite can still be checksummed after reassembly as is. We don’t want or need to do that check twice and can’t usefully string together partial sums.
>> 
>> Joe
>> 
>> On Mar 12, 2019, at 12:10 AM, C. M. Heard <[e-mail]> wrote:
>> 
>> On Mon, Mar 11, 2019 at 9:26 AM C. M. Heard <[e-mail]> wrote:
>>> I'd like to float a different idea, namely, putting the UDP user data
>>> inside the FRAG option itself.
>> 
>> Well, that proposal was rather obviously flawed by limiting fragment
>> sizes to ~240 bytes. My apologies. I withdraw the FRAG proposal in
>> 
>> https://mailarchive.ietf.org/arch/msg/tsvwg/JZ8ohgwMs9eRPRQ6KJDqUZTJxSk
>> 
>> However, I think that the following simpler version will actually work:
>> maintain the format of the FRAG option as currently defined, but instead
>> of having the option capture preceding conventional or LITE user data as
>> fragment data, insist that it appear ***last*** in the option list and
>> have it capture all remaining octets in the packet as fragment data. By
>> convention, if this option appears, OCS would cover all UDP options as
>> well as all octets in the UDP trailer that follow the FRAG option.
>> 
>> The following requirements would apply:
>> 
>>>> When the FRAG option appears, it MUST come last in the UDP options
>>   list.  All remaining options in the packet are interpreted as fragment
>>   data.
>> 
>> 
>>>> OCS, if present, covers both the FRAG option and the trailing
>>   fragment data.
>> 
>> 
>>>> A host that wishes to signal that it is able to accept and process
>>   the FRAG option MAY do so by transmitting an unfragmented datagram
>>   with an empty terminal FRAG option whose Offset and Checksum fields
>>   are set to zero.
>> 
>> 
>>>> Non-empty FRAG options MUST NOT be present in packets with ordinary
>>   UDP user data or LITE data. Any such options MUST be silently dropped.
>> 
>> 
>>>> UDP options other than OCS and padding MUST NOT accompany the FRAG
>>   option in non-terminal fragments.  Any such options MUST be silently
>>   dropped.  All other options that apply to a reassembled packet must
>>   accompany the FRAG header in the terminal fragment.
>> 
>> 
>> This proposal does not suffer from the disadvantage that a legacy receiver
>> could misinterpret a UDP fragment as a complete datagram, as does the
>> currently-defined version of FRAG without LITE.  And it avoids the problem
>> that OCS does not cover the currently defined version of FRAG+LITE.
>> 
>> Note that because of their unusual property of capturing following or
>> preceding data, FRAG and LITE would have to be mandatory to
>> recognize, but I do not believe that they should be mandatory to
>> generate or process. An implementation that cannot process these
>> options should silently drop packets that contain them.
>> 
>> There's probably something wrong; if so, please tell me what it is.
>> 
>> Mike Heard