From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 BD92C3CB37; Fri, 17 Mar 2023 16:36:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1679085400; i=moeller0@gmx.de; bh=TvibdeNjSodPzbqgqXSkCdasISCrB1SEUlLCQQN4JBU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=V2PqfU8r1Afr0iiACZiukCEW2nVOE/FK+BtCnbslarEzCW+hu6o+PefPIJfGcZ8gX D3FJDA8jWTzJ3ccSfRjp66F6axpe0jHC4WOfmAC2CkOd64CVu334lrDtgXctaR6gPp ag59JcoMd9ZA0oqRtQ7mqUFwmBkHN0V7LbjfV7SIyyIyS5/3EfF9DL7uIAdOtqXkT5 vycLLdyak6CzmnsNDwqevZlcnskkc9ATeOzhR+VBBnKWPxwFXZjWDzx9CoTAbjD5wB fzn/AElTfJQfYj1UMYOvd88BtBTXpxyGloFAfOpeAIvNqTgUjfXGFjIPdMSXh3UkQn iX2IBJZWulcig== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([95.116.92.219]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MLzBj-1pv4eH2utV-00HzNl; Fri, 17 Mar 2023 21:36:40 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 17 Mar 2023 21:36:39 +0100 Cc: =?utf-8?Q?David_Fern=C3=A1ndez?= , Dave Taht via Starlink , libreqos Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3696.120.41.1.2) X-Provags-ID: V03:K1:tzc4BXt3dJU3fBxjh7ITAIzBY013OfOdJBxxjTXYbyW2elYTM9V 5frKyHYl31xG8jAciaIG6ATTtaW3q6y8BJag5qljG6ULqoXfZZV1S4FLWdZURY9B1Z347To XnWZo42Ig4dKdQvxLrU0CMPqB1OBpjt2QQzB4fy2Hmf1z5JHAk+Xhp9USN2MMNdLUR87CjS XJPq3fIi7nKMEsxDYvBIA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:HnixPsAkNxY=;evCeC6QxOeAsOZfyFhWbBmcHXUn QFcEIg5kR921MESK4crdHbU8TMj29QwI0gpEo904OcxtyKOZJLw+1d+ZC4ksXpVghCY0a9RNh GQN7WcCKHKmE8i1kzKRxpPS4VsoceQOSAwJLmX/gfOsC2oQn7kBTShNOHWeeh/fyyGmnWn1K9 ct5GNGD9E2ggBjQ9Qq+JV6MLU66pAMxou6D43FbTR3JihrzlCH0Zx1FCiu1YoN5IwUpnSMcCC 7u+Mx4Osb0Yyv7WaKxzO+M14dnG66cB46Ji4YFZDspgUt9sOTIkcbeehDWcEt9tECtjy2thgW ynjQrGcHtB/t+QyLg114e8wmfEUjGMgPjfuWxGxdgHayC9PPokGxEh0NBIYTSQytQgPyQA2I9 f2FUIVeZScDdOU1k7hqdM6USs8U4gv+VzJ/s2WuYXe/WFKJMCmvzSy2Afkpu9E4SlnA0ZmBfT RUMG/rUdvxa04Ob2F2XAKwj+xvAS7HhZBSbslfSDg/SGUTC4SHlSF28nDq3ewKt+2v49G9bK2 jPrTzJOX1qbjm+KRH3jhRwQbYF7bTlJxHL71RczYSIrrPYW0Az1i4f9XvN6g8OXlVQJvUP68m K41npxDDRTtX9fystFF/oLck7tD9kM7oo3lZFBijOAKqNNOcoBKCxtM4+x+TD/OodM+1FARaR tRHAGBXfDsOnm+HmtsCXqg/xGCq6toyZ3zTqrpi5fikYSgF6w428c4gR6J85xdt/Td/OGcfFH YL/UMlGKM4ETUDknFjMbHsmccYzidaGQej40qD2fqg+ABInUpVbZzukm3YypCK/cVninKbo/7 t5MjlA7MtCm6v9rW7UBCSChH7UKRf6kbZBv/i9SL6M2iW3zABjXX09t+yM2weFvRDEKdoLhhM 20OkJ3i4ormWPcii/GpGNEVxMFlopOAD9i5mnHUVR1OBDAbfxmdTsmEcanSLRmDaMdeNH2V+H yGYUFqBPz5WKko2cXqzGbplxfCo= Subject: Re: [Starlink] GPON vs Active Fiber Ethernet 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: Fri, 17 Mar 2023 20:36:43 -0000 Hi Dave, > On Mar 17, 2023, at 18:05, Dave Taht via Starlink = wrote: >=20 > On Fri, Mar 17, 2023 at 9:54=E2=80=AFAM David Fern=C3=A1ndez via = Starlink > wrote: >>=20 >> Hi Dave, >>=20 >> Telefonica achieved considerable gains in efficiency dismantling the >> copper network (85% gains in energy efficiency). >>=20 >> Read here: = https://www.xataka.com/empresas-y-economia/paso-cobre-adsl-a-fibra-ha-sido= -beneficioso-para-todos-especialmente-para-telefonica >=20 > I am not prepared to make a coherent argument (although I enjoy them), > but I look at the serialization delay of gpon of 250us and other GPON has no strict 250=C2=B5s serialization delay, it uses time = slots of 250=C2=B5s... for its accounting... that is IMHO the timescale = for the grant-request cycle and considerably below what DOCSIS gets away = with today. > potential multiplexing problems, For downstream the OLT simply encrypts with the target ONT's key = and "broadcasts it to all ONTs that are listening on the PON-tree. For = upstream we have a rather typical request grant scheme like in DOCSIS = where the OLT assigns transmit slots to the ONT's so these do not step = on each other (the ONTs as far as I can tell can not see/hear each = other's transmissions so the OLT needs to arbitrate.) > and go, "yuck". It really, really, > really is the RTT that dominates the performance of all our networking > technologies, and no matter how much bandwidth you have, nearly every > per-sub tech I know of has a floor above 250us today. Multiple hops of > mmwave are particularly bad here. I would assume that the actual delay from sending a request to = sending the first bit is probably more than one cycle, so the access = delay is likely >> 250=C2=B5s, compared to other delays this still seems = to be quite fine to me... (DSL operate with a 4 KHz "clock" as well, but = without request-grant since the last mile is not directly shared*) *) Vectoring bring in a certain fate sharing, but still does not bring = request grant delays. > Modern active fiber ethernet is 10000x quicker (nanoseconds!), very > standardized, increasingly low power (with a ton of bang for the > buck/gbit), with gear available everywhere that "just works", > leveraging the past decade of rapid development in the data center, > with USED 1Gbit SFPs going into trashbins everywhere. >=20 > ... while gpon is, if anything, more proprietary than cable, the gear, > more expensive, and did I mention the latency? >=20 > /me dons flame retardant suit No need, I am not a PON fan, but given its cost benefits (power = and central office space, a single OLT port can terminate anywhere from = 64 (GPON) to 128 (XGSPON) ONTs**, and finally regulatory control***) = that is what we are going to get, and honestly it could be worse. I am not sure GPON is more expensive than cable stuff, it seems = less proprietary than DOCSIS (which is CableLabs or nothing) and is = described in ITU standards. I think there is an open source OLT software = stack (voltha?) so this looks not that bad compared to what I know about = DOCSIS... and latency wise it smokes DOCSIS... heck look at low-latency = docsis instead of tackling the elephant in the room the slow = request-grant cycling they essentially added L4S... (they also propose a = slight speed-up of the grant mechanism IIRC, but nothing close to 250=C2=B5= s epochs). Regards Sebastian **) The big incumbent over here mosty aims for <=3D 32 users on an OLT = port... ***) An ISP operating PONs can no really be forced to rent out dark = fibers to competitors, with a PON realistic worst case is having to = offer some sort of bitstream access where the original ISP is still = tightly in control. As enduser I do not think this to be a good outcome, = yet it seems to factor in technology decisions ISPs make. E.g. deutsche = glasfaser started with AON but mostly switched to PON for new build = outs. P.S.: One thing I always thought great about any kind of AON is that = direct traffic to my neighbors would never have to leave the local = switch, but that is not how ISPs over here operate, all links are = terminated somewhere semi-centrally (incumbent ~900 places, my ISP ~9 = places) and any traffic will only cross over at that central site = anyway. >=20 >>=20 >> Regards, >>=20 >> David >>=20 >>> Date: Fri, 17 Mar 2023 09:38:03 -0700 >>> From: Dave Taht >>> To: Mike Puchol >>> Cc: Dave Taht via Starlink , Rpm >>> , libreqos >>> , bloat = >>> Subject: Re: [Starlink] [Rpm] On FiWi >>> Message-ID: >>> = >>> Content-Type: text/plain; charset=3D"utf-8" >>>=20 >>> This is a pretty neat box: >>>=20 >>> https://mikrotik.com/product/netpower_lite_7r >>>=20 >>> What are the compelling arguments for fiber vs copper, again? >>>=20 >>>=20 >>> On Tue, Mar 14, 2023 at 4:10=E2=80=AFAM Mike Puchol via Rpm < >>> rpm@lists.bufferbloat.net> wrote: >>>=20 >>>> Hi Bob, >>>>=20 >>>> You hit on a set of very valid points, which I'll complement with = my views >>>> on where the industry (the bit of it that affects WISPs) is = heading, and >>>> what I saw at the MWC in Barcelona. Love the FiWi term :-) >>>>=20 >>>> I have seen the vendors that supply WISPs, such as Ubiquiti, = Cambium, and >>>> Mimosa, but also newer entrants such as Tarana, increase the = performance >>>> and on-paper specs of their equipment. My examples below are = centered on >>>> the African market, if you operate in Europe or the US, where you = can >>>> charge customers a higher install fee, or even charge them a = break-up fee >>>> if they don't return equipment, the economics work. >>>>=20 >>>> Where currently a ~$500 sector radio could serve ~60 endpoints, at = a cost >>>> of ~$50 per endpoint (I use this term in place of ODU/CPE, the = antenna >>>> that >>>> you mount on the roof), and supply ~2.5 Mbps CIR per endpoint, the >>>> evolution is now a ~$2,000+ sector radio, a $200 endpoint, = capability for >>>> ~150 endpoints per sector, and ~25 Mbps CIR per endpoint. >>>>=20 >>>> If every customer a WISP installs represents, say, $100 CAPEX at = install >>>> time ($50 for the antenna + cabling, router, etc), and you charge a = $30 >>>> install fee, you have $70 to recover, and you recover from the = monthly >>>> contribution the customer makes. If the contribution after OPEX is, = say, >>>> $10, it takes you 7 months to recover the full install cost. Not = bad, >>>> doable even in low-income markets. >>>>=20 >>>> Fast-forward to the next-generation version. Now, the CAPEX at = install is >>>> $250, you need to recover $220, and it will take you 22 months, = which is >>>> above the usual 18 months that investors look for. >>>>=20 >>>> The focus, thereby, has to be the lever that has the largest effect = on the >>>> unit economics - which is the per-customer cost. I have drawn what = my >>>> ideal >>>> FiWi network would look like: >>>>=20 >>>>=20 >>>>=20 >>>> Taking you through this - we start with a 1-port, low-cost EPON OLT = (or >>>> you could go for 2, 4, 8 ports as you add capacity). This OLT has = capacity >>>> for 64 ONUs on its single port. Instead of connecting the typical = fiber >>>> infrastructure with kilometers of cables which break, require = maintenance, >>>> etc. we insert an EPON to Ethernet converter (I added "magic" = because >>>> these >>>> don't exist AFAIK). >>>>=20 >>>> This converter allows us to connect our $2k sector radio, and serve = the >>>> $200 endpoints (ODUs) over wireless point-to-multipoint up to 10km = away. >>>> Each ODU then has a reverse converter, which gives us EPON again. >>>>=20 >>>> Once we are back on EPON, we can insert splitters, for example, >>>> pre-connectorized outdoor 1:16 boxes. Every customer install now = involves >>>> a >>>> 100 meter roll of pre-connectorized 2-core drop cable, and a $20 = EPON ONU. >>>>=20 >>>> Using this deployment method, we could connect up to 16 customers = to a >>>> single $200 endpoint, so the enpoint CAPEX per customer is now = $12.5. Add >>>> the ONU, cable, etc. and we have a per-install CAPEX of $82.5 = (assuming >>>> the >>>> same $50 of extras we had before), and an even shorter break-even. = In >>>> addition, as the endpoints support higher capacity, we can = provision at >>>> least the same, if not more, capacity per customer. >>>>=20 >>>> Other advantages: the $200 ODU is no longer customer equipment and = CAPEX, >>>> but network equipment, and as such, can operate under a longer = break-even >>>> timeline, and be financed by infrastructure PE funds, for example. = As a >>>> result, churn has a much lower financial impact on the operator. >>>>=20 >>>> The main reason why this wouldn't work today is that EPON, as we = know, is >>>> synchronous, and requires the OLT to orchestrate the amount of time = each >>>> ONU can transmit, and when. Having wireless hops and media = conversions >>>> will >>>> introduce latencies which can break down the communications (e.g. = one ONU >>>> may transmit, get delayed on the radio link, and end up overlapping >>>> another >>>> ONU that transmitted on the next slot). Thus, either the "magic" = box needs >>>> to account for this, or an new hybrid EPON-wireless protocol = developed. >>>>=20 >>>> My main point here: the industry is moving away from the = unconnected. All >>>> the claims I heard and saw at MWC about "connecting the = unconnected" had >>>> zero resonance with the financial drivers that the unconnected = really >>>> operate under, on top of IT literacy, digital skills, devices, = power... >>>>=20 >>>> Best, >>>>=20 >>>> Mike >>>> On Mar 14, 2023 at 05:27 +0100, rjmcmahon via Starlink < >>>> starlink@lists.bufferbloat.net>, wrote: >>>>=20 >>>> To change the topic - curious to thoughts on FiWi. >>>>=20 >>>> Imagine a world with no copper cable called FiWi (Fiber,VCSEL/CMOS >>>> Radios, Antennas) and which is point to point inside a building >>>> connected to virtualized APs fiber hops away. Each remote radio = head >>>> (RRH) would consume 5W or less and only when active. No need for = things >>>> like zigbee, or meshes, or threads as each radio has a fiber = connection >>>> via Corning's actifi or equivalent. Eliminate the AP/Client power >>>> imbalance. Plastics also can house smoke or other sensors. >>>>=20 >>>> Some reminders from Paul Baran in 1994 (and from David Reed) >>>>=20 >>>> o) Shorter range rf transceivers connected to fiber could produce a >>>> significant improvement - - tremendous improvement, really. >>>> o) a mixture of terrestrial links plus shorter range radio links = has the >>>> effect of increasing by orders and orders of magnitude the amount = of >>>> frequency spectrum that can be made available. >>>> o) By authorizing high power to support a few users to reach = slightly >>>> longer distances we deprive ourselves of the opportunity to serve = the >>>> many. >>>> o) Communications systems can be built with 10dB ratio >>>> o) Digital transmission when properly done allows a small signal to >>>> noise ratio to be used successfully to retrieve an error free = signal. >>>> o) And, never forget, any transmission capacity not used is wasted >>>> forever, like water over the dam. Not using such techniques = represent >>>> lost opportunity. >>>>=20 >>>> And on waveguides: >>>>=20 >>>> o) "Fiber transmission loss is ~0.5dB/km for single mode fiber, >>>> independent of modulation" >>>> o) =E2=80=9CCopper cables and PCB traces are very frequency = dependent. At >>>> 100Gb/s, the loss is in dB/inch." >>>> o) "Free space: the power density of the radio waves decreases with = the >>>> square of distance from the transmitting antenna due to spreading = of the >>>> electromagnetic energy in space according to the inverse square = law" >>>>=20 >>>> The sunk costs & long-lived parts of FiWi are the fiber and the CPE >>>> plastics & antennas, as CMOS radios+ & fiber/laser, e.g. VCSEL = could be >>>> pluggable, allowing for field upgrades. Just like swapping out SFP = in a >>>> data center. >>>>=20 >>>> This approach basically drives out WiFi latency by eliminating = shared >>>> queues and increases capacity by orders of magnitude by leveraging = 10dB >>>> in the spatial dimension, all of which is achieved by a physical = design. >>>> Just place enough RRHs as needed (similar to a pop up sprinkler in = an >>>> irrigation system.) >>>>=20 >>>> Start and build this for an MDU and the value of the building = improves. >>>> Sadly, there seems no way to capture that value other than over = long >>>> term use. It doesn't matter whether the leader of the HOA tries to >>>> capture the value or if a last mile provider tries. The value = remains >>>> sunk or hidden with nothing on the asset side of the balance sheet. >>>> We've got a CAPEX spend that has to be made up via "OPEX returns" = over >>>> years. >>>>=20 >>>> But the asset is there. >>>>=20 >>>> How do we do this? >>>>=20 >>>> Bob >>>> _______________________________________________ >>>> Starlink mailing list >>>> Starlink@lists.bufferbloat.net >>>> https://lists.bufferbloat.net/listinfo/starlink >>>>=20 >>>> _______________________________________________ >>>> Rpm mailing list >>>> Rpm@lists.bufferbloat.net >>>> https://lists.bufferbloat.net/listinfo/rpm >>>>=20 >>>=20 >>>=20 >>> -- >>> Come Heckle Mar 6-9 at: https://www.understandinglatency.com >>> / >>> Dave T=C3=A4ht CEO, TekLibre, LLC >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> = >>> -------------- next part -------------- >>> A non-text attachment was scrubbed... >>> Name: Hybrid EPON-Wireless network.png >>> Type: image/png >>> Size: 149871 bytes >>> Desc: not available >>> URL: >>> = >>>=20 >>> ------------------------------ >>>=20 >>> Subject: Digest Footer >>>=20 >>> _______________________________________________ >>> Starlink mailing list >>> Starlink@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/starlink >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> End of Starlink Digest, Vol 24, Issue 39 >>> **************************************** >>>=20 >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink >=20 >=20 >=20 > --=20 > Come Heckle Mar 6-9 at: https://www.understandinglatency.com/ > Dave T=C3=A4ht CEO, TekLibre, LLC > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink