Re: [tcpm] WGLC for UTO

On 2007-10-19, at 2:10, ext Joe Touch wrote:
> - MUST/MAY/SHOULD on the whole option
> 	I didn't see this; I'm not sure I care what the decision is,
> 	but it should be stated in the abstract and intro

I'd like to ask the opinion of the WG here: Should we recommend that  
all stacks implement UTO as a PS? Or only some stacks, and in this  
case, which ones?

(Alternatively, if we're going for Experimental with this document,  
this question is moot, because implicitly only hosts desiring to  
experiment with this option need to implement it.)

> - sec 3 at "Before opening..." for two paragraphs
> This section uses 2119 language in ways I don't understand. An app  
> that
> wishes to do something SHOULD? If it wishes to do something, it "DOES"
> it. I don't see a reason for 2119 there, or MAY at the end of that
> paragraph, or MAY in the next. In these cases, there are choices
> involved that determine what happens. You cannot dictated userland /
> application behavior when defining these events in this document, IMO.

I've rephrased these sentences to not use 211 terms.

> - sec 3 "In addition to"
> There is no reason in requiring (via SHOULD) a refresh of
> SYN-coordinated state. Either that state is coordinated, or it is not.
> If not, then the connection is in error.

The intent was to make UTO work with SYN cookie implementations that  
can't encode whether a UTO option was present in the cookie, by  
including the option also in the first non-SYN packets. It may also  
help when the option space in the SYN packets was too full to allow  
UTO to be included. So there is some use to doing this. We could  
state that including UTo in the first non-SYN packets is only useful  
if the option was not included in the SYN?

> - sec 3 "A host that supports"
> What happens if there is no option space in the next outgoing segment?
> What happens if there is no option space at all? Do you tell the  
> app? Do
> you do anything special? IMO, this deserves a separate section rather
> than just a note at the end of 3.0

I don't know what we can say about this - this is a general issue  
with TCP. What should be done depends a lot on which other options  
are in use for a particular connection. Maybe UTO is considered more  
important than some options, but less important than others. Which  
options do you include and which ones do you not include, generally?  
Hard to say.

> - sec 3.1 "When a host"
> "In this case, they SHOULD" - they who?

s/they/TCP/ - fixed

> - sec 3.1 "In general"
> This is contrary to the default values. CHANGEABLE defaults to  
> true, but
> ENABLED defaults to false. That means, IMO, that received UTO options
> would be dropped, not acted upon, in the default case.

When the draft was targeted as Experimental, having ENABLED default  
to false was needed, so that hosts would need to actively enable the  
mechanism to participate to experiment with the option.

If we're going with PS (are we?), ENABLED should default to true, I  
guess.

> - sec 6
> I thought this section should say a few specific things:
>
> 1) There are no new IANA namespaces. (which you say)
>
> 2) This doc requires IANA to assign a value from the TCP Option
> namespace, to be referred in section 3.3 accordingly. (which you don't
> quite ask for!)

Right - I made this explicit.

> Very minor points, if an edit occurs:
...

Most of these are addressed in the next revision. But not these, so far:

> - sec 3.1 "This means that"
> This paragraph is part of a discussion on checks and limits; this  
> should
> not be the first place you introduce the "max" concept.

It's not - the formula further up introduces it.

> - hysteresis?
> The doc doesn't describe how quickly the UTO can be changed by the
> remote end or application. Does it matter, e.g., for security reasons?

I don't think there are security implications here. The only result  
of changing the value very frequently is that all segments have the  
option attached, so there is some mild increase in bandwidth use. But  
the app can always just send more data anyway :-)

> - sec 3.2
> If you retransmit the option and attach it to a particular byte,  
> and the
> byte is ACKd, then why don't you KNOW the option has been received
> (i.e., second part of the handshake)? if the other end receives data
> over 1 window away from that byte, why doesn't it KNOW the source end
> knows it has been recieved (i.e., third part of the handshake)?

*If* you do this, yes, but there was consensus earlier that the WG  
didn't want the UTO exchange to be reliable, which is why this  
"attaching" the option to a byte is a MAY.

> About retransmission, IMO, it SHOULD be done - or else what's the  
> point
> of this?

Is this related to your previous comment? If so, there was consensus  
to not make UTO reliable, i.e., retransmit lost options.

Thanks!

Lars

Re: [tcpm] WGLC for UTO

Attachment: smime.p7s