Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

[Toke Høiland-Jørgensen]

Jan Ceuleers <jan.ceuleers@gmail.com> writes:

> On 01/12/17 01:28, David Lang wrote:
>> Stop thinking in terms of single-flow benchmarks and near idle
>> 'upstream' paths.
>
> Nobody has said it so I will: on wifi-connected endpoints the upstream
> acks also compete for airtime with the downstream flow.

There's a related discussion going on over on the make-wifi-fast list
related to the FastACK scheme proposed by Meraki at this year's IMC:

https://conferences.sigcomm.org/imc/2017/papers/imc17-final203.pdf

It basically turns link-layer ACKs into upstream TCP ACKs (and handles
some of the corner cases resulting from this) and also seems to contain
an ACK compression component.

-Toke

Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

[Кирилл Луконин]

As I noticed from the Meraki document:

"FastACK also relies on packet inspection, and will not work when
payload is encrypted. However, in our networks, we do not currently
see an extensive use of encryption techniques like IPSec."

But what about TLS ?
As for me, this technology will never work in most cases.


Best regards,
Lukonin Kirill.

2017-12-01 17:53 GMT+05:00 Toke Høiland-Jørgensen <toke@toke.dk>:
> Jan Ceuleers <jan.ceuleers@gmail.com> writes:
>
>> On 01/12/17 01:28, David Lang wrote:
>>> Stop thinking in terms of single-flow benchmarks and near idle
>>> 'upstream' paths.
>>
>> Nobody has said it so I will: on wifi-connected endpoints the upstream
>> acks also compete for airtime with the downstream flow.
>
> There's a related discussion going on over on the make-wifi-fast list
> related to the FastACK scheme proposed by Meraki at this year's IMC:
>
> https://conferences.sigcomm.org/imc/2017/papers/imc17-final203.pdf
>
> It basically turns link-layer ACKs into upstream TCP ACKs (and handles
> some of the corner cases resulting from this) and also seems to contain
> an ACK compression component.
>
> -Toke
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast



-- 
Best Regards,
Lukonin Kirill

Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

[Luca Muscariello]

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

I think only IPSEC would be a problem for fastACK but not TLS.

On Fri, Dec 1, 2017 at 2:13 PM, Кирилл Луконин <klukonin@gmail.com> wrote:

> As I noticed from the Meraki document:
>
> "FastACK also relies on packet inspection, and will not work when
> payload is encrypted. However, in our networks, we do not currently
> see an extensive use of encryption techniques like IPSec."
>
> But what about TLS ?
> As for me, this technology will never work in most cases.
>
>
> Best regards,
> Lukonin Kirill.
>
> 2017-12-01 17:53 GMT+05:00 Toke Høiland-Jørgensen <toke@toke.dk>:
> > Jan Ceuleers <jan.ceuleers@gmail.com> writes:
> >
> >> On 01/12/17 01:28, David Lang wrote:
> >>> Stop thinking in terms of single-flow benchmarks and near idle
> >>> 'upstream' paths.
> >>
> >> Nobody has said it so I will: on wifi-connected endpoints the upstream
> >> acks also compete for airtime with the downstream flow.
> >
> > There's a related discussion going on over on the make-wifi-fast list
> > related to the FastACK scheme proposed by Meraki at this year's IMC:
> >
> > https://conferences.sigcomm.org/imc/2017/papers/imc17-final203.pdf
> >
> > It basically turns link-layer ACKs into upstream TCP ACKs (and handles
> > some of the corner cases resulting from this) and also seems to contain
> > an ACK compression component.
> >
> > -Toke
> > _______________________________________________
> > Make-wifi-fast mailing list
> > Make-wifi-fast@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
>
> --
> Best Regards,
> Lukonin Kirill
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

