Re: [tcpm] Review of draft-ietf-tcpm-rtorestart-02.txt

[Per Hurtig <[e-mail]>]

Hi Alexander

thanks for the review, please see my comments inline…


On 13 May 2014, at 11:57, Zimmermann, Alexander <[e-mail]> wrote:

> Hi folks,
> 
> first of all thank you for writing this draft. The draft is clearly written: the
> problem is well described, the doc is self-contained (it’s not necessary to read
> dozens of other RFCs to understand the problem), and the authors state why the
> doc is experimental and what further experiments are needed for being a STD.
> However, on the technical side I see some open points. In detail:
> 
> * Sec 1, 4. para: „a considerable number of flows have such properties“
>  Can you backup this with some numbers? This is exactly the point I raised at the
>  (last?) IETF. I would like to see some data on how severe the problem is we would
>  like to fix.
> 

For short flows (e.g. web) there are a number of references in the draft. These are
the primary target for the mechanism. We’ll elaborate some more on the importance
for other types of traffic. 


> * Sec 1.1: please change this subsection to a section (1.1 => 2) and also
>  introduce your new state variable rrthresh here
> 

I don’t get why the section should be renumbered. The “terminology” is often the
last subsection of the introduction of most drafts and RFCs. Furthermore, it seems 
slightly overkill to introduce the variable there. RFCs that manages many more 
variables, e.g. RFC6298 does not explicitly introduce any variable in this section.

> * Sec 1, 5. para: „Spurious timeouts typically degrade the performance of flows
>  with multiple bursts of data, as a burst following a spurious timeout might
>  not fit within the reduced congestion window (cwnd)“
> 
>  This is (only) true with respect to your algo, not in general. The general
>  problem of a spurious timeout is the cwnd reduction, the go-back-N
>  retransmissions, … See RFC 3522. After reading section 4.2 of your draft I
>  understand what you want to see here. Please rephrase the section and maybe
>  add the spurious RTO RFC as reference.
> 
What is meant is the actual cwnd reduction. We should clarify this.


> * Sec 3: Suppose FlightSize is 2 and you have exactly one segment to send,
>  your algo doesn’t trigger since step 2.b isn’t true. Bug? I would say yes.
> 
Good catch! The question is if it’s worth fixing since the algorithm will
become more complex and the situation you mention is really a corner case that
requires either (i) the cwnd to be exactly 3 segments large; or (ii) having a
packet written to the socket just between previous data transmission and the
arrival of the acknowledgment.

Furthermore, this mechanism is only an optimization to the standard timer. So
if it doesn’t work in this particular scenario it won’t break anything. It will
just not be triggered. 

> * Sec 3: Why the condition 2.b is different from the early retransmission
>  condition 2.b or 3.b? Is there any specific reason why we exclude the
>  advertised receive window part from the condition?
> 
Because the advertised window can be small in situations where it’s not
preferable to use RTO restart. For instance, in the middle of a transfer where
it’s better to wait for fast/early retransmit to kick in.

> * Sec 3: IMO the algo/doc is too much Linux driven. I would like to see a
>  segment-based *and* byte-based version of the algo, like RFC 5827.
> 
Yes, this comment was given by several people at the last IETF. We will update
the draft to address this.

> * General: IMO I would be a little bit easier to read the doc if you give the
>  algo a proper name. By reading „RTO restart“ I had sometimes trouble to
>  know if mean your algo or the „action“ of restarting the RTO.
> 
Agreed, this will be fixed.



Thank you,
Per Hurtig

> 
> Alex
> 
> 
>