On 3/17/14, 11:13 AM, Gorry Fairhurst 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.
imho I don't really have any intention of subjecting the document or author to an IETF lc that goes down in flames. So review is in fact part of the assumption, but it has to start somewhere. >> 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 >
signature.asc
Description: OpenPGP digital signature
