From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp126.iad3a.emailsrvr.com (smtp126.iad3a.emailsrvr.com [173.203.187.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8615D3B29E for ; Fri, 31 May 2019 13:15:04 -0400 (EDT) Received: from smtp32.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 483512C20; Fri, 31 May 2019 13:15:04 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1559322904; bh=1Bl6CKWjhCeXq4zlXVX3O9VqqpM3mElbQDnpekWPuGE=; h=Date:Subject:From:To:From; b=WzoWCybA5SGtVnCAdZdil+O1h64+euz/LIafdbMv1f5Kn5vOydZbi00fbfSJ1N6z2 ML96oZnmKaNmNqJXrc/V3Y2UyCa2wdvsrEQNWnoKJaG1yGq5rlcK4OAwXW4kjVrCFg ZlOK0uO2KGXUQBvbtvOTFC6SVu2XAwTZyxE8kIcE= Received: from app28.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 24634587C; Fri, 31 May 2019 13:15:04 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app28.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 31 May 2019 13:15:04 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app28.wa-webapps.iad3a (Postfix) with ESMTP id 11C0960060; Fri, 31 May 2019 13:15:04 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Fri, 31 May 2019 13:15:04 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Fri, 31 May 2019 13:15:04 -0400 (EDT) From: "David P. Reed" To: "Dave Taht" Cc: "Make-Wifi-fast" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20190531131504000000_27047" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1559322904.0719176@apps.rackspace.com> X-Mailer: webmail/16.4.4-RC Subject: Re: [Make-wifi-fast] a thought about acks X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 17:15:04 -0000 ------=_20190531131504000000_27047 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AInteresting ideas, but these ideas don't belong in TCP.=0A =0AIt's perfe= ctly OK to have acknowledgements at the MAC layer. After all, it affects a = single contention domain, which is like a shared link, not an end-to-end co= nnection.=0A =0ATCP's flow and congestion control mechanisms are conceived = entirely around the idea of a heterogeneous dynamically changing overlay gr= aph. The expectations of the layer below IP are simple: no buildup of late= ncy, reasonably high reliability (this is what "best efforts" has always me= ant).=0A =0AThe idea of making TCP the "physical layer" protocol was NOT in= the original design, on purpose! I was part of the design team working dir= ectly under Vint Cerf and Jon Postel when this was decided.=0A =0AInstead, = the idea was that the physical layer properties (including "medium acquisit= ion time", better called "arbitration overhead") would NOT be visible at th= e end-to-end level.=0A =0ASo, I would just suggest that these experiments d= emonstrate how to think about making *WiFi* fast, and not how to make TCP s= pecial over WiFi.=0A =0AOn Friday, May 31, 2019 11:38am, "Dave Taht" said:=0A=0A=0A=0A> http://www0.cs.ucl.ac.uk/staff/m.handley= /papers/hack2014.pdf=0A> =0A> --=0A> =0A> Dave T=C3=A4ht=0A> CTO, TekLibre,= LLC=0A> http://www.teklibre.com=0A> Tel: 1-831-205-9740=0A> ______________= _________________________________=0A> Make-wifi-fast mailing list=0A> Make-= wifi-fast@lists.bufferbloat.net=0A> https://lists.bufferbloat.net/listinfo/= make-wifi-fast ------=_20190531131504000000_27047 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Interesting ideas, but= these ideas don't belong in TCP.

=0A

 

=0A<= p style=3D"margin:0;padding:0;font-family: arial; font-size: 12pt; overflow= -wrap: break-word;">It's perfectly OK to have acknowledgements at the MAC l= ayer. After all, it affects a single contention domain, which is like a sha= red link, not an end-to-end connection.

=0A

 =0A

TCP's flow and congestion control mechanisms are = conceived entirely around the idea of a heterogeneous dynamically changing = overlay graph.  The expectations of the layer below IP are simple: no = buildup of latency, reasonably high reliability (this is what "best efforts= " has always meant).

=0A

 

=0A

The idea of making TCP the "physical layer" protocol was NOT in the = original design, on purpose! I was part of the design team working directly= under Vint Cerf and Jon Postel when this was decided.

=0A

 

=0A

Instead, the idea was that the phy= sical layer properties (including "medium acquisition time", better called = "arbitration overhead") would NOT be visible at the end-to-end level.

= =0A

 

=0A

So, I would just = suggest that these experiments demonstrate how to think about making *WiFi*= fast, and not how to make TCP special over WiFi.

=0A

On Friday, May 31, 2019 11:38am, "Dave = Taht" <dave.taht@gmail.com> said:

=0A
=0A

> http://www0.cs.ucl.ac.uk/staff= /m.handley/papers/hack2014.pdf
>
> --
>
>= Dave T=C3=A4ht
> CTO, TekLibre, LLC
> http://www.teklibre.= com
> Tel: 1-831-205-9740
> _______________________________= ________________
> Make-wifi-fast mailing list
> Make-wifi-= fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo= /make-wifi-fast

=0A
 ------=_20190531131504000000_27047--