Subject: RE: [tcpm] last open issue in UTO

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Tue, 10 Apr 2007 12:12:28 -0700

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

As a potential end-user of this feature, I'd prefer (1).  I'd like to be
able to allow users to control how long we can guarantee that a TCP
connection will survive a network outage, and if we offer that as a
configurable option that can only be increased it is somewhat hard to
explain.  (Or more precisely if you decreased it that would only apply
to new connections, but not to existing ones.)

--J

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 11 Apr 2007 10:41:59 +0300

Thanks for the feedback! I think there may be a misunderstanding; let  
me attempt to clarify.

On 2007-4-10, at 22:12, ext Mahdavi, Jamshid wrote:
> connection will survive a network outage,

UTO gives no guarantees. All it does is let the other end know how  
long your end will leave the connection state around when there is no  
end-to-end connectivity. If the other end has decided to react to  
that information by adopting a similar local UTO, there is some  
likelihood that the TCP connection will survive if connectivity  
returns before that timeout. But your end can't tell if the other end  
is reacting to the UTO information you sent, hence no guarantees of  
anything.

> and if we offer that as a

The configurable option is (1) what your local end uses as its UTO,  
and (2) whether that should be send to the other end via the UTO  
option (i.e., whether UTO is in use at all) and (3) whether your  
local end is willing to adapt the local UTO based on what the other  
end uses asa UTO.

Your end is always free to increase and decrease its local UTO as it  
sees fit. The issue I described is with what happens at the other  
end, if it is configured to adapt its local UTO based on what you  
send. In the first case, if you send a long UTO and then a short one  
later, the remote end can decrease its UTO to the shorter value when  
it had been using the longer one. In the second case, it can't go to  
a shorter UTO.

The question is whether the ability to shorten UTOs on the remote  
side is useful to have.

Lars

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 11 Apr 2007 23:56:53 +0800

Lars Eggert wrote:

> The configurable option is (1) what your local end uses as its UTO, and
> (2) whether that should be send to the other end via the UTO option
> (i.e., whether UTO is in use at all) and (3) whether your local end is
> willing to adapt the local UTO based on what the other end uses asa UTO.
> 
> sees fit. The issue I described is with what happens at the other end,
> if it is configured to adapt its local UTO based on what you send. In
> the first case, if you send a long UTO and then a short one later, the
> remote end can decrease its UTO to the shorter value when it had been
> using the longer one. In the second case, it can't go to a shorter UTO.

The question to ask is if it is important.  Since the option is
advisory anyway, so it is really up to the implementation what
to do with it.  "Specifying" that an implementation SHOULD not
decrease its UTO in response to an incoming UTO option seems
contrary to the advisory nature of the option.  The receiver of
the option is free to do whatever it likes.  And the sender of
the option has no way to find out how the peer reacts.  So I
don't think it is important to "disallow" the UTO decrease.

BTW, why does this require a state LAST_SENT_UTO?

-- 

						K. Poon.
						[email-masked]