Subject: Re: Draft Review request - EUDP

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 02 Jan 2011 12:59:27 +0200

Hello all,

Now, almost after the month, I am ready to comment some issues we were 
discussing about EUDP (that is 
http://tools.ietf.org/html/draft-yevstifeyev-eudp-04). So, please find 
some comments below...

01.12.2010 18:10, David Borman wrote:
> 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.
David, now I have added a few options that, IMO, would be quite useful 
for possible users. So, they are: Echo request and response (see 
http://tools.ietf.org/html/draft-yevstifeyev-eudp-04#section-2.3.2.3) 
and (maybe the most important) Packet ID and Packet Acknowledgment (see 
http://tools.ietf.org/html/draft-yevstifeyev-eudp-04#section-2.3.2.5). 
These two provide the possibility to request the acknowledgment of 
single, unit packet. For more detailed analysis of this packet ACKs 
mechanism can be found at 
http://tools.ietf.org/html/draft-yevstifeyev-eudp-04#section-2.5 .
>>> (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.
I really do not understand why do you think so. What danger could the 
traffic with unknown protocol cause? And if it is e. g. 253 or 254 
(experimentation), middleboxes definitely can't know what protocol is 
used. In this occasion they will ignore that traffic, you think?
> 			-David Borman
Waiting for other comments.

All the best,
Mykyta Yevstifeyev
>>> 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
>