Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Michael Richardson <[e-mail]>]

Ted Lemon <[e-mail]> wrote:
    > On Aug 11, 2017, at 12:53 PM, Michael Richardson <[e-mail]>
    > wrote:

    mcr> The example that, in contrast to all other content, is when content
    mcr> is zero-rated via 3G but not via WIFI. (generalized to any two
    mcr> uplinks) I don't know the source address selection or source routing
    mcr> can deal with that problem period.

    > Two points here. First of all, does the IETF want to support zero-rating on a
    > technological level? I guess we're somewhat agnostic about it, but I would be
    > resistant to spending cycles on it unless somebody is really energized about
    > it. It seems to me that if you have zero-rating, you have a problem.

In one of the original homenet architecture usage scenarios we have IPTV
being provided over a seperate DSL connection over IPv6, but which did not
provide general IPv6 connectivity.  This was from Japan, I believe.

That's actually an easier situation, since the connection won't work at all
if an application uses the wrong source address.  I suggested in:
   https://datatracker.ietf.org/doc/draft-richardson-homenet-secret-gardens/

which I wrote hurriedly when I understand what MIF was doing (but really it
was too late).  I feel that a lot of MIF's problem statement was tied up with
existing operators apply IPv4 think to IPv6.

    > That said, I certainly agree with you that MPvD doesn't solve this problem.
    > The general attitude with MPvD is that when you have multiple provisioning
    > domains, it's not necessarily the case that you can believe the claims that
    > one provider or the other makes. If you want to zero-rate, the person who's
    > going to be paying for it when the zero-rating doesn't happen is going to be
    > responsible for making sure that it's configured correctly. If the person who
    > makes the money is responsible for configuring it, they are going to
    > configure it in a way that serves their interests, not the user's
    > interests.

In the debate in Canada over this (where N=Bell Canada, who owns CTV), two
things seem to occur:
  a) if one is a customer of ISP N, then you use XYZ app on your phone, you
     get access to content Q. It's free because your relationship with N.
     If you are N's network, then usage fees that would normally occur are
     waved.  If you are not on N's 3G network, but on WIFI (or some other
     provider), your credentials get you access, but you might pay via that
     other path.
     The MPvD required to happen can happen in the XYZ app, and actually the
     entire ecosystem is a walled garden.

  b) as a bonus for having play PQRT, when on ISP's N's network, then your
     traffic to third party B is free. (Typical example is Spotify)
     You can use *ANY* app you like to access the content.

    > What MPvD _does_ do in addressing this problem is that it provides a context
    > in which special-casing for zero-rating can be effectively configured.
    > Without MPvD or something like it, it's actually impossible to support
    > zero-rating, even if you think that's a desirable thing to do.

I agree that it may be required. I am suggesting that it's not sufficient on
it's own.  You can only get situation (a) above, not situation (b).

    > If we were to support zero-rating, the way I would propose that we do it is
    > to specify a way that a provider can advertise the availability of
    > zero-rating for some set of products, and the user can choose to accept or
    > not accept that advertising in a convenient way, rather than having to
    > manually configure a whitelist. But don't get me started on the opportunities
    > for trouble that this idea presents.

I agree.  It seems like it ought to be a routing protocol at the edge, that
the destinations involved should be advertised with longer prefixes, and with
some kind of metric that implies the cost.  The edge routers that hear this
should be skeptical, but should provide the information to the user.
(The CAPPORT protocol and API would be useful here!)

    mcr> It seems to me that we are re-inventing SHIM6, trying in vain to
    mcr> pretend wenever heard of that. And I still don't understand why it
    mcr> was killed.

    > Shim6 attempts to solve a much larger problem, and in a rather heavyweight
    > and top-down way.

I view MPvD as being as being heavier weight, involving changes to more parts
of the host stack, with poorer results.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-