Mailing List Archive: allocating backend attributes to layers

allocating backend attributes to layers

Dec 8, 2020, 2:11 AM

Post #1 of 4 (720 views)

I'm working on the "backend-clone" thing for dynamic directors and
I have run into something I could surprisningly not answer: Which
backend attributes lives at which levels ?

So roughly speaking our backend stack looks like this:

Director
|
+-----> [CGI]
|
v
Backend probe, hosthdr
|
+-----> [Http2, QUIC]
|
v
Http1
|
v
|
Endpoint
|
+---------+
| |
| proxyhdr prefix, proxy_header
v |
+<--------+
|
+------> TCP ipv4, ipv6, port
|
+------> UDS path
|
+------> [TLS] ipv4, ipv6, port, [clientcert, pubkey]

I have added the obvious extension-points in [....]

I have allocated the some of the backend attributes in the right column.

But now I need help:

proxy_header
------------

Can one send a PROXY header over a TLS connection ?

If not, it needs to go to the TCP and UDS levels

{connect|first_byte|between_bytes}_timeout
------------------------------------------

I dont think these would apply to [CGI], they would have
their own separate timeouts.

I lean that they belong at the Backend level, but does that make sense ?

What would first_byte and between_bytes refer to in H2 or QUIC
context ? Payload bytes or overhead bytes ?

Same question for TLS ?

max_connections
---------------

Does it go to the Backend level or the Endpoint level ?

Endpoints pool and serve multiple backends, so if we
put it in at the Backend level, you have to summ all the
backends limits to get the limit at the Endpoint level.

Maybe we need to be able to set limits both at the
Backend and Endpoint levels ?

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: allocating backend attributes to layers [ In reply to ]

slink at schokola

Dec 8, 2020, 7:51 AM

Post #2 of 4 (719 views)

Permalink

Hi,

my 2¢:

On 08/12/2020 11:11, Poul-Henning Kamp wrote:
> proxy_header
> ------------
>
> Can one send a PROXY header over a TLS connection ?

Yes. With a hypothetical TLS backend (or tls onload with a preamble), we would
still want to be able to send (a second) PROXY header if the backend has the
proxy_header attribute.

This implies that we might use the same format (PROXY) for different purposes
("connect-to" vs. "client socket" info).

> {connect|first_byte|between_bytes}_timeout
> ------------------------------------------
>
> I dont think these would apply to [CGI], they would have
> their own separate timeouts.
>
> I lean that they belong at the Backend level, but does that make sense ?
>
> What would first_byte and between_bytes refer to in H2 or QUIC
> context ? Payload bytes or overhead bytes ?
>
> Same question for TLS ?

I think your leaning makes sense. While we might need additional timeouts for
specific protocols, I think the existing timeouts are so generic that they
should have sensible translations to the payload of any protocol. IMHO,
including CGI, so I would tend to see CGI hat the same level as [Http2, QUIC].
But at any rate having it only at the director level would not be a show stopper.

> max_connections
> ---------------
>
> Does it go to the Backend level or the Endpoint level ?

Either backend or both.

- it is vital to be able to set limits on something "virtual" like a vhost or
application by defining a backend with a max_connection limits.

- adding limits at the endpoint level could make sense, but we would also need
to consider sharing of endpoints across vcls

Off topoc, yet related:

- For use with routing directors, we could make good use of some kind of
"reservation ticket" such that a routing director can make it more likely to get
a connection once the fetch starts.

- When we added the connection stats, we put them at the backend level as, at
the time, we did not want to introduce another user-visible layer. Should we
change that, we should also move the connection stats to the endpoint layer.

Nils
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: allocating backend attributes to layers [ In reply to ]

phk at phk

Dec 9, 2020, 2:13 AM

Post #3 of 4 (718 views)

Permalink

--------
Nils Goroll writes:

> - For use with routing directors, we could make good use of some kind of
> "reservation ticket" such that a routing director can make it more likely
> to get a connection once the fetch starts.

And what happens when VCL takes an entirely different path, how does the
reservation gets released ? vmod_priv ?

> - When we added the connection stats, we put them at the backend level as, at
> the time, we did not want to introduce another user-visible layer. Should we
> change that, we should also move the connection stats to the endpoint layer.

'move' or 'also implement' ?

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: allocating backend attributes to layers [ In reply to ]

slink at schokola

Dec 11, 2020, 6:36 AM

Post #4 of 4 (716 views)

Permalink

On 09/12/2020 11:13, Poul-Henning Kamp wrote:
>> - For use with routing directors, we could make good use of some kind of
>> "reservation ticket" such that a routing director can make it more likely
>> to get a connection once the fetch starts.
> And what happens when VCL takes an entirely different path, how does the
> reservation gets released ? vmod_priv ?
>
Something like that maybe, I have not looked into the details.

>> - When we added the connection stats, we put them at the backend level as, at
>> the time, we did not want to introduce another user-visible layer. Should we
>> change that, we should also move the connection stats to the endpoint layer.
> 'move' or 'also implement' ?

I think the implementation should be consistent with the user view, so yes, both.