<div dir="ltr">We have done something like that a year ago in our team in Cisco<div>for a project that you Dave are aware of but that is out of scope for these lists.</div><div><br></div><div>It is important to have vantage points in residential and enterprise networks. </div><div>Cloud to Cloud never goes to transit and the big Clouds have global footprints.</div><div>So you can traverse the planet inside the Cloud WAN (100% bit consistency) and then traverse a safe peering </div><div>point where the adjacency  has been well set (or not).</div><div><br></div><div>IPv4/IPv6 of course we'll see a big difference in favour of IPv6. </div><div>What Michael has shown is his paper makes a lot of sense to me.</div><div>Depending on the use case hit ratio can be very high or very low.</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 24, 2019 at 9:55 AM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">1) The research into whether bit flipping to the extent that SCE will<br>
do has not been done yet. The study of ECT(0) vs ECT(1) behavior<br>
transiting to CE was a little lightweight.<br>
<br>
To test this we going to fire up a ton of nanodes in various data<br>
centers, with low SCE thresholds, and low bandwidths, to flip lots of<br>
bits, and test between the data centers and from as many vantage<br>
points around the net as we can get - do packet captures as well as<br>
flent tests<br>
<br>
as a control, set up identical boxes, with SCE disabled, in the same<br>
data centers.<br>
<br>
Setup flent, irtt, iperf3.<br>
<br>
2) Diffserv bit preservation test<br>
<br>
The research going by on the tsvwg mailing seems a bit dated. It is<br>
very straightforward to use irtt to test to see what udp codepoints<br>
survive e2e, and to also leverage this testbed setup. Similarly,<br>
netperf can easily be used to mark tcp. We do not have a good packet<br>
cap tool to verify that the bits are being set right, however I think<br>
irtt can be modified to check for correctness here and produce a<br>
report.<br>
<br>
On Sun, Mar 24, 2019 at 1:45 AM Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>> wrote:<br>
><br>
> > On 24 Mar, 2019, at 8:37 am, Pete Heist <<a href="mailto:pete@heistp.net" target="_blank">pete@heistp.net</a>> wrote:<br>
> ><br>
> > I should theoretically arrive at the boat today some time after 3pm, having picked up a mini HDMI to HDMI adapter, which we can use with the cable that’s there…<br>
><br>
> Awesome.  I'm also setting up a Linux VM on my Mac, which should help things along.<br>
><br>
> We're bringing up some actual hardware with the SCE-enabled Cake on it now.  Dave wants to investigate various theoretical phenomena the Internet might exhibit with a mixture of ECN codepoints; I just want to be sure it actually works as intended, before I move on to fiddling with TCP.<br>
><br>
>  - Jonathan Morton<br>
><br>
> _______________________________________________<br>
> Cake mailing list<br>
> <a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
<br>
<br>
<br>
-- <br>
<br>
Dave Täht<br>
CTO, TekLibre, LLC<br>
<a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
Tel: 1-831-205-9740<br>
_______________________________________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
</blockquote></div>