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 > > On 3/16/2014 7:46 AM, [email protected] wrote: > ... > > 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? > > 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... > > > 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. > > 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'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, > > 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 > > 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! > > > > > > > > > > > > > > > > >
