Subject: Draft Review request - EUDP

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 01 Dec 2010 13:25:45 +0200

Hello all,

I have recently made a draft which, IMO, will be interesting
for the WG. You can find it here:

http://datatracker.ietf.org/doc/draft-yevstifeyev-eudp/?include_text=1

Could you please review it?

Any suggestions for improvement are welcome.

All the best,
Mykyta Yevstifeyev

---

From: Lars Eggert <[email-masked]>
Date: Wed, 1 Dec 2010 13:52:39 +0200

Hi,

> Could you please review it?

This is not a useful proposal. Why? UDP is IP plus ports and a checksum. There is no feature negotiation, no state machine to be extended, etc. *at the protocol level*.

(Sure, applications using UDP have these things. But they can *already* put whatever they like into the payload anyway. There is no need for a common spec.)

Plus, by using a different IP protocol number, it is pretty much guaranteed that middleboxes will simply drop this traffic.

Lars

PS: Meta comment: You have submitted quite a number of IDs lately (http://tools.ietf.org/id/yevstifeyev). I really do applaud your enthusiasm. But the vast majority of your IDs to me appear to be rather pointless. I encourage you to follow some WGs that interest you most more closely, in order to learn where your contributions would be most useful. I'm being blunt here - please don't be offended. I don't want you to turn away from the IETF in frustration because your contributions don't get traction; I want your contributions to matter.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 01 Dec 2010 16:29:43 +0200

> This is not a useful proposal. Why? UDP is IP plus ports and a checksum. There is no feature negotiation, no state machine to be extended, etc. *at the protocol level*.
IMO (and this is the main purpose of the EUDP) if some feature concerns 
any protocol or data which is to be put into payload of the protocol of 
some layer, the corresponding option should be put in 'this-layer' 
protocol header. Moreover, UDP provides core service while TCP or DCCP 
provide many features which can be just not needed. EUDP can provide (or 
not provide) any features except core ones.
It is made to provide the choice of features.
> Plus, by using a different IP protocol number, it is pretty much guaranteed that middleboxes will simply drop this traffic.
Why do you think that if there is unknown protocol code the traffic will 
be dropped? Currently there are 142 IP Protocol umbers and near 10 are 
really used. Will you prove that other 132 are being dropped?
> PS: Meta comment: You have submitted quite a number of IDs lately (http://tools.ietf.org/id/yevstifeyev). I really do applaud your enthusiasm. But the vast majority of your IDs to me appear to be r…
Thank you for advice.

I hope I have explained everything clearly.

All the best,
Mykyta Yevstifeyev

---

From: David Borman <[email-masked]>
Date: Wed, 1 Dec 2010 10:10:42 -0600

On Dec 1, 2010, at 8:29 AM, Mykyta Yevstifeyev wrote:

> IMO (and this is the main purpose of the EUDP) if some feature concerns any protocol or data which is to be put into payload of the protocol of some layer, the corresponding option should be put in 'this-layer' protocol header. Moreover, UDP provides core service while TCP or DCCP provide many features which can be just not needed. EUDP can provide (or not provide) any features except core ones.

I read the document, and adding option space to UDP is not interesting if you don't also have at least one useful option defined at the same time.  There is no motivation to implement this with just the NOP and EOL options.  In addition, as Lars points out, UDP does not have a state machine.  This means that adding any new option will require that the option can either be safely ignored, or negotiation needs to be added to the option itself.  That implies potentially sending UDP packets with just options, and no data.  Or the applications have to do the option negotiation.

So, yes, if you want to add options to UDP, this would be a way to do it, but first you need to have at least one useful option to make use of the new mechanism.

> Why do you think that if there is unknown protocol code the traffic will be dropped? Currently there are 142 IP Protocol umbers and near 10 are really used. Will you prove that other 132 are being dropped?

Middle boxes that filter traffic tend to first block everything and then only allow through things that they understand, otherwise if they let through unknown traffic it provides a wide-open door for the middle box to be circumvented.

			-David Borman