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

From: joel jaeggli <[email-masked]>
Date: Thu, 13 Mar 2014 15:22:57 -0700

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.

https://datatracker.ietf.org/doc/draft-masotta-tftpexts-windowsize-opt/

from Martin Stiemerling . The concerns expressed in the IESG review of
the independent stream submission of this document are visible here:

https://datatracker.ietf.org/doc/conflict-review-masotta-tftpexts-windowsize-opt/ballot/311132/

The author  and I have discussed and applied non-normative text to the
document describing how TFTP implementations respond to persistent error
conditions, inclusive of repeated loss. While somewhat different in
effect than traditional implementations of RFC 1350, implementations of
tftp window-size applying behavior consistent with current tftp
implementations and the advice in draft-masotta-tftpexts-windowsize-opt
can be expected to do what tftp implementations do in the the face of
persistent or pathological conditions (which is bail-out) e.g. fail.

diff vs 08 which Martin was shepherding is visble here.

http://tools.ietf.org/rfcdiff?url2=draft-masotta-tftpexts-windowsize-opt-09.txt

While we could revisit the subject of advice that RFC 1350 provides to
implementers with respect to when to bail-out (It doesn't provide any,
nor do subsequent updates) existing lore, mature code and common sense
(in addition to how it is commonly used) have effectively prevented TFTP
from becoming  a menace for more than two decades, a modest extension to
allow transmission queues greater than lock-step transmission for
supporting implementations should not in my view motivate significant
concern but I'd like feedback on that...

Thanks
joel

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 14 Mar 2014 06:50:39 +0000

Hi,

have there been any substantive changes addressing the lack of congestion control? If I recall correctly, that was the critical issue in the past. (The diff at the URL below doesn't seem to do that.)

Lars

---

From: joel jaeggli <[email-masked]>
Date: Fri, 14 Mar 2014 02:36:35 -0700

On 3/13/14, 11:50 PM, Eggert, Lars wrote:
> Hi,
> 
> have there been any substantive changes addressing the lack of
> congestion control? If I recall correctly, that was the critical
> issue in the past. (The diff at the URL below doesn't seem to do
> that.)

The expected response to congestion induced loss (or in fact any other
source of induced loss) across multiple windows is to fail. this is
entirely consistent with  how traditional tftp implementations address
persistent faults. If you treat acks of partial window sized blocks as
non-acks are in lockstep tftp implentations and you have imposed at
threshold after which you will fail then induced loss will cause you to
fail as it does deployed tftp implementations.

>> draft-masotta-tftpexts-windowsize-opt and am looking for some
>> additional review before revisiting the subject of and IETF last
>> call.
>> 
>> document describing how TFTP implementations respond to persistent
>> error conditions, inclusive of repeated loss. While somewhat
>> different in effect than traditional implementations of RFC 1350,
>> implementations of tftp window-size applying behavior consistent
>> with current tftp implementations and the advice in
>> draft-masotta-tftpexts-windowsize-opt can be expected to do what
>> tftp implementations do in the the face of persistent or
>> pathological conditions (which is bail-out) e.g. fail.
>> 
>> implementers with respect to when to bail-out (It doesn't provide
>> any, nor do subsequent updates) existing lore, mature code and
>> common sense (in addition to how it is commonly used) have
>> effectively prevented TFTP from becoming  a menace for more than
>> two decades, a modest extension to allow transmission queues
>> greater than lock-step transmission for supporting implementations
>> should not in my view motivate significant concern but I'd like
>> feedback on that...
>> 
>> Thanks joel
>> 
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 14 Mar 2014 10:43:05 +0000

Hi,

> fail as it does deployed tftp implementations.

I don't quite follow. What is the behavior is some packets of a window are lost, retransmission of the full window? Retransmission of the delta?

In any event, unless the window is shrunk and/or delays before retries are being applied, I don't see anything here that actually reduces the sending rate when loss is detected, which is required.

Lars

---

From: joel jaeggli <[email-masked]>
Date: Fri, 14 Mar 2014 03:50:12 -0700

> In any event, unless the window is shrunk and/or delays before retries are being applied, I don't see anything here that actually reduces the sending rate when loss is detected, which is required.

aborting the transfer is pretty effective at reducing reducing the rate.

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 14 Mar 2014 11:01:22 +0000

> aborting the transfer is pretty effective at reducing reducing the rate.

Where is the abort mechanism specified?

Lars

---

From: Joe Touch <[email-masked]>
Date: Fri, 14 Mar 2014 13:34:18 -0700

Hi, Joel,

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

> 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?)

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

----

---

From: joel jaeggli <[email-masked]>
Date: Sat, 15 Mar 2014 09:20:29 -0700

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

> 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)

> currently don't appear to).

Yes that seems necessary.

---

