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. > 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 >
signature.asc
Description: OpenPGP digital signature
