Re: [Bloat] [Make-wifi-fast] 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 Кирилл Луконин  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 :

Jan Ceuleers  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-f...@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



___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] 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 :
> Jan Ceuleers  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-f...@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: [Bloat] [Make-wifi-fast] benefits of ack filtering

[David Collier-Brown]

On 04/12/17 10:44 AM, Juliusz Chroboczek wrote:

In a previous life I did some work on the optimization (by remote
proxying) of the SMB protocol used by Samba [...]  Eventually we said
the heck with it, and sat Samba on top of a different protocol entirely,

The audience are waiting with held breath for more details.

-- Juliusz


They aren't discussable in polite company. Way too much cursing (;-))

Joking aside, that was definitely a case where we said "don't go 
there".   To the best of my knowledge, there are two network 
optimization products that do SMB, so it's physically possible.  In our 
opinion, it was better to use the SMB protocol locally and a different, 
cached,  protocol over a wide-area network.  I actually prototyped it 
with Solaris NFS and cachefs, and was pleasantly surprised it worked for 
a single-writer case.


--dave

--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net   |  -- Mark Twain

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Juliusz Chroboczek]

> In a previous life I did some work on the optimization (by remote
> proxying) of the SMB protocol used by Samba [...]  Eventually we said
> the heck with it, and sat Samba on top of a different protocol entirely,

The audience are waiting with held breath for more details.

-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[David Collier-Brown]

On 03/12/17 10:44 PM, Dave Taht wrote:

More generally, the case where you have a queue containing acks, stored
up for whatever reason (congestion, media access, asymmetry), is a
chance for a middlebox or host to do something "smarter" to thin them
out.

Acks don't respond to conventional congestion control mechanisms anyway.

There is another case (that I don't support) where you would try to
filter out acks on the fly without a queue (similar to how a policer
works). The flaws of this approach are many, including tail loss,
which the concept of filtering down (reducing?) a queue, doesn't have.


Taking a very high-level view of this discussion, the times you want to 
change a protocol or add a 'network optimizer" are when enough time has 
passed that the original requirements don't describe what you want any more.


In a previous life I did some work on the optimization (by remote 
proxying) of the SMB protocol used by Samba. It was very desirable, but 
at the cost of continuing to support a protocol that did the wrong 
thing, and kludging it with additional middleware.  In effect, making 
your new system dependent on a bug in the old one.


Eventually we said the heck with it, and sat Samba on top of a different 
protocol entirely, one which worked well over non-local links. That 
concentrate the impedance matching in Samba, not in code I had to 
maintain in synchronization with a bug (;-))


--dave

--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net   |  -- Mark Twain

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Dave Taht]

On Sun, Dec 3, 2017 at 12:14 PM, Sebastian Moeller  wrote:
>
>
> On December 3, 2017 8:54:40 PM GMT+01:00, Juliusz Chroboczek  
> wrote:
>>> Many would kill for a 10:1 DOCSIS connection. 50:1 is not rare, and I
>>> have personally been subscribed to a near 100:1 service.
>>
>>Some people should not be allowed to design networks.

The upstream/downstream problem over long distances has been
problematic for dsl (phone line) and
cable (coax) deployments. The head-ends have much greater control over
the signal strengths than the
(usually much cheaper)

Gpon fiber is also commonly sold in 1Gbit/100Mbit modes. Testing on a
GPON network showed about
80ms worth of buffering in the ONT - which we can get rid of entirely, in cake.

