Re: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF inHiroshima?

[João Taveira Araújo <[e-mail]>]

Feedback inline.

[e-mail] wrote:
> A problem statement motivating the need for congestion exposure
>
> The Internet has been a phenomenal success. But for how much longer can
> that success last? As access networks get faster and faster, the nature
> of the network is changing. New applications appear every year, each in
> turn making greater and greater demands on the infrastructure. It is
> increasingly clear that the current approach to sharing capacity between
> users of networks isn't working. As a consequence ISPs feel they have to
> police "heavy users" to free up resources for the bulk of their
> customers. This involves making assumptions about the wishes of their
> customers which in turn is eroding trust between ISPs, customers,
> content providers and application writers.
>   

My issue with the first half of the paragraph is it could hold true at 
any point
in time over the past 20 years at the very least. Before going into how ISPs
react I think it would be more useful to directly state why throwing 
bandwidth
at the problem is no longer an effective way of dealing with capacity 
sharing
*at this point in time*, and why it will only get worse.


> Their motives for behaving like this are perfectly understandable - they
> want the majority of their customers to receive a good service. The
> problem is that in trying to control these so-called heavy users, ISPs
> are seeking to control the wrong thing. It isn't the volume of data a
> user sends that causes problems; it is trying to send too much data when
> everyone else is that is the problem - it is a gross simplification to
> assume that a user sending lots of data must be causing lots of
> congestion. By "punishing" traffic regardless of the impact it is
> having, these ISPs are second-guessing their customers priorities and
> not allowing them the freedom to prioritise their own traffic.
>
>   

Then this paragraph can give an overview of how ISPs retaliate, and 
explain how
each fails to address the problem scalably/elegantly/efficiently. So I 
think the last
two sentences of the first paragraph actually belong somewhere here.


> Current work at the IETF [LEDBAT, ALTO] and IRTF [ICCRG] is looking at
> new approaches to controlling bulk data transfer rates. But these new
> approaches will only work if the operators stop limiting traffic purely
> based on application type. What is lacking is a mechanism to build trust
> between operators and end-users and between different tiers of
> operators. In short the Internet lacks a system for accountability.
>
>   

This bridges nicely into proposed solution. Might want to add that this 
simply
subdivides traffic into best-effort and lower-than-best effort, so while 
it is
an improvement, it is not flexible enough to span the full range of 
application
requirements.



> So what is the solution? Well the first stage is to be more open about
> the information end-hosts are using to determine their sending rate -
> congestion along the path. Currently this information is visible to the
> end-points but is concealed from the rest of the network. It is our
> thesis that this information should be made visible at the IP layer -
> the waist of the hourglass. Specifically, the protocols to be considered
> by this BoF will expose the actual congestion and expected rest-of-path
> congestion in the IP header of each packet such that nodes downstream of
> the source can see the impact that will be caused by any packet they
> forward. 
>
>   

Not sure it's perfectly clear how exposing congestion helps here, namely 
that it
corrects information asymmetry. Maybe something along the lines

"This lack of accountability derives from an information asymmetry which
deprives the network from viewing path metrics only available to
end-hosts. It is our thesis .."?

I'm not sure what you mean by saying the protocol will expose actual 
congestion
and expected rest-of-path congestion. AFAIK, only the latter is 
revealed, which
can be taken as a decent approximation of the former.


> Once the information is there, it is then possible to use it to measure
> the true impact of this traffic on the network. Rather than counting
> volume, a node in the network now counts congestion volume - the
> remaining congestion along the path multiplied by the size of the
> packet. This reflects the excess data that packet is trying to push
> through the network and make this a measure of the marginal cost of
> forwarding that packet.
>
>   

Not sure how deep we have to go into actually explaining what the 
network does
with this information, but then again i'm not entirely familiar with 
proposal
statements. Is it not enough to explain that networks can leverage this
information in the tussle with end-hosts, or is that too much of an
architectural vision?

Cheers,
Joao.