TFTP Windowsize Option
RFC 7440

Received changes through RFC Editor sync (changed abstract to 'The "Trivial File Transfer Protocol" (RFC 1350) is a simple, lockstep, file transfer protocol that allows a client to get or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a Local Area Network (LAN). TFTP has been used for this application because it is very simple to implement. The employment of a lockstep scheme limits throughput when used on a LAN.

This document describes a TFTP option that allows the client and server to negotiate a window size of consecutive blocks to send as an alternative for replacing the single-block lockstep schema. The TFTP option mechanism employed is described in "TFTP Option Extension" (RFC 2347).')

[Ballot discuss]
[updated based on -12]

I have those points to be discussed, while being supportive to get TFTP transmitted files faster.

1) cleared.

2) Updated: It is not clear to me how this extension is reacting to all kinds of packet loss. Right now, it assumes sporadic losses that require a retransmission of a single or a few packets. However, more heavily losses that require an action from the data sender are not covered. Such a heavily loss could be due to congestion on the network path between both TFTP peers.
In short, it doesn't make sense to keep sending large windows, if the network path is congested.
However, I am also sympathizing with the circuit break idea, but I would to get my point 5 **really** addressed first to discuss this.

3) moved to comments section.

4) cleared.

5) Updated:
Please update the formerly Section 6, now Section 4. to define what the acknowledgment mechanism is, including the difference to the currently defined acknowledgment mechanism. Right now, the Section is just describing one error situtation, but not the ack mechanism. It is not enough to point to an example figure in order to define normative behavior in a standards document.

[Ballot comment]
What is the error handling for this (Section 3, last paragraph):
"  The rules for determining the final packet are unchanged from
  [RFC1350] and [RFC2348].
  The reception of a data window with a number of blocks less than the
  negotiated windowsize is the final window. If the windowsize is
  greater than the amount of data to be transferred, the first window
  is the final window."

You receive a data window with a number of blocks less than the negotiated window but no packet that is shorter than the negotiated block size?

[Ballot comment]
Thank you for addressing my Discuss point.

I had one sentence in my proposed text that I didn't see in -12, that I wish was in there:

“The windowsize extension is intended for use in managed networks, where any
instances of sustained congestion loss will be noticed and corrected."

But the text you did use is sufficient to resolve the Discuss.

[Ballot comment]
One editorial suggestion in section 3:

OLD
  MUST be ASCII strings followed by a single-byte NULL character.
NEW
  MUST be ASCII strings terminated by a single-byte NULL character.

[Ballot discuss]
[updated according to the discussions during the telechat]

I have those points to be discussed, while being supportive to get TFTP transmitted files faster.

1) Waiting for an update of the draft to include Spencer's proposed text.
This document must clearly state that this extension in its current state is solely suitable for well-mananged and monitored environments, but that it is not suitable to be used across the Internet or any unmanaged IP network. An example for a well-managed and monitored environment is a data center network.
The reason for this is that there now back off mechanisms defined to loss.

2) It is not clear to me how this extension is reacting to all kinds of packet loss. Right now, it assumes sporadic losses that require a retransmission of a single or a few packets. However, more heavily losses that require an action from the data sender are not covered. Such a heavily loss could be due to congestion on the network path between both TFTP peers.
In short, it doesn't make sense to keep sending large windows, if the network path is congested.
My proposal is to half the window-size on losses and potentially, depending on the desired compelixty, to allow an increase of the window size if there is no loss experienced anymore.
However, I am also sympathizing with the circuit break idea, but I would to get my point 6 addressed first to discuss this.

3) What is the error handling for this (Section 3, last paragraph):
"  The rules for determining the final packet are unchanged from
  [RFC1350] and [RFC2348].
  The reception of a data window with a number of blocks less than the
  negotiated windowsize is the final window. If the windowsize is
  greater than the amount of data to be transferred, the first window
  is the final window."

You receive a data window with a number of blocks less than the negotiated window but no packet that is shorter than the negotiated block size?

4) It is not clear to me, if the sender is sending a full window out to the network and waits for the successful transmission of the window (or any error), or if the sender keeps constanly sending out new packets, once it does receive an acknowledgment for a non-terminal packet? This relates to the below question 5).

