Re: [CDNi] [E] draft-ietf-cdni-additional-footprint-types-01.txt

[Benson Muite <[e-mail]>]

Hi Kevin,

For footprints, RajeevRK raised issues on capability advertisement and 
overlapping footprints - one example use case is in education where one 
may want to stream to a particular set of learning institutions. Cities 
such as New York, Shanghai etc. provide a use case where a large number 
of people may stream video on mobile devices or through broadband 
connections - thereby having overlapping footprints with different 
capabilities. At this point, satellites such as Starlink are not in high 
use, but may be another consideration of overlapping footprints with 
different capabilities.  Appropriately protecting the metadata for these 
was also raised.

Probably the easiest way forward is specifying extensions with optional 
additional capabilities.

Benson

On 8/2/22 08:02, Kevin Ma wrote:
> Hi Benson,
> 
>    I think if there is a good use case and you want to submit a draft, 
> we can take it up, but we'll move forward with the current draft.
> 
> thanx!
> 
> --  Kevin J. Ma
> 
> 
> On Fri, Jul 29, 2022 at 3:30 PM Benson Muite <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Kevin,
> 
>       From the discussion today, probably something that is more carefully
>     considered is better.  Happy to draft an extension/addition if it would
>     be considered.
> 
>     Benson
> 
>     On 7/9/22 17:50, Kevin Ma wrote:
>      > Hi Benson,
>      >
>      >    I think what I'm hearing is that: there is no disagreement
>     that ISO
>      > 3166-2 would be useful to have; but, there is value in having
>     something
>      > more granular.  I personally agree with both of those statements.
>      >
>      >    As chair, I would prefer not to hold up the footprint types
>     draft.
>      > If this is a quick addition, I think we can consider it, but if
>     it is
>      > something that needs more time, I would suggest tracking it in a
>      > separate draft.  I would actually suggest submitting a draft either
>      > way.  Do you have proposed text for a more granular footprint,
>     and could
>      > you get a quick and dirty draft in before Monday, so that we could
>      > discuss it at IETF 114?  If it is straightforward, we could merge
>     the
>      > drafts, otherwise it could proceed as a separate draft.
>      >
>      > thanx!
>      >
>      > --  Kevin J. Ma
>      >
>      > On Tue, Jul 5, 2022 at 12:34 AM Benson Muite
>     <[e-mail] <mailto:[e-mail]>
>      > <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
>      >
>      >     Hi Kevin,
>      >
>      >     ISO 3166-2 is nice, but there are no sub divisions below it,
>     likely
>      >     partly because there are so many country specific
>     variations.  Many
>      >     states in the USA have similar land areas and populations to
>     countries
>      >     in Europe.
>      >
>      >       From a practical point of view, consumer facing ISPs will
>     either have
>      >     cables to end users in certain regions, or cell towers in certain
>      >     regions with particular capabilities.  Thus, if they are
>     going to give
>      >     quality of service assurance guarantees, ISO 3166-2 regions
>     will be too
>      >     large.  From deploying and using video conferencing
>     platforms, the
>      >     current end user tool for testing quality of service is using
>     ping and
>      >     measuring upload and download speeds.  Knowing that an ISP
>     can provide
>      >     high quality of service within a particular region would be
>     helpful for
>      >     end users and broadcasters.
>      >
>      >     Regards,
>      >     Benson
>      >
>      >     On 7/4/22 19:51, Kevin Ma wrote:
>      >      > Hi Benson,
>      >      >
>      >      >    Thanks for the pointer!  In my past experience, a lot
>     of the
>      >      > contractual obligations for content serving tended to
>     revolve around
>      >      > political subdivisions (for better or worse), so I can see the
>      >     immediate
>      >      > use case for ISO 3166-2.  Though I've heard of trying to
>     do more
>      >      > granular geo-fencing in local markets, I'm not sure how
>     prevalent
>      >     those
>      >      > are these days.  When looking at a use case, it is certainly
>      >     helpful if
>      >      > technical solutions (as you point out) exist, but I'd also
>     look
>      >     at ease
>      >      > of use and adoption by end users.  Again, I don't have insight
>      >     into how
>      >      > broadly coordinate-based geo-fencing is used or how much
>     demand
>      >     there is
>      >      > for it today or on the horizon.  My concern is that: though
>      >      > coordinate-based geo-fencing is a superset, as you point
>     out, if the
>      >      > increased complexity of managing the official coordinate set
>      >     definitions
>      >      > and translating them back to the business terms is too
>     high, then
>      >     the
>      >      > solution may not be useful.  I don't want to discount a viable
>      >      > alternative, but I also don't want to over-engineer a
>     solution if
>      >     the
>      >      > proposed solution meets our needs.
>      >      >
>      >      >    I look to others who may have more real world use case
>      >     knowledge here
>      >      > to weigh in on the merits of the coordinate-based geo-fencing
>      >     alternative?
>      >      >
>      >      > thanx!
>      >      >
>      >      > --  Kevin J. Ma
>      >      >
>      >      >
>      >      > On Mon, Jul 4, 2022 at 12:31 PM Benson Muite
>      >     <[e-mail]
>     <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      > <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>> wrote:
>      >      >
>      >      >     An openly accessible version of the standard is
>     available at
>      >      > https://docs.ogc.org/as/18-005r5/18-005r5.html
>     <https://docs.ogc.org/as/18-005r5/18-005r5.html>
>      >     <https://docs.ogc.org/as/18-005r5/18-005r5.html
>     <https://docs.ogc.org/as/18-005r5/18-005r5.html>>
>      >      >     <https://docs.ogc.org/as/18-005r5/18-005r5.html
>     <https://docs.ogc.org/as/18-005r5/18-005r5.html>
>      >     <https://docs.ogc.org/as/18-005r5/18-005r5.html
>     <https://docs.ogc.org/as/18-005r5/18-005r5.html>>>
>      >      >
>      >      >     On 7/4/22 18:25, Benson Muite wrote:
>      >      >      > Hi Kevin and Sanjay,
>      >      >      >
>      >      >      > Thanks for the feedback and takig this into
>      >     consideration.  Sorry
>      >      >     missed
>      >      >      > your first message Sanjay.
>      >      >      >
>      >      >      > For your use case of distribution from an upstream
>     CDN to ISP
>      >      >     caches,
>      >      >      > this seems ok.
>      >      >      >
>      >      >      > For distribution from ISP caches, ISO 3166-2 are
>     political
>      >      >     subdivisions
>      >      >      > of a country.  Many ISPs will give information on
>     particular
>      >      >      > neighborhoods they serve, so it is possible to be
>     much more
>      >      >     precise on
>      >      >      > their reach than is possible from ISO 3166-2. There
>     will
>      >     be many
>      >      >     cases
>      >      >      > where a full subdivision will not be reachable - I
>     expect some
>      >      >     regions
>      >      >      > in Alaska would fit in this category, in addition
>     to many
>      >     regions in
>      >      >      > Africa and possibly some regions in Russia and
>     Australia.
>      >      >      >
>      >      >      >
>      >      >      > There is a standard for earth based coordinates
>     [1], and an
>      >      >      > implementation[2]. This may give more flexibility
>     since it
>      >     can also
>      >      >      > describe ISO 3166-2 regions.
>      >      >      >
>      >      >      > Benson
>      >      >      >
>      >      >      > [1] https://www.iso.org/standard/74039.html
>     <https://www.iso.org/standard/74039.html>
>      >     <https://www.iso.org/standard/74039.html
>     <https://www.iso.org/standard/74039.html>>
>      >      >     <https://www.iso.org/standard/74039.html
>     <https://www.iso.org/standard/74039.html>
>      >     <https://www.iso.org/standard/74039.html
>     <https://www.iso.org/standard/74039.html>>>
>      >      >      > [2] https://www.osgeo.org/projects/proj/
>     <https://www.osgeo.org/projects/proj/>
>      >     <https://www.osgeo.org/projects/proj/
>     <https://www.osgeo.org/projects/proj/>>
>      >      >     <https://www.osgeo.org/projects/proj/
>     <https://www.osgeo.org/projects/proj/>
>      >     <https://www.osgeo.org/projects/proj/
>     <https://www.osgeo.org/projects/proj/>>>
>      >      >      >
>      >      >      > On 7/4/22 17:18, Kevin Ma wrote:
>      >      >      >> Hi Benson/Sanjay,
>      >      >      >>
>      >      >      >>    (As chair) I think if there is a strong use
>     case for a
>      >     more
>      >      >      >> detailed closed-polygon approach, it could be
>      >     considered.  It could
>      >      >      >> also be a separate draft if it is not yet fully
>     fleshed
>      >     out.  Given
>      >      >      >> the SVAs specific use case, and the simplicity of the
>      >     proposal, I
>      >      >      >> would hesitate to add more complexity without a
>     real world
>      >      >      >> requirement.  Again, nothing prevents a subsequent
>     draft
>      >     adding
>      >      >      >> another footprint type if it turns out we need more
>      >     granularity.
>      >      >      >>
>      >      >      >>    Do we think we can live with the current
>     proposal for now?
>      >      >      >>
>      >      >      >> thanx!
>      >      >      >>
>      >      >      >> --  Kevin J. Ma
>      >      >      >>
>      >      >      >>
>      >      >      >> On Thu, Jun 30, 2022 at 9:12 AM Mishra, Sanjay
>      >      >      >> <sanjay.mishra=[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >      >     <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      >      >> <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >      >     <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>>> wrote:
>      >      >      >>
>      >      >      >>     Hi Benson -
>      >      >      >>
>      >      >      >>     (speaking as a co-author of the document ->
>      >      >      >>
>      >      >      >>
>      >      >
>      >
>     https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/
>     <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/>
>      >   
>       <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/ <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/>>
>      >      >
>      >     
>       <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/ <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/> <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/ <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/>>>
>      >      >
>      >      >      >>
>      >      >      >>
>      >      >      >>
>      >      >
>      >     
>       <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/ <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/> <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/ <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/>>
>      >      >
>      >     
>       <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/ <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/> <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/ <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/>>>>)
>      >      >
>      >      >      >>
>      >      >      >>
>      >      >      >>     The scope of the current draft is intentionally
>      >     limited to a use
>      >      >      >>     case that allows delegation from an
>     upstream CDN (a
>      >     CDN or a
>      >      >     content
>      >      >      >>     provider) to be able to delegate to a
>     downstream CDN
>      >      >     (specifically,
>      >      >      >>     ISP hosted caches) for content distribution to the
>      >     eyeballs. The
>      >      >      >>     particular use case focused on delegation that
>     allowed
>      >      >     delegation
>      >      >      >>     such as ASN+State, and for the purposes of
>     reaching
>      >     out to the
>      >      >      >>     larger geographic area, this level of
>     granularity was
>      >      >     implemented
>      >      >      >>     and tested.
>      >      >      >>
>      >      >      >>     Much of the work and implementation has been done
>      >     within the
>      >      >     open
>      >      >      >>     caching working group(1) of the streaming Video
>      >     Alliance(2).
>      >      >      >>
>      >      >      >>     My sense is to keep the scope to what has been
>     verifiably
>      >      >      >> implemented.
>      >      >      >>
>      >      >      >>     Thanks
>      >      >      >>     Sanjay
>      >      >      >>
>      >      >      >>     1.
>     https://opencaching.streamingvideoalliance.org/
>     <https://opencaching.streamingvideoalliance.org/>
>      >     <https://opencaching.streamingvideoalliance.org/
>     <https://opencaching.streamingvideoalliance.org/>>
>      >      >     <https://opencaching.streamingvideoalliance.org/
>     <https://opencaching.streamingvideoalliance.org/>
>      >     <https://opencaching.streamingvideoalliance.org/
>     <https://opencaching.streamingvideoalliance.org/>>>
>      >      >      >>    
>     <https://opencaching.streamingvideoalliance.org/
>     <https://opencaching.streamingvideoalliance.org/>
>      >     <https://opencaching.streamingvideoalliance.org/
>     <https://opencaching.streamingvideoalliance.org/>>
>      >      >     <https://opencaching.streamingvideoalliance.org/
>     <https://opencaching.streamingvideoalliance.org/>
>      >     <https://opencaching.streamingvideoalliance.org/
>     <https://opencaching.streamingvideoalliance.org/>>>>
>      >      >      >>     2. https://www.streamingvideoalliance.org/
>     <https://www.streamingvideoalliance.org/>
>      >     <https://www.streamingvideoalliance.org/
>     <https://www.streamingvideoalliance.org/>>
>      >      >     <https://www.streamingvideoalliance.org/
>     <https://www.streamingvideoalliance.org/>
>      >     <https://www.streamingvideoalliance.org/
>     <https://www.streamingvideoalliance.org/>>>
>      >      >      >>     <https://www.streamingvideoalliance.org/
>     <https://www.streamingvideoalliance.org/>
>      >     <https://www.streamingvideoalliance.org/
>     <https://www.streamingvideoalliance.org/>>
>      >      >     <https://www.streamingvideoalliance.org/
>     <https://www.streamingvideoalliance.org/>
>      >     <https://www.streamingvideoalliance.org/
>     <https://www.streamingvideoalliance.org/>>>>
>      >      >      >>
>      >      >      >>
>      >      >      >>
>      >      >      >>     On Tue, Mar 22, 2022 at 2:47 PM Benson Muite
>      >      >      >>     <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >      >     <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      >     <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >      >     <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>>>
>      >      >      >> wrote:
>      >      >      >>
>      >      >      >>         Hi,
>      >      >      >>
>      >      >      >>         This is a helpful addition.  However, the
>      >     specification may
>      >      >      >>         still be too
>      >      >      >>         broad, in particular for sparsely
>     populated regions
>      >      >     where one
>      >      >      >>         might be
>      >      >      >>         able to guarantee access to a single town
>     or city
>      >     in an
>      >      >     ISO3166-2
>      >      >      >>         region, but not to other settlements in the
>      >     region.  The
>      >      >     original
>      >      >      >>         specification does allow for geographical
>      >     coordinates.
>      >      >     It may be
>      >      >      >>         helpful
>      >      >      >>         to also allow optional specification of a
>     closed
>      >     polygon
>      >      >     using
>      >      >      >>         latitude
>      >      >      >>         and longitude coordinates. One could take
>     inspiration
>      >      >     from the
>      >      >      >>         shapefile
>      >      >      >>         specification which uses a bounding box,
>     and an
>      >     inscribed
>      >      >      >>         polygon[1].
>      >      >      >>
>      >      >      >>         [1]
>      >      >      >>
>      >      >      >>
>      >      >