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

["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.

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