[e2e] Simple Question on TCP Window Size

[Vernon Schryver]

> From: "Eric A. Hall" <ehall at ehsco.com>

> ...
> > I think most UDP flows (as opposed to short duration exchanges like
> > DNS) would benefit from using ECN and RED information.
>
> Actually, short flows like DNS can benefit from the information if they
> are designed to make weighted decisions. For example, DNS resolving
> servers that understand the concept of preferred servers will weight the
> preferred servers for remote queries according to parameters like
> time-to-resolve. Incorporating congestion information as another metric
> into this decision is certainly feasible.
> ...

There are some problems with that idea at least as applied to DNS:

  - DNS lookups do not or should not occur frequently enough.  By the time
   a DNS server askes another given server again, a large number cycles
   of congestion and no congestion should have happened.  With the
   exception of TLD's like .com, a single distant server should not be
   queried more often than once in minutes, hours, or even days.  Local
   caching servers might be queried frequently, but no one with any sense
   uses a cache that is very distant.  Even a local caching server should
   accessed infrequently on the timescale of congestion events on a LAN.

  - the current sockets API doesn't include delivering arbitrary IP 
   header bits with UDP payloads.

  - few DNS queries can be sent to more than 2 distant servers.  Situations
   where congestion might affect one but not the other server for a zone
   sound relatively unlikely.

  - DNS servers might remember which oher DNS servers are faster or slower,
   but keeping such state in resolver libraries involves major hassles.
   The problems from reliability to security in such mechansims in IRIX
   and Solaris are case studies in how a simple sounding idea of saving
   such state among processes is not simple in practice.


> This isn't even far-fetched, but it would be a feature rather than a
> baseline. As it stands now, some DNS systems use ICMP Destination
> Unreachable messages to short-circuit query timers, while others do not.

Unreachables are quite different from ECN bits and aborting a timeout for
a response based on knowledge that the query was lost is very different
from declaring some servers faster than others based on ECN bits.

A better argument for the idea would be to point to the performance metrics
associated with servers by BIND.  However, there are good reasons why
those performance metrics are smoothed.  Worse, if you've observed those
mechanisms in real life, you've probably been disappointed with their
effects.  Other than the roots and a few TLD's, a DNS server does not send
many packets to any other single server, and so the notions of speed and
congestion are not very profitable.


> It's not a stretch to imagine that those servers which already implement
> these types of features can use any available feedback, and that would
> include ECN (although SQ would be faster and more explicit; some messages
> would provide greater weights than others, which would provide more
> appropriate adjustments faster, such as responding to immediate critical
> congestion with an immediate change in preference or responding to subtle
> changes with a minor preference tweak).

How many bits in the ECN bits?  In other words, even if DNS queries to a
single server were frequent enough for transient congextion events to be
good things to track, how would you distinguish congestion that needs
"immediate change in preference" from that which needs "a minor preference
tweak"?  For DNS, what is "a minor preference tweaks?"

It sounds more plausible to use ECN bits to inform applications such as
streaming UDP audio or video, but on reflection, they don't sound much
better.  Such applications necessarily have some reverse traffic to tell
the sender to continue sending.  That reverse traffic ought to tell the
sender about more than the effects of congestion.  The sender would better
adjust its stream not just for what ECN can say but also for jitter, delay,
and packet losses unrelated to congestion,


ECN sounds great, but let's not oversell it.


Vernon Schryver    vjs at rhyolite.com