5) TFTP is acknowledging each non-terminal packet. I assume this behavior is unchanged also for this extension? If so, smaller windows that slide by each acknowledgment are a nice option to behave well in the network. Especially, as the test results show already a good performance gain with a window size of 8.
Please update Section 6 to define what the acknowledgment mechanism is, including the difference to the currently defined acknowledgment mechanism. Right now, the Section is just describing one error situtation, but not the ack mechanism.

[Ballot comment]
Thanks for your work on this draft.  Since the draft is an extension, I'll move my discuss points to a "No Objection".  The reasons for the discuss was the way in which the Security Considerations section was written.  It was written with the full text that you'd expect to see in the TFTP RFC itself as opposed to a pointer to that section and a statement that no additional considerations are added.  If the text stays in the draft, I'd really like to see the considerations include the lack of both authentication and integrity protections.

I'm copying my proposed text here so you have it in an easy to access place and do appreciate that you have already agreed to change out 'login' for 'authentication'.  I am fine with you leaving out confidentiality (although there are no protections if there were any concerns along those lines).  The same idea is covered in the second change proposed.

Security Considerations section:

Propose the following change to the first sentence:
From: "TFTP includes no login or access control mechanisms."
To: "TFTP includes no authentication, integrity protection, confidentiality, or access control mechanisms."

Propose text for the first sentence of second paragraph:
From: "TFTP includes no protection against an on-path attacker, care must be
  taken in controlling windowsize values according to provider,
  requester, and network environment capabilities. "
To: "TFTP also does not support session encryption and therefore does not protect against an on-path attacker from active (session hijacking) or passive (monitoring) attacks.  Care must be
  taken in controlling windowsize values according to provider,
  requester, and network environment capabilities. "

I think it's enough to just list monitoring as an example as with TFTP, as it's likely to be a targeted attack and unlikely to be privacy related since it is typically used to do things like update firmware on a local network, etc.  Those attacks fit into the general category of monitoring.

Thank you for addressing the comments received in the SecDir review.  From the SecDir review, there was a recommendation to include other references in the the security considerations section of this document.  One of those was from RFC5405.  The first paragraph of that section (altered a bit) could be helpful in the set of warnings given here - basically, use something else if you need any security.  I don't think the rest really applies because you'd switch to SFTP or something else rather than layer on security to TFTP in reality.

Here is a link to the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg04922.html

[Ballot comment]
I support Spencer Dawkin's current Discuss, and Martin's Discuss item #1. I am sympathetic to the change that Kathleen proposes, although it is perhaps more with TFTP than this extension. Finally, I'm also sympathetic to Ted's issue, but I think it is easily fixable.

Some comments. These are all comments, something you might consider but none of the issues are serious enough to block the document. Fixing them might improve readability, however.

  Note that all fields
  except "opc" MUST be NULL-terminated.

  +-------+---~~---+---+---~~---+---+-----~~-----+---+---~~---+---+
  |  opc  |filename| 0 |  mode  | 0 | windowsize | 0 | #blocks| 0 |
  +-------+---~~---+---+---~~---+---+-----~~-----+---+---~~---+---+

I thought this was a bit unclear, should I include a zero byte in the windowsize field for instance, or is the zero byte the one in above diagram already? One or two zero bytes.

  The number of blocks in a window MUST be specified in ASCII.

MUST be specified in decimal in ASCII.

  The rate at
  which TFTP UDP datagrams are sent SHOULD follow the CC guidelines in
  Section 3.1 of RFC 5405 [RFC5405].

It would be REALLy helpful if you pointed directly to the one that should be implemented, e.g., Section 3.1.1. Which I think is the right one.

[Ballot comment]
Some comments. These are all comments, something you might consider but none of the issues are serious enough to block the document. Fixing them might improve readability, however.

  Note that all fields
  except "opc" MUST be NULL-terminated.

  +-------+---~~---+---+---~~---+---+-----~~-----+---+---~~---+---+
  |  opc  |filename| 0 |  mode  | 0 | windowsize | 0 | #blocks| 0 |
  +-------+---~~---+---+---~~---+---+-----~~-----+---+---~~---+---+

I thought this was a bit unclear, should I include a zero byte in the windowsize field for instance, or is the zero byte the one in above diagram already? One or two zero bytes.

  The number of blocks in a window MUST be specified in ASCII.

MUST be specified in decimal in ASCII.

  The rate at
  which TFTP UDP datagrams are sent SHOULD follow the CC guidelines in
  Section 3.1 of RFC 5405 [RFC5405].

It would be REALLy helpful if you pointed directly to the one that should be implemented, e.g., Section 3.1.1. Which I think is the right one.