[-- Attachment #2: Type: text/html, Size: 2948 bytes --]

Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

[Simon Barber]

TLS works over TCP, so the TCP headers are not encrypted.

Simon

Sent with AquaMail for Android
http://www.aqua-mail.com


On December 11, 2017 8:17:47 AM Кирилл Луконин <klukonin@gmail.com> wrote:

> As I noticed from the Meraki document:
>
> "FastACK also relies on packet inspection, and will not work when
> payload is encrypted. However, in our networks, we do not currently
> see an extensive use of encryption techniques like IPSec."
>
> But what about TLS ?
> As for me, this technology will never work in most cases.
>
>
> Best regards,
> Lukonin Kirill.
>
> 2017-12-01 17:53 GMT+05:00 Toke Høiland-Jørgensen <toke@toke.dk>:
>> Jan Ceuleers <jan.ceuleers@gmail.com> writes:
>>
>>> On 01/12/17 01:28, David Lang wrote:
>>>> Stop thinking in terms of single-flow benchmarks and near idle
>>>> 'upstream' paths.
>>>
>>> Nobody has said it so I will: on wifi-connected endpoints the upstream
>>> acks also compete for airtime with the downstream flow.
>>
>> There's a related discussion going on over on the make-wifi-fast list
>> related to the FastACK scheme proposed by Meraki at this year's IMC:
>>
>> https://conferences.sigcomm.org/imc/2017/papers/imc17-final203.pdf
>>
>> It basically turns link-layer ACKs into upstream TCP ACKs (and handles
>> some of the corner cases resulting from this) and also seems to contain
>> an ACK compression component.
>>
>> -Toke
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
>
> --
> Best Regards,
> Lukonin Kirill
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

[Luca Muscariello]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

If I understand the text right, FastACK runs in the AP and generates an ACK
on behalf (or despite) of the TCP client end.
Then, it decimates dupACKs.

This means that there is a stateful connection tracker in the AP. Not so
simple.
It's almost, not entirely though, a TCP proxy doing Split TCP.


On Fri, Dec 1, 2017 at 1:53 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Jan Ceuleers <jan.ceuleers@gmail.com> writes:
>
> > On 01/12/17 01:28, David Lang wrote:
> >> Stop thinking in terms of single-flow benchmarks and near idle
> >> 'upstream' paths.
> >
> > Nobody has said it so I will: on wifi-connected endpoints the upstream
> > acks also compete for airtime with the downstream flow.
>
> There's a related discussion going on over on the make-wifi-fast list
> related to the FastACK scheme proposed by Meraki at this year's IMC:
>
> https://conferences.sigcomm.org/imc/2017/papers/imc17-final203.pdf
>
> It basically turns link-layer ACKs into upstream TCP ACKs (and handles
> some of the corner cases resulting from this) and also seems to contain
> an ACK compression component.
>
> -Toke
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 2172 bytes --]

Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

[Toke Høiland-Jørgensen]

Luca Muscariello <luca.muscariello@gmail.com> writes:

> If I understand the text right, FastACK runs in the AP and generates an ACK
> on behalf (or despite) of the TCP client end.
> Then, it decimates dupACKs.
>
> This means that there is a stateful connection tracker in the AP. Not so
> simple.
> It's almost, not entirely though, a TCP proxy doing Split TCP.

Yeah, it's very much stateful, and tied closely to both TCP and the MAC
layer. So it has all the usual middlebox issues as far as that is
concerned... Also, APs need to transfer state between each other when
the client roams.

It does increase single-flow TCP throughput by up to a factor of two,
though... Which everyone knows is the most important benchmark number ;)

-Toke

Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

[Dave Taht]

Toke Høiland-Jørgensen <toke@toke.dk> writes:

> Luca Muscariello <luca.muscariello@gmail.com> writes:
>
>> If I understand the text right, FastACK runs in the AP and generates an ACK
>> on behalf (or despite) of the TCP client end.
>> Then, it decimates dupACKs.
>>
>> This means that there is a stateful connection tracker in the AP. Not so
>> simple.
>> It's almost, not entirely though, a TCP proxy doing Split TCP.
>
> Yeah, it's very much stateful, and tied closely to both TCP and the MAC
> layer. So it has all the usual middlebox issues as far as that is
> concerned... Also, APs need to transfer state between each other when
> the client roams.
>
> It does increase single-flow TCP throughput by up to a factor of two,
> though... Which everyone knows is the most important benchmark number ;)

Were you always as cynical as I am?

I'd like to compare (eventually) what we are trying with cake's new ack
filter here, which at least doesn't lie to the endpoint.

my guess, however, would be that the media access negotiation will
dominate the cost, and savings from (say) reducing 10 acks to 1 would
only be somewhere in the 5-20% range, for simple benchmarks.

I think we might get a better rrul result, however, as we'd be able to
pack more big flows into a given aggregate, with less acks there.

>
> -Toke
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

[Juliusz Chroboczek]

