XMIT and Ethernet

[dwis...@gmail.com]

I read the XMIT spec with some interest.  As always, I hate to pay the overhead of a 64-bit identifier, but I understand your reasoning.  I have a thought: for network packets, what if you packaged XMIT in a raw Ethernet Frame, using a unique EtherType field?  That will save you more than 64-bits when you eliminate the IP and UDP headers, which your UUID supplants anywise.  

Unicast, Multicast and Broadcast are all supported at the Ethernet level so switches and routers can do what you need with non-IP EtherTypes.  While I will not use them, others can even use VLAN's and Q-in-Q, because they are, once again, Ethernet concepts.  

Where you feel you are best served by TCP, you probably are not working towards the lowest latency anywise, and if latency becomes an issue you can implement a TCP-lite protocol within your own EtherType, which could just add a byte-count and ACK mechanism with a few optimizations that do not exist in the TCP protocol.

This scheme would give you all the flexibility you want while lowering the time required to process packets.  At 10 Gbps you receive 64 bits every 6.4 ns, so the savings add up fast if you move the interesting data 256 bits or 25.6 ns closer to the beginning of the packet.  This assumes, of course, that you do cut-through processing of the incoming data before the FCS arrives and cancel the rare bad packet later, but everyone should be doing that anywise if they are concerned with lowering their latency.

I watch your progress with much interest,

Daniel

[Anders Furuhed]

Hi Daniel, very interesting.

Rolf is planning to do some experiments around this.

On an IP perspective, I have been thinking along the lines of http://tools.ietf.org/html/draft-tschofenig-hourglass-00:

The waist of the hourglass has changed over time: new applications
have to run on top of UDP or TCP. Protocol designs that use other
transport protocols have turned out to be undeployable on the public
Internet. Running protocols on bare IP is also doomed to fail. This
change is not theoretic in nature but has real-world implications for
protocol designers.

We should think of relating an Ethernet approach to workflows where working directly on top of Ethernet is helpful. An Ethernet based solution would obviously not violate the above requirement as it is below IP.

Kind Regards,

Anders