Re: [Ecn-sane] cctrace prototype

[Pete Heist <pete@heistp.net>]

> On Mar 20, 2019, at 4:42 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 20 Mar, 2019, at 2:41 am, Pete Heist <pete@heistp.net> wrote:
>> 
>> https://www.heistp.net/downloads/cctrace/
>> 
>> For each point, right arrow is used for upstream and left for downstream.
>> 
>> You can see that the SCE signals start sooner before CE takes over, which could theoretically prevent CE with a cooperating TCP.
> 
> Well, it's not *very* easy to see - but that is the idea in theory.  It might be easier to analyse such things (at this early stage of development) with a single flow, or possibly a pair with staggered start times.

Easier to see when zoomed.

Also the scale independent symbologies can be retina bending on modern displays. I don’t think xplot.org makes any adjustments for screen dpi.

> One thing I'm noticing is that the SCE rate drops off very sharply when the CE marking rate rises, but the latter doesn't read higher than 50%.  Check your axis scale and your window average function for fenceposts.

Ah, you’re probably expecting the proportion of packets carrying each mark _in the same direction_, right? I can fix that.

> I'd like to see a sequence plot with the ECN codepoint indicated by colour coding, and similarly for ECE/NS/CWR on the ack path.

Ok, this will mean either creating a new sequence plot in Go or getting this into tcptrace, the former probably still being easier for me.

> I'd also like to see a dynamic estimate of cwnd (or rather, in-flight data), with similar colour coding and/or labelling, for correlation.

I'll see if I can figure out how to estimate that.

I’ll push what’s available so far later this morning, needs some cleanup…