>> It does increase single-flow TCP throughput by up to a factor of two,
>> though... Which everyone knows is the most important benchmark number ;)

> Were you always as cynical as I am?

(Giggle)

Dave, you've always underestimated Toke ;-)

Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

I'm skeptical that this would improve single stream throughput by a factor
of two.   The larger RTT would drive larger aggregations and it's
aggregation that scales peak average throughput.

Also, the time difference between the 802.11 ack and the client network
stack writing the TCP ack would probably be in the 100s of microseconds
(mileage will vary.)  So it's the client's media access that will drive the
increase in RTT.    It might be preferred to modify EDCA parameters to
reduce media access latencies for TCP acks rather than spoof them.

Bob

On Fri, Dec 1, 2017 at 12:39 PM, Juliusz Chroboczek <jch@irif.fr> wrote:

> >> It does increase single-flow TCP throughput by up to a factor of two,
> >> though... Which everyone knows is the most important benchmark number ;)
>
> > Were you always as cynical as I am?
>
> (Giggle)
>
> Dave, you've always underestimated Toke ;-)
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>

[-- Attachment #2: Type: text/html, Size: 1679 bytes --]

Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

[Juliusz Chroboczek]

> It might be preferred to modify EDCA parameters to reduce media access
> latencies for TCP acks rather than spoof them.

I'm lost here.  What exact problem is the ACK hack supposed to work
around?  Ridiculous amount of asymmetry in the last-hop WiFi link, or
outrageous amounts of asymmetry in a transit link beyond the last hop?

-- Juliusz

Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

My understanding per the thread is a last hop wifi link.  I could be wrong
though.

Bob

On Sun, Dec 3, 2017 at 2:35 AM, Juliusz Chroboczek <jch@irif.fr> wrote:

> > It might be preferred to modify EDCA parameters to reduce media access
> > latencies for TCP acks rather than spoof them.
>
> I'm lost here.  What exact problem is the ACK hack supposed to work
> around?  Ridiculous amount of asymmetry in the last-hop WiFi link, or
> outrageous amounts of asymmetry in a transit link beyond the last hop?
>
> -- Juliusz
>

[-- Attachment #2: Type: text/html, Size: 930 bytes --]

Re: [Make-wifi-fast] [Bloat] benefits of ack filtering

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 2518 bytes --]

802.11 acks are packet or ampdu driven while tcp, being a byte protocol,
acks bytes.  Aligning these may not be straightforward.  We test with
different read() rates on the wifi clients as TCP is supposed to flow
control the source's writes() as well.  Wifi clients are starting to align
their sleep cycles with "natural" periodicity in traffic so having larger
aggregates can help both peak average throughput as well as power
consumption.  It's not obvious with Wifi that a faster RTT is always
better.  (Reminds me of the early days of NASA where many designed to
reduce weight without keeping in account structural integrity, shave a few
grams and lose a rocket.)

Bob

On Fri, Dec 1, 2017 at 9:42 AM, Dave Taht <dave@taht.net> wrote:

> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>
> > Luca Muscariello <luca.muscariello@gmail.com> writes:
> >
> >> If I understand the text right, FastACK runs in the AP and generates an
> ACK
> >> on behalf (or despite) of the TCP client end.
> >> Then, it decimates dupACKs.
> >>
> >> This means that there is a stateful connection tracker in the AP. Not so
> >> simple.
> >> It's almost, not entirely though, a TCP proxy doing Split TCP.
> >
> > Yeah, it's very much stateful, and tied closely to both TCP and the MAC
> > layer. So it has all the usual middlebox issues as far as that is
> > concerned... Also, APs need to transfer state between each other when
> > the client roams.
> >
> > It does increase single-flow TCP throughput by up to a factor of two,
> > though... Which everyone knows is the most important benchmark number ;)
>
> Were you always as cynical as I am?
>
> I'd like to compare (eventually) what we are trying with cake's new ack
> filter here, which at least doesn't lie to the endpoint.
>
> my guess, however, would be that the media access negotiation will
> dominate the cost, and savings from (say) reducing 10 acks to 1 would
> only be somewhere in the 5-20% range, for simple benchmarks.
>
> I think we might get a better rrul result, however, as we'd be able to
> pack more big flows into a given aggregate, with less acks there.
>
> >
> > -Toke
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>

[-- Attachment #2: Type: text/html, Size: 3532 bytes --]