Subject: Re: 'Slow-Start Restart after Idle' draft

From: Vernon Schryver <[email-masked]>
Date: Fri, 23 Oct 1998 10:59:57 -0600 (MDT)

> From: [email-masked] (Sam Manthorpe)

> ...
> It seems both methods have their flaws; how about a routing table
> flag that allows go-fast-mode on a route-by-route basis.  This could
> be both manually set/cleared and automatically set/cleared by some, as yet
> undefined, mechanism.  This also avoids introducing cubersome hop-counting
> or RTT estimation mechanisms.  
>
> You would have to be careful about setting go-fast-mode for the local
> net if you have proxy-ARP on that net, but you could still hack around
> that by setting up specific routes for the proxyarped hosts.  It would
> be a bit messy, but that would serve you right ;-)

Set asside the question of how a router would compute the go-fast bit when
advertising routes.

On standards committee political grounds, there is absolutely no hope that
any interior routing protocol would ever carry a go-fast bit.  That implies
such that a routing-table bit would be either only a local, purely manual
configuration option, or it would a repository for a bit set by other
means such as hop counting, RTT estimating, or netmask peeking.  Thus,
we're back where we started, having only chosen a place to put the
information in some implementations.

In other words, the "some, as yet undefined, mechanism" by which routing
or anything else would figure out whether to go fast is the crux of the
issue.  Given that mechanism, where you cache its answer is an
implementation detail.

Vernon Schryver    [email-masked]

---

From: [email-masked] (Sam Manthorpe)
Date: Fri, 23 Oct 1998 10:40:20 -0700 (PDT)

Vernon Schryver wrote:
> [...]

I can't immediately see any reason why you would even want to communicate
this information in a routing protocol, but I haven't thought about it
in any depth yet.

> issue.  Given that mechanism, where you cache its answer is an

I wasn't suggesting this is an alternative to an RTT based, or hop-count 
based or whatever-based mechanism, rather as a supplement to one of these.

The way I interpreted the ongoing discussion is to find _automatic_
mechanisms that would become part of a TCP implementation to determining
whether to `go fast' or not.  The routing table flag suggestion enables
you to manually configure go-fast mode and thus takes care of all
these `special' cases (proxy-ARP, LANE, bridges) that have been cited
as examples of why automated-scheme-x will not work.

It would be an implementational choice of whether you employ some automated
scheme of setting this bit, based on hop counts, RTT or whatever...

-- Sam

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sam Manthorpe, SGI.  tel: (650)933-2856 fax: (650)932-2856  [email-masked]