In einer eMail vom 09.08.2010 22:50:03 Westeuropäische Sommerzeit schreibt [email protected]:
One can argue that our layering structure is mis-constructed (as John Day does). I do not know John Day's arguments and therefore don't question the existing layering. But even if it is misconstructed, with the approach we use, flow control and congestion response are very separate functions from the path finding functions. Intertwining them makes life much more complicated. If we look at it as a layer construct, Network is concerned with path finding / forwarding, and transport is concerned with reliability, folw control, congestion response, and other end systems issues. This is related to the ideas behind moving end functions to end systems (buffering and flow control). IMHO, buffering and flow control is the task of the transport layer while detour forwarding i.e. making a next hop selection out from a set of multipath-alternatives is a network layer task. I don't want to intertwine both mechanism for responding to congestions. And I don't suggest any throttle wrt flow control. The huge traffic bulk is video/TV where throttling would destroy the service. The solution can only be an intelligent and concerted concept for detouring the congested node( cluster). Some traffic can easily bypass it, some other traffic which would require longer detours might still be sent via the congested node. Why can't we build such an intelligent network layer ? Heiner Yours, Joel [email protected] wrote: > > In einer eMail vom 09.08.2010 20:08:06 Westeuropäische Sommerzeit > schreibt [email protected]: > > and congestion response is definitely NOT > the network layer's responsibility. > > Joel, > Why ? The TCP endpoints don't have any idea how to dissolve a > congestion. It takes a concerted action in the network for dissoving a > congestion such that it is not just relocated. Individual TCP endpoints > may only try out SOMETHING ELSE - without seeing, without knowing. > > Heiner
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
