Re: [Marnew] The "explicit Internet" discussion

[Natasha Rooney <[e-mail]>]

Thanks for this Ted! Sorry for the late response. Copying Wendy because I mention A LOT of web stuff here and she can sense check my thoughts.

> On Aug 20, 2015, at 5:54 AM, Ted Hardie <[e-mail]> wrote:
>
> So, I started thinking about this some time ago, got distracted, but re-awoke to the need to send it out today after a separate message from Brian.  My apologies for the dealy.
>
> During the ISOC briefing panel on Tuesday of IETF 93, one of the discussion points was the tension among the radio network, the device, and the application.  That tension results in part from each trying to optimize its own piece of the puzzle using only inferences about what the others' state is or requirements might be.  In order to deliver a snappy user experience, for example, an app may pre-cache DNS information about likely next destinations in the click trail; that costs energy from the device's store of energy and radio air time from the radio network (as well as actual money).

Yeah this realisation was my favourite part of the panel. It was funny given that as soon as people say "solve the performance issue as in the best way you can" I think "yeah I’ll just build an app with serviceworker", which is a web tech. My first inclination is not "fix it with protocols", and the fact that much of the panel spoke of protocols made me go "huh.". I’ve felt a bit different about these issues since then.

>
> One possible improvement to the current state is to enable different actors to have a better understanding of the current state of the others' resources.  An application that knows the battery is under 30% full may decide not to do opportunistic cache fill; it may also decide to bundle likely queries into groups if it knows when the radio network can support the traffic.

Apps should be able to do this now - even web apps (with serviceworker again!). Although this is a special cache, not HTTP cache.

>
> That particular approach requires a good bit of application logic be built into lots of applications.  A different design might allow the application to use a marker (like "speculative request") on the DNS query.  The application  can then test the cache for the presence of the result when it's needed, rather than blocking on a return.  The OS might block the use of the radio for speculative requests if it is energy starved, causing the application to incur latency (but only for the requests actually used).  Similarly, the UE could use markers from the radio network in making its decision (such as the current bandwidth of the data channel assigned), instead of passing that information up to the application.

Cool. I am a little confused how this saves battery on a lookup (so I assume you mean just for filling in which case it makes sense!)

>
> It's clear that cross-layer optimization might yield some benefits, but there are also some obvious concerns.  Being able to test what the current battery drain is, for example, can expose when the screen and camera are active, which may not be appropriate information to yield to all applications.  Radio networks may be reluctant to allow UEs and applications to know the current state, especially if there is resource contention.

Sorry the web dev in me is screaming again: permissions should handle this (I think). Web permissions API is happening here - I think (Google’s) Adrienne Porter Felt is the pro in this area (personal hero of mine). Saying this though, I wonder if I am either making this more complicated or simple than it should / needs to be.

>
> So, what can we do?  I suspect that the best answer at the moment is to allow explicit declarations to go from the edge of the network inward, but to limit those declarations to the type of treatment that is permitted/required rather than what it is being required for.  So, an application can mark a set of packets as drop eligible, and the UE can take that into account, and then pass that along to the network.  The reason might be the packets are covered by FEC, are speculative requests, or something else.  That remains opaque; only the network treatment desired is made explicit.

I wonder whether sorting items into their correct layers is something which should be done here. There’s a lot of work going on in the web community and in the IETF (as you say above) and sometimes the right thing falls in the wrong place. For instance (ok, I know you know this but for the sake of others reading!); RTCWeb started looking into permissions for WebRTC - this was the right thing to do. However, the W3C have been knee-deep in the permissions issue for ages, and, it more naturally fits in their remit being application layer - so they sent the permissions issue back to W3C.

I am also wary though that just "sorting stuff" doesn’t solve the issues above, as some things (caching in particular!) falls into many camps. So maybe some more work needs to be looked at to tie the groups together or get them to understand each others work and goals.

Interestingly I was actually talking to Hiro Nakajima from ISOC Japan about this today! We were saying that the number of people who come to W3C AND IETF is actually shockingly small! Like in the 10s. I can name five of them (mnot, me, Wendy, Rigo, Dan Druta), I should play cross W3C/IETF bingo.

>
> Similarly, the network and UE can signal back to applications when capacity is available for less common network treatments.  For example, they could signal capacity is available for lower-than-best-effort traffic; in that case, the network would originate the signal but the UE would propagate it to an app only when it had sufficient battery and no other applications contending for the network.   The app may or may not use that capacity, and it has no need to tell the UE or the network what the scavenger class traffic might be.

We looked at this in the Web and Mobile Interest Group at W3C. Saying what I said above I think this IETF a good place to chat about this, but we just had one huge issue when we tried to work on this which I’ll bring up here. Network information for fixed networks is fine; but for mobile it sucks hard. This is mostly because a user can take two steps forward and their whole network experience can change. So, if you advertise a good network, user moves forward a few steps (or 20m on a train) and everything goes to crud and that nice big movie they started downloading is stuck. But - I can see from what you have written is that this could send for "lower-than-best-effort traffic", which wouldn’t produce the same problem above, but perhaps the opposite. Sorry if I misunderstood your point.

>
> Given encrypted networks, in other words, I think we need more explicit network signalling but only about what the network either can do or is to do.  As a cross-layer optimization, that seems like the minimum we need to make things work well and where we should stop.
>
> Any initial thoughts?
>

Think I covered my thoughts; the TLDR is; new caching stuff is good and should be looked at, the web is getting more extensible to cover this but I am not sure if this is totally the right move for everything above, and yes, groups should talk more!

Natasha

>
> Ted
> _______________________________________________
> Marnew mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/marnew

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call [phone] and highlight the error.