Re: [Bloat] [Make-wifi-fast] benefits of ack filtering
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
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
> 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
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
Jan Ceuleers writes: > 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. 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. fq_codel has a tendency to gather up flows into a quantum (usually 1514 bytes), which translates out to 22 ipv4 acks before it will switch flows. The cake implementation will always deliver the lastmost ack packet, and also has some compensations for stuff in slow start. (it could use a more formal state machine, and perhaps tuning out the sparse flow optimization, and more testing. It certainly is not fast code, but still cheaper than the hashing bits in cake) > ___ > 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
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
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
> 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
> 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
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
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
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
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
>> 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
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
> 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
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
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
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