[Ballot discuss]
I don't know how to implement this based on the spec as written.  In particular, the meaning of the error markers in the error handling section is completely obscure to me.  I've been reading this document and the ones it references over and over again trying to figure out what this means, and maybe I'm just stupid, but I don't get it.  Please describe explicitly what these error marks mean, and what is done in response to them.  I am not convinced that updating the document to explain this will completely resolve this DISCUSS, because I literally do not know what I am missing, but I think it would be a good first step.

[Ballot comment]
I agree that in addition to or instead of specifying where it *is* appropriate to use this extension, the document should say where it's *not* appropriate.

[Ballot comment]

Section 7 says: "The use of TFTP is appropriate on networks
where the inherent protocol limitations are not a liability."
I think that would be better as a negative myself, e.g. maybe
something like "The use of TFTP is inappropriate on networks
where confidentiality, authentication or access control are
needed." (And note that I personally don't think that that
means TFTP is safe on all LANs.) However, just deleting the
sentence would be fine, since it has little or nothing to do
with this extension. Note: I don't feel that strongly about
this, so feel free to ignore me.

Nothing to do with this draft, but it would be a fine thing
if someone were interested doing the work to improve the
security of TFTP.

[Ballot comment]
I support point #1 in Martin's DISCUSS. I don't think saying where the protocol is currently used or not is the same as saying where it should not be used. And the reasons it should not be used on some networks are not confined to security, so I don't think the security considerations section should be the only place where this is discussed.

[Ballot discuss]
Thank you, Patrick and Joel, for our pre-ballot conversation. It was helpful, and short-circuited a number of points that didn't need to be part of a DIscuss.

And for the record, I’m sympathetic to a desire to decrease boot times in the 21st century, and something like this proposal seems a reasonable way to satisfy that desire.

My original Discuss would have overlapped Martin’s significantly, so I’m downsizing to a couple of points that I’d like to talk about, to avoid duplication.

First (as my Discuss point) - as Joel has stated in various emails, this document does contain a significant number of “health warnings” about where TFTP is appropriate to use, but they are tilted toward (very real) security concerns. I’d suggest text that also points to concerns about congestion behavior. Perhaps something like this, in Section 4:

“The windowsize extension is intended for use in managed networks, where any instances of sustained congestion loss will be noticed and corrected. The choice of an appropriate windowsize value depends on the underlying networking technology and topology, and likely other factors as well. This document does not make recommendations for a specific value, and it allows the operator considerable flexibility, with a maximum windowsize of 65535 blocks. Operators are encouraged to test various values, as shown in Section 5. Operators are encouraged to be conservative when selecting a windowsize, because as the table and chart in Section 5 shows, the benefit of continuing to increase the windowsize is subject to diminishing returns. Operators are encouraged to consider the possibility of events such as power-on/avalanche restarts, when a large number of clients may issue Read Requests to reboot within a small interval of time.”

I think I'm capturing points that we've chatted about in e-mail already, But please rephrase as appropriate.

[Ballot comment]
Second - and I emphasize this is a question, not an assertion - I keep hearing about distributed multi-tenant data centers, where a data center operator might rehome a significant number of virtual machines from one data center to another that’s an arbitrary distance away. Is that a real possibility?

The reason I’m guessing that using this extension with large windowsize values would be significantly safer in the same rack than on opposite coasts, and I’m curious what a good strategy would be for an operator to either know that the clients have been moved, or to prevent the clients from being moved while the TFTP server stays.

[Ballot discuss]
I have those points to be discussed, while being supportive to get TFTP transmitted files faster.

1)
This document must clearly state that this extension in its current state is solely suitable for well-mananged and monitored environments, but that it is not suitable to be used across the Internet or any unmanaged IP network. An example for a well-managed and monitored environment is a data center network.
The reason for this is that there now back off mechanisms defined to loss.

2) It is not clear to me how this extension is reacting to all kinds of packet loss. Right now, it assumes sporadic losses that require a retransmission of a single or a few packets. However, more heavily losses that require an action from the data sender are not covered. Such a heavily loss could be due to congestion on the network path between both TFTP peers.
In short, it doesn't make sense to keep sending large windows, if the network path is congested.
My proposal is to half the window-size on losses and potentially, depending on the desired compelixty, to allow an increase of the window size if there is no loss experienced anymore.

