This is also true in the consumer space, and is the reason why ISPs can
save money by taking advantage of statistical multiplexing. On average, I
personally could be satisfied with a megabit, but it's a real pain to
download gigabyte-class software updates at that speed.
If it takes me literally
Luca's point tends to be correct - variable latency destroys the stability of
flow control loops, which destroys throughput, even when there is sufficient
capacity to handle the load.
This is an indirect result of Little's Lemma (which is strictly true only for
Poisson arrival, but almost
Actually, the cost argument goes the other way. You need heavy DSP to
*receive* high bandwidths; sending it is much easier computationally.
Also, in aggregate a hundred cheap CPE boxes probably have more DSP
horsepower than the one head-end box serving them.
What the centralised head-end has an
On Wed, 13 Dec 2017, Jonathan Morton wrote:
The one "correct" argument against ack-filtering I've seen is that it
encourages (or rather validates) the use of extreme asymmetry ratios.
I would sure rather have a extremely asymmetric ration than a 'proper' ratio
with the same upstream
The one "correct" argument against ack-filtering I've seen is that it
encourages (or rather validates) the use of extreme asymmetry ratios.
However, these extreme ratios are already in widespread use without the aid
of ack-filtering. Even ADSL2 Annex A has, as its "ideal" sync rate, a 16:1
Taking into account a variety of scenarios, I have difficulty identifying a
case where an ack deleted by a reasonably conservative algorithm would have
given any practical benefit had it remained, *including* considerations of
smoothness of ack-clocking.
If the uplink isn't congested then no
On Tue, 12 Dec 2017, Benjamin Cronce wrote:
I do not feel that thinning ACKs gains much for any healthy ratio of
down:up. The overhead of those "wasteful" ACKs are on par with the overhead
of IP+TCP headers.
assuming that there was no traffic going the other way to compete with the acks.
in reading this
https://blog.apnic.net/2017/12/12/internet-protocols-changing/
I stumbled across the "spin bit" idea being discussed in the ietf.
https://tools.ietf.org/html/draft-trammell-quic-spin-00
In a world where quic is 7% of all traffic presently (wow, I didn't know)...
--
Dave Täht
On Wed, Nov 29, 2017 at 10:50 AM, Sebastian Moeller wrote:
> Hi Mikael,
>
>
> > On Nov 29, 2017, at 13:49, Mikael Abrahamsson wrote:
> >
> > On Wed, 29 Nov 2017, Sebastian Moeller wrote:
> >
> >> Well, ACK filtering/thinning is a simple trade-off: redundancy
Luca Muscariello writes:
> I think everything is about response time, even throughput.
>
> If we compare the time to transmit a single packet from A to B, including
> propagation delay, transmission delay and queuing delay,
> to the time to move a much larger amount
I think everything is about response time, even throughput.
If we compare the time to transmit a single packet from A to B, including
propagation delay, transmission delay and queuing delay,
to the time to move a much larger amount of data from A to B we use
throughput in this second case because
11 matches
Mail list logo