Re: [tcpm] Is this a problem?

Mahesh Jethanandani spake unto us the following wisdom:
> Ethan Blanton wrote:
> >Joe keeps making this point because it is _very important_.  Any
> >feature which can be accomplished at Layer N can be accomplished at
> >Layer N - 1, and vice-versa.  However, the Internet protocols have
> >enjoyed tremendous success and longevity in part because they resist
> >the urge to push application and other high-layer semantics into the
> >lower layers.
>
> But  in case of congestion control it was felt that it would be done 
> better in TCP. Why? After all nothing stopped applications from 
> implementing congestion control.

This has been answered several times; it's not clear to me that you
are actually reading the responses to your emails.

Congestion control is important for the preservation _shared
resources_.  Mistakes in congestion control lead to problems on
somebody else's network.  The timer you are asking for is a change
which affects only _local resources_, and its disposition will have
little or no effect on others.  Congestion control was determined, by
the community, to be both important and tricky enough that it should
be solveld in one place (or a very small number of places), and shared
among applications.  It appears that there is not consensus that a
persist timer tunable has impact which is anywhere near similar.

If you are trying to suggest that stale sockets in zero window probing
are anywhere near the impact of congestion control, I find your
argument disingenuous.

> >For my own part, I have not yet seen a reason why application layer
> >timeouts are not a reasonable solution to this problem, or even the
> >_correct_ solution to this problem, because only the application knows
> >how much progress is "sufficient" progress, and as such I cannot see
> >driving this feature into the TCP _standards_.  I also, however, see
> >no reason why some particular TCP stack could not provide a socket
> >tunable for persist timeout, if sufficient userspace demand were
> >present.
>
> We give reasons as to why a timeout in application will not work. For 
> one, a fixed timeout is easy to defeat. If you are not proposing a fixed 
> timeout, what kind of timeout are you proposing? Is it going to be based 
> on that applications view of how many buffers it is holding on to? What 
> if that application is not the problem, but some other application is? 
> What if the other application does not even bother about connections in 
> persist condition.

I don't follow this, for several reasons.  What do you mean, a fixed
timeout is easy to defeat?  You're *asking* for a timeout which can be
set on zero window probing, are you not?  Regarding your final
statement, are you suggesting that application A should be able to
tell the operating system that application B's sockets should time out
if they are in a persist state?  None of this makes any sense to me.

> The problem is also that the resources in question are TCP resources and 
> applications have a snapshot of the problem from their connection point 
> of view. They do not see the problem that TCP is seeing.

We fundamentally disagree on this; Joe pointed out that you _can_
indeed know whether or not a TCP connection is open or closed, by way
of blocking calls and appropriate twiddling of SO_LINGER.  The
application therefore knows exactly how many sockets it is using, and
can be tuned appropriately.  I don't see what you think kernel space
can accomplish, that user space cannot.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

Re: [tcpm] Is this a problem?

Attachment: signature.asc