<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
It will not be easy to get a straight answer, I would say more about your environ and applications. So if you considered the classical TCP algorithm ignoring latency it is large buffer, yet what about microburst?</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
LG<br>
</div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> NANOG <nanog-bounces+lobna_gouda=hotmail.com@nanog.org> on behalf of William Herrin <bill@herrin.us><br>
<b>Sent:</b> Friday, April 9, 2021 1:07 PM<br>
<b>To:</b> Mike Hammett <nanog@ics-il.net><br>
<b>Cc:</b> nanog@nanog.org <nanog@nanog.org><br>
<b>Subject:</b> Re: Trident3 vs Jericho2</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">On Fri, Apr 9, 2021 at 6:05 AM Mike Hammett <nanog@ics-il.net> wrote:<br>
> What I've observed is that it's better to have a big buffer device<br>
> when you're mixing port speeds. The more dramatic the port<br>
> speed differences (and the more of them), the more buffer you need.<br>
><br>
> If you have all the same port speed, small buffers are fine. If you have<br>
> 100G and 1G ports, you'll need big buffers wherever the transition to<br>
> the smaller port speed is located.<br>
<br>
<br>
When a network is behaving well (losing few packets to data<br>
corruption), TCP throughput is is impacted by exactly two factors:<br>
<br>
1. Packet round trip time<br>
2. The size to which the congestion window has grown when the first<br>
packet is lost<br>
<br>
Assuming the sender has data ready, it will (after the initial<br>
negotiation) slam out 10 packets back to back at the local wire speed.<br>
Those 10 packets are the initial congestion window. After sending 10<br>
packets it will wait and wait and wait until it hits a timeout or the<br>
other side responds with an acknowledgement. So those initial packets<br>
start out crammed right at the front of the round trip time with lots<br>
of empty afterwards.<br>
<br>
The receiver gets the packets in a similar burst and sends its acks.<br>
As the sender receives acknowledgement for each of the original<br>
packets, it sends two more. This doubling effect is called "slow<br>
start," and it's slow in the sense that the sender doesn't just throw<br>
the entire data set at the wire and hope. So, having received acks for<br>
10 packets, it sends 20 more. These 20 have spread out a little bit,<br>
more or less based on the worst link speed in the path, but they're<br>
still all crammed up in a bunch at the start of the round trip time.<br>
<br>
Next round trip time it doubles to 40 packets. Then 80. Then 160. All<br>
crammed up at the start of the round trip time causing them to hit<br>
that one slowest link in the middle all at once. This doubling<br>
continues until one of the buffers in the middle is too small to hold<br>
the trailing part of the burst of packets while the leading part is<br>
sent. With a full buffer, a packet is dropped. Whatever the congestion<br>
window size is when that first packet is dropped, that number times<br>
the round trip time is more or less the throughput you're going to see<br>
on that TCP connection.<br>
<br>
The various congestion control algorithms for TCP do different things<br>
after they see that first packet drop. Some knock the congestion<br>
window in half right away. Others back down more cautiously. Some<br>
reduce growth all the way down to 1 packet per round trip time. Others<br>
will allow faster growth as the packets spread out over the whole<br>
round trip time and demonstrate that they don't keep getting lost. But<br>
in general, the throughput you're going to see on that TCP connection<br>
has been decided as soon as you lose that first packet.<br>
<br>
So, TCP will almost always get better throughput with more buffers.<br>
The flip side is latency: packets sitting in a buffer extend the time<br>
before the receiver gets them. So if you make a buffer that's 500<br>
milliseconds long and then let a TCP connection fill it up, apps which<br>
work poorly in high latency environments (like games and ssh) will<br>
suffer.<br>
<br>
Regards,<br>
Bill Herrin<br>
<br>
<br>
-- <br>
William Herrin<br>
bill@herrin.us<br>
<a href="https://bill.herrin.us/">https://bill.herrin.us/</a><br>
</div>
</span></font></div>
</div>
</body>
</html>