Re: [PATCH v6 0/2] Add l2reflect measurement application

[Henning Schild <henning.schild@siemens.com>]

Am Wed, 21 Sep 2022 14:22:07 +0200
schrieb Morten Brørup <mb@smartsharesystems.com>:

> > From: Henning Schild [mailto:henning.schild@siemens.com]
> > Sent: Wednesday, 21 September 2022 13.27
> > 
> > Am Wed, 21 Sep 2022 11:43:13 +0200
> > schrieb Morten Brørup <mb@smartsharesystems.com>:
> >   
> > > > From: Felix Moessbauer [mailto:felix.moessbauer@siemens.com]
> > > > Sent: Friday, 2 September 2022 10.46
> > > >
> > > > Dear DPDK community,
> > > >
> > > > this patch provides the l2reflect measurement tool
> > > > which will be discussed in our 2022 DPDK Userspace Summit talk:
> > > > "Using DPDK OVS for deterministic low latency communication"
> > > >
> > > > While the code still might need some polish, we believe it is
> > > > a good starting point for discussions about low latency
> > > > networking in DPDK.
> > > >
> > > > The tool can also be used in a CI environment to contineously
> > > > measure latencies across the evolution of DPDK and Linux.
> > > >
> > > > Best regards,
> > > > Felix Moessbauer
> > > > Siemens AG  
> > >
> > > Dear Felix and Henning,
> > >
> > > Great to meet you at the 2022 DPDK Userspace conference.
> > >
> > > Have you considered using the Configuration Testing Protocol
> > > (CTP), described in chapter 8 of the Ethernet specification from
> > > 1984 [1], instead of your own packet format and the Local
> > > Experimental Ethertype?  
> > 
> > No we have not, first time i hear about that. First type we used
> > must have been 0xaffe or 0xdead, would have to dig through version
> > control.  
> 
> You seem to be using the correct EtherType for an experimental
> protocol like this. I was not opposing to that.
> 
> >   
> > > [1]: http://decnet.ipv7.net/docs/dundas/aa-k759b-tk.pdf
> > >
> > > The CTP an obsolete protocol, and not part of the IEEE standards
> > > for Ethernet, but I think Wireshark is able to parse such
> > > packets.  
> > 
> > Yes ... does not seem to be a train one wants to hop on.
> > 
> > Maybe you can explain how one would use CTP to measure roundtrip
> > times, and go into detail on how that would add value.  
> 
> I would only change the packet format, not the way of measuring.
> 
> > 
> > I had a quick look at the spec and did not clearly see whether the
> > protocol could be used at all ... maybe "abused". And being a CTP
> > server one would need to implement more than just "reply". And i do
> > not see any value, except maybe "wireshark support" ... but i am
> > not sure how that would add value. The packets we send are trivial,
> > headers are ethernet and the content does not matter ... so
> > wireshark support is there for all relevant fields.  
> 
> The primary - and probably only - advantage would be that the
> EtherType 0x9000 is officially allocated for CTP, so you don't need
> to use one of the EtherTypes allocated for experimental purposes,
> which might also be used for other purposes.

Yes that is something i thought about as well. In case there would be
some sort of conflict with 88B5 i would rather include some sort of
"magic start" or sub-protocol id if you want.
But until we see such a conflict i would simply stick with 88B5 which
seems to be a good fit, but not "clearly standardized". I would not
envision people running l2reflect on a very busy/big network, as the
results would become increasingly fuzzy and meaningless and other
latency benchmarks would probably be a better fit.

Any confusion with another 88B5 application is "highly unlikely". And
when jumping on 9000 we switch from one "unlikely number" to another
one ... or in fact we are now on one that is "more likely"? From what i
read cisco equipment might start acting on those 9000 packets.

I think a "highly unlikely" conflict does not justify a rewrite. For a
not well defined protocol it would not be a "conflict" really. While
9000 would be "more likely" and dictate a corset to try and fit in.
Even if we can make it fit today, future extensions might not work out.

So i think i would stay away from CTP.

Henning

> The CTP packet format is also trivial:
> 
> The "Request" packet basically contains a SkipCount=0 field followed
> a sequence of 1) a "FORWARD" structure with the MAC address of the
> Request sender, and 2) a "REPLY" structure containing only a receipt
> number (which I guess is like the ID or Sequence Number of an ICMP
> Echo packet).
> 
> The "Reply" packet is the same, but the SkipCount is increased by the
> size of the "FORWARD" structure (i.e. 8 bytes), so the SkipCount
> field now points to the "REPLY" structure.
> 
> 
> Furthermore, the protocol also allows forwarding the packet through
> multiple hops, like MPLS. In that case, the initial packet's sequence
> will contain two or more "FORWARD" structures, and the CTP server on
> each hop will pop the topmost "FORWARD" structure (by updating the
> SkipCount field) and forward the packet to the next hop. However,
> nothing prevents you from also expanding your protocol to also
> multi-hop, if the need for it should arise.
> 
> > 
> > regards,
> > Henning
> >   
> > > There might also be long term perspectives in building on top of a
> > > published (although obsolete) standard - e.g. the protocol could
> > > be revived and become part of the DPDK protocol library, along
> > > with  
> > LACP.  
> > >
> > > On the other hand, it might limit your ability to expand the  
> > protocol.  
> 
> Just wanted to let you know about the existing protocol, so you can
> give it a few thoughts. There are pros and cons.
> 
> I have no personal preferences for CTP vs. your protocol.
> 
> -Morten
>