Re: [Ecn-sane] cctrace prototype

Re: [Ecn-sane] cctrace prototype

[Jonathan Morton]

> On 20 Mar, 2019, at 2:41 am, Pete Heist <pete@heistp.net> wrote:
> 
> So I’m starting work on a tool to make congestion signal plots in xplot.org format. It’s in Go for now and reads pcap files, producing one plot for each flow of the timestamp vs signal proportion. I’ll merge it to tcptrace later if needed, this is just faster for getting it started.
> 
> Here are screenshots and xpl files of one flow from a 10 second, 16-flow iperf upload with fq_codel_fast:
> 
> 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.

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.

> It needs some work, and I’m not yet satisfied with the windowing behavior. Choose a window size too low and the proportion value is visibly quantized. Too high and changes aren’t well reflected. I might be able to make a reasonable choice automatically through.
> 
> Thoughts? Ok to discuss this on ecn-sane?
> 
> Also, feel free to imagine what else would help visualize CC (different plot entirely? combined with throughput / RTT / TCP window?) and I’ll try to make it happen...

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.

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.

 - Jonathan Morton

Re: [Ecn-sane] cctrace prototype

[Pete Heist]

> 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…

Re: [Ecn-sane] cctrace prototype

[Pete Heist]

> On Mar 20, 2019, at 8:20 AM, Pete Heist <pete@heistp.net> wrote:
> 
> I’ll push what’s available so far later this morning, needs some cleanup…

Code: https://github.com/heistp/cctrace

Updated samples: https://www.heistp.net/downloads/cctrace/

Proportions are calculated now by direction, which also cleaned up some of the output. Also, I now ignore flags for SYN packets.

Probably easiest to use Issues for further requests / bugs…