Github user repodude commented on the pull request:
https://github.com/apache/trafficserver/pull/232#issuecomment-159095402
Yeah, bummer we weren't able to sync up at ATS summit as I think it might
be helpful to clarify some of this application's requirements and/or divulging
the run-time profile vetting done prior to selection of this particular
container. I'm not sure that either of the two latest alternative suggestions
are ideal for this application. Further it would be good for me to better
understand where your concerns are coming from. Will try explaining in this
PR....
The session-tickets contain the previously negotiated TLS parameters, an
expiration timestamp, are encrypted using a key known only to server, and have
the ability to tell whether a ticket came from itself. Prior to SSLConnect(),
our client does a look up in it's origin server side session ticket cache to
see if it has a non-expired ticket for the particular SNI. If so, then it
includes it in it's Client-Hello.
On completion of a handshake, if server sends back a session-ticket, it is
stored in the origin server side session ticket cache with SNI as the index
key. In a continuously running production system, one of the required
constraints on this cache is mem size and of course speed. Some TLS protocol
related details about this application that may be helpful here for picking a
container:
1) Session tickets expiration times are max bound by server and possibly
further constrained by client. 24 hours is common though based on
server's trust of AES128 and key rotations schedule.
2) Protocol is completely tolerant of delivery of wrong or expired tickets.
3) Failure of session-ticket re-use simply results in fallback to session-ID
re-use or worst case, full-handshake.
We can use these constraints to optimize to our hard production speed and
space system requirements. Namely, hash collisions are fine, i.e. buckets
never grow past a size of 1. We overwrite in our bucket because in the case of
collision, the cost in the vast majority of cases will be non-consequential,
and in worse case amortize into nothing. Overwriting of already allocated
buckets is fastest reclamation. In patch, even the hostname key (small fixed
size to 32), is re-used, so no alloc/free, but rather overwrite of previous
allocated space.
While, I'm not necessarily advocating for standard unordered_map because
I'm not sure what the other concerns are, I will say relevant to the above, the
max_load_factor is set to 1.0 for no-growth bucket overwrite case, and I did
run independent tests to profile bucket number growth characteristics. A
possible alternative unordered_map that I discussed with Alan would be just to
use a non-growth hash indexed array.
Thoughts?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
