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