Re: [tcpm] Is this a problem?

[Chandrashekhar Appanna <[e-mail]>]

On Tue, Nov 20, 2007 at 04:01:21PM -0800, Joe Touch wrote:
> 
> 
> Lloyd Wood wrote:
> > At Tuesday 20/11/2007 07:12 -0500, Mark Allman wrote:
> > 
> >>> Why does congestion control require standardization, when every
> >>> client/server application out there is perfectly capable of doing it?
> >>> To achieve consistent behaviour across the widest range of
> >>> applications...
> >> I think this is a complete mis-characterization.  The answer is that
> >> congestion control is standardized because congestion control is about
> >> dealing with a *shared resource*.  We can do that control from a number
> >> of places in the stack and people have advocated for each of them at
> >> different points.  But, *where* that functionality exists is a second
> >> question after we establish that the functionality needs to exist and we
> >> need to standardize on it.  This persist business is not about
> >> controlling a shared resource, but about controlling a *local
> >> resource*.  Why should the community standardize local resource control?
> > 
> > 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!!)

> >> That seems absurd to me.  So, to me, arguing about where to mitigate the
> >> persist stuff is putting the cart before the horse.  First, we'd need to
> >> establish some reason to standardize local resource control.
> > 
> > because it's useful?
> 
> 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.

  -
  Chandra.

 
> Joe
> 



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


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