[e2e] Simple Question on TCP Window Size

[Vernon Schryver]

> From: "David P. Reed" <dpreed at reed.com>


> I was focusing on things like streaming audio and video because they *do* 
> need congestion information, and they contribute significantly to congestion.
>
> RED and ECN provide useful congestion signalling from the network to the 
> endpoints.  Since closed-loop control exists for streaming audio and video, 
> these signals can be part of the input (along with ordinary drops) to the 
> streaming control loop.  Properly done, it will make them more 
> "tcp-friendly" than they currently are (many of the streaming services 
> don't even think of packet drops as possible congestion and throttle back).

I trust that by  "RED congestion signalling from the network to the
endpoints," you mean packet losses seen by the end points.  From that
point of view, ECN does sound cool as a preview of packet losses should
the application not slow down and play nice.

Still, a portable way to get ECN bits to the UDP application is a problem.
Perhaps you could sneak the ECN bits that arrive with the UDP datagram
into the mbuf that holds the source address, then have a modified recvmsg()
marked by a new flags bit that would set msg_flags with the ECN bits.  It
might be possible to get that into the freely redistributable BSD and
Linux and some of the commercial UNIX systems within a year or two.
It sounds like a major hurdle for the Pacific Northwest operating systems
that still don't even understand setsockopt(, IPPROTO_IP, IP_TOS,), which
could be far more useful to audio and video UDP applications than any ECN
bits.


> Wasn't at all trying to oversell - I assumed that DNS would not benefit.

My point about overselling was intended to be about DNS and other very
low volume (per given pair of hosts) UDP/IP applications.  Even better
poster-children for the far side of the line are NTP and ports 13 and 37.


Vernon Schryver    vjs at rhyolite.com