[squid-users] parameter forward_max_retries

[Niu, Steven (NSB - CN/Qingdao)]

Amos, 

Thanks for your so detailed explanation. 😊 . I used wrong email address. 
Yes, we plan to have a test. But before our lab gets ready, it would be good to know the answer. 

Thanks again, 
Steven

-----Original Message-----
From: Amos Jeffries <squid3 at treenet.co.nz> 
Sent: Monday, June 3, 2019 7:05 PM
To: Niu, Steven (NSB - CN/Qingdao) <steven.niu at nokia-sbell.com>; squid-users at lists.squid-cache.org
Cc: Liu, Hank (NSB - CN/Qingdao) <hank.liu at nokia-sbell.com>
Subject: Re: [squid-users] parameter forward_max_retries

On 3/06/19 9:20 pm, Niu, Steven (NSB - CN/Qingdao) wrote:
> Hello,
> 
> I'm sorry for any bother to you. But we are evaluating our solutions and need author's confirmation about the parameter forward_max_retries. 


Then you had best contact the author. This is a mailing list for *users* of Squid to discuss and learn about the software from each other, and from those developers like myself who participate here.

AFAIK neither the developer who designed the feature, nor the developer who re-designed it to operate differently participate in this mailing list.


> Could you give me a yes or no if you have clear answer? I appreciate you response very much! Thank you!
> 
> If the configuration parameter of forward_max_retries is 3, for the following cases, is the assumption true or false? 
> Case 1:  FQDN has 4 IPs from DNS result: ip1, ip2, ip3, ip4. 
> 	If ip1, ip2, ip3 are failed, Squid would not try ip4 since forward_max_retries is 3. 
> Case 2:  FQDN has 2 IPs from DNS result: ip1, ip2. 
> 	If ip1, ip2 are failed, Squid would give final response since no more IP can try. 
> 

The answer depends on which version of Squid you are using, what those IPs are, what type of HTTP message is being attempted, and how long the process is taking.


In regards to Squid version:

* The initial design used (n_tries > forward_max_tries). Squid up to
v4.0 use this.

* The redesigned code uses (n_tries >= forward_max_tries). Squid v4 and later use this.

=> Both versions prevent destinations being contacted when their expression produces the "true" boolean result.


In regards to IPs:

* Squid which are built with IPv6 disabled completely ignore IPv6 results from DNS. They are not considered in the retries list.

* If the failure occurs at the TCP connect(2) level, then Squid-3.1 and older do not count these as tries and will attempt all IPs forward_max_tries times. Squid-3.2 and later will count them as tries.


Please also be aware that many popular websites have dozens of IPs in their DNS responses. Setting forward_max_tries less than 20 can result in these very popular websites not being contactable.


In regards to HTTP message type:

* HTTP standards specify some request methods as non-idempotent.
Retrying these requests is forbidden.

* HTTP standards define some response status codes as final and fatal.
These cannot ever be retried by an intermediary.

* HTTP transactions which involve certain stateful application layer features which break HTTP requirements about statelessness cannot be retried.
 ==> These features impact retry behaviour of the TCP connection itself.
So the non-retry outcome can be inherited from some past HTTP
transaction(s) activity.

* Any HTTP request with a payload that has begun delivery cannot be retried.

* Any HTTP response which began but did not completely arrive cannot be retried.


In regards to timing:

* timeouts for TCP connect action, TCP lifetimes, HTTP forwarding, and I/O actions can terminate any given tries early and cause later ones to not happen.

* TCP error handling is subject to ICMP (both v4 and v6) being enabled and working on your network and on *every* network between your proxy and the origin serves (both outbound and inbound routes).
 -> without ICMP the TCP errors result in 'hung' connections which usually hit timeout errors before the forwarding re-tries succeed.


Overall;

  Squid always give a final response when that final response is known.
Where that response comes from is far more complicated than your stated cases consider.


Have you tried testing for yourself the particular sites you are worried about?

Amos