> On Mar 17, 2014, at 11:13 AM, Gorry Fairhurst <[email protected]> wrote: > > >> On 17/03/2014 14:49, Joe Touch wrote: >> Spencer, >> >> All good questions, but IMO the TSVDIR shouldn't be doing this analysis. >> The authors should, in front of the transport area. > This needs more than a TSVDIR review.
Right - the authors should defend /explain in a WG and on the public list. Joe > >> Joe >> >>> On 3/17/2014 7:42 AM, Spencer Dawkins wrote: >>> I'm doing my best not to express an opinion early in the process, but I >>> am reading along. Thanks to all for your help. >>> >>> Gorry made two points that I'd like to ask about, in order to see if I'm >>> understanding where we are ... >>> >>>> On 03/16/2014 09:46 AM, [email protected] wrote: >>>> 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. >>> >>> If I'm understanding correctly, the maximum window size (measured in >>> blocks) is 32K, up from 1 block in standard TFTP today, so a sender can >>> transmit (at the default blocksize of 512 bytes) about 16 megabytes with >>> no feedback about path capacity. > That's what I read. > >>> Is that the way others are understanding the draft? >>> >>>> 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! >>> >>> Again, if I'm understanding the Proof of Concept text correctly, you get >>> about 50 percent of the benefit from using a windowsize of 2. The >>> benefit seems to max out with a windowsize of something like 8 to 16. >>> >>> Is that the way others are understanding the draft? >>> >>> If that's correct, I'm not understanding why anything like 32K would be >>> a reasonable maximum. Can anyone cast some light on that? >>> >>> Thanks, >>> >>> Spencer > > Gorry
