Re: New draft possibilities

[Frank Cusack <fcusack%fcusack.com@localhost>]

On August 30, 2005 9:01:59 PM +0100 Ben Harris <bjh21%bjh21.me.uk@localhost> wrote:
> In article <15F6428B71F2CC3D02A44AE0%maguro.savecore.net@localhost> you write:
> > On August 30, 2005 3:25:12 AM -0400 der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> wrote:
> > > > A TCP tunnel would change the characteristics of most UDP apps quite
> > > > significantly and would not be desirable, I'd think.
> > >
> > > Depends on what you're using UDP for.  It will change the
> > > characteristics of UDP, but whether the change is significant will
> > > depend on the application UDP is being put to.
> > >
> > > For example, I would expect it to work fine for DNS traffic (which is
> > > pretty close to the only use I can see for it offhand, though that
> > > could just mean I don't do much with UDP).
> >
> > But what happens when DNS times out and sends a retry, while TCP has
> > also queued it's own retry?  You end up drastically increasing the
> > amount of network traffic.
>
> Not necessarily.  A reasonable implementation of UDP-over-SSH would notice
> the TCP congestion (in the Unix world, by write() on the TCP socket
> returning EWOULDBLOCK) ...

Only after the receiver's window goes to 0, and even then only if no
packets whatsoever get through.  In congested conditions where packets
make it after a few retrans, you'll never get this error.  You are also
assuming something (a lot) about a specific implementation.  Nothing
requires a TCP stack to notify the application like this.

-frank