Per-Entity Metadata Working Group

[Chris Phillips <>]

Good dialogue on identifying what matters..

I'm sensing there's a sentiment around how one can expect something >4 9's
if no other services will claim that -right?

'Availability' metrics of a network as a whole are hard as Patrick points
out. It's a blended number and highly geographically/topology dependant --
not everything is redundant everywhere but I think 'highly available
(100%)' is worth striving to describe and the cost to get there.


FWIW, most, if not all NRENs are best effort network operators that
consistently exceed SLA's of commercial carriers/services.
This is achieved by a layered approach with techniques at different layers
mitigating gaps in the SLA/availability space. CANARIE operates a network
across 19,000km of fibre and the TCP/IP layer has a higher availability
metric than the fibre does.

I think if we step back from the lower level primitives of availability
and seek more clarity of the higher order business requirements for
per-entity metadata delivery, we may find it easier to pin down things we
need or want.  The current ones are a too vague and more precision allows
a recommendation to be more specific and prescriptive on outcomes.

Here's one take on translating availability elements into business
requirements (or vice-versa):

A When a Federation's client(IdP/SP) needs to evaluate trust, it MUST be
able to do so with these qualities:
 1. sub ${chosen_time_here} (e.g. 1000ms?) time or equivalent to current
performance characteristics, whichever is better
 2. as reliable as possible as measured by . . .
 3. under expected load peaks of X activities/sec
 4. all at runtime
 5. All as perceived by the user
B When a Federation wants to support discovery with it's metadata, it
SHOULD be:
 1. in the most trustworthy/least risk way.
 2. least punishing to the Service Provider to implement/operate
 3. least punishing to the federation Operator to implement/operate
 4. as friendly to the user as possible as often as possible
 5. As sustainable as possible.
C. Your item here


For example, if we agree on A.1.'s 'chosen time', we can profile what it
would take to deliver this and things like 'how much caching is needed in
the Shib components' with a higher degree of certainty and hone in on
areas where more detail is needed.
Everything has a price tag too. I see that as a recommendation is made it
helps shape expectations on the floor cost to delivering a quality service
and what those qualities are.

Thoughts and comments welcome as always ..

C






On 2016-08-10, 8:12 PM, 
"
 on behalf of
Cantor, Scott" 
<
 on behalf of
>
 wrote:

>On 8/10/16 8:08 PM, Patrick Radtke wrote:
>> 
>> I've spent part of the afternoon reading through outage reports for
>> CDNs and 5 9s only seems possible for short time frames. Akamai had a
>> 75 minute outage in 2011
>> (https://gigaom.com/2011/08/08/akamai-dns-issue/). Limelight's CDN had
>> a 76 minute outage in 2014
>> (http://blog.streamingmedia.com/2014/07/limelights-network-outage.html).
>> AWS's CDN has a 2 hour outage in 2014
>> 
>>(http://www.theregister.co.uk/2014/11/27/aws_cloudfront_wobbles_at_worst_
>>possible_time/).
>> Interestingly Akamai and AWS faulted DNS for their outages.
>
>Of course, usually one extended outage is much, much better than
>constant short ones. I'm more interested in monthly or weekly than annual.
>
>Which is what you were saying, and I agree, the distribution matters a
>great deal. But there has to be a metric, or only the most conservative
>position can be taken.
>
>-- Scott