3) What is the error handling for this (Section 3, last paragraph):
"  The rules for determining the final packet are unchanged from
  [RFC1350] and [RFC2348].
  The reception of a data window with a number of blocks less than the
  negotiated windowsize is the final window. If the windowsize is
  greater than the amount of data to be transferred, the first window
  is the final window."

You receive a data window with a number of blocks less than the negotiated window but no packet that is shorter than the negotiated block size?

6) It is not clear to me, if the sender is sending a full window out to the network and waits for the successful transmission of the window (or any error), or if the sender keeps constanly sending out new packets, once it does receive an acknowledgment for a non-terminal packet?

5) TFTP is acknowledging each non-terminal packet. I assume this behavior is unchanged also for this extension? If so, smaller windows that slide by each acknowledgment are a nice option to behave well in the network. Especially, as the test results show already a good performance gain with a window size of 8.

[Ballot comment]
- Section 5:
" Comparatively the same 180 MB transfer performed over an SMB/CIFS
  mapped drive on the same scenario took 23 seconds."

Well, that is comparing two different things, as TFTP is running over UDP and with lock step or your extension and a control-loop based transport used for SMB/CIFS.

[Ballot comment]
Thanks for the effort on this document and for going the extra mile. I agree with Spencer that this version is much easier to read, and I find it clear and have no objection to its publication.

[Ballot comment]
Neither of these are showstoppers at all; just suggested improvements:

1. In other protocols, the NULL-terminated thing is something that implementers often miss, so you might want to be really specific about it. I'd suggest:

OLD
  Note that all fields except "opc" MUST be NULL-terminated.
NEW
    Note that the filename, mode, windowsize, and #blocks fields below
    are all ASCII strings and MUST be NULL-terminated.

and then add to each description of the fields, "...as a NULL-terminated ASCII string".

2. Several of the MUSTs in section 3 are superfluous, as they're definitions, not protocol interop instructions:

s/MUST be modified/is modified
s/MUST contain either a 1/either contains a 1
s/MUST be specified in ASCII/is represented as a NULL-terminated ASCII string
s/MUST send an Option Acknowledgment/sends an Option Acknowledgment

[Ballot comment]
I read an earlier version of this draft soon after joining the IESG, and I do want to say this version is easier for me to review. Thank you for your work on that.

Before I cast my ballot, I have two questions.

(1) Where did the 65535 maximum number of blocks come from, in this text?

  #blocks
    The number of blocks in a window MUST be specified in ASCII. Valid
  values range MUST be between "1" and "65535" blocks, inclusive. The
  windowsize refers to the number of consecutives blocks transmitted
  before stop and wait for the reception of the acknowledgment of the
  last block transmitted.

(2) The reason I'm asking is, if I'm reading this text in section 5. Proof of Concept correctly,

  Performance tests were run on the prototype implementation using a
  variety of windowsizes and a fixed blocksize of 1456 bytes.  The
  tests were run on a lightly loaded Gigabit Ethernet, between two
  Toshiba Tecra Core 2 Duo 2.2 Ghz laptops, in "octet" mode,
  transferring a 180 MByte file.

  The comparison of transfer times (without a gateway) between the
  standard lock-step schema and the negotiated windowsizes are:

        Windowsize  |  Time Reduction (%)
        ----------    -----------------
              1            -0%
              2            -49%
              4            -70%
              8            -79%
              16            -84%
              32            -85%
              64            -86%

I get an 86-percent time reduction using a windowsize of 64. That's deep into "diminishing returns", because I could have gotten 79 percent using a windowsize of 8.

Is there a scenario where using a windowsize three orders of magnitude bigger than 64 is required?

[Ballot comment]
I read an earlier version of this draft soon after joining the IESG, and I do want to say this version is easier for me to review. Thank you for your work on that.

Before I cast my ballot, I have two questions.

(1) Where did 65535 maximum number of blocks come from, in this text?

  #blocks
    The number of blocks in a window MUST be specified in ASCII. Valid
  values range MUST be between "1" and "65535" blocks, inclusive. The
  windowsize refers to the number of consecutives blocks transmitted
  before stop and wait for the reception of the acknowledgment of the
  last block transmitted.

