On Wed, Nov 28, 2018 at 11:45 PM Jonathan Morton wrote:
>
> > On 29 Nov, 2018, at 9:39 am, Dave Taht wrote:
> >
> > …when it is nearly certain that more than one flow exists, means aiming
> > for the BDP in a single flow is generally foolish.
>
> It might be more accurate to say that the BDP of
On Thu, 29 Nov 2018, Jonathan Morton wrote:
You are essentially proposing using ECT(1) to take over an intended function of
Diffserv.
Well, I am not proposing anything. I am giving people a heads-up that the
L4S authors are proposing this.
But yes, you're right. Diffserv has shown itself
> On 29 Nov, 2018, at 9:39 am, Dave Taht wrote:
>
> …when it is nearly certain that more than one flow exists, means aiming
> for the BDP in a single flow is generally foolish.
It might be more accurate to say that the BDP of the fair-share of the path is
the cwnd to aim for. Plus epsilon for
Mikael Abrahamsson writes:
> On Tue, 27 Nov 2018, Luca Muscariello wrote:
>
>> link fully utilized is defined as Q>0 unless you don't include the
>> packet currently being transmitted. I do, so the TXtteer is never
>> idle. But that's a detail.
>
> As someone who works with moving packets, it's
> On 29 Nov, 2018, at 9:28 am, Mikael Abrahamsson wrote:
>
> This is one thing about L4S, ETC(1) is the last "codepoint" in the header not
> used, that can statelessly identify something. If anyone sees a better way to
> use it compared to "let's put it in a separate queue and CE-mark it
>
"Bless, Roland (TM)" writes:
> Hi Luca,
>
> Am 27.11.18 um 10:24 schrieb Luca Muscariello:
>> A congestion controlled protocol such as TCP or others, including QUIC,
>> LEDBAT and so on
>> need at least the BDP in the transmission queue to get full link
>> efficiency, i.e. the queue never
On Wed, 28 Nov 2018, Dave Taht wrote:
see ecn-sane. Please try to write a position paper as to where and why
ecn is good and bad.
if one day we could merely establish a talmud of commentary
around this religion it would help.
From my viewpoint it seems to be all about incremental deployment.
"Bless, Roland (TM)" writes:
> Hi Luca,
>
> Am 28.11.18 um 11:48 schrieb Luca Muscariello:
>
>> And for BBR, I would say that one thing is the design principles another
>> is the implementations
>> and we better distinguish between them. The key design principles are
>> all valid.
>
> While the
Luca Muscariello writes:
> On Wed, Nov 28, 2018 at 11:40 AM Dave Taht
> wrote:
>
> On Wed, Nov 28, 2018 at 1:56 AM Luca Muscariello
> wrote:
> >
> > Dave,
> >
> > The single BDP inflight is a rule of thumb that does not account
> for fluctuations of the RTT.
> >
Michael Welzl writes:
> Just a small clarification:
>
>
>
>
> To me the switch to head dropping essentially killed the tail
> loss RTO
> problem, eliminated most of the need for ecn.
>
>
>
> I doubt that: TCP will need to retransmit that
Jonathan Morton writes:
>>> "polylog(n)-wise Independent Hash Function". OK, my google-foo fails
>>> me: The authors use sha1, would something lighter weight suit?
>
>> The current favorite in DPDK land seems to be Cuckoo hashing.
>> It has better cache behavior than typical chaining.
>
> That
On Wed, Nov 28, 2018 at 8:55 AM Dave Taht wrote:
>
> Bruno George Moraes writes:
>
> > Nice resource, thanks.
> >
> > If someone wonders why things look the way they do, so it's all about
> > on-die and off-die memory. Either you use off-die or on-die memory, often
> > SRAM which requires 6
That would be really cool: I loved the Mips we had at YorkU.ca
--dave
On 2018-11-28 2:02 p.m., Dave Taht wrote:
I really don't know a whole heck of a lot about where mips is going.
Certainly they remain strong in the embedded market (I do like the
edgerouter X a lot), but as for their current
I really don't know a whole heck of a lot about where mips is going.
Certainly they remain strong in the embedded market (I do like the
edgerouter X a lot), but as for their current direction or future
product lines, not a clue.
I used to know someone over there, maybe he's restored new
On 2018-11-28 11:55 a.m., Dave Taht wrote:
Thank you for that. I do have a long standing dream of a single chip
wifi router, with the lowest SNR possible, and the minimum number of
pins coming off of it. I'd settle for 32MB of (static?) ram on chip as
that has proven sufficient to date to drive
Bruno George Moraes writes:
> Nice resource, thanks.
>
> If someone wonders why things look the way they do, so it's all about
> on-die and off-die memory. Either you use off-die or on-die memory, often
> SRAM which requires 6 gates per bit. So spending half a billion gates
> gives you
>
> Nice resource, thanks.
>
> If someone wonders why things look the way they do, so it's all about
> on-die and off-die memory. Either you use off-die or on-die memory, often
> SRAM which requires 6 gates per bit. So spending half a billion gates
> gives you ~10MB buffer on-die. If you're doing
Hi Luca,
Am 28.11.18 um 11:48 schrieb Luca Muscariello:
> And for BBR, I would say that one thing is the design principles another
> is the implementations
> and we better distinguish between them. The key design principles are
> all valid.
While the goal is certainly right to operate around
On Wed, Nov 28, 2018 at 11:40 AM Dave Taht wrote:
> On Wed, Nov 28, 2018 at 1:56 AM Luca Muscariello
> wrote:
> >
> > Dave,
> >
> > The single BDP inflight is a rule of thumb that does not account for
> fluctuations of the RTT.
> > And I am not talking about random fluctuations and noise. I am
On Wed, Nov 28, 2018 at 1:56 AM Luca Muscariello
wrote:
>
> Dave,
>
> The single BDP inflight is a rule of thumb that does not account for
> fluctuations of the RTT.
> And I am not talking about random fluctuations and noise. I am talking about
> fluctuations
> from a control theoretic point of
Dave,
The single BDP inflight is a rule of thumb that does not account for
fluctuations of the RTT.
And I am not talking about random fluctuations and noise. I am talking
about fluctuations
from a control theoretic point of view to stabilise the system, e.g. the
trajectory of the system variable
21 matches
Mail list logo
