Re: [tcpm] Is this a problem?

Chandrashekhar Appanna spake unto us the following wisdom:
> On Tue, Nov 20, 2007 at 04:01:21PM -0800, Joe Touch wrote:
> > Lloyd Wood wrote:
> > > The community standardised TCP window size advertisements. That's a
> > > local resource control issue, surely?
> > 
> > That's something you have to tell the other end, i.e., it requires a
> > change to the protocol on the wire. This one can be implemented without
> > any change to the protocol at all - entirely at the app layer.
> 
> And I think the authors are positioning that there is a better place
> in the architecture to solve this and that is in tcp. I think it is
> boiling down to just a matter of opinions so far.. esp when you keep
> repeating that it could be solved in the app layer (for as long as I
> recall!!)

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.

> > Useful is a fine metric for a new protocol, not for mucking with such a
> > ubiquitous and established one unnecessarily, IMO.
> 
> I do not understand that line of reasoning at all.. I think the point
> was that it could be useful to tcp.. not to some new protocol. I think
> the discussion has to be around that point only.. last I checked this
> was the tcp m mailing list.

"Unnecessarily" is an important word in that statement, which you did
not address.  The question has never been "can this be done in TCP",
it is rather, "should this be done in TCP?"

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.

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