Re: determining proxy reliability

Patrick McManus writes:
    My comments are based on the belief that
    draft-ietf-http-hit-metering-00.txt dated 1/21/97 is current.. let me
    know if that's not the case.. Jeff makes some references to 'latest
    draft' that had me confused, but now I think I realize that he just
    means an unreleased version..

Yes, draft-ietf-http-hit-metering-01.txt is currently wending
its way through the Internet-Draft editor's queues.  Sorry for
the confusion.
    
    :: This leaves #3, loss-in-transit.  My experience is that the most
    :: common way for servers to lose HTTP requests is due to internal
    :: congestion (i.e., the SYN_RCVD problem), so if hit-metering
    :: improves caching, the reduction in congestion ought to help this.
    :: But loss due to network partition is also a problem, and (according
    :: to Vern Paxson's SIGCOMM '96 paper) it's getting worse.  This
    :: has inspired me to change the text in the next version of the
    :: draft from "The proxy is not required to retry the [report]
    :: if it fails" to "The proxy is not required to retry the [report]
    :: if it fails (but it should do so, subject to resource constraints)."
    :: This is still "best-efforts", but the specification now encourages
    :: more effort.
    
    A strictly editorial comment.. I like the content, how about the slightly
    firmer language: The proxy SHOULD retry the [report] if it fails but
    MAY abort it if resource constraints dictate.
    
The text I put into draft-ietf-http-hit-metering-01.txt says:

      - The proxy is not required to retry the HEAD request if it
        fails (this is a best-efforts design).  To improve
        accuracy, however, the proxy SHOULD retry failed HEAD
        requests, subject to resource constraints.

Your wording is perhaps a little crisper; I'll think about
using it in a subsequent draft.

Thanks
-Jeff

Received on Thursday, 20 March 1997 10:42:30 UTC