From: Joe Touch <[email-masked]>
Date: Sat, 15 Mar 2014 11:42:29 -0700

> On 3/14/14, 1:34 PM, Joe Touch wrote:
..
> be happier with examples. (I am aware of some of them)

My basic metric on SHOULD is that it needs to explain the reason for not 
using MUST or MAY. I.e., there's a recommendation here, but not enough 
to be invariant.

If a SHOULD is 'SHOULD do X', that implies there are reasons not to; 
that warrants an explanation.

If a SHOULD is "SHOULD be capable of X", that implies both enough of a 
target that it warrants a described procedure to get there AND reasons 
when this might not be appropriate.

If you don't know enough to answer either of these, then you don't know 
enough to say "SHOULD".

Joe

---

From: <[email-masked]>
Date: Sun, 16 Mar 2014 05:05:34 +0000

I am uncomfortable with independent stream
submissions modifying standards track documents,
and getting published as standards track.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: tsv-area [[email-masked]] On Behalf Of joel jaeggli [[email-masked]]
Sent: 15 March 2014 16:20
To: Joe Touch; [email-masked]; [email-masked]; Martin Stiemerling
Subject: Re: AD sponsoring draft-masotta-tftpexts-windowsize-opt-09

---

From: [email-masked]
Date: Sun, 16 Mar 2014 14:46:42 -0000

I've re-read this document, and I am still puzzled by why the IETF is
considering a standard for this.

Fundamentally this is a simple change. It could be easilly implemented -
many of us already have some simple window-based UDP transfer protocol
like this that we use as a hack for specific cases where something strange
is needed.  However, I do not see a use-case where it is wise to
standardise this - I'd urge the community to re-think this:

First, TFTP is an old protocol, and mostly FTP, NFS, SMB, and others have
replaced this for Internet use over TCP - at least we should acknowledge
that using TFTP in the general Internet is NOT RECOMMENDED  - probablty
one reason why we as a community have not standardised this. This use-case
is not clear, why can FTP over TCP (or at least a minimal TCP) not be
used?

When looked at this before, my take was that this was not a minor change
to the capacity sharing properties of tftp. I still think this is the
case, and the proposal, as written, is unsuitable for use beyond a LAN.

That's not to say that adding a window-based flow/congetstion control
could not be done, but in so-doing this would make TFTP into a protocol
that does not operate with an ACK for each segment, and hence you REALLY
DO NEED to pay attention to the design of the transport protocol.  ... The
comments raised by Lars and Joe hint at some of these issues that would
need to be solved. The IETF does have transport expertise that could help
with this, but the document doen't actually propose any mechansims.

Finally, I don't understand why this it is being considered to update a
transport STD document outside of any working group.  I think, given the
issues involved, that would need a very clear applicability statement.

Gorry

---

Examples of other areas where work is needed:

Please use RFC 2119 laguage to explain how to negotiate the #blocks
between sender or receiver? - usage of RFC 2347 seems not specified.

I believe TFTP has more than 3 Opcodes! The last I counted it had 5,
increased to 6 with RFC 2347.

IANA section incomplete.

Aside: I see from the analysis that more than 50% of the benefit could
alternatively be achieved using a block size of 1024B, I would suggest
that negotiating that wouldn't significantly change any CC or transport
behaviour!

---

From: joel jaeggli <[email-masked]>
Date: Sun, 16 Mar 2014 08:08:56 -0700

> and getting published as standards track.

Agree to the former that's a basis for IESG conflict review, the later
isn't possible under our rules.

In it's present form it is AD-sponsored, so it has been removed from the
independent stream. This was done after conflict review in the IESG
concluded that it conflicted with existing (not ongoing) IETF work.

I doubt there's enough work here to form tftpext-redux, hence my
solicitation of feedback to help the author and provide me with guidance
as to how to proceed.

Thanks
joel

---

From: "ietfdbh" <[email-masked]>
Date: Sun, 16 Mar 2014 13:07:40 -0400

+1

