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