RE: multi-host virtual sites for HTTP 1.2

>----------
>From: 	Jeffrey Mogul[SMTP:mogul@pa.dec.com]
>
>I consider it potentially quite important that Paul's proposal
>allows more than one referral-URI.  This not only allows replication
>for performance, it also allows replication for fault-tolerance.
>The use of multiple DNS bindings, for example, doesn't help much
>if one of the actual servers is dead (or your path through the
>Internet to that server is broken).
>
>On the other hand, Paul's description ("append [the suffix of
>the original URI] to one of the referrals") might not be sufficiently
>well specified.

Agreed. I promised Larry to get some indication that I wanted this out
within a week of the IETF, so not every detail was perfect. Of course
with more time it would have been :-).

>  I.e., if a client chooses one of the referral-URIs,
>and then after a few successful transactions that server seems to
>die, should the client re-negotiate with the original server?
>Pick another referral-URI?  Keep trying?  The behavior of the
>client in this case has some potential implications for the
>failure semantics, especially if the client is updating a
>database at the server end.

Good point.
>
>Paul's proposed BNF was:
>
>	Referral	= "Referral" ":" prefix 1#referral-URI
>	prefix  	= absoluteURI
>	referral	= absoluteURI
>
>I assume that the last line should have been:
>	referral-URI	= absoluteURI

Yes.
>
>I'd like to suggest an elaboration, to:
>
>	Referral	= "Referral" ":" prefix 1#referral-info
>	prefix  	= absoluteURI
>	referral-info	= referral-URI delta-seconds metric
>	referral-URI	= absoluteURI
>	metric		= 1*DIGIT

I was thinking about this too. I didn't want to complicate the original
proposal.
>
>Thus, a referral would include not only a new URI, but a maximum
>age ("time-to-live" in DNS terms) and a cost metric.

I thought the TTL would be in Expires header for the cached 302 response
in which this was returned.

>  The client
>algorithm would then be
>	choose from the unexpired referral-infos (those whose
>	delta-seconds is less than the Age of the response)
>	the referral-URI with the lowest metric.
>Or maybe that should be "highest metric"?  I dunno.

You probably want to spread the requests out among the referral-URIs in
proportion to the cost; otherwise everyone will jump on the lowest cost
site and it will get overloaded.

It turns out this is exactly was the proposal for SRV RRs in DNS does,
which is why I dithered about having whether it was better to use DNS.
Also, there's another proposal for location RRs in DNS (I think the name
is LOC) that include longitude and latitude -- not perfect, as all the
backbone suppliers tell me, but certainly good enough to pick a server
on the same continent in preference to one on a different continent. If
it makes sense to have them in the DNS, it makes sense to have them
here, too -- or to just use the DNS. The problem with the latter is that
SRV and LOC aren't standards, I don't know if they will become
standards, and even if they do it takes a while to get them into the
"official" DNS implementation.

Maybe a DNS guru can comment? Or a friend of one can forward it along?
I'd hate to duplicate the functionality.
>
>We could perhaps get rid of the expiration (delta-seconds) parameter if
>we made it explicit that a referral lasts only as long as the
>Cache-control: max-age of the response that carries it.  But
>you need an expiration mechanism of some sort, or else these bindings
>are impossible to revoke.

Right. Expires or max-age seemed like a good thing to re-use.
>
>We might want to modify that client algorithm so that "unexpired
>referral-info" includes "which has not been unresponsive recently".
>I.e., if a server is playing hard-to-GET, drop it from the list.

All good suggestions.

I wanted to see if there was enough interest to produce a real I-D.
Sounds like there is. Any suggestions received to date will be
incorporated; as will answers to as many objections as I can --
including future ones received as I'm writing, so keep them coming.

Thanks,

Paul

Received on Wednesday, 10 July 1996 19:17:30 UTC