David Harrington
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: tsv-area [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Sunday, March 16, 2014 1:06 AM
> To: [email-masked]; [email-masked]; [email-masked]; tsv-
> [email-masked]; [email-masked]
> Subject: RE: AD sponsoring draft-masotta-tftpexts-windowsize-opt-09
> 
> additional

---

From: Joe Touch <[email-masked]>
Date: Sun, 16 Mar 2014 10:15:02 -0700

On 3/16/2014 7:46 AM, [email-masked] wrote:
...
 > is not clear, why can FTP over TCP (or at least a minimal TCP) not be

It's a much simpler implementation that's often used only for 
bootstrapping, e.g., grabbing images to run at boot time.

While it's not useful to expect it to remain stop-and-go (window=1), 
it's equally not useful to expect the performance of FTP/TCP using TFTP.

However...

 > case, and the proposal, as written, is unsuitable for use beyond a LAN.

AFAIK, that's the primary (or only intended) use of TFTP.

I tend to think of this more like the windowing in NFSv3, but then I 
would have preferred to allow TFTP to allow true pipelining -- which is 
what NFS added, where each request remains independent and individual 
request/response failure would be handled by current rules.

 > that does not operate with an ACK for each segment,

That's what allowing pipelining would effectively achieve, and it would 
leave the rest up to the client side to decide how to manage. That seems 
simpler to me.

Joe

  and hence you REALLY

---

From: [email-masked]
Date: Sun, 16 Mar 2014 18:32:23 -0000

Sure, you could do work to fix this, if this is done in the IETF we need
at least to pay attention to the possibility it could be used in the wider
Internet  - and .. many devices already have a basic TCP stack available
at boot.

Gorry

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 17 Mar 2014 09:42:43 -0500

I'm doing my best not to express an opinion early in the process, but I 
am reading along. Thanks to all for your help.

Gorry made two points that I'd like to ask about, in order to see if I'm 
understanding where we are ...

> case, and the proposal, as written, is unsuitable for use beyond a LAN.

If I'm understanding correctly, the maximum window size (measured in 
blocks) is 32K, up from 1 block in standard TFTP today, so a sender can 
transmit (at the default blocksize of 512 bytes) about 16 megabytes with 
no feedback about path capacity.

Is that the way others are understanding the draft?

> that negotiating that wouldn't significantly change any CC or transport

Again, if I'm understanding the Proof of Concept text correctly, you get 
about 50 percent of the benefit from using a windowsize of 2. The 
benefit seems to max out with a windowsize of something like 8 to 16.

Is that the way others are understanding the draft?

If that's correct, I'm not understanding why anything like 32K would be 
a reasonable maximum. Can anyone cast some light on that?

Thanks,

Spencer

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Mar 2014 07:49:05 -0700

Spencer,

All good questions, but IMO the TSVDIR shouldn't be doing this analysis. 
The authors should, in front of the transport area.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 17 Mar 2014 18:13:07 +0000

> The authors should, in front of the transport area.
This needs more than a TSVDIR review.

>> no feedback about path capacity.
That's what I read.

Gorry

---

From: joel jaeggli <[email-masked]>
Date: Mon, 17 Mar 2014 11:19:30 -0700

> This needs more than a TSVDIR review.

imho I don't really have any intention of subjecting the document or
author to an IETF lc that goes down in flames.  So review is in fact
part of the assumption, but it has to start somewhere.

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Mar 2014 11:20:10 -0700

> On Mar 17, 2014, at 11:13 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> 

Right - the authors should defend /explain in a WG and on the public list. 

Joe

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Mar 2014 19:00:33 -0000

Dave, 

I agree with you, and yet that is not incompatible with AD Sponsored.
"Reviewed and last called by the Foo WG" is not "a product of the Foo WG."

We are usually at this point because the Foo WG either doesn't exist or has
expressed no enthusiasm to adopt and work on the topic.

AD Sponsorship is not, IMHO, contradictory to "reviewed by the IETF community".

Adrian

> From: apps-discuss [mailto:[email-masked]] On Behalf Of Dave
> Thaler
> Sent: 17 March 2014 18:54
> To: joel jaeggli; Joe Touch; [email-masked]; [email-masked]; Martin
> Stiemerling
> Subject: Re: [apps-discuss] AD sponsoring draft-masotta-tftpexts-windowsize-
> opt-09
> 
> >  I'm not very comfortable with AD sponsored standards-track updates.
> 
> +1
> 
> Standards track documents ought to be reviewed by some WG.   For example,
> back
> when I did RFC 2667, it didn't fall into any existing WG, but the AD had it
get
> reviewed
> and last called by the most relevant WG that existed.  I still believe that's
the
> most
> appropriate thing to do, even for things that are nominally "AD sponsored".
> 
> -Dave
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: joel jaeggli <[email-masked]>
Date: Tue, 18 Mar 2014 08:13:25 -0700

> no feedback about path capacity.

having a value that sufficiently extensible that you don't have to come
back and revist it again seems like a sensible premise.

I doubt very much that any application leveraging a larger window is not
also going to implement rfc 2348 block size option. so 512 byte is
probably the wrong assumption

Moving from 512 byte blocks to 1428 byte blocks or 8k blocks if you roll
that way is effectively a 2.8x or 16x increase in the window size.

with zero inter-packet delay (while afaik is not part of this proposal)
a 16MB window would be ~3ms at 40Gb/s  ethernet rates which sounds
totally sensible  if appropiate on the face of it.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 18 Mar 2014 16:00:25 +0000

