Sorry, you have to do better than "TLS/HTTPS is slow". Anything over TCP is slow on congested and lossy networks. That's given, but that's hardly a reason to reinvent the whole crypto stack.

How is your protocol superior / faster / better than DTLS with session resuming? Is it faster than IKE in Quick Mode or IKE v2, which are both datagram protocols designed to work over lossy networks? What are the inherent problems with adopting DTLS or IKE to your purposes? This is dead easy to do without touching original crypto design and it instantly removes all questions pertaining to the quality of your crypto design. So why not?

I'm not a professional cryptographer, but I know applied crypto well and I've seen my share of custom crypto designs. Virtually ALL of them are is a result of thinking that it's better and easier to invent something new than to diligently learn what exists and understand how it works. It's fine for some areas, but it is decidedly not a way to go in the cryptography domain.

I'd like to see some papers/surveys/case studies on the matter. Yes, it's an "experiment", doesn't mean it's a good idea to roll out your own implementation before performing (and publishing) extensive tests.

Not saying you're doing something wrong, just that security-oriented people (usually who'd be interested in your product) may want to know more than just "yes guys it's secure, trust us".