>>> The DOCSIS shaper deals with ethernet frames so 58 / 1518 bytes.
>>
>>Could you please point me to details of the DOCSIS shaper?
>
> the relevant section from the Docsis standard 
> (http://www.cablelabs.com/specification/docsis-3-0-mac-and-upper-layer-protocols-interface-specification/):
>
> "C.2.2.7.2 Maximum Sustained Traffic Rate 632 This parameter is the rate 
> parameter R of a token-bucket-based rate limit for packets. R is expressed in 
> bits per second, and MUST take into account all MAC frame data PDU of the 
> Service Flow from the byte following the MAC header HCS to the end of the 
> CRC, including every PDU in the case of a Concatenated MAC Frame. This 
> parameter is applied after Payload Header Suppression; it does not include 
> the bytes suppressed for PHS. The number of bytes forwarded (in bytes) is 
> limited during any time interval T by Max(T), as described in the expression: 
> Max(T) = T * (R / 8) + B, (1) where the parameter B (in bytes) is the Maximum 
> Traffic Burst Configuration Setting (refer to Annex C.2.2.7.3). NOTE: This 
> parameter does not limit the instantaneous rate of the Service Flow. The 
> specific algorithm for enforcing this parameter is not mandated here. Any 
> implementation which satisfies the above equation is conformant. In 
> particular, the granularity of enforcement and the minimum implemented value 
> of this parameter are vendor specific. The CMTS SHOULD support a granularity 
> of at most 100 kbps. The CM SHOULD support a granularity of at most 100 kbps. 
> NOTE: If this parameter is omitted or set to zero, then there is no 
> explicitly-enforced traffic rate maximum. This field specifies only a bound, 
> not a guarantee that this rate is available."
>
> So in essence DOCSIS users need to only account for 18 Bytes of ethernet 
> overhead in both ingress and egress directions under non-congested conditions.

Also, cake, as a deficit mode shaper, it is the opposite of how htb
functions in terms of bursts. TB tries to make up
for bandwidth you should have, verses cake which gives you the
bandwidth you have "right now".

This lets us set the shaper much closer (seemingly exact in the case
of docsis, atleast) to the actual configured TB rate (with better
fq/aqm queue management)

I just submitted an initial patch for cake to net-next after a huge
round of testing.

>
>
>
>>
>>-- Juliusz
>>___
>>Bloat mailing list
>>Bloat@lists.bufferbloat.net
>>https://lists.bufferbloat.net/listinfo/bloat
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Sebastian Moeller]

On December 3, 2017 8:54:40 PM GMT+01:00, Juliusz Chroboczek  
wrote:
>> Many would kill for a 10:1 DOCSIS connection. 50:1 is not rare, and I
>> have personally been subscribed to a near 100:1 service.
>
>Some people should not be allowed to design networks.
>
>> The DOCSIS shaper deals with ethernet frames so 58 / 1518 bytes.
>
>Could you please point me to details of the DOCSIS shaper?

the relevant section from the Docsis standard 
(http://www.cablelabs.com/specification/docsis-3-0-mac-and-upper-layer-protocols-interface-specification/):

"C.2.2.7.2 Maximum Sustained Traffic Rate 632 This parameter is the rate 
parameter R of a token-bucket-based rate limit for packets. R is expressed in 
bits per second, and MUST take into account all MAC frame data PDU of the 
Service Flow from the byte following the MAC header HCS to the end of the CRC, 
including every PDU in the case of a Concatenated MAC Frame. This parameter is 
applied after Payload Header Suppression; it does not include the bytes 
suppressed for PHS. The number of bytes forwarded (in bytes) is limited during 
any time interval T by Max(T), as described in the expression: Max(T) = T * (R 
/ 8) + B, (1) where the parameter B (in bytes) is the Maximum Traffic Burst 
Configuration Setting (refer to Annex C.2.2.7.3). NOTE: This parameter does not 
limit the instantaneous rate of the Service Flow. The specific algorithm for 
enforcing this parameter is not mandated here. Any implementation which 
satisfies the above equation is conformant. In particular, the granularity of 
enforcement and the minimum implemented value of this parameter are vendor 
specific. The CMTS SHOULD support a granularity of at most 100 kbps. The CM 
SHOULD support a granularity of at most 100 kbps. NOTE: If this parameter is 
omitted or set to zero, then there is no explicitly-enforced traffic rate 
maximum. This field specifies only a bound, not a guarantee that this rate is 
available."

So in essence DOCSIS users need to only account for 18 Bytes of ethernet 
overhead in both ingress and egress directions under non-congested conditions.



>
>-- Juliusz
>___
>Bloat mailing list
>Bloat@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Juliusz Chroboczek]

