IETF conflict review for draft-masotta-tftpexts-windowsize-opt
conflict-review-masotta-tftpexts-windowsize-opt-01

In full support of Wes' DISCUSS and the response should be "The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval."

In the past, many RFCs have updated RFC 1350 by adding new TFTP Options. All of those drafts have a) explicitly updated 1350, b) been published on the standards track.

Why is this document different from its predecessors?

Given the widespread use of TFTP in bootstrapping devices, and hence its importance to the Internet, I think that this needs to go for IETF review.

I do not think this document conflicts with IETF work.  However, it may be harmful for those using it, and it clearly should not be used across the Internet.

In September, I sent these comments to the ISE, which do not seem to be addressed in the document:
"""
It is definitely missing text about what you do in the case of loss,
and probably completely pathologically broken, as currently written.

I say this because the window size is specified as any chosen value,
without any probing of what the network can actually support.

Further, on losses, the entire window is retransmitted.  So, a single
packet loss (which could be signalling congestion) causes retransmission
of an entire window, and this is going to occur either at line rate or
probably the same rate that the last window was paced out at, which
caused loss.

It sounds like a great way to shoot yourself in the foot while trying
to improve performance!
"""

This is just clearly an unsafe algorithm since it fails to backoff in response
to loss.  An overly aggressive setting will harm other traffic.

At minimum, it should:
1) halve the window size in-use on losses

2) encourage implementation of a "memory" such that if a window size
causes loss, you use a smaller size for subsequent transfers to the
same host

3) make it clear that host buffers can be a constraint on tiny devices
and that part of the TFTP 1-segment benefit is that it greatly simplifies
the resources and memory needed for reordering, etc., as this may be
taking place within a 1st or 2nd stage bootloader.