Minutes for AQM at IETF-89
minutes-89-aqm-1

AQM IETF-89 Minutes
IETF 89 in London, United Kingdom
Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign)

Minutes Takers: Alex Zimmermann, Spencer Dawkins, (Lars Eggert)

WG status

agenda not bashed

------------------------------------
draft-ietf-aqm-recommendation
Fred Baker / Gorry Fairhurst

short WGLC will be started after IETF89, no objections

------------------------------------
draft-welzl-ecn-benefits
Gorry Fairhurst/Michael Welzl

Next Steps - 
Is a document like this helpful?

Fred Baker: yes the doc is helpful, especially to make sure we don't 
trip on other mechanisms that are also trying to help.

Lingli Deng from China Mobile: Have you done any experimentation about 
how pervasive ECN is on the Internet? Google has explored this, their 
conclusion is that the percentage of well-functioning ECN is below 20%. 
ECN has a long history, however is still not widley deployed

Michael Welzl: General feeling is that is much more possible than those 
numbers. Please send link to the list?

Stuart Cheshire: Thanks for the work. Good to get the message out. Was 
independently looking at Apple perf issues, did measurements, found 
surprisingly good results from ECN, wondered why not used more 
widespread. Will show graphs at TSVAREA.

Michael Welzl (Anwser previously Q): Linux has ECN available (it 
responds with ECN if it get a ECN market SYN), MacOS has turned off by 
default. Bottleneck router needs to do ECN marking. Point of my 
presentation is get router vendors to do it. 

Mirja: We have some results showing a population around 30% of servers 
support ECN.
    
Stuart: Consider 30% a large number for adoption of a technology that 
doesn't actually do anything yet

Mirja: Not so large after 30 years.

Dave Taht: Came up with six negatives of ECN before started drinking. 
Agree that expressing ECN benefits is very good. Would put out anti-ECN 
manifesto, or roll into one document?

Michael Welzl: Can have a long conversation about this.

Al Morton: Friend (former AD) said "ECN should be made historic". Will 
try to get him to comment. But is good work, please do.

Mirja: Is helpful, need to be more careful on how to describe. If you 
use it wrong, it can cause issues. Can't tell you exactly now what 
should be in the doc. Document would be useful IF we write it right. 
Need to more exactly describe scenarios where you see benefits.

Matt Mathis: There are documents that never make it out of being 
Internet Drafts (never published).
    
Mirja: How ECN is being specified is currently changing (immediate ECN)

Gorry: Is this type of document useful? 

Mirja: ECN could be much more useful than it is right now.

Michael Welzl: Yeah

Matt: Like to have a documents that presents a balanced point of view. 
RED manifesto made requirements that they thought would apply for all 
times, but... If you turn on ECN on industrial strength server, expect 
to see a small number of routers with issues.

Andrew McGregor: If you're trying to enable ECN in a large content 
provider, you can find the routers that cause you problems and disable 
ECN toward the subnets behind them.  It can be a more serious issue to 
deal with mark-equals-drop ECN on the outside and early-onset ECN on the 
inside, since traffic often crosses the same switches in both cases. 

Dave Robinson: Interested when you have some flows that are ECN 
protected and some flows not. Last hop device may have different flows 
coming from different sources.

Dirk Kutscher: Use cases, what you can achieve. If audience is outside 
the working group, that's the right approach. The focus for this 
document should be an audience outside of this WG.

Stuart Cheshire: Answer point that Dave made. Easy to only care about 
bandwidth in this community. Fairness. OK, if I use ECN i may not get a 
fair share. I don't care. Care about bufferbloat, latency. Don't care 
about Bandwidth. As BW goes up, fair share doesn't matter anymore. 
Someone asked "does ECN work on OSX, how can I do it. Use 

sudo sysctl -w net.inet.tcp.ecn_initiate_out=1
sudo sysctl -w net.inet.tcp.ecn_negotiate_in=1

(MAC OS X). There is a benefit to playing with it for real rather than 
just reading about it in the drafts.

Bob Briscoe: recommenend that this draft adds a section on use cases, 
explaining what applications benefit and why. Also interesting to have a 
draft on deployment challenges, but it should be a separate draft.

