[e2e] Is a non-TCP solution dead?

[Cannara]

John, the various non-TCP flows that have been increasing, and are planned to
be used even more in the future, center on media communications, such as audio
& video streaming, as well as IP phone, conferencing, etc.  I'm not sure that
Inet2 is representative for what's going on in the bulk of the net.

On congestion handling at the network (and lower) layer, indeed there are
various standards applied within and between switching/queueing boxes (CSIX,
SPI-3, 4 & 5, proprietary serial, etc.) and, of course, full-duplex 1 and 10Gb
Enet allow flow controlling a source with Pause frames.  The components of
today's Network Layer know a lot about what's going on within and among them,
up to points of management disconnects.  There's good reason to look at
extending the reach of this good, fast knowledge, so that traffic management
can indeed be done sensibly and more effectively at the Network Layer.

Alex

John Kristoff wrote:
> 
> On Mon, 21 Apr 2003 12:30:25 -0700
> Cannara <cannara at attglobal.net> wrote:
> 
> > collapse.  Now that TCP flows are waning in relation to others, the
> > emperor's clothes are indeed diaphonous.
> 
> Can you provide some pointers to data supporting that assertion?  I
> don't see that as true in our environment or on Internet2 in general.
> Perhaps in special case walled garden environments?  There may be some
> slight skew with regards to UDP increasing slightly over the past couple
> of months due to Slammer/Sapphire, but that seems minimal.  Any
> observations about what is conversely increasing would be interesting to
> know if you pointers to that info as well.
> 
> > On: "TCP definitely has its problems.  And, one can make the case for
> > CC being in the network layer (or transport or application)." --
> > exactly, on Network Layer, that is, because that's where the "network"
> > congestion is! That's where reliable old telco switches, Sonet ADMs,
> [...]
> > handling -- i.e., this is the Network Layer to us.  More needs doing
> > at the packet network layer (IP).
> 
> Rather than in the protocols themselves, there are a number of
> strategies for handling congenstion within the network layer, but they
> are often built into the network layer devices rather than IP itself
> (e.g. RED, rate limiting, fair queueing and even plain old capacity
> upgrades).  Without 'circuits' and fixed bandwidth sources and with a
> relatively simple network layer in general, these are the sorts of
> things that are available to handle network layer congestion.
> 
> John