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. > > Lars > > On 2014-3-13, at 23:22, joel jaeggli <[email protected]> wrote: > >> 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 >> >
signature.asc
Description: OpenPGP digital signature
