Re: Draft Review request - EUDP

Mykyta Yevstifeyev <evnikita2@gmail.com> Sun, 02 January 2011 10:57 UTC

Return-Path: <evnikita2@gmail.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743263A6956 for <tsvwg@core3.amsl.com>; Sun, 2 Jan 2011 02:57:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.268
X-Spam-Level:
X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1anhem30VRs for <tsvwg@core3.amsl.com>; Sun, 2 Jan 2011 02:57:09 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 9DF0B3A6953 for <tsvwg@ietf.org>; Sun, 2 Jan 2011 02:57:08 -0800 (PST)
Received: by bwz12 with SMTP id 12so12907784bwz.31 for <tsvwg@ietf.org>; Sun, 02 Jan 2011 02:59:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bmDzveAWebZmHtvOnUAjRvMi2vFX0IOKnckakw1mY6A=; b=k/TNmBtfZfjwMhSzVJzroIF8F3VPbJh7ls/YREI78IxaXRUGbGYSwMxA1n3py8Qgjf shYUqn94xlLNlv4VH808dvFQ4tn4UFirT15fD4pPXSjN93KVW6WaoHJDVS0YgTXzo4j0 9pbBjno10FUX4BvmgyO1FfT7wANy0HdFDP7Os=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=hZSQWtdbfRiJeqWX9Y2ms4rP3I8bCAf+7qeFChtgbF3an+cfftdI5+J3Yk5HGjgi8N c1kUIuttZva7PrZLwCDEW6a59wY+sv1Mnl0qJDXG+yy+Nzd2pUaS3Ii67XLSi4C9PVJJ 6E6qDii61WSkEkU+iNCpvfkjqCKV4H9Vb4pYk=
Received: by 10.204.53.148 with SMTP id m20mr7894917bkg.150.1293965953122; Sun, 02 Jan 2011 02:59:13 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id a17sm10894742bku.23.2011.01.02.02.59.09 (version=SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 02:59:11 -0800 (PST)
Message-ID: <4D205A8F.3060206@gmail.com>
Date: Sun, 02 Jan 2011 12:59:27 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: David Borman <dab@weston.borman.com>
Subject: Re: Draft Review request - EUDP
References: <4CF630B9.2070901@gmail.com> <C23D4465-516D-4150-A3EC-8AF7E21E084B@nokia.com> <4CF65BD7.20304@gmail.com> <2C2B9319-37F5-478C-B2E8-5B4EB0223D47@weston.borman.com>
In-Reply-To: <2C2B9319-37F5-478C-B2E8-5B4EB0223D47@weston.borman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Jan 2011 10:57:10 -0000

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
>