Low Extra Delay Background Transport (LEDBAT)
draft-ietf-ledbat-congestion-10

A nit:
-- Section 2 --
The second sentence looks like it needs to be split in two after "however", perhaps with a colon.


Mail to Stanislav Shalunov is bouncing.  If you can't get a current address, you should probably remove him from the front-page authors list, and move him to a "Contributors" section to avoid delays during AUTH48.

====================================================
My original DISCUSS, now recorded as a comment for posterity:

I understand that the shepherd says that the algorithm "requires further experimentation and targeted deployments before it is ready for standards track."  But the shepherd also says that there are "several independent implementations" that include a product deployment, that there's been a lot of experimentation and that "parameterization and associated tradeoffs are well understood and documented," that "we got enough (independent) experimental data that guided the design decisions," and that it's been reviewed by experts from TCPM and ICCRG (who I presume are happy with it).  All this over a development period of a year and a half.

It makes me wonder what experimentation is still needed, such that this can't be sent out a Proposed Standard.  In general, have we really gotten to where "Proposed Standard" means "final and perfect"?  For this specific document, is there really not enough data at this point to recommend greatly expanded deployment?  Does this really still have to be carefully rolled out here and there in controlled experiments?  Is it intended that this will eventually become a Proposed Standard?  What data will you collect from limited experimentation at this point, that you haven't already gotten?  How will we know when the experiment is ready to be turned into a Proposed Standard (or declared a failure), how far from that point are we now, and how will be make sure the experiment progresses?

--------
Response from Rolf Winter:

We have seen a large deployment by a single company. While this means that there indeed is massive deployment, it doesn't mean we have (enough) independent data to say it is always safe, efficient, reliable etc. The company in question says they have deployed it with "good results" (no other indicators or data really). I personally feel that this is not enough and (as far as I am concerned) not enough independent experimental results. In particular, the WG made decisions that changed the initial design that was brought to the IETF which is what has been run in the wild I believe. 

Generally, I know what you mean when you say that this smells like Proposed Standard rather than Experimental. We should aim to bring good proposals faster to standards track, however this is congestion control and the IETF was always cautious when it came to congestion control (you could argue this as being positive or negative of course). So I think experimental here is the right way to go for now. We have just seen implementations from other people and I would like them to experiment as well (hopefully sharing more real data with the community).

Once we decide to go standards track we would also need to define a framing format. I'd say we should do these two things at the same time. The experiment I believe is over, once people that have implemented the congestion control part are actually asking for a framing format. This hasn't happened as of now.

--------
Further response from Wes Eddy:

One of the open questions that I think would warrant further understanding before going Standards Track is discussed in the Applicability Section 2.2, and summarized at the end:

  Further study is required to fully understand the behaviour of LEDBAT
  with non-drop-tail, non-FIFO queues.

In my opinion, that's one of the important unknowns.  It's related to the question of what happens when queues are very small.

Another question that has received a lot of discussion lately is whether the LEDBAT target delay is really low enough that the people doing competing real-time media flows are totally happy with it, how to know whether we've got this balance right, and how low it can really go without suffering from other issues.

I think Rolf explained well that we tend to be pretty conservative about advancing CC specifications, traditionally.  Look at the progression of 2001 (PS) in 1997 to 5681 (DS) in 2009 as an example! (and of course SS and CA predate RFC 2001 by quite a bit as well).

Thanks for addressing my DISCUSS/COMMENT

I am happy to see this document being published.  I only have a minor, non-blocking, comment.

In several places within the document, it says that LEDBAT is "no more aggressive than TCP".  Given the wide range of TCP congestion control algorithms, I think it would be good to indicate which ones are being compared to LEDBAT.  I assume the document is referring to those congestion control algorithms that conform to RFC 5681.

Thanks for addressing my Discuss points.  I've changed my position to No Objection.

Had the same security question Stephen had.

One security/2119 question and a bunch of nits on what's a good
document.

section 7 - you say a protocol using LEDBAD "should"
authentiate timestamp and delay fields. Is that a 2119 SHOULD?
If so, then someone who turns up with an I-D that uses LEDBAT
but has no MTI authentication might get DISCUSS comments on
that basis. Is that what you want? If not, then perhaps
s/should/ought/ will reduce the scope for possible future
confusion. You could also mean that if using (D)TLS then
the timestamp and acks SHOULD be protected, but that
its ok for a protocol that has no MTI security (heaven
forbid:-) to use LEDBAT.

(See also the recent endless discussion on case for
2119 keywords on ietf-discuss if you've time to spare:-) 

I don't mind how you choose to handle this, since its
really an issue to be handled when LEDBAT is used,
but think that this could usefully be clarified here.

nits:

- list in 2.1 ends with a comma - just checking that a
point 4 wasn't dropped off the end of the list

- 2.2 uses "tail-drop" and "non-drop-tail" - would
"non-tail-drop" be better there?

- p8, there's no mandatory-to-implement FILTER() - is that
ok? You give a bunch of options, but don't say that one of
them MUST be implemented.

- p9, says a maximum value MAY be placed on CTO, then gives a
MUST about that value. Just checking that its intended to be
ok to implement with no maximum CTO at all.

- 4.2.2, a reference to the limited experimented with BT nodes
would be nice (I've a few such comments, the added references
would be good I think if someone's reading this in 10 years
time, which they may do.)

- 4.3 a reference to the G.114 doc would be nice (incl. the
version since that can change and the 150ms recommendation
might also)

- 4.3, references to the DNA and uTorrent implementations 
would be nice

- 5.3, typo s/worse case/worst case/

- p16, a reference for NTP would be nice in Appendix A

- p17, typo "condersiderations"

- A.3, earlier you mentioned two BT implementations but
here you talk about *the* BT implementation - which do
you mean? And a reference would be nice.

Thank you for addressing my concerns.