* Section 9.7: Specify that RES echoes the token in the most recently receive REQ

[Mike-Heard]

Raised by Erik Auerswald

[auerswal]

Suggested text also in https://mailarchive.ietf.org/arch/msg/tsvwg/mdPPObp-ULgSWWQnJbh3SEeYdTE/ (the suggestion as for issue #15 includes both adjustments).

[jtouch]

Updated -23 to address this issue. Please advise if other text from the suggestion is needed.

[auerswal]

Thanks! I would prefer it if one additional sentence from my suggestion would also be incorporated:

A RES option echoes the token received in the corresponding REQ option.

This could be added as last sentence before figure 15. It would make explicit that the token is reflected by this echo mechanism. The later sentence regarding to use the latest received token, i.e., to possibly ignore some REQ options before returning a RES, only implicitly provides a use for the token.

[jtouch]

UDP doesn't keep state. If multiple REQs arrive before the upper layer sends a RES, the upper layer sends a RES with the most recently received REQ.

UDP REQ/RES doesn't actually operate at the UDP layer; it operates at the layer above. I thought this clarification was made on-list a while back. UDP isn't stateful and we don't want to introduce that as a new "feature".

[auerswal]

The token is not explained. Why have a token at all? The only reason to have a token in REQ is to have it echoed in RES. But that must be written in words in the draft, otherwise implementers will create a new token for RES instead of using the one received in REQ and call this compliant.

[jtouch]

Tokens are what are returned; the most recent token is returned by the ULP - but the ULP (upper layer protocol) could send oldest token too, or "largest" or "smallest" (if the ULP orders the token). UDP doesn't know or care; this is a User protocol extension, so the user (ULP) decides.

[gorryfair]

DPLPMTUD has a clear understanding of token. I think we ought to make this the same.

[auerswal]

As written in -23, an implementation could use a token in a RES that has no correlation to any tokens received in any REQ, and still be seen by the implementer as compliant. I think that this is problematic, and the draft should be more specific.

I think, but cannot know this for sure, because it is not written down, that the idea of this option pair is for RES to echo a token received in a REQ. A RES with a token received in some REQ corresponds to that REQ.

Thus my suggestion for an additional sentence: "A RES option echoes the token received in the corresponding REQ option."

This does not specify which REQ is answered with a RES, or if any REQ results in a RES, but only that any RES needs to use a received token, and this token was received with a REQ, and thus there is a correspondence between REQ and RES (this may not even be one-to-one, e.g., all REQs from one sender could use the same token, for whatever reason, or the responder might always use the token received in the first REQ, for whatever reason, even though I think that would be useless).

[jtouch]

Although the idea is for the token in the RES to match one in the REQ, UDP is not a bidirectional protocol. The sentence proposed is backwards; the user infers that two UDP packets are correlated when the RES token received matches a REQ token sent, but UDP doesn't "echo" anything. Making REQ automatic would turn UDP into the Echo service, which is disabled for security reasons. Letting the user decide allows the receiver of a set of REQs decide which token to return, which makes sense because this is a user protocol. You're correct that with this rule a receiver could keep sending the same token in response regardless of REQ, and that might actually be useful to indicate a persistent "cookie" known at the user level, i.e., to cache the notion of a connection at the user level that doesn't exist at the UDP level.

[auerswal]

Well, I do not think the sentence is backwards. Anyway, how about:

">> The token used in a RES option MUST be a token received in a REQ option."

[jtouch]

That works for me. Is that sufficient for everyone else?

[gorryfair]

Could WFM, DPLPMTUD says how to handle tokens for that use, but this is the base minimum - and is not inconsistent.

[auerswal]

I'd say the perfect place for that sentence would be between figure 15 and the current advice to prefer a recently received token (I see the new sentence as an addition to the current text, not as a replacement for anything).

[jtouch]

AOK - will do in -24.

[jtouch]

Done in -24

[gorryfair]

Done