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!
