Re: [tcpm] Last Call: <draft-ietf-tcpm-newcwv-10.txt> (Updating TCP to support Rate-Limited Traffic) to Experimental RFC

[Mirja Kühlewind <[e-mail]>]

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
> [e-mail] mailing lists by 2015-05-22. Exceptionally, comments may be
> sent to [e-mail] 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: [phone]
email: [e-mail]
------------------------------------------