From 985323631c890b30bbcd00b69ee8ea5aeb3e2f59 Mon Sep 17 00:00:00 2001 From: Dimitri Staessens Date: Mon, 21 Dec 2020 09:50:36 +0100 Subject: blog: Some fixes in wireshark post --- content/en/blog/news/20201219-congestion-avoidance.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'content/en') diff --git a/content/en/blog/news/20201219-congestion-avoidance.md b/content/en/blog/news/20201219-congestion-avoidance.md index e13fdba..7391091 100644 --- a/content/en/blog/news/20201219-congestion-avoidance.md +++ b/content/en/blog/news/20201219-congestion-avoidance.md @@ -6,10 +6,11 @@ description: "" author: Dimitri Staessens --- -In my recently did some quick tests with the new congestion avoidance -implementation, and thought to myself that it was a shame that -Wireshark could not identify the Ouroboros flows, as that could give -me some nicer graphs. +I recently did some +[quick tests](/blog/2020/12/12/congestion-avoidance-in-ouroboros/#mb-ecn-in-action) +with the new congestion avoidance implementation, and thought to +myself that it was a shame that Wireshark could not identify the +Ouroboros flows, as that could give me some nicer graphs. Just to be clear, I think generic network tools like tcpdump and wireshark -- however informative and nice-to-use they are -- are a @@ -56,7 +57,7 @@ layer. The graph above shows the bandwidth -- as captured on the congested 100Mbit Ethernet link --, separated for each traffic flow, from the same pcap capture as in my previous post. A flow can be identified by -a pair, and since the destination +a (destination address, endpoint ID)-pair, and since the destination is all the same, I could filter out the flows by simply selecting them based on the (64-bit) endpoint identifier. -- cgit v1.2.3