Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Brandon Butterworth <brandon@rd.bbc.co.uk>
To: Dave Taht <dave.taht@gmail.com>
Cc: Dave Taht via Starlink <starlink@lists.bufferbloat.net>,
	brandon@rd.bbc.co.uk
Subject: Re: [Starlink] mems optical switching
Date: Sun, 19 Mar 2023 14:16:20 +0000	[thread overview]
Message-ID: <20230319141619.GA1774@sunf68.rd.bbc.co.uk> (raw)
In-Reply-To: <CAA93jw6YnEGmDfRVFBgeigaJ5bLsdLgXEj-2RtgNsSqjCcfOwQ@mail.gmail.com>

On Sat Mar 18, 2023 at 03:19:49PM -0700, Dave Taht via Starlink wrote:
> Today, this about google's mems switching tech hit,

They've been talking about it since last year, seems to have got
a hype bump recently.

Who expected circuit switching to make a comeback?

> I keep wondering where else it could be applied.

They've been used for a long time, eg almost 20 years ago -
https://archive.nanog.org/meetings/nanog32/presentations/zwart.pdf

There is a goal of optical packet switching, until then you're
limited to where there are limited flows of long enough duration
to make the change from packet to circuit switching viable. So mostly
automated testing.

I've dabbled with the idea in an archive use case where very few of
a large set of storage nodes need to connect to a moderate number
of servers. For some cases we could have zero switches. The goal was
a mostly dark infrastructure and many 1000s of storage nodes,
removing the switches saves a lot of power.

Commercial optical switches are expensive so I was looking at
making an optical strowger as I wanted a high fan out not
large n^2.

In the mobile world they are looking at doing flexible bandwidth
per node with coherent optics over gpon fibre plant, allocating
variable amounts of spectrum to each, which could be adapted to a
similar circuit model. It'd be no use to google as they want the
full bandwidth between each node but as dwdm coherent optic costs
come down you could imagine doing the same with a full channel
between each pair, so like a conventional WSS but cheaper. If it
wasn't for the optics cost I suspect they'd have done that reducing
switching time to a channel change.

brandon

  parent reply	other threads:[~2023-03-19 14:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-18 22:19 Dave Taht
2023-03-19 12:58 ` Michael Richardson
2023-03-19 14:16 ` Brandon Butterworth [this message]
2023-03-19 14:33   ` Christian von der Ropp
2023-03-20 11:32     ` Dave Taht
2023-03-20 11:42       ` David Lang
2023-03-20 11:46       ` Mike Puchol
2023-03-20 18:55         ` Ulrich Speidel

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/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230319141619.GA1774@sunf68.rd.bbc.co.uk \
    --to=brandon@rd.bbc.co.uk \
    --cc=dave.taht@gmail.com \
    --cc=starlink@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