On 18/03/2014 15:13, joel jaeggli wrote:
On 3/17/14, 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.
having a value that sufficiently extensible that you don't have to come
back and revist it again seems like a sensible premise.
I doubt very much that any application leveraging a larger window is not
also going to implement rfc 2348 block size option. so 512 byte is
probably the wrong assumption
Moving from 512 byte blocks to 1428 byte blocks or 8k blocks if you roll
that way is effectively a 2.8x or 16x increase in the window size.
with zero inter-packet delay (while afaik is not part of this proposal)
a 16MB window would be ~3ms at 40Gb/s ethernet rates which sounds
totally sensible if appropiate on the face of it.
That's exactly why this draft would need to provide sound reasoned
arguments for the choice of mechanisms for error recovery and congestion
control.
I don't agree that 40 Gb/s non-congestion controlled traffic with
basically no security or retransmission logic is a good thing for the
IETF to standardise.
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
