Re: [tcpm] Is this a problem?

[Chandrashekhar Appanna <[e-mail]>]

On Tue, Nov 20, 2007 at 08:11:05PM -0500, Ethan Blanton wrote:
> 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.
>

  And still it is a matter of opinion as to which layer should have what
  beyond a point of debate. Lot of the current model has also historical
  significance that we try to justify now with good language and architecture.
  But I do not disagree with your point but the repetition, to me, means that
  we are stuck at a stalemate and that is not interesting..


> > > 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",

  I think useful to me is still a fine metric even for tcp and therefore
  I stopped there.

  0.02,
  Chandra.

> 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



> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tcpm


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