Per-Entity Metadata Working Group - 2016-09-07
Agenda and Notes
[EtherPad used to create these notes: Agenda_and_Notes_-_2016-09-07.etherpad]
Dial in from a Phone:
Dial one of the following numbers:
Meeting URL (for VOIP and video): https://bluejeans.com/195646158
Wiki space: https://spaces.at.internet2.edu/x/T4PmBQ
- Scott Koranda (LIGO)
- Michael Domingues (University of Iowa)
- David Walker (Internet2/InCommon)
- Tom Scavo, InCommon/Internet2
- Tom Mitchell (GENI)
- Ian Young
- IJ Kim, Internet2
- John Kazmerzak, University of Iowa
- Walter Hoehn, Memphis
- Rhys Smith, Jisc
- Phil Pishioneri, Penn State (leaving @14:25UTC)
- Chris Phillips, CANARIE
- Paul Caskey, Internet2
- Scott Cantor, tOSU
Agenda and Notes
- NOTE WELL: All Internet2 Activities are governed by the Internet2 Intellectual Property Framework. - http://www.internet2.edu/policies/intellectual-property-framework/
- NOTE WELL: The call is being recorded.
- Agenda bash
- Interim report/finding on IdP only aggregate
- Any feedback from TAC or Steering?
- What happens now?
- Anything further needed from the working group?
- TomS: The TAC accepted the interim report and will forward it to Steering as an FYI. (It doesn't require a Steering vote.) Nothing more is needed from the working group.
- Update from UK fed MDQ rollout (Rhys)
- Moved UK federation infrastructure to Azure
- Ian has created Shibboleth MDA pipelines to take a single aggregate and output per-entity files, then sign them (performed with HSM)
- Symlinking SHA1 hash of entityID to per-entity file (and supports gzipped versions of each)
- Result is a MDQ server (Apache) that serves static files that are generated whenever a new aggregate is created (once it's in production).
- Not using commercial CDN at present (?)
- Pipeline performance (N.B.: Uses a "top-of-the-line" HSM -- Thales nShield Connect): Generated 3605 files in 00:01:20
- 10.45k is the average size of the per-enttiy metadata files
- If you want to hit it, it's at http://mdq-test.ukfederation.org.uk/entities/
- Acceptable latency for our Requirements section
- Where do we measure latency?
- What numbers do we require?
- Strawman: "The 99th percentile of response times for queries to the distribution layer must be less than 500ms, as measured from [the Internet2 backbone]
- Do we have a measurement point on [the Internet2 backbone]?
- Over what period should we do these measurements?
- How often should the measurements be taken?
- The IdP could be instrumented to log response times. We could monitor selected IdPs.
- We should request that instrumentation from the TIER project.
- We'll change 500ms to 200ms at 99th percentile (David and Scott K will add further specifiers / decorations to this metric)
- Ability to maintain the latency requirements over time -- should include target latency over rate of queries -- incorporate load for target metrics
- Understanding the initial load to be placed on the servers is hard. Function of net federation login activity (future) as opposed to net aggregate size (current). We'll put the issue on Ops's road map.
- The performance targets above will be measured on a monthly basis
- Scott C: In the education space (as opposed to the commercial sector) we tend to have different seasonal load peaks
- HTTPS and the TLS trust model for InCommon MDQ service
- Further discussion of pros and cons
- Consensus for report?
- HTTPS is desirable, but not required in our specs (?)
- Perhaps a Phase II item?
- We'll need to decide what the certificate should be.
- ScottC: At some point, we'll need to address validity times
- These will probably be hours or days.
- TLS can help mitigate the risk of getting stale metadata from a spoofed server.
- To be clear, TLS is not a substitute for the signatures in the metadata.
- We'll continue this discussion via email and in next week's call.
- Deployment architecture: CDN versus hosted servers
- What are the discriminators other than cost?
- (We ran out of time for this.)
- Charter review: what have we missed?
- Everyone please review this before next call to make sure we aren't missing anything.
- Timeline going forward (2 calls)
- Propose that we focus on the report deliverable
- Use calls to efficiently work through issues on text/diagrams
- Any remaining time is spent brainstorming on discovery