Re: Draft Review request - EUDP

[David Borman <[e-mail]>]

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

> 01.12.2010 13:52, Lars Eggert wrote:
>> Hi,
>> 
>> On 2010-12-1, at 13:25, Mykyta Yevstifeyev wrote:
>>> 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?
>> 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.

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.

>> (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.
> 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

>> 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.
> Thank you for advice.
> 
> I hope I have explained everything clearly.
> 
> All the best,
> Mykyta Yevstifeyev