> totally sensible  if appropiate on the face of it.
That's exactly why this draft would need to provide sound reasoned 
arguments for the choice of mechanisms for error recovery and congestion 
control.

I don't agree that 40 Gb/s non-congestion controlled traffic with 
basically no security or retransmission logic is a good thing for the 
IETF to standardise.

Gorry

---

From: joel jaeggli <[email-masked]>
Date: Tue, 18 Mar 2014 09:14:16 -0700

On 3/16/14, 7:46 AM, [email-masked] wrote:
> is needed.

On the other hand I'm aware of a least two implementations of tftp with
a window scale function. It's maybe in the interests of clients and
server implementations to interoperate.

>  However, I do not see a use-case where it is wise to

I don't really a lot of use cases outside of scoped domains for tftp, I
wouldn't use it on the internet at large, it is however widely
implemented and relatively ubiquitous with respect to usage. devices
need to boot-strap and when they do recourse to an unatheticated  to
resource demand  facility is desirable.

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Mar 2014 10:25:08 -0700

Sorry, all, but as engaging as this discussion is, I really don't think 
we should be having it on this distro.

The authors need to make the case to the TSVWG (?) that this needs to 
become a WG doc, and then we can all scrutinize/optimize it in public.

I propose that we cease further analysis prior to that.

Joe

---

From: joel jaeggli <[email-masked]>
Date: Tue, 18 Mar 2014 11:01:10 -0700

> become a WG doc, and then we can all scrutinize/optimize it in public.

I'm happy to take it there. I agreed to take over AD sponsorship from
Martin, so I am not inclined, nor I imagine is he  (though I will not
speak for him) to go through the vehicle of a TSVWG doc. I am clear on
the need for improvement/review.

> I propose that we cease further analysis prior to that.

wfm
thanks

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Mar 2014 11:07:01 -0700

> the need for improvement/review.

If this isn't headed to become a WG doc, IMO it's dead in the water.

Again, we're talking about a mod to a widely-deployed standards-track 
protocol. That shouldn't happen via AD sponsorship.

Joe

---

From: Barry Leiba <[email-masked]>
Date: Tue, 18 Mar 2014 14:18:47 -0400

Just one bit here that Joel has touched on, but that I want to say clearly:

> The authors need to make the case to the TSVWG (?) that this needs to become
> a WG doc, and then we can all scrutinize/optimize it in public.

1. It's absolutely right to say that &WG (be that TSVWG or any other)
needs to review a document that's being put forth for IETF consensus.

2. It's absolutely right to say that the comments that result from
that review need to be addressed.

3. I believe it is *not* right to say that the document cannot go
forward unless &WG accepts it as a working group product.  If they do,
that's very nice.  If they reject it because of fundamental flaws that
have not been adequately addressed, then loop back to #2.  But if they
simply don't want it, that isn't a valid reason to stop the document
from progressing.

I think we're likely in agreement on this, but, as I say, I want to
put it out there clearly.

Barry

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Mar 2014 11:24:56 -0700

> simply don't want it, that isn't a valid reason to stop the document

Hazard to the Internet?

At the least, it would presumably have a very high hurdle for being 
standards-track.

But I don't understand why a protocol extension that would be considered 
harmful must be published by the RFC Editor.

Joe

---

From: Barry Leiba <[email-masked]>
Date: Tue, 18 Mar 2014 15:14:37 -0400

>> simply don't want it, that isn't a valid reason to stop the document

Hazard to the Internet would be a fundamental flaw that would have to
be addressed, of course.

> harmful must be published by the RFC Editor.

Nothing considered harmful.  I thought I was clear that those things
need to be sorted out.

I'm just saying that lack of interest from some particular working
group isn't a reason to block publication.  Serious flaws, or lack of
interest from everyone... that's different.

Barry

---

From: <[email-masked]>
Date: Tue, 18 Mar 2014 22:01:48 +0000

> simply don't want it, that isn't a valid reason to stop the document

If it's a standalone document, publishing without going through a working group
is perfectly valid.

But this modifies a standards track protocol, and would be published as
standards track. The bar is higher.

Having said that, I think the draft is silly, the appeal was silly, AD
sponsorship is silly. Limited TSVWG resources are better spent elsewhere.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: tsv-area [[email-masked]] On Behalf Of Barry Leiba [[email-masked]]
Sent: 18 March 2014 18:18
To: Joe Touch
Cc: joel jaeggli; [email-masked]; [email-masked]; Martin Stiemerling
Subject: Re: [apps-discuss] AD sponsoring draft-masotta-tftpexts-windowsize-opt-09

Barry

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Mar 2014 10:10:00 -0700

> sponsorship is silly. Limited TSVWG resources are better spent elsewhere.

+1, but our collective private opinion should not affect whether a WG 
sees a doc.

Joe