Re: [tcpm] WGLC for UTO

Lars Eggert wrote:
> On 2007-10-19, at 2:10, ext Joe Touch wrote:
...
>> - 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. 

That should be deemed non-compliant. The point of the SYN cookie is to
reestablish the entirety of state that would have been established by
the SYN; if the cookie can't do that, a cookie should not be used.

TCP has no provisions for post-SYN establishment of new connection state
AFAIK. Requiring this of this option would be new, and, IMO, a bit
confusing for designers. What happens if the post-SYN packet lacks the
option? do you declare state mis-synchronization and drop it?

> It may also help
> when the option space in the SYN packets was too full to allow UTO to be
> included.

IMO, if that's a concern, then make sure the UTO MUST NOT be included in
the SYN. I.e., it's in one place or the other; once in place, it
shouldn't be repeated in subsequent segments - only replayed in segments
being retransmitted.

> 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?

I'd prefer that, adjusted to say "if the option was not included in the
SYN due to space limitations".

>> - 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.

I'm not making an assertion as to what to do, only that the doc ought to
consider the issue. I'll suggest that it ought to send it within 2
segments OR indicate to the application that it has failed; the latter
requires a new API variable, though.

>> - 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.

Sure - making the two consistent is the issue.

...
>> 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.

It might be useful to introduce the issue in prose first. The reason for
using max is the issue, and it's not clear by just stating the formula.

>> - 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 :-)

Can someone on the path do something you don't want to your connection
by tacking this option on?

>> - 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.

Ah - it might be useful to explain that. I thought MAY implied that the
information about reliability was in doubt, rather than that the use of
the attachment was optional but would provide reliable UTO exchange if used.

>> 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.

I have no idea what the point of an unreliable option on a reliable
transport protocol means. IMO, options should be retransmitted when
their associated segments are. The control protocol ought to be at least
as robust as the data. Although I appreciate that UTO isn't as critical
as some other options or flags, introducing nondeterminism at this level
doesn't seem appropriate, IMO.

I.e., I think there are separate questions:

	1) is UTO critical enough to ensure correct exchange via
	an explicitly ack'd handshake
		no - I agree with the WG

	2) should options associated with a segment be retransmitted
	with that segment in general in TCP
		I think the answer to this should be YES, always,
		but I don't think it was asked.

Joe

Re: [tcpm] WGLC for UTO

Attachment: signature.asc