From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp110.iad3a.emailsrvr.com (smtp110.iad3a.emailsrvr.com [173.203.187.110]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9AF7B3CB37 for ; Mon, 12 Jul 2021 21:23:25 -0400 (EDT) Received: from app35.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp22.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3CD3430C0 for ; Mon, 12 Jul 2021 21:23:25 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app35.wa-webapps.iad3a (Postfix) with ESMTP id 282FBA0081; Mon, 12 Jul 2021 21:23:25 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Mon, 12 Jul 2021 21:23:25 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Mon, 12 Jul 2021 21:23:25 -0400 (EDT) From: "David P. Reed" To: starlink@lists.bufferbloat.net Cc: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1626139405.16213728@apps.rackspace.com> X-Mailer: webmail/19.0.7-RC X-Classification-ID: dcc424ad-582a-4ff2-9f3d-34c7e2b7455b-1-1 Subject: Re: [Starlink] =?utf-8?q?SatNetLab=3A_A_call_to_arms_for_the_next_glo?= =?utf-8?q?bal=3E_=09Internet_testbed?= X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 01:23:25 -0000 > From: David Lang =0A> =0A> Wifi has the added issue that t= he blob headers are at a much lower data rate=0A> than the dta itself, so y= ou can cram a LOT of data into a blob without making a=0A> significant diff= erence in the airtime used, so you really do want to be able to=0A> send fu= ll blobs (not at the cost of delaying tranmission if you don't have a=0A> f= ull blob, a mistake some people make, but you do want to buffer enough to f= ill=0A> the blobs)=0AThis happens naturally if the senders in the LAN take = turns and transmit what they have accumulated while waiting their turn, fai= rly naturally. Capping the total airtime in a cycle limits short message la= tency, which is why small packets are helpful.=0A=0A> =0A> and given that d= ropped packets results in timeouts and retransmissions that=0A> affect the = rest of the network, it's not obviously wrong for a lossy hop like=0A> wifi= to retry a failed transmission, it just needs to not retry too many times.= =0A> =0AAbsolutely right, though not perfect. local retransmit on a link (o= r WLAN domain) benefits if the link has a high bit-error rate. On the other= hand, it's better if you can to use FEC, or erasure coding or just lower t= he attempted signalling rate, from an information theoretic point of view. = If you have an estimator of Bit Error Rate on the link (which gives you a p= acket error rate), there's a reasonable bound on the number of retransmits = on an individual packet at the link level that doesn't kill end-to-end late= ncy. I forget how the formula is derived. It's also important as BER increa= ses to use shorter packet frames.=0A=0AEnd to end retransmit is not the opt= imal way to correct link errors - the end-to-end checksum and retransmit in= TCP has confused people over the years into thinking link reliability can = be omitted! That was never the reason TCP does end-to-end error checking. P= eople got confused about that. As Dave Taht can recount based on discussion= s with Steve Crocker and me (ARPANET and TCP/IP) the point of end-to-end ch= ecks is to make sure that *overall* the system doesn't introduce errors, in= cluding in buffer memory, software that doesn't quite work, etc. The TCP re= transmission is mostly about recovering from packet drops and things like d= uplicated packets resulting from routing changes, etc.=0A=0ASo fix link err= ors at link level (but remember that retransmit with checksum isn't really = optimal there - there are better ways if BER is high or the error might be = because of software or hardware bugs which tend to be non-random).=0A=0A=0A= =0A=0A> David Lang=0A> =0A> =0A> On Sat, 10 Jul 2021, Rodney W. Grimes wr= ote:=0A> =0A>> Date: Sat, 10 Jul 2021 04:49:50 -0700 (PDT)=0A>> From: Rodne= y W. Grimes =0A>> To: Dave Taht =0A>> Cc: starlink@lists.bufferbloat.net, Ankit Singla ,=0A>> Sam Kumar =0A>> Subject: Re: [Starl= ink] SatNetLab: A call to arms for the next global Internet=0A>> testb= ed=0A>>=0A>>> While it is good to have a call to arms, like this:=0A>> ... = much information removed as I only one to reply to 1 very=0A>> narrow,= but IMHO, very real problem in our networks today ...=0A>>=0A>>> Here's an= other piece of pre-history - alohanet - the TTL field was the=0A>>> "time t= o live" field. The intent was that the packet would indicate=0A>>> how much= time it would be valid before it was discarded. It didn't=0A>>> work out, = and was replaced by hopcount, which of course switched=0A>>> networks ignor= e and isonly semi-useful for detecting loops and the=0A>>> like.=0A>>=0A>> = TTL works perfectly fine where the original assumptions that a=0A>> device = along a network path only hangs on to a packet for a=0A>> reasonable short = duration, and that there is not some "retry"=0A>> mechanism in place that i= s causing this time to explode. BSD,=0A>> and as far as I can recall, almo= st ALL original IP stacks had=0A>> a Q depth limit of 50 packets on egress = interfaces. Everything=0A>> pretty much worked well and the net was happy.= Then these base=0A>> assumptions got blasted in the name of "measurable b= andwidth" and=0A>> the concept of packets are so precious we must not loose= them,=0A>> at almost any cost. Linux crammed the per interface Q up to 10= 00,=0A>> wifi decided that it was reasable to retry at the link layer so=0A= >> many times that I have seen packets that are >60 seconds old.=0A>>=0A>> = Proposed FIX: Any device that transmits packets that does not=0A>> already= have an inherit FIXED transmission time MUST consider=0A>> the current TTL= of that packet and give up if > 10mS * TTL elapses=0A>> while it is trying= to transmit. AND change the default if Q=0A>> size in LINUX to 50 for fif= o, the codel, etc AQM stuff is fine=0A>> at 1000 as it has delay targets th= at present the issue that=0A>> initially bumping this to 1000 caused.=0A>>= =0A>> ... end of Rods Rant ...=0A>>=0A>> --=0A>> Rod Grimes = rgrimes@freebsd.org=0A>> _________________= ______________________________=0A>> Starlink mailing list=0A>> Starlink@lis= ts.bufferbloat.net=0A>> https://lists.bufferbloat.net/listinfo/starlink=0A>= =0A> =0A> ------------------------------=0A> =0A> Subject: Digest Footer= =0A> =0A> _______________________________________________=0A> Starlink mail= ing list=0A> Starlink@lists.bufferbloat.net=0A> https://lists.bufferbloat.n= et/listinfo/starlink=0A> =0A> =0A> ------------------------------=0A> =0A> = End of Starlink Digest, Vol 4, Issue 21=0A> *******************************= ********=0A> =0A