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

From: [email-masked] (Sam Manthorpe)
Date: Fri, 23 Oct 1998 11:59:00 -0700 (PDT)

Vernon Schryver wrote:
> 
> > From: [email-masked] (Sam Manthorpe)
> 
> > ...
> > 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.
> 
> If it is not sent in routing packets, why should the go-fast-to-this-host
> bit be in the routing table?  I agree that's a nice place to put it, but
> it is not the only place.  The situation is very much like path MTU
> discovery.  Many people put the discovered MTU in the routing table, but
> that is not the only choice, as shown by some code on bonnie.engr.sgi.com.
> 
> 
> > > 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.
> >
> > 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.
> 
> How does putting the per-host go-fast bit in the routing table entry
> for that host (presumably along with other things such as the manual MSS)
> help the proxy-ARP case?  As far as the host that would have the bit in
> its routing table is concerned (assuming a merged ARP-IP routing table),
> all peers look the same regardless of whether proxy-ARP is involved.
> 
> Manual go-fast bits are not practical.  Proofs by example of that claim
> are the manual MSS mechanism used among SGI and Cray boxes, and the
> popularity of the automated path MTU discovery mechanism.
> 
> Are you suggesting that if the MAC source address in an ARP entry does not
> match the contents of the ARP packet (after allowing for bit-order
> nonsense on FDDI), that the go-fast bit would be automatically turned off?
> And on by default otherwise?
> 
> > It would be an implementational choice of whether you employ some automated
> > scheme of setting this bit, based on hop counts, RTT or whatever...
> 
> I am still confused.  Are you saying more than that the 4.4BSD-Lite style
> routing table is a nicer place for a per-host go-fast bit than, for
> example, an independent kernel data structure?  Note that many systems
> do not have the 4.4BSD-Lite style routing table.

I'm thinking in terms of user-interface.  My point was simply that since
there seem to be a multitude of scenarios where the simple go-fast-detection
schemes discussed would fail, it would be desirable for a sysadmin to be able
to override any automatic decision on a net-by-net or host-by-host basis.
It also provides the possibility to enable/disable GFM (go fast mode)
in the complete absence of any automated mechanism.

So my argument is really orthogonal to the discussion on a nice scheme
for detecting when one should use go-fast mode.

Yes, my thinking is definitely BSD biased; how alien OSes would chose
to implement such a scheme would be for them to decide. (the word alien
is in no way meant to be derogatory, I am myself currently a legal alien).

-- Sam

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

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 23 Oct 1998 12:26:34 -0600 (MDT)

Vernon Schryver    [email-masked]