Re: keepalives and proxies: a request and a proposal

Hi,

>     The `Connection: Keep-Alive my-name' solution allows each compliant
>     proxy to realize whether is talking to a compliant proxy/client or not.
> 
> One quibble: we should not use a host name here; we should use
> the IP address of the host (and on a multi-homed host or proxy,
> the IP address that is actually assigned to the connection).  This
> avoid the overhead (and possibly the failure) of an extra DNS lookup
> at each proxy and server.

We discussed this with Lorenzo. The IP address is probably better, but
it's just a matter of efficiency. Also,
   i) the DNS mapping is likely to be already cached locally;
  ii) all we need is a verifiable identifier which can be valid between
      the two parties. An address (IP, Decnet, whatever) is better
      than a name, but it should not be mandatory. Especially, not
      limited to the IP address family.

> Aside from that, I agree; this is 100% foolproof because every link in
> the chain must prove that it understands this header.  I don't
> understand Roy's comment that it does not adequately account for
> hierarchical proxies or gateways.

Neither do I. The only setting where this cannot work is where the two
proxies are connected through a tunnel, e.g.

	C --- P1 ---- T ---- P2 --- S

and T is passing bidirectional data without interpreting them. How
common is this setting, I don't know. Especially, I don't know if
it can be useful.

> Roy sez:
>     The only way to differentiate communication capabilities is through
>     the protocol name + version number, since that is the only feature
>     that cannot be passed on by a proxy.
> The implication is that the 1.1 protocol spec will say something
> like "a client or proxy must not send or forward a Keepalive:
> header to a proxy [or server?] with a version number below 1.1".
> Is that what you are planning, Roy?
> 
> One problem that the "Keepalive: myaddress" approach seems to
> solve better than the version-number based approach is that it
> allows a 1.1 proxy to not implement persistent connections.
> That is, under Roy's approach, persistent connection support
> would have to be 100% mandatory for all 1.1 (and later) proxies.
> Under the alternate approach, any proxy not wanting to support
> persistent connections (either for implementation reasons or
> for policy reasons) could simply drop the "Keepalive: myaddress"
> header.

Not even necessary to drop it. Just pass it downstream, the next
node will notice the difference between the addresses and will
disable the feature.

Ari Luotonen says:

> I think we can reasonably make it a requirement that proxies in the  
> upstream are same revision or newer, or at least it will be easier to
> upgrade those few.  Typical case is a company's/country's main proxy
> vs departmental proxies.  This'll keep the protocol cleaner.

No, the assumption is completely unreasonable (not only for this
particular topic, but every change in the protocol). Each organisation
uses its own product, and it is hard to force anybody to upgrade.

As for the cleannes of the protocol: Lorenzo's proposal uses just
a single header field as opposed to the two that are currently
used.  And the client has to send the same header both to a Server
and to a Proxy.

Also I would like to emphasize Lorenzo's last sentence:

> BTW, such an approach can be of general use whenever we want to
> add backward-compatible options using proxies: compliant nodes just
> replace the name field, non-compliant ones leave it untouched.

The idea of adding, next to a header field, the identifier of the node 
asking for that particular feature, is of very general applicability,
and should be kept in mind when adding new features.

	Luigi
====================================================================
Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

Received on Friday, 17 November 1995 16:00:02 UTC