Jana Iyengar: Haven't read the draft. ECN is just a signal. If 
explaining it, want to be clear how the signal can be generated, and how 
it can get used. ID not the best way to teach a religion. 

Michael Welzl: Different spec on how it is generated (RFC 3168)

Andrew McG: Type of the document maybe "perpetual draft". Or maybe it's 
not this doc but a different one 

Jon Crowcroft: if you encourage people to get rid of bufferbloat, Cisco 
will buy less memory, so people save money. Win win.

Richard: Should we adopt this in AQM?

Gorry: As TSVWG chair, I don't think we need to adopt now, and AQM may 
not be the right place. Should talk about whether this doc is the right 
doc. Wanted feedback, and got feedback. 



------------------------------------
          
draft-kuhn-aqm-eval-guidelines
Nicolas Kuhn et. al.
          
Lars: Why it is useful to have metric on the queue?

Nicolas: We believe having metrics on the queue length would help us 
react, the benefit of having these metrics may be specific to a 
particular algorithm. 

Matt Matthis: The queue will add additional delay

Scott Bradner: several years ago I tried to collect queue length 
statistics from routers and got NO useful data. Statistics varied by 17 
percent with exactly the same traffic inputs. This might work for you, 
but it didn't work for me. 

Question from "john" from Jabber room: What about multiple queueus (sfq, etc)?

??? there could be buffers along the path. Can you tell AQM is doing its job?

Rong Pan: if we come up with a new method of curing cancer, the person 
has been cured, but if we want to prevent cancer, curing cancer after 
you get it doesn't help. It's the same with queue length.

Matt: ???

Michael Scharf: On link utiliziation, want to see how you measure this 
on a real box with multiple queues, diffserv, etc. Is really difficult. 
Add an example on how you want to measure this metric

Fred Baker: Place I'd really like to know queueing delay is input queue 
switch, with multiple racks, etc. I don't know how to tell you in an 
input q switch, how to calculate q delay. Might be able to tell you "on 
this card", but measure through the box really hard.

Dave Robinson: For adaptive streaming, all we could do is algorithmic 
way to compare 2-3 simulations. 

Dave Taht: I care a lot about interflow latency, jitter, and packet 
loss. Only bursty packet loss is really bad.  I'd like to have a metric 
on interflow latency, jitter, and packet loss.

Al Morton: This is a lot like benchmarking. If you want to do this sort 
of evaluation, we have folks that have experience. 2nd comment: QoE 
requires content.

Lars: Could we level-up this discussion? We should ask 1) what is good 
for a queuing algo, and 2) what is bad - when we get results, can we 
tell from the results whether what we saw was good or bad?

Ruediger Geib: Good depends on the application.

Andrew McGregor: We can agree on algorithms that are disasterously bad 
(laughter). I've had good results scatter-graphing *input bandwidth* vs 
*packet loss*, which were very illuminating.  We can also describe what 
the requirements for algorithms to be composable, to avoid their control 
systems fighting each other.  It's not clear we know exactly how to do 
that, but it is critical that we do this.

Chris ???: How you deal with cases where deal with power consumption?

Lee Howard: We do not know what the end is and we don't know what the 
link is

Lars: we should narrow down the common set of metrics

Dave Taht: we should also take care about packet scheduling

Naeem Khademi: It's up to the AQM designers to justify the cost of their 
proposed AQM given a set of scenarios/environments where their AQM is 
aimed to operate at. Is it mandatory for them to design an AQM that is 
justified in cost for every possible network scenario (e.g. w/ packet 
scheduling, etc.)? 
 
Answer: no! 
 
Naeem Khademi: Do we require them (or is it mandatory) to justify the 
cost of AQM implementation in where they define their AQM to operate at? 
 
Answer: yes!

Lars: before defining metrices, we should define first the goals we want 
achieve. Then we can talk about metrices to achieve this goals

Gorry: I like this work, but we need a shorter list on metrices


------------------------------------
          
          
draft-lauten-aqm-gsp
Wolfram Lautenschlaeger
(presented in ICCRG)
   
          
draft-white-aqm-docsis-pie
Greg White
(presented in ICCRG)