> Many would kill for a 10:1 DOCSIS connection. 50:1 is not rare, and I
> have personally been subscribed to a near 100:1 service.

Some people should not be allowed to design networks.

> The DOCSIS shaper deals with ethernet frames so 58 / 1518 bytes.

Could you please point me to details of the DOCSIS shaper?

-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Juliusz Chroboczek]

> I can buy 300/10 megabit/s access from my cable provider.

Don't!

> If I understand correctly, DOCSIS has ~1ms sending opportunities
> upstream. So sending more than 1kPPS of ACKs is meaningless, as these ACKs
> will just come back to back at wire-speed as the CMTS receives them from
> the modem in chunks. So instead, the cable modem just deletes all the
> sequential ACKs and doesn't even send these back-to-back ones.

If true -- then it's horrible.

> LTE works the same, it's also frequency divided and TDM, so I can see the
> same benefit there of culling sequential ACKs sitting there in the
> buffer. I don't know if this is done though.

I cannot find anything about Ack compression in LTE.  (The PDCP protocol
does header compression, so that's the place I'm looking.)

-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Bob McMahon]

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  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
>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Robert Bradley]

On 03/12/2017 13:57, Juliusz Chroboczek wrote:
> A TCP Ack is 40 bytes.  A data packet is up to 1500 bytes.
> 
> As far as I know, DOCSIS has an asymmetry factor that is between 4 and 10,
> depending on the deployment.  With worst case asymmetry being 10, this
> means that you can send an Ack for every data packet with 400 byte data
> packets, every second data packet with 200 byte data packets.  If the
> asymmetry is a more reasonable 4, then the figures are 100 and 50
> respectively.
> 

I currently have 230 Mb/s down to 12.7 Mb/s up, so about an 18:1 ratio.
That's roughly an ACK for every 750 byte packet.

-- 
Robert Bradley



signature.asc
Description: OpenPGP digital signature
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Ryan Mounce]

On 4 December 2017 at 00:27, Juliusz Chroboczek  wrote:
>>> 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?
>
>> My understanding is that the issue that gave rise to this discussion was
>> concerned with upstream bandwidth conservation in the uplink of a DOCSIS
>> network by the cable modem dropping a large percentage of upstream TCP ACKs.
>
> Ok, that's what I thought.  I'm glad we agree that WiFi is a different issue.
>
> A TCP Ack is 40 bytes.  A data packet is up to 1500 bytes.
>
> As far as I know, DOCSIS has an asymmetry factor that is between 4 and 10,
> depending on the deployment.  With worst case asymmetry being 10, this
> means that you can send an Ack for every data packet with 400 byte data
> packets, every second data packet with 200 byte data packets.  If the
> asymmetry is a more reasonable 4, then the figures are 100 and 50
> respectively.
>

Many would kill for a 10:1 DOCSIS connection. 50:1 is not rare, and I
have personally been subscribed to a near 100:1 service.

Either way, the issue is not so much ACKs from downloads on an
otherwise idle link. The real issue is when the ACKs are contending
with a file upload, in this case download speeds will suffer if ACKs
are naively tail-dropped. Recovering extra bandwidth for the file
upload can be a happy side-effect.

You're also only counting IP packet length. The DOCSIS shaper deals
with ethernet frames so 58 / 1518 bytes.

> Try as I might, I fail to see the problem.  Are we advocating deploying
> TCP-aware middleboxes, with all the problems that entails, in order to
> work around a problem that doesn't exist?
>
> -- Juliusz
> ___
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat


Regards,
Ryan Mounce
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Mikael Abrahamsson]

On Sun, 3 Dec 2017, Juliusz Chroboczek wrote:


As far as I know, DOCSIS has an asymmetry factor that is between 4 and 10,
depending on the deployment.  With worst case asymmetry being 10, this


