[ledbat] FW: Draft IETF 77- LEDBAT Meeting Notes

[Murari Sridharan <[e-mail]>]

Thanks David for the meeting notes. Let me know if you have comments before I post it up. 

Thanks

-----Original Message-----
From: Mcdysan, David E [mailto:[e-mail]] 
Sent: Monday, March 22, 2010 11:24 AM
To: [e-mail]; Murari Sridharan; [e-mail]
Subject: Draft IETF 77- LEDBAT Meeting Notes

LEDBAT IETF 77 Meeting Agenda 

Chairs:  S. Shalunov
         M. Sridharan
Monday, March 22, 2010 0900-1130  Manhattan

Preliminaries (10 minutes)
Note well
Blue Sheets
Minute Takers
- Dave McDysan
Jabber Scribe
- No volunteers?
Agenda bashing
- No commments
Document Status - Murari summarized slides, no comments
See http://www.ietf.org/proceedings/10mar/slides/ledbat-1.pdf 

9:10 - 9:40 LEDBAT Practices and Recommendations, R. Penno (30 minutes)
http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendation
s-01.txt 

Renaldo presented:
http://www.ietf.org/proceedings/10mar/slides/ledbat-0.pdf  
Murari Q: Is recommendation of less than 6 connections needed if window
scale implemented?

REC-3: Applications in general should not open more than 6 connections
to download the same
object.

A: Yes, but another issue is server bandwidth limit per connection.
Murari Q: How would client know about this server restriction?
Stuart Chesire (Apple): Guidelines apply to http but not necessarily
appropriate for other applications. Easier for server to send as fast as
possible and let TCP flow control work. Opening 6 connections will
create more load on the server than one.
Mathis: Institutionalizing workarounds (such as this) for a problem is a
dangerous road.
Renaldo: Proposed rewording recommendation for "purposes of throughput"
Murari: Capture disucssion in document.
Chesire: Why 6 instead of 5 or 7. Recommending that this be one.
Stan: Focus should be on the reason for multiple connections (e.g.,
control/ data is OK), or for throughput (probably not OK). 
Janai (sp?) Franklin/ Marshall College: Is any number needed? Discussion
of pros/cons should be in document.
Joe Touch: Proposed wording: "Apps should not open multiple connections
for the sole purpose of increasing throughput." Emphasis on "sole"
Dave McDysan: Suggested adding the impact on NAT, especially IPv6
Carrier Grade NAT which would be impacted by multiple TCP connections.
Renaldo: More materia
Matthew Kaufmann (Adobe): Agree with "sole." Other protocols do not have
this problem. 
Stan: Only TCP, other protocols out of scope.

REC-4: HTTP based applications should use HTTP/1.1 pipelining when
transferring multiple small objects from the same server.

Joe Touch: Differentiate between persistent connections (OK) and
pipelining (possibly not OK in some situations).
Chesire: Is the draft mixing up http and TCP? What is the focus: server
developers, application developers, robust clients. 
Polly (Apple): Need to tolerate buggy servers (e.g., transparent
proxies).
Lars Eggert: Recommend the good thing to do and what is realistic (i.e.,
under what conditions environments can it be used). Similar to ECN and
other Diffserv marking in this sense. 

REC-5: Application developers should provide users with a way to
configure the number of
concurrent TCP connections used to transfer a single object.

Lars: Specifying the conditions under which such a number/knob should be
used.
Stanislav: Majority of users will not use such configuration options,
and those who do may not forsee consequences of such configuration.
Fraction who can do something useful is small, but they are vocal.
Murari: Make specific to applications. 
Lars: Should list specific applications in the draft. Suggest stating as
configure the upper limit.
KK Ramakrishnan: Goals: improve thruput, separate control/data, HOL
blocking versus increase in state. Is an aspect that of different remote
end points?
Herbert Koogle: Since most web objects are small is goal to eliminate
slow start.
Renaldo: Yes, but also avoidance of HOL blocking.
Joe Touch: Pipelining as a general concept is OK, but HTTP 1.1 version
has issues and that is why it is turned off. 

* Bi-directional HTTP - HyBi working group effort at IETF
Lars: Seems to be outside of charter (http specific) and may be out of
scope.

Mark Polly: http is fundamental impedance mismatch with modern web
browsing. Originally, http pulled down one object while now http
retrieves a page with multiple objects.
Joe Touch: Can cite publications that describe this mismatch.
Stanislav: True, but this seems out of scope. 
Joe: Recommends pointing to papers. 
Lars: http is good example that uses multiple TCP connections. OK to use
http and ftp as examples, but DON't make recommendations about the
applications.
Chesire: HOL blocking is an issue if browser wants to display page
before all objects are received; however, other apps (e.g.,
audio/video.program) everything needs to be downloaded. 
Joe: Pieplining for a single object can impact other objects. Amazon
example given.
Chesire: Scope was a single object.
Mark Polly: Webdav has a similar issue.

Renaldo recap: Reword following:
- sole purpose of multiple connections is to increase 
- Summarize why pipelining is broken, what is needed
- REC-5 configuration reworded based upon Lars' comments

9:40 - 10:10 LEDBAT Congestion Architecture, M. Arumaithurai (30
minutes)
http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-0
0
Mayutan presented
http://www.ietf.org/proceedings/10mar/slides/ledbat-2.pdf

