Per-Entity Metadata Working Group - 2016-08-31
Agenda and Notes
[Etherpad used to create these notes: Agenda_and_Notes_-_2016-08-31.etherpad]
Dial in from a Phone:
Dial one of the following numbers:
+1.408.740.7256
+1.888.240.2560
+1.408.317.9253
195646158 #
Meeting URL (for VOIP and video): https://bluejeans.com/195646158
Wiki space: https://spaces.at.internet2.edu/x/T4PmBQ
Attendees
- David Walker, InCommon/Internet2
- Scott Koranda, LIGO
- Nick Roy, InCommon/Internet2
- Ian Young
- Regrets for not attending: Chris Phillips /CANARIE
- Regrets for not attending: Rhys Smith, Jisc
- John Kazmerzak, University of Iowa
- Paul Engle (Rice U)
- Tom Scavo, InCommon/Internet2
- IJ Kim, Internet2
- Tom Mitchell, GENI
- Scott Cantor, tOSU
- Paul Caskey, Internet2
- Steve Carmody, Brown
- Ann West, Internet2/InCommon
- Tommy Doan, Southern Methodist University
Agenda and Notes
- (Discussion of collaboration for the final report before official start of call)
- David and Scott will talk about moving final report to Google Docs.
- 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
- Distributing an IdP-only aggregate
- Ops perspective: https://spaces.at.internet2.edu/x/UgAZBg (Tom Scavo)
- Nick: No service is permanent; there will always be change. Being conservative about change is warranted, but need to balance it with pragmatism
- A single IdP-only aggregate or a pipeline triplet (preview, main, fallback)?
- Not clear if there is an Ops recommendation?
- It's nice having the triplet, but there's a cost for each aggregate. Also, there's a potential of confusion due to a large number of aggregates.
- Consensus from last week was that we don't need the triplet. It's still our consensus.
- Ops claim: "we only get one chance to migrate deployers to a new metadata configuration." Thoughts?
- Scott K disagrees
- Getting started on this before final report from working group?
- Scott and SteveC will get the issue onto tomorrow's TAC agenda so Ops can start quickly.
- Commercial CDN latencies
- Amazon CloudFront last mile testing: https://media.amazonwebservices.com/FS_WP_AWS_CDN_CloudFront.pdf
- Interesting benchmarking exercise: http://goldfirestudios.com/blog/142/Benchmarking-Top-CDN-Providers
- It seems we're looking at ~.25 second response times.
- CDNs still seem like the right approach, but we need to have our eyes open.
- A CDN that's connected to the Internet2 backbone is a good idea, although it's not clear how any InCommon participants are Internet2 connected.
- Per-entity metadata file size for InCommon (great data!)
- Largest (without signature) is 148K (due to embedded logo)
- Smallest (without signature) is 3K
- Median is 5.3K
- Average is 6.3K
- Std deviation is 4.7K
- Current overhead of signature is roughly 2.8K
- So most per-entity payloads will be roughly 8.1K
- What contribution to the actual user experience does the CDN latency make in a MDQ scenario?
- How does it compare to the rest of the SAML flow?
- How does it compare to the rest of the work the IdP or SP must do?
- What benchmarking should be part of the roadmap?
- What is the requirement for ongoing monitoring?
- CDN features and MDQ
- Push mechanism (scp, sftp, rsync, ...)
- Origin pull (instead of push)
- Purge (invalidation)
- Purge All
- HTTPS (custom SSL capability, ie. InCommon can provide X.509 cert)
- Access logs
- SAMLbits CDN (Leif)
- Community-driven CDN specifically built for high-trust applications
- Can be customized for caching in the CDN flow
- Can translate headers, for example, SAML-HTTP
- Essentially a varnish cache - wanted to prove that it would be possible to build a community-driven CDN that didn't have to consume a lot of resources at the site
- A couple boxes online with I2 operations (TSG)
- Doesn't require the network-aware interconnect that a lot of the commercial CDN appliances require
- Been running for a couple years and seems to work well
- How do we address governance issues as SAMLbits becomes part of our solution?
- This a good excuse to start a discussion. We could think of this as governed by the community of InCommon participants or international federation operators.
- If it is to become a part of the solution, it probably needs to go to Steering for a request of some sort +1
- It's not overly difficult to deploy a local SAMLbits node, for example at a campus.
- Solution architecture description for the final report
- Next call on September 7 at the usual time and place.