I can buy 300/10 megabit/s access from my cable provider. So that's a lot 
worse. My cable box has 16 downstream channels, and 4 upstream ones. Each 
channel is TDM based, and there is some kind of scheduler granting sending 
opportunities for each channel to each modem, as needed. I'm not a DOCSIS 
expert.



means that you can send an Ack for every data packet with 400 byte data
packets, every second data packet with 200 byte data packets.  If the
asymmetry is a more reasonable 4, then the figures are 100 and 50
respectively.

Try as I might, I fail to see the problem.  Are we advocating deploying
TCP-aware middleboxes, with all the problems that entails, in order to
work around a problem that doesn't exist?


If I understand correctly, DOCSIS has ~1ms sending opportunities upstream. 
So sending more than 1kPPS of ACKs is meaningless, as these ACKs will just 
come back to back at wire-speed as the CMTS receives them from the modem 
in chunks. So instead, the cable modem just deletes all the sequential 
ACKs and doesn't even send these back-to-back ones.


LTE works the same, it's also frequency divided and TDM, so I can see the 
same benefit there of culling sequential ACKs sitting there in the buffer. 
I don't know if this is done though.


I've seen people I think are involved in TCP design. They seem to be under 
the impression that more ACKs give higher resolution and granularity to 
TCP. My postulation is that this is commonly false because of how the 
network access is designed and how also the NICs are designed (the 
transmit/receive offloading). So sending 35kPPS of ACKs for a gigabit/s 
transfer is just inefficient and shouldn't be done. I would prefer if end 
points would send less ACKs instead of the network killing them.


And the network does kill them, as we have seen. Because any novice 
network access technology designer can say "oh, having 16 sequential ACKs 
here in my buffer, sitting waiting to get sent, is just useless 
information. Let's kill the 15 first ones."


--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Juliusz Chroboczek]

>> 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?

> My understanding is that the issue that gave rise to this discussion was
> concerned with upstream bandwidth conservation in the uplink of a DOCSIS
> network by the cable modem dropping a large percentage of upstream TCP ACKs.

Ok, that's what I thought.  I'm glad we agree that WiFi is a different issue.

A TCP Ack is 40 bytes.  A data packet is up to 1500 bytes.

As far as I know, DOCSIS has an asymmetry factor that is between 4 and 10,
depending on the deployment.  With worst case asymmetry being 10, this
means that you can send an Ack for every data packet with 400 byte data
packets, every second data packet with 200 byte data packets.  If the
asymmetry is a more reasonable 4, then the figures are 100 and 50
respectively.

Try as I might, I fail to see the problem.  Are we advocating deploying
TCP-aware middleboxes, with all the problems that entails, in order to
work around a problem that doesn't exist?

-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Jan Ceuleers]

On 03/12/17 11:35, Juliusz Chroboczek wrote:
> 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?

My understanding is that the issue that gave rise to this discussion was
concerned with upstream bandwidth conservation in the uplink of a DOCSIS
network by the cable modem dropping a large percentage of upstream TCP ACKs.

One element of that discussion was the question as to whether it was OK
for middleboxes (such as in this case cable modems) to reduce the number
of TCP ACKs, or whether instead the TCP stacks in the endpoints should
be made to send fewer such ACKs in the first place.

I then added more confusion by saying that in the case of wifi-connected
endpoints the upstream TCP ACKs also compete for airtime with the
downstream flow. Of course this no longer has anything to do with the
cable modem.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] 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
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Bob McMahon]

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  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-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Bob McMahon]

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  wrote:

> Toke Høiland-Jørgensen  writes:
>
> > Luca Muscariello  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-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Luca Muscariello]

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

On Fri, Dec 1, 2017 at 2:13 PM, Кирилл Луконин  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 :
> > Jan Ceuleers  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-f...@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
>
> --
> Best Regards,
> Lukonin Kirill
> ___
> Make-wifi-fast mailing list
> make-wifi-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat