IETF Logo Mail Archive

Re: AD sponsoring draft-masotta-tftpexts-windowsize-opt-09

joel jaeggli <joelja@bogus.com> Sat, 15 March 2014 16:20 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC661A00C3; Sat, 15 Mar 2014 09:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcazxMfLK8Rt; Sat, 15 Mar 2014 09:20:43 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 383C31A00B9; Sat, 15 Mar 2014 09:20:43 -0700 (PDT)
Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s2FGKYll005878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 15 Mar 2014 16:20:35 GMT (envelope-from joelja@bogus.com)
Message-ID: <53247DCD.40002@bogus.com>
Date: Sat, 15 Mar 2014 09:20:29 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>, apps-discuss@ietf.org, tsv-area@ietf.org, Martin Stiemerling <martin.stiemerling@neclab.eu>
Subject: Re: AD sponsoring draft-masotta-tftpexts-windowsize-opt-09
References: <53222FC1.7040009@bogus.com> <532367CA.4080807@isi.edu>
In-Reply-To: <532367CA.4080807@isi.edu>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="qfc0eKNiP28NSWgQ1KoXTDo9EiqaNren3"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sat, 15 Mar 2014 16:20:35 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/tsv-area/6-7LmrVDwIgHgewvoUesQGbxLpU
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area/>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Mar 2014 16:20:45 -0000

On 3/14/14, 1:34 PM, Joe Touch wrote:
> Hi, Joel,
> 
> On 3/13/2014 3:22 PM, joel jaeggli wrote:
>> Greetings,
>>
>> I have taken on the AD sponsorship of
>> draft-masotta-tftpexts-windowsize-opt and am looking for some additional
>> review before revisiting the subject of and IETF last call.
>
> FWIW, this ought to be vetted in a broader venue, e.g., TSVWG. I'm not
> very comfortable with AD sponsored standards-track updates.

This is very useful feedback.

The process that got this  thing from an independent stream submission
in iesg conflict review to where we are today is  somewhat torturous,
that's why I'm asking.

>> https://datatracker.ietf.org/doc/draft-masotta-tftpexts-windowsize-opt/
> 
> A quick check indicates a few disconnects, summarized below.
> 
> Joe
> 
>> Congestion and Error Control
>>
>>    From a congestion control standpoint while the number of blocks in
>>    a window does not represent a threat,
> 
> The entirety of TCP's congestion control is about managing the window
> size; the same is true here. Increasing the window absolutely increases
> the potential for congestion and represents a threat.
> 
> The doc includes a number of SHOULDs that are underspecified, e.g.,
> SHOULD implement a timeout on retransmissions (what value?), and SHOULD
> abort (under what conditions?)

I sympathize with the authors lack of desire to specify specific values
which may be appropriate now but not into the future. That said. I would
be happier with examples. (I am aware of some of them)


> How are retransmissions handled? Go-back-N is known problematic; SACK
> requires a much more complex mechanism.
> 
> The document should also request that IANA register "windowsize" as the
> TFTP option string (and IANA should have a registry of these - they
> currently don't appear to).

Yes that seems necessary.

> 
> ----
>

v2.23.0 | Report a Bug | By Email