Hi authors,
I've review this document (missed the WG last call though) and support
publication of this document.
Find some comments below that I recommend to further improve readability and may
or may not be addressed in the final version.
Mirja
--------------------
pipeACK (section 4.1 and 4.2 and 4.5.1):
1) Can you maybe add a sentence that explains why FlightSize is not sufficient.
I understand the difference between the two variables but are there actually
cases where it makes a big difference if one or the other is used?
2) This is just an idea and does not make a big difference: Instead of saying
pipeACk is undefined, you could just set it to infinity or 'max' (what every the
max in the implementation is) and this would always keep you in validated phase.
3) The implementation for pipeACK (based on HighACK) that you propose does not
take into account that dupACK also acknowledge new data. Is this on purpose? If
so please state explicitly.
4) Text says "When no meaurements are available, ..."
Maybe say more explicitly "When no meaurements are available as the
connection is idle" or "... as no data were sent during the last measurement
period" or "... no ACK were received...".
5) I would appreciate a forward reference to section 4.5.1 here (as also done
for other stuff as for cwnd-limited in the next section).
6) Could you also include pseudo code in 4.5.1? I far as I know you have an
implementation, so it should not be extremely hard to come up with pseudo code
and I personally think it would be really helpful...
7) nit in last paragraph: s/method defined on [RFC6675]is/ method defined in
[RFC6675] is/
8) Figure 1 (section 4.5.1): Maybe add a y-axis...?
non-validated phase (section 4.3 and 4.4)
1) Maybe add one sentence saying "A connection is also in non-validated phase if
pipeACK is zero which means the connection is idle". Saying this explicit would
help me to understand things better.
I just notice that this might actually not be true because in the section above
you say that pipeACK is set to undefined if no measurements are available and
that would mean the connection goes into validated phase... okay I think there
is some clarification needed here.
2) In section 4.4 you first say
"cwnd neither grows nor reduces while the sender remains in this phase"
and then
"A sender that is cwnd-limited MAY use the standard TCP method to increase
cwnd".
Please clarify!
3) In section 4.4.1:
"A sender that detects a packet-drop MUST record the current
FlightSize in the variable LossFlightSize ..."
Is this "packet-drop" or "congestion notification"? I guess the difference
is that if ECN is used R=0. So that's okay. Please check again that this also
works correctly for ECN.
4) Is this
cwnd = (Max(pipeACK,LossFlightSize) - R)/2
or
cwnd = (Max(pipeACK,(LossFlightSize - R))/2 [only LossFlightSize - R] ?
Because the text reads as if it should be the second...
5) "ssthresh is adjusted using the standard TCP method."
This is not clear to me. Is ssthread set to cwnd/2 before the adjustment or
to cwnd-1 after the adjustment? The first option would restart the connection in
Slow Start... Please clarify!
6) "then this can result in the final cwnd after loss recovery being 1/4 of the
cwnd"
Shouldn't this be "being at max 1/4 of the cwnd"...?
7) "Subsequent updates to cwnd do not therefore reflect pipeACK history before any
congestion event."
Not sure I understand this sentence... which subsequent updates?
8) nit: s/updated during loss recoverySection 4.2/ updated during loss recovery
as stated in Section 4.2/
Non-validated phase (section 4.4.3 and 5)
1) I would recommend to change the title to
"4.4.3 Adjustment at the end of the Non-Validated Phase (NVP)"
2) "An application that remains in the non-validated phase for a period
greater than the NVP is required to adjust its congestion control
state. If the sender exits the non-validated phase after this
period, it MUST update the ssthresh:"
This is not fully clear to me. Do I have to adapt cwnd and ssthresh right
after NVP or as soon as I leave the non-validated phase after being for at leats
NVP time in this phase? If I'm not idle but only sending with a low rate, I
should probably do this adjustment with the next ACK, no...?
3) Further, these adjustments mean that the connection will be in Slow Start. If
I understand this correctly, this is not a problem as long as the connection
stays in non-validated as the cwnd will not be further increased. But as soon as
it leaves non-validated phase it will increase its cwnd as in Slow Start. I
would like to have this spelled out explicitly.
4) This section does not tell/specify what value NVP should have. Please add a
sentence that this is on purpose and add a reference to section 5.
5) Section 5 says "A period of five minutes was chosen for this NVP."
This seeems to be a left over from an older version as nothing was specified
so far. Please check!
On 08.05.2015 11:33, The IESG wrote:
The IESG has received a request from the TCP Maintenance and Minor
Extensions WG (tcpm) to consider the following document:
- 'Updating TCP to support Rate-Limited Traffic'
<draft-ietf-tcpm-newcwv-10.txt> as Experimental RFC
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@xxxxxxxx mailing lists by 2015-05-22. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This document provides a mechanism to address issues that arise when
TCP is used to support traffic that exhibits periods where the
sending rate is limited by the application rather than the congestion
window. It provides an experimental update to TCP that allows a TCP
sender to restart quickly following a rate-limited interval. This
method is expected to benefit applications that send rate-limited
traffic using TCP, while also providing an appropriate response if
congestion is experienced.
It also evaluates the Experimental specification of TCP Congestion
Window Validation, CWV, defined in RFC 2861, and concludes that RFC
2861 sought to address important issues, but failed to deliver a
widely used solution. This document therefore recommends that the
status of RFC 2861 is moved from Experimental to Historic, and that
it is replaced by the current specification.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ballot/
No IPR declarations have been submitted directly on this I-D.
--
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland
Room ETZ G93
phone: +41 44 63 26932
email: mirja.kuehlewind@xxxxxxxxxxxxxx
------------------------------------------