Subject: [arch-d] Comments on <draft-iab-marnew-report-01>

From: Bob Hinden <[email-masked]>
Date: Fri, 6 Apr 2018 10:00:04 -0700

Hi,

A few comments on <draft-iab-marnew-report-01>.  This ranges from editorial to substantive.

Bob

------------

When was this workshop?  I could not find a meeting date in the draft.

----

1.1.  Understanding "Bandwidth Optimization"

   ….

   o  Prioritisation of interactive traffic over background traffic

What do you mean by “background traffic”?  Customers on mobile networks don’t consider their email or web browsing as “background traffic”.  For that matter, what do you mean by interactive traffic?  Voice?  Please clarify.

…

   o  Business-related topics such as content delivery arrangements with
      specific content providers.

Like practices that violate network neutrality?

——

Quite a typo in:

1.4.  Use of Note Well and Charter House Rule

   The workshop was conducted under the IETF [NOTE_WELL] with the
   exception of the "Technical Analysis and Response to Potential
   Regulatory Reaction" session which was conducted under
   [CHATHAM_HOUSE_RULE].

I assume you mean “Chatham House Rule” in the section header.

———

Section 2.1 Scene Setting

I don’t think this section did an adequate job describing a mobile network.  For example, my understanding is that mobile networks the radio part is confined to the edges, the rest of the network is wired.  There isn’t any architectural differences with the wired part as compared with other ISP networks.  I think the report would be better if it went into more detail about this.  The issues are in or near the radio network.

I realize this is a report on a meeting, but there wasn’t any discussion of the tradeoff so creating smaller cell site to get more bandwidth and reduced latency.  This can also be a solution to some of the issues discussed here.

——

2.1.2  Encryption Statistics

Good to see that encrypted content is reaching around 50%.  But as I noted earlier when was this?  What is it today?

———

2.3.  Awareness of User Choice (Privacy)

….

   If users and content providers are to opt-in to user network
   management services with negative privacy impacts they should see
   clear value from using these services, and understand the impacts on
   clear interfaces.  Users should also have easy abilities to opt-out.
   Some users will always automatically click through consent requests,
   so any model relying on explicit consent is flawed for these users.
   Understanding the extent of "auto click through" may help make better
   decisions for consent requests in the future.  One model (Cooperative
   Traffic Management) works as an agent of the user; by opting-in
   metadata can be shared.  Issues with this involve trust only being
   applied at endpoints.

I note my personal view is that I am fine with providers using me as the product when I am using a free service (like gmail that I am using to send this).   I strongly dislike my information being used when I pay for the service.  Since mobile operators don’t usually provide a free service, I don’t think they should be using our data to make additional money.  Enough is enough.

This would be a good topic for the IAB to explore.

----------

3.1.  Sending Data Up / Down for Network Management Benefits

….

   o  Network Status API: An API for operators to share congestion
      status or the state of a cell before an application starts sending
      data could allow applications to change their behaviour.

So this would be something like giving the hosts a way to understand what’s going on inside a particular network (or access network)?  Does this scale?  This seems to me to be looking at the mobile network as the center and not just a part of the Internet.  Could you clarify this?

———

7.  Suggested Principles and Solutions

….

   o  CDNs and Caches: placing caches closer to the mobile user or
      making more intelligent CDNs would result in faster content
      delivery and less train on the network.  Related work includes:

Does this mean putting caches closer to the the edge where the radios are?

….

   o  One bit for latency / bandwidth trade-off: determining whether
      using a single bit to distinguish between traffic that the sender
      prefers to be queued and traffic that the sender would prefer to
      drop rather than delay provides additional benefits beyond what
      can be achieved without this signaling.

A bit in the IP header?  Who’s going to set this bit?  Why not support RFC3514 too and solve all security problems too?

——

8.  Since MaRNEW

…..

   The most rewarding output of MaRNEW is perhaps the most intangible.
   MaRNEW gave two rather divergent industry groups the opportunity to
   connect and discuss common technologies and issues affecting users
   and operations.  Mobile Network providers and key Internet engineers
   and experts have developed a greater collaborative relationship to
   aid development of further standards which work across networks in a
   secure manner.

Very good!

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 11 Apr 2018 14:38:23 -0500

Hi, Bob,

> editorial to substantive.

Thanks for these. Your comments are very helpful, especially to someone
who's been really close to this work and doesn't always remember what
people haven't seen.

I'll coordinate with the IAB when it's time to put out a revision.

Spencer

> What do you mean by “background traffic”?  Customers on mobile networks
> don’t consider their email or web browsing as “background traffic”.  For
> that matter, what do you mean by interactive traffic?  Voice?  Please
> clarify.
>
> …
>
> I don’t think this section did an adequate job describing a mobile
> network.  For example, my understanding is that mobile networks the radio
> part is confined to the edges, the rest of the network is wired.  There
> isn’t any architectural differences with the wired part as compared with
> other ISP networks.  I think the report would be better if it went into
> more detail about this.  The issues are in or near the radio network.
>
> I realize this is a report on a meeting, but there wasn’t any discussion
> of the tradeoff so creating smaller cell site to get more bandwidth and
> reduced latency.  This can also be a solution to some of the issues
> discussed here.
>
> ——
>
> I note my personal view is that I am fine with providers using me as the
> product when I am using a free service (like gmail that I am using to send
> this).   I strongly dislike my information being used when I pay for the
> service.  Since mobile operators don’t usually provide a free service, I
> don’t think they should be using our data to make additional money.  Enough
> is enough.
>
> So this would be something like giving the hosts a way to understand
> what’s going on inside a particular network (or access network)?  Does this
> scale?  This seems to me to be looking at the mobile network as the center
> and not just a part of the Internet.  Could you clarify this?
>
> ———
>
> A bit in the IP header?  Who’s going to set this bit?  Why not support
> RFC3514 too and solve all security problems too?
>
> ——
>
> 8.  Since MaRNEW
>
> …..
>
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>
>