[Marnew] Fwd: The "explicit Internet" discussion

[Ted Hardie <[e-mail]>]

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

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.

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.

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.

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.

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.

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?


Ted