Hi,

It seems I overlooked this answer, sorry - some answers below, but also cutting stuff to keep it to the point:


On Nov 1, 2018, at 9:20 PM, Dave Taht <dave.taht@gmail.com> wrote:


Despite the undebatable importance of bufferbloat and its impact on e2e packet latency, this is only one of the factors playing into the "latency" that I perceive when I click on the link as I surf the Internet.

Doing a breakdown of that latency - most of that seems solved...

Background prefetch
DNS lookup
SSL connection negotiation
The actual transfer.
Screen draw....

I'm still missing your point. Is looking for "sparseness" part of a
CCN-like effort?

No, it’s just about flow completion time (“The actual transfer”) above being a function not only of the queue length, but also of the capacity the flow gets to use. Hence the push for a larger initial window.


Flow completion time has to do with saturation as well.

FCT was not a subject of that draft.

Right - sorry for side-tracking.


My (admittedly ranty) points were:

I read them - I didn’t want to get into this debate, it was only a side comment about not all flows being limited, and there being some value in better capacity usage too.

Cheers,
Michael