<div><div><br></div><div><br><div class="gmail_quote"></div></div></div><div><div dir="ltr" class="gmail_attr">On Mon, Aug 8, 2022 at 5:39 AM <<a href="mailto:sronan@ronan-online.com" target="_blank">sronan@ronan-online.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">You keep using the term “imaginary” when presented with evidence that does not match your view of things. <br>
<br>
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.<br>
</blockquote><div dir="auto"><br></div></div><div><div dir="auto">I believe this all started with asic experts saying trade-offs need to be made to operate at crazy speeds in a single package. </div><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><br></div><div dir="auto">The only thing that will change that is $$$.  </div></div><div><div><div class="gmail_quote"><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>
Shane<br>
<br>
> On Aug 8, 2022, at 7:34 AM, Masataka Ohta <<a href="mailto:mohta@necom830.hpcl.titech.ac.jp" target="_blank">mohta@necom830.hpcl.titech.ac.jp</a>> wrote:<br>
> <br>
> Saku Ytti wrote:<br>
> <br>
>>> which is, unlike Yttinet, the reality.<br>
>> Yttinet has pesky customers who care about single TCP performance over<br>
>> long fat links, and observe poor performance with shallow buffers at<br>
>> the provider end.<br>
> <br>
> With such an imaginary assumption, according to the end to end<br>
> principle, the customers (the ends) should use paced TCP instead<br>
> of paying unnecessarily bloated amount of money to intelligent<br>
> intermediate entities of ISPs using expensive routers with<br>
> bloated buffers.<br>
> <br>
>> Yttinet is cost sensitive and does not want to do<br>
>> work, unless sufficiently motivated by paying customers.<br>
> <br>
> I understand that if customers follow the end to end principle,<br>
> revenue of "intelligent" ISPs will be reduced.<br>
> <br>
>                        Masataka Ohta<br>
> <br>
> <br>
> <br>
</blockquote></div></div>
</div>