From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: make-wifi-fast@lists.bufferbloat.net
Subject: [Make-wifi-fast] Fwd: Re: [iccrg] TCP behavior across WiFi pointers ?
Date: Thu, 30 Nov 2017 08:39:02 +0100 [thread overview]
Message-ID: <87lgionrl5.fsf@toke.dk> (raw)
[-- Attachment #1: Type: text/plain, Size: 93 bytes --]
The folks over at Meraki had a paper at this year's IMC talking about
TCP over WiFi.
-Toke
[-- Attachment #2: Type: message/rfc822, Size: 10553 bytes --]
[-- Attachment #2.1.1.1: Type: text/plain, Size: 2020 bytes --]
We’ve been doing some studies and work in this area at Meraki.
https://conferences.sigcomm.org/imc/2017/papers/imc17-final203.pdf
Simon
> On Nov 29, 2017, at 7:17 AM, Aaron Falk <aaron.falk@gmail.com> wrote:
>
> Hey Mark-
>
> Didn't you do some work on TCP over wifi a while ago?
>
> --aaron
>
> On Wed, Nov 8, 2017 at 1:33 PM Michael Welzl <michawe@ifi.uio.no <mailto:michawe@ifi.uio.no>> wrote:
> I would think that 1) there are probably pointers, and 2) the people who have them should be on the ICCRG list, which I’m cc’ing.
>
> I suggest for this to be the last email that includes tsvarea so that the thread entirely moves to ICCRG.
>
>
> > On Nov 8, 2017, at 6:42 PM, Toerless Eckert <tte+ietf@cs.fau.de <mailto:tte%2Bietf@cs.fau.de>> wrote:
> >
> > Any pointers to work analyzing the differences in behavior when TCP is run
> > across WiFi as opposed to wired ? Especially with WiFi in the home ?
> >
> > I am primarily thinking that there could be a higher demand for
> > TCP (end-to-end) retransmissions when using WiFi because the L2/WiFi
> > local retransmissions are insufficient. And if so, what the characteristics
> > of those end-to-end retransmissions is (would assume they would be larger
> > than N msec, where N is whatever the L2/wifi protection window is, which
> > unfortunately i don't know).
> >
> > Asking because we've got the poor "must-sit-in-back-of-the-bus" traffic
> > called IP multicast that is not protected by L2/wifi retransmissions at
> > all and now we're wondering if carrying it over TCP as a workaround
> > could help, and therefore trying to educate myself on specific known
> > issue left when running traffic over TCP over WiFi.
> >
> > If any other TSV or other WG mailing list might be a better place to
> > ask. pls. let me know.
> >
> > Thank!
> > Toerless
> >
>
> _______________________________________________
> iccrg mailing list
> iccrg@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg
[-- Attachment #2.1.1.2: Type: text/html, Size: 3534 bytes --]
[-- Attachment #2.1.2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
iccrg mailing list
iccrg@irtf.org
https://www.irtf.org/mailman/listinfo/iccrg
next reply other threads:[~2017-11-30 7:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-30 7:39 Toke Høiland-Jørgensen [this message]
2017-11-30 8:04 ` Dave Taht
2017-11-30 8:07 ` Dave Taht
2017-11-30 8:21 ` Jonathan Morton
2017-11-30 8:52 ` Toke Høiland-Jørgensen
2017-11-30 22:35 ` Simon Barber
2017-11-30 22:50 ` Toke Høiland-Jørgensen
2017-11-30 22:59 ` Simon Barber
2017-12-01 12:48 ` Toke Høiland-Jørgensen
2017-12-01 14:57 ` Dave Taht
2017-11-30 9:03 ` Sebastian Moeller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lgionrl5.fsf@toke.dk \
--to=toke@toke.dk \
--cc=make-wifi-fast@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox