400G forwarding - how does it work?

Ca By cb.list6 at gmail.com
Mon Aug 8 13:02:36 UTC 2022


On Mon, Aug 8, 2022 at 5:39 AM <sronan at ronan-online.com> wrote:

> You keep using the term “imaginary” when presented with evidence that does
> not match your view of things.
>
> There are many REAL scenarios where single flow high throughout TCP is a
> real requirements as well as high throughput extremely small packet size.
> In the case of the later, the market is extremely large, but it’s not
> Internet traffic.
>

I believe this all started with asic experts saying trade-offs need to be
made to operate at crazy speeds in a single package.

Ohta-san is simply saying your usecase did not make the cut, which is
clear.  That said, asic makers have gotten things wrong (for me), and some
things they can adjust in code, others not so much. The LPM / LEM lookup
table distribution is certainly one that has burned me in ipv6 and mpls
label scale, but thankfully SiliconOne can make some adjustments… but
watch-out if your network is anything other than /48s

The only thing that will change that is $$$.



> Shane
>
> > On Aug 8, 2022, at 7:34 AM, Masataka Ohta <
> mohta at necom830.hpcl.titech.ac.jp> wrote:
> >
> > Saku Ytti wrote:
> >
> >>> which is, unlike Yttinet, the reality.
> >> Yttinet has pesky customers who care about single TCP performance over
> >> long fat links, and observe poor performance with shallow buffers at
> >> the provider end.
> >
> > With such an imaginary assumption, according to the end to end
> > principle, the customers (the ends) should use paced TCP instead
> > of paying unnecessarily bloated amount of money to intelligent
> > intermediate entities of ISPs using expensive routers with
> > bloated buffers.
> >
> >> Yttinet is cost sensitive and does not want to do
> >> work, unless sufficiently motivated by paying customers.
> >
> > I understand that if customers follow the end to end principle,
> > revenue of "intelligent" ISPs will be reduced.
> >
> >                        Masataka Ohta
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220808/781b359d/attachment.html>


More information about the NANOG mailing list