[ipxe-devel] tftp windowsize RFC 7740

[James Harper]

> From: Gene Cumm [mailto:gene.cumm at gmail.com]
> Sent: Thursday, 3 December 2015 10:32 PM
> Subject: Re: [ipxe-devel] tftp windowsize RFC 7740
> 
> On Thu, Dec 3, 2015 at 5:28 AM, James Harper <james at ejbdigital.com.au>
> wrote:
> > Is anyone working on implementing rfc 7740 tftp windowsize into ipxe?
> >
> > https://tools.ietf.org/html/rfc7440
> >
> > the rfc includes some observed speedup times which are quite impressive.
> 
> I can't say if anyone is looking at implementing such but I could
> offer some other information.
> 
> Such an option requires both sides to cooperate.  If a tftpd didn't
> use it, I believe it would require another attempted option
> negotiation, mildly slowing things down.  iPXE would probably need to
> default to not using it UNLESS set in a run-time script.  I'm left to
> assume the tftpd that Patrick works on is probably the only one that
> implements this (yet)

I have a custom TFTP server, and a windows kernel driver, and some custom ipxe code (makes use of existing ipxe tftp), and I'm basically using TFTP as a SAN protocol.

So my TFTP server supports it, my windows driver supports it, but ipxe doesn't. yet. I will add the code at some point, but just wanted to make sure I wasn't duplicating effort.

> It seems commonplace in the Microsoft WDS realm to use a larger TFTP
> blocksize and generate multiple IP fragments in order to accelerate
> transfers of large files.  I've seen many PXE clients that can deal
> with this.  I'm all but certain all of the systems in our environment
> work well this way with a TFTP blocksize of 4096 and 8192.  On the
> other hand, I've been dealing with clients recently that can't deal
> with the IP fragments being delivered out of order while having some
> that can.

Yeah Microsoft seems to cheat in a few places. I've thought about this sort of thing too to get some additional speed.

> 
> The more impressive part that Patrick didn't demonstrate is how using
> TFTP windowsize or IP fragments shows greater benefit on links with
> higher round trip latencies.
> 

Yes. That's not my use case though :)

Thanks

James