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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 May 2018 17:03:56 -0500

Hi, Bob,

On Fri, Apr 6, 2018 at 12:00 PM Bob Hinden <[email-masked]> wrote:

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

Thanks for these. They;re especially valuable because I'm just too close to
this topic to see what's not clear to people who didn't attend the workshop.

Inline.

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

Duh. Fixed!

>
> ----
>
> 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.
>

I don't know that this was defined precisely in a way that all participants
would have agreed with.

I think the intention was something like "- Prioritisation of traffic for
applications with a "human in the loop" who is waiting for a response".

I made that change. There was one other use of "interactive" later in the
document, describing the target for SPROUT, but I was able to simply remove
that use. The resulting sentence is "- SPROUT: research at MIT which is a
transport protocol for applications that desire high throughput and low
delay. {{SPROUT}}".

>
> …
>
>    o  Business-related topics such as content delivery arrangements with
>       specific content providers.
>
> Like practices that violate network neutrality?
>

I suppose that would be part of the same space, but after looking back at
detailed minutes, I'm pretty sure the point is about cooperation between
operators and content providers - if an operator doesn't cooperate the same
way across all content providers, yes, but the concern was whether
operators could collaborate with ANY content providers if they're just
carrying random bits.

I think "specific" is a red herring/distraction, so I removed that word.

>
> ——
>
> 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.
>

D'oh! Fixed.

>
> ———
>
> 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.
>

Yeah, about that. We tried to dig on exactly the topic you mentioned for
roughly a year, and finally chartered the ACCORD BOF in Yokohama to press
down on that. Details at https://www.ietf.org/proceedings/94/accord.html.

So I couldn't agree with you more, but the workshop didn't explore that.
The closest we came was brainstorming on how to work together to improve
our mutual understanding, and (speaking only for myself) I'd say that a
sizable minority of the QUIC working group in London still thinks that
measuring encrypted traffic is at least as much a research topic as an
engineering topic - and that's in 2018.

I wish the workshop outcome had been different.

>
> ——
>
> 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?
>

Depending on who was measuring what ... Mozilla was reporting 50 percent as
of the workshop date in 2014. Akamai was reporting percentages in the 30s
from 2014 and expecting more than 50 percent in the next couple of years.

I'll rely on Brian Trammell and the IAB for clue about this point, but my
understanding is that IAB reports try to present the conversation as of the
workshop date, rather than trying to update the workshop report based on a
continued investigation. If that's the case, I probably won't try to
provide updated statistics.

And yes, 2014 was a long time ago ...

>
> ———
>
> 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.
>

Understood, and your comment is aging very well - it sounds smarter every
day :-( ...

>
> ----------
>
> 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?
>

Someone from the GSMA side is probably more excited than I am about this -
I was one of the TRIGTRAN BOF co-chairs in the early 2000s, and we couldn't
make a plausible case for a "local link up/down" signal, much less
congestion information that is a lot more volatile on a wireless link than
overall link status.

I still see smart people who are working in this space presenting results,
but they're presenting at ICCRG meetings because this is still research,
not engineering.

So, yes, I think you're exactly right ("the mobile network is the center
and the source of all the answers to your problems"), and if you're only
talking about congestion status for a local wireless link, and the
information is only intended for mobile devices in a single cell (or even
"mobile devices actively sending in a single cell"), you probably could
scale that, but scaling is the least of your problems.

(The closer the wireline endpoint is to the wireless link, the more
accurate it is to treat the mobile network as the center, if you push
content all the way to the cell site controller, but that's another
conversation)

I'm not thinking I should change something here. I think this was an
accurate assessment in 2014.

>
> ———
>
> 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?
>

Yes, I think so. I suspect that

   o  CDNs and Caches: placing caches closer to the edge of the radio
network, as close as possible to the mobile user, or
      making more intelligent CDNs would result in faster content
      delivery and less train on the network.

might be clearer. Does it seem to help?

Also, fixing "train on the network".

> ….
>
>    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?
>

I don't think anyone in the room was thinking "in the IP header". This was
definitely about transport space solutions. Something like SPUD (which
added an unencrypted header for encrypted payloads being carried in UDP) or
the QUIC public header were on people's minds.  The QUIC "spin bit" is
still on people's minds in 2018.

I can see this being ambiguous enough that I should clarify this. I'll go
with "one bit in an unencrypted transport header" and see if anyone else
struggles with that.

If this was a personal draft, I'd add 3514 as a reference in a heartbeat
;-) ...

>
> ——
>
> 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!
>
>
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>