[re-ECN] some comments on congestion exposure problem statement

[<[e-mail]>]

Here are a few comments on
http://www.ietf.org/id/draft-moncaster-congestion-exposure-problem-00.tx
t 

Hope they're useful, 

best wishes

phil.

                                     

Abstract

>> Congestion exposure gives many benfits
   including meaningful 

I'd re-phrase this: Congestion exposure potential allows mechanisms to
be built on top that could do <list of things>

 

>> fairer

I'd avoid the F word here and throughout the doc - it's too
emotionally-laden. The only place it's ok is the first para of S2, where
you're talking specifically about tcp-fairness.

 

Intro

Para 3: complex vs crude measures. I don't really understand how you've
divided these things up, eg I'd have thought that per-application
prioritisation is quite a complex measure, esp if traffic is encrypted. 

 

I'd avoid mentioning Ledbat - I think the argument needs more explaining

 

S3 Why now?

I don't think ledbat is the right place to start, but first some
comments about what you say about ledbat:

"will focus ... seem to" -> "focuses ... are"

to me the ledbat argument is 

[1] operators penalise certain 'heavy' apps. Ledbat behaves 'nicely',
therefore operator doesn't penalise it. So user can avoid DPI action (&
maybe avoid any contribution to my volume cap). 

[2] ledbat based on congestion, rather than delay, would be better [ie
react more accurately to actual network conditions]. (this is based on
instinct, eg are there ecn papers that explored the issue?)

 

anyway, I think a better structure for section 3 (& re-organising some
of the other material) would be:-

 

1. what are the current problems? How does congestion exposure help?

This is really the argument you make in section 2, plus some bits of S4.
I think it's good to concentrate on one main story here (I suggest: the
problem is 'capacity sharing conflict' (ie the bandwidth exceeds a
link's capacity) in an ISP's network - DPI etc - applications encrypt -
arms race) . It's terms of how it helps, you could give a para from the
isp perspective & a para from the user's perspective. I'm not sure how
far to go here & what to leave to bullet 3 below, but maybe you could
mention:

- user:  allow the most urgent applications to go faster than today,
whilst encouraging less urgent ones to delay their transmissions until
there was spare capacity, and so increasing the overall utility of the
internet

- ISP: provide an equable basis for simple and reasonable network
management by operators

 

2. what are the emerging/expected problems where congestion exposure
helps? How does it help?

For instance, I think it's reasonably likely that congestion is no
longer at the edge only &/or there are multiple congestion bottlenecks
on the path. Then the DPI-style approach struggles & congestion exposure
is good.

 

3. what are the new uses that congestion exposure enables?

possibly concentrating on explaining one, with other ideas just
mentioned?

A simple one would be Don's performance metric "an indication of
backhaul health"

 

move S6 [the straw proposal] to after all this.

 

S5.1

>> In economic terms, this impact
   is known as a negative externality and the classic solution is to
   convert it to a shadow price that is used to determine the marginal
   cost of using the network.
Maybe stop the sentence after "externality". Mention of price/cost means
you need the caveat, to avoid confusion: "nb in practice customers
reject congestion pricing where you pay per congested packet; but a "non
classic" solution doesn't need to do this but still gets the benefit
blah" - but I think this is getting into more detail than needed, hence
I'd just end the sentence earlier. 
 
S5.1 para 3
I don't really get the relevance of the comment 
>> However this has no
   benefit to the user if the operator is unable to see that they are
   behaving in an altruistic manner.  
 
S5.2
>> Upstream congestion is defined as 
      Downstream congestion is defined 
I'd call them "rest-of-path congestion" and maybe "congestion-so-far"
 
S5.2 
I hate the idea of a requirements section. firstly from a practical
point of view, ietf reqts docs seems to turn into vast lists of MUSTs,
SHOULDs etc that then everyone ignores. Secondly, I don't think you've
actually written a requirements section (phew!). 
 
So maybe re-jig what you have into 
[1] something about what the solution looks like - it's key
characteristics [rest-of-path congestion & congestion-so-far are visible
at the IP layer] 
[2] something about the assumptions you're going to make when fleshing
out the solution [eg we will do both v4 & v6, only do tcp, etc.
Incremental deployment could be mentioned here, but could do with
detailing what deployment cases are in scope.]
 
In terms of your list,
Bullet 1 is ok, except mentioning benefits is out of place
Bullet 2 I think is already covered because the congestion exposure is
in the IP layer
Bullet 3 I don't really get. Do you mean the congestion information will
be accurate within ~ RTT (contrast several minutes accuracy that a
solution at the O&M layer might have)? Actually I think it would be
worth mentioning this as a 'key characteristic' of the solution. 
Bullet 4 again I think is already covered because the congestion
exposure is in the IP layer
Bullet 5 see earlier comment
Bullet 6 & 7 - I'd put in the security considerations section
 
S6
After "it works" in para 1, I'd skip straight to para 3. to me, it's
easier to give the example and then talk about more generic stuff - the
specific example makes it easier to understand the more general
discussion
 
A pic might help?
 
Para 4 seems in the wrong place.