Bug 1314744 - RFE: Evaluate RFC7440 for tftp
RFE: Evaluate RFC7440 for tftp
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: tftp (Show other bugs)
rawhide
All All
medium Severity low
: ---
: ---
Assigned To: Jan Synacek
Fedora Extras Quality Assurance
https://tools.ietf.org/html/rfc7440
: FutureFeature, Patch, Performance, RFE
Depends On:
Blocks: 1328827
  Show dependency treegraph
 
Reported: 2016-03-04 06:43 EST by Noel McLoughlin
Modified: 2016-04-20 08:02 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1328827 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch-v1 (20.95 KB, patch)
2016-04-06 09:54 EDT, Jan Synacek
no flags Details | Diff

  None (edit)
Description Noel McLoughlin 2016-03-04 06:43:55 EST
Description of problem:

** I could not find a duplicate bug. **

I was wondering if RFC7440 (TFTP Windowsize Option) will be supported as it offers performance improvements over RFC2348 (TFTP blocksize option).  Image transfer time is quite slow but traditionally rom images are quite small.

- With BIOS, pxelinux.0 is only circa 27K in size.
- With uEFI, the images are getting bigger: shim.efi (1.3M), grubx86.efi (986K)

There is no sign of TFTP becoming obsolete in cloud/IoT era.



Version-Release number of selected component (if applicable):
N/A

How reproducible:
N/A

Steps to Reproduce:
N/A

Actual results:
Slow PXE/TFTP transfer times for larger uEFI images.

Expected results:

Most likely we configure '--windowsize nnn' server argument on daemon. 

service tftp
{
    socket_type	= dgram
    protocol	= udp
    wait	= yes
    user	= root
    server	= /usr/sbin/in.tftpd
    server_args	= -s /var/lib/tftpboot --blocksize 1478 --windowsize nnnn
    disable	= no
    per_source	= 11
    cps		= 100 2
    flags	= IPv4
}

I understand IPv6 has some efficiencies over IPv4 but I think the option would be required as IPv6 network boot becomes more established.

service tftp
{
    socket_type	= dgram
    protocol	= udp
    wait	= yes
    user	= root
    server	= /usr/sbin/in.tftpd
    server_args	= -s /var/lib/tftpboot --blocksize 1478 --windowsize nnnn
    disable	= no
    per_source	= 11
    cps		= 100 2
    flags	= IPv6
}


Additional info:
Comment 2 Jan Synacek 2016-04-04 04:35:22 EDT
Looks like a valuable addition. I'll take a look at it.
Comment 3 Jan Synacek 2016-04-06 09:50:41 EDT
There seems to be a misunderstanding in how the reporter understands the --blocksize (and subsequently the suggested --windowsize) addition. The --blocksize specifies the *maximum allowed* blocksize, should there be any request for the blocksize TFTP option (see RFC2348). The blocksize (or windowsize) option itself is always present in the initial read/write request packet. Therefore, no additional option will be added to the server parameters, but the server will be improved to also understand the windowsize TFTP option, as specified in RFC7440.
Comment 4 Jan Synacek 2016-04-06 09:54 EDT
Created attachment 1144234 [details]
patch-v1

Implement RFC7440 in both server and the client.

This needs a lot of testing! Especially on error conditions and duplicate packets.

Note that the client improvement was a bit forced, since it hadn't implemented any TFTP options before. It still uses the default TFTP blocksize of 512.
Comment 5 Jan Synacek 2016-04-06 09:55:56 EDT
The patch was created against the current F24 (and rawhide, they are the same) code base.
Comment 7 Jan Synacek 2016-04-07 02:53:31 EDT
I've created builds for F24 and F25 that can be downloaded from:
https://jsynacek.fedorapeople.org/tftp/f24/
https://jsynacek.fedorapeople.org/tftp/f25/
Comment 8 Noel McLoughlin 2016-04-20 08:02:03 EDT
Kudos for the fast analysis and turnaround. Unfortunately I not be able to test his (no time) but hopefully wider Fedora community will pick this up.

Note You need to log in before you can comment on or make changes to this bug.