Murari: Appears more appropriate for iccrg. Context could be
architectural framework. Not sure decoupling is such a good idea, way
that everything works together is more important. 
KK Ramakrishnan: Proposing a framework as useful to think about the
components of the protocol and how they fit together and interact with
other mechanisms. 
Stanislav: Specific comments on the wg spec and any suggestions as to
what should be changed?
KK: If/when network supports explicit congestion notification, how could
this be plugged in. Better estimate of fair share as a target for
exploration instead of a delay based scheme. 
Murari: ECN is TCP-based, ledbat is striving to be more general.
Arami (sp?) Cisco: No mention of RED? Why not? 
Murari: Not clear if RED is available in cable modems.
Stan: From charter, AQM is a more generic term that includes RED.

Janai: One use is a clear separation of constants in the congestion
draft (e.g., the max latency of 25 ms). Introduce more flexibility into
the experimental solution in terms of configurable constants. 
Stan: Inconsistent with wg comments from last meeting where feedback was
to pick specific values.
Jana: Don't use MUST, but move to recommendations.
Stan: MUST is needed for interoperability. 
Lars: Use specified value for interoperability, but does not preclude
experimentation with other values. 

KK: Specific feedback requested on draft.
Murari: Could use bandwidth estimate, feedback instead of or in
complementary way with delay estimation.
Stanislav: Provide specific text changes on congestion.
Bob Briscoe: Add specific text to describe how ledbat congestion
interacts with ECN. 

10:10 - 10:40 Low Extra Delay Background Transport (LEDBAT), S. Shalunov
(30 minutes)
http://tools.ietf.org/html/draft-ietf-ledbat-congestion-00
Stanislav presented
http://www.ietf.org/proceedings/10mar/slides/ledbat-3.pdf

Lars: This draft missed the cutoff and was noted in the meeting.
Stanislav: Tentative proposed text changes, premilinary version sent to
mailing list, will follow up with a version -01 based upon feedback
received.

Fairness
Lars: Measurements in Trilogy project is not enough, minutes may be
needed to determine baseline delay measurement. Explicit randomization
should help. 
Rolf Winter NEC:  An issue is one minute slots for base delay, with
history of ten minutes. A long delay in a one minute slot will not be
aged out until ten minutes. 
Stanislav: Clarification, inserts small random (zero mean) values to
delay which changes amount of capacity that is distributed to other
flows. Paramter should be related to the target. 

Prameter Values:
Dave McDysan: Question on clarification of interoperability related to
different implementations achieving similar performance.
Stanislav: Stronger than that, is a distributed algorithm where the
implementations interact. For example, in a shared bottleneck two
implementations with similar demand should get a fair share of the
bottleneck bandwidth.

Covers all issues?
Rolf: DSL case in rural areas has a lower rate. More than 25 ms can
occur at lower rates. Should segment size be reduced for these lower
speed links. 
Stanislav: Preliminary algorithm for adapting segment size has been
developed, but not as well baked as other work. It adds considerable
complications. 
Rolf: Agrees that this is not trivial, and recommends saying something
about this in the draft.
Stan: If serialization exceeds the target, then ledbat should work. 
Rolf: But does not do what was specified. Home Gateways do more than
FIFO/ drop tail for European market. For example, multiple queues voice,
BE, Lower Effort. P2P can be classified as Worse than Best Effort, which
is in a different queue and hence delay measurements don't work. 
Stanislav: Requested more info on this. 
Murari: Requested a formal presentation at the next meeting on
measurements performed.
Cheshire: This may not be an issue, putting lower effort in another
queue has been done by the home gateway.

Lars: These are points for discussion on applicability of draft. Also,
extension on packet (segment) size is problematic. Nothing stops wg from
moving current draft for stable baseline to experimental and then make
other extensions, such as variable segment size as future experimental
drafts. 
Lars: Confirmation of stability to be done on mailing list, then run
last call on the mailing list.  

Lars/KK: State underlying assumptions in draft (e.g., ledbat traffic
shares bottleneck queue with foreground traffic). 

Detailed Text slides are in the distributed deck, and are also on the
mailing list. 

Jana: Doesn't seem to address issue if off_Target is high then Ceiling
could increase due to a long cumulative ACK (e.g., due to prior ACKs
being lost), back-back ACKs and bursty behavior could result. 
Stan: Increases in ceiling are bounded and are no more than TCP. 
Murari: Reframed question as to how acknowledgements are received and
the packets are "released" and not necessarily how congestion window
(ceiling in Jana's question) increases. Such behavior will cause
measured delay to increase.
Stan: Pseudocode on slide 16 
	cwnd += GAIN * off_target / cwnd
is increase once per RTT 
Pseudocode applies to one ACK per packet (for exposition purposes). 
Lars: Summarize the issue in the draft and consider this as a possible
future extension. 

Mathis: Number of TCP implementations behave this way and result in
"stretch ACKs."  Consequence is that measured delay momentarily
increases and throughput decreases. 
Stanislav: Ultimate solution is rate-based instead of window-based.
However, straightforward port to rate-based does not work as well as
window-based.

Jana: State assumption that ACKs must be sent (and received) frequently
for the spec to work.
Stan: Will add this to framing considerations.

??: Separate specification from implementation recommendations in
separate documents
Stan: Could be a later document when to not use SHOULD in original spec
for a particular environment. 
Murari: Asking for experimental data?
Cheshire: Supports having one clear document. Avoid making things too
general.
Reggisio (??): Recommend assuming ACK per data packet. 
Stan: However, doesn't address case of multiple lost ACKs.

KK: Suggested trying to understand to burst release of data from one or
more sources that could cause impact on other flows. 

A Survey of Lower-than-Best-Effort Transport Protocols (No Presentation,
updated document)
http://tools.ietf.org/html/draft-ietf-ledbat-survey-00


Next Steps and Wrapup (20 minutes)