Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Joe Touch <[e-mail]>]

Hi, Mike,

> On Jul 17, 2019, at 1:13 PM, C. M. Heard <[e-mail]> wrote:
> 
> On Tue, Jul 16, 2019 at 9:18 PM Joe Touch <[e-mail] <mailto:[e-mail]>> wrote:
> Hi, Tom, et al.,
> 
> The checksum behavior as described in Sec 8. These were designed based on WG discussion to achieve the following properties:
> 
> - presence of options should NEVER cause behavior different than at a legacy receiver
>         this is why if UDP CS passes but OCS fails, the UDP payload should still be passed to the user
>         i.e., it should never be a penalty to use options
> 
> I have no issue with that action.
>  
> - individual options can cause the receiver to drop the packet when the option fails ONLY if both sides agree in advance
>         when that is NOT the case, the success/failure of the option is indicated to the user but UDP doesn’t made the decision
> 
> There is a counter-argument to this: when an option that affects payload processing is present, and an options-aware implementation does not understand it ignoring it and passing the payload data to the application is clearly incorrect.

It would be:
	- pass the user data to the app
	- indicate to the app that this option has failed

It remains up to the user to decide how to proceed. If the user thinks that this message should be handled as legacy, they can. If not, they can ignore / delete it.

> Such options need (a) to share fate with the payload (i.e., be covered by the same checksum) and (b) must be marked in the KIND as requiring that packet to be dropped if they are present.

It’s not the option that makes this determination; it’s the receiver. All the options and their success/failure are passed to the user (if they want to see them). Or a given socket can be configured to handle that discard-if-fail.

But this isn’t the sender’s decision - senders get to add options, but receivers MUST be able to act as legacy if they want. Consider that they could always be running their own legacy stack anyway.

This design rationale is all already explained in the current doc, FWIW.

> As I have explained previously, fate-sharing, while unachievable with the protocol trailer format but can be achieved with a protocol header packet format.

It really can’t - again, you can’t force a receiver to act as options-aware.

>  
> What changed that makes these incorrect or insufficient?
> 
> Additionally, it is highly undesirable to loop though the option TLVs prior to validating the OCS is undesirable. draft-ietf-tsvwg-udp-options-07#section-8 doesn't account for that.

It actually does if you consider that OCS MUST come first if present. That can be made more clear in that section, though.

> Admittedly it's taken me a while to figure this out, sorry that I am so slow on the uptake. But serious bugs do need to be corrected, even if they are discovered late.

Agreed, but so far I don’t see a bug so much as revisiting decisions we already had consensus on, e.g., as per above. 

——

I think we do need to (re)converge on the basic assumptions and design goals.

One is the list of 8 items I previously noted, but another is the one highlighted in this note.

Joe