[GitHub] trafficserver pull request: Ts 3559

[repodude <gi...@git.apache.org>]

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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---