Subject: [tcpm] last open issue in UTO

From: Lars Eggert <[email-masked]>
Date: Tue, 10 Apr 2007 11:47:58 +0300

Hi,

during the Prague presentation (http://www3.ietf.org/proceedings/ 
07mar/slides/tcpm-1.pdf), I described the changes we made in the last  
revision. We tried to address reviewer comments that the text wasn't  
consistent with regard to how to respond to incoming UTO options. The  
change was to introduce a few pieces of per-connection state and  
describe UTO in terms of those variables. I heard some agreement that  
this has helped. (I'd like to hear more opinions.)

That change has also re-opened an older issue. UTO could:

	(1) allow hosts to lengthen _and_ shorten the local
	UTO in response to incoming UTO options (if the local
	stack has allowed that)

	(2) allow hosts to only modify the local UTO in one
	direction, i.e., always lengthen it (lengthening
	is more useful to survive periods without
	end-to-end connectivity)

(1) is obviously more flexible, but also requires us to maintain one  
more piece of per-connection state. (1) is also what the draft so far  
has described, and is thus probably WG consensus.

(2) reduces overhead and make the mechanism a bit simpler. It can  
also be argued that the ability to shorten UTOs hasn't really been  
shown to be terribly useful (the argument was that busy servers could  
notify clients that they weren't keeping the connection around for  
long if end-to-end connectivity would go away, which lets the client  
do the same and conserve some resources.)

I think Fernando prefers (1), and I have a slight preference for (2).

Thoughts?

(IMO this is the last open issue with the draft, and we should be  
able to settle this quickly.)

Lars

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm