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