Open Stack

On 2/16/15 11:48 AM, Lance Bragstad wrote:
>
>
> On Mon, Feb 16, 2015 at 1:21 PM, Samuel Merritt <sam at swiftstack.com
> <mailto:sam at swiftstack.com>> wrote:
>
>     On 2/14/15 9:49 PM, Adam Young wrote:
>
>         On 02/13/2015 04:19 PM, Morgan Fainberg wrote:
>
>             On February 13, 2015 at 11:51:10 AM, Lance Bragstad
>             (lbragstad at gmail.com <mailto:lbragstad at gmail.com>
>             <mailto:lbragstad at gmail.com <mailto:lbragstad at gmail.com>>)
>             wrote:
>
>                 Hello all,
>
>
>                 I'm proposing the Authenticated Encryption (AE) Token
>                 specification
>                 [1] as an SPFE. AE tokens increases scalability of
>                 Keystone by
>                 removing token persistence. This provider has been
>                 discussed prior
>                 to, and at the Paris summit [2]. There is an
>                 implementation that is
>                 currently up for review [3], that was built off a POC.
>                 Based on the
>                 POC, there has been some performance analysis done with
>                 respect to
>                 the token formats available in Keystone (UUID, PKI,
>                 PKIZ, AE) [4].
>
>                 The Keystone team spent some time discussing limitations
>                 of the
>                 current POC implementation at the mid-cycle. One case
>                 that still
>                 needs to be addressed (and is currently being worked),
>                 is federated
>                 tokens. When requesting unscoped federated tokens, the
>                 token contains
>                 unbound groups which would need to be carried in the
>                 token. This case
>                 can be handled by AE tokens but it would be possible for
>                 an unscoped
>                 federated AE token to exceed an acceptable AE token
>                 length (i.e. <
>                 255 characters). Long story short, a federation
>                 migration could be
>                 used to ensure federated AE tokens never exceed a
>                 certain length.
>
>                 Feel free to leave your comments on the AE Token spec.
>
>                 Thanks!
>
>                 Lance
>
>                 [1] https://review.openstack.org/#__/c/130050/
>                 <https://review.openstack.org/#/c/130050/>
>                 [2]
>                 https://etherpad.openstack.__org/p/kilo-keystone-__authorization
>                 <https://etherpad.openstack.org/p/kilo-keystone-authorization>
>                 [3] https://review.openstack.org/#__/c/145317/
>                 <https://review.openstack.org/#/c/145317/>
>                 [4]
>                 http://dolphm.com/__benchmarking-openstack-__keystone-token-formats/
>                 <http://dolphm.com/benchmarking-openstack-keystone-token-formats/>
>                 ______________________________________________________________________________
>                 OpenStack Development Mailing List (not for usage questions)
>                 Unsubscribe:
>                 OpenStack-dev-request at lists.__openstack.org?subject:__unsubscribe
>                 <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>                 http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>                 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>             I am for granting this exception as long as it’s clear that the
>             following is clear/true:
>
>             * All current use-cases for tokens (including federation)
>             will be
>             supported by the new token provider.
>
>             * The federation tokens being possibly over 255 characters
>             can be
>             addressed in the future if they are not addressed here (a
>             “federation
>             migration” does not clearly state what is meant.
>
>         I think the length of the token is not a real issue.  We need to
>         keep
>         them within header lengths.  That is 8k.  Anything smaller than that
>         will work.
>
>
>     I'd like to respectfully disagree here. Large tokens can
>     dramatically increase the overhead for users of Swift with small
>     objects since the token must be passed along with every request.
>
>     For example, I have a small static web site: 68 files, mean file
>     size 5508 bytes, median 636 bytes, total 374517 bytes. (It's an
>     actual site; these are genuine data.)
>
>     If I upload these things to Swift using a UUID token, then I incur
>     maybe 400 bytes of overhead per file in the HTTP request, which is a
>     7.3% bloat. On the other hand, if the token + other headers is 8K,
>     then I'm looking at 149% bloat, so I've more than doubled my
>     transfer requirements just from tokens. :/
>
>     I think that, for users of Swift and any other OpenStack data-plane
>     APIs, token size is a definite concern. I am very much in favor of
>     anything that shrinks token sizes while keeping the scalability
>     benefits of PKI tokens.
>
>
> Ideally, what's the threshold you consider acceptable for token length
> from a non-persistent perspective? Does under 255 work or do you need
> something smaller?

I don't have a particular limit in mind, but smaller is better in 
general. 255 is fine, but 300 or 400 bytes isn't too bad.

Really, it's a question of how much application developers will 
tolerate. If you tell me that uploads to object storage incur 10% 
overhead (for my workload) due to HTTP and tokens and such, I'll 
probably just accept that as the cost of convenient storage. If you tell 
me it's 150% overhead, I'm probably going to look for another way to do 
things.

Of course, that's application-dependent. If my application runs on 
mobile phones and uploads data directly to object storage over 
expensive, metered networks, then 10% might be the upper limit of my 
tolerance. On the other hand, if I've got an application running in 
cloud VMs with big fat unmetered pipes to the object storage system, I 
might not even notice 150% overhead.

Basically, the smaller the tokens, the easier it is to use OpenStack 
APIs from bandwidth-constrained locations.