(2) The reason I'm asking is, if I'm reading this text in section 5. Proof of Concept correctly,

  Performance tests were run on the prototype implementation using a
  variety of windowsizes and a fixed blocksize of 1456 bytes.  The
  tests were run on a lightly loaded Gigabit Ethernet, between two
  Toshiba Tecra Core 2 Duo 2.2 Ghz laptops, in "octet" mode,
  transferring a 180 MByte file.

  The comparison of transfer times (without a gateway) between the
  standard lock-step schema and the negotiated windowsizes are:

        Windowsize  |  Time Reduction (%)
        ----------    -----------------
              1            -0%
              2            -49%
              4            -70%
              8            -79%
              16            -84%
              32            -85%
              64            -86%

I get an 86-percent time reduction using a windowsize of 64. That's deep into "diminishing returns", because I could have gotten 79 percent using a windowsize of 8.

Is there a scenario where using a windowsize three orders of magnitude bigger than 64 is required?

[Ballot comment]
I read an earlier version of this draft soon after joining the IESG, and I do want to say this version is easier for me to review. Thank you for your work on that.

Before I cast my ballot, I have two questions.

(1) Where did the maximum number of blocks come from, in this text?

  #blocks
    The number of blocks in a window MUST be specified in ASCII. Valid
  values range MUST be between "1" and "65535" blocks, inclusive. The
  windowsize refers to the number of consecutives blocks transmitted
  before stop and wait for the reception of the acknowledgment of the
  last block transmitted.

(2) If I'm reading this text in section 5. Proof of Concept correctly,

  Performance tests were run on the prototype implementation using a
  variety of windowsizes and a fixed blocksize of 1456 bytes.  The
  tests were run on a lightly loaded Gigabit Ethernet, between two
  Toshiba Tecra Core 2 Duo 2.2 Ghz laptops, in "octet" mode,
  transferring a 180 MByte file.

  The comparison of transfer times (without a gateway) between the
  standard lock-step schema and the negotiated windowsizes are:

        Windowsize  |  Time Reduction (%)
        ----------    -----------------
              1            -0%
              2            -49%
              4            -70%
              8            -79%
              16            -84%
              32            -85%
              64            -86%

I get an 86-percent time reduction using a windowsize of 64. That's deep into "diminishing returns", because I could have gotten 79 percent using a windowsize of 8.

Is there a scenario where using a windowsize three orders of magnitude bigger than 64 is required?

[Ballot comment]
I read and earlier version of this draft soon after joining the IESG (as background for the appeal), and I do want to say this version is easier for me to review. Thank you for your work on that.

Before I cast my ballot, I have two questions.

(1) Where did the maximum number of blocks come from, in this text?

  #blocks
    The number of blocks in a window MUST be specified in ASCII. Valid
  values range MUST be between "1" and "65535" blocks, inclusive. The
  windowsize refers to the number of consecutives blocks transmitted
  before stop and wait for the reception of the acknowledgment of the
  last block transmitted.

(2) If I'm reading this text in section 5. Proof of Concept correctly,

  Performance tests were run on the prototype implementation using a
  variety of windowsizes and a fixed blocksize of 1456 bytes.  The
  tests were run on a lightly loaded Gigabit Ethernet, between two
  Toshiba Tecra Core 2 Duo 2.2 Ghz laptops, in "octet" mode,
  transferring a 180 MByte file.

  The comparison of transfer times (without a gateway) between the
  standard lock-step schema and the negotiated windowsizes are:

        Windowsize  |  Time Reduction (%)
        ----------    -----------------
              1            -0%
              2            -49%
              4            -70%
              8            -79%
              16            -84%
              32            -85%
              64            -86%

I get an 86-percent time reduction using a windowsize of 64. That's deep into "diminishing returns", because I could have gotten 79 percent using a windowsize of 8.

Is there a scenario where using a windowsize three orders of magnitude bigger than 64 is required?

[Ballot discuss]
Thanks for your work on this draft.  I have some text recommendations to make sure all of the security concerns are covered.  My main points are covered in the proposed text.

Security Considerations section:

Propose the following change to the first sentence:
From: "TFTP includes no login or access control mechanisms."
To: "TFTP includes no authentication, integrity protection, confidentiality, or access control mechanisms."

Propose text for the first sentence of second paragraph:
From: "TFTP includes no protection against an on-path attacker, care must be
  taken in controlling windowsize values according to provider,
  requester, and network environment capabilities. "
To: "TFTP also does not support session encryption and therefore does not protect against an on-path attacker from active (session hijacking) or passive (monitoring) attacks.  Care must be
  taken in controlling windowsize values according to provider,
  requester, and network environment capabilities. "

I think it's enough to just list monitoring as an example as with TFTP, as it's likely to be a targeted attack and unlikely to be privacy related since it is typically used to do things like update firmware on a local network, etc.  Those attacks fit into the general category of monitoring.

[Ballot comment]
Thank you for addressing the comments received int he SecDir review.  From the SecDir review, there was a recommendation to include other references in the the security considerations section of this document.  One of those was from RFC5405.  The first paragraph of that section (altered a bit) could be helpful in the set of warnings given here - basically, use something else if you need any security.  I don't think the rest really applies because you'd switch to SFTP or something else rather than layer on security to TFTP in reality.

Here is a link to the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg04922.html

1. Summary

Joel Jaeggli is the Sponsoring area director.

The Genesis of draft-masotta-tftpexts-windowsize-opt is an involved
one. It entered the IETF review process as an individual submission.
Concern over interaction with existing IETF standards was identified.
As no instance of the working groups in which tftp was advanced still
exists, it has been variously sponsored by A Transport Area AD and by
an Ops AD.

This document describes a TFTP option which allows the client and
server to negotiate a window-size of consecutive blocks to send as an
alternative for replacing the single block lock-step schema.

2. Review

This document has over time received extensive scrutiny by the IESG.
Review by the transport directorate was solicited and received,
resulting in more explicit description of the circuit breaker
mechanisms employed with TFTP (which while widely employed a not part
of the specification) and some implementation specific values. Security review
during IETF LC resulted in draft 11.

3. Intellectual Property

No IPR's have been lodged again this work nor are they expected. There
exist multiple implementations of windowed TFTP deployed in the field.

1. Summary

Joel Jaeggli is the Sponsoring area director.

The Genesis of draft-masotta-tftpexts-windowsize-opt is an involved
one. It entered the IETF review process as an individual submission.
Concern over interaction with existing IETF standards was identified.
As no instance of the working groups in which tftp was advanced still
exists, it has been variously sponsored by A Transport Area AD and by
an Ops AD.

This document describes a TFTP option which allows the client and
server to negotiate a window-size of consecutive blocks to send as an
alternative for replacing the single block lock-step schema. The TFTP
Option Extension mechanism is described in [2].

2. Review

This document has over time received extensive scrutiny by the IESG.
Review by the transport directorate was solicited and received,
resulting in more explicit description of the circuit breaker
mechanisms employed with TFTP (which while widely employed a not part
of the specification) and some implementation specific values. Security review
during IETF LC resulted in draft 11.

3. Intellectual Property

No IPR's have been lodged again this work nor are they expected. There
exist multiple implementations of windowed TFTP deployed in the field.

IESG/Authors/WG Chairs:

IANA has reviewed draft-masotta-tftpexts-windowsize-opt-10, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion. 

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TFTP Windowsize Option) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'TFTP Windowsize Option'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Trivial File Transfer Protocol [1] is a simple, lock-step, file
  transfer protocol which allows a client to get or put a file onto a
  remote host. One of its primary uses is the early stages of nodes
  booting from a Local Area Network. TFTP has been always used because
  it is very simple to implement. However, the choice of a lock-step
  schema is not the most efficient for use on a LAN.

  This document describes a TFTP option which allows the client and
  server to negotiate a windowsize of consecutive blocks to send
  as an alternative for replacing the single block lock-step schema.
  The TFTP Option Extension mechanism is described in [2].



The file can be obtained via
http://datatracker.ietf.org/doc/draft-masotta-tftpexts-windowsize-opt/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-masotta-tftpexts-windowsize-opt/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Joel Jaeggli is the Sponsoring area director.

The Genesis of draft-masotta-tftpexts-windowsize-opt is an involved one. It entered the IETF review process as an individual submission. Concern over interaction with existing IETF standards was identified. As no instance of the working groups in which tftp was advanced still exists, it has been variously sponsored by A Transport Area AD and by an Ops AD.

This document describes a TFTP option which allows the client and
server to negotiate a window-size of consecutive blocks to send
as an alternative for replacing the single block lock-step schema.
The TFTP Option Extension mechanism is described in [2].

2. Review

This document has over time received extensive scrutiny by the IESG. Review by the transport directorate was solicited and received, resulting in more explicit description of the circuit breaker mechanisms employed with TFTP (which while widely employed a not part of the specification) and some implementation specific values.

3. Intellectual Property

No IPR's have been lodged again this work nor are they expected. There exist multiple implementations of windowed TFTP deployed in the field.