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

From: "Zimmermann, Alexander" <[email-masked]>
Date: Tue, 13 May 2014 09:57:36 +0000

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.

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

* 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.

* 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.

* 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?

* 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.

* 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.

Alex

---

From: Per Hurtig <[email-masked]>
Date: Thu, 15 May 2014 12:00:18 +0200

Hi Alexander

thanks for the review, please see my comments inline…

>  (last?) IETF. I would like to see some data on how severe the problem is we would

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. 

>  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.

>  add the spurious RTO RFC as reference.
What is meant is the actual cwnd reduction. We should clarify this.

>  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. 

>  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.

>  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.

>  know if mean your algo or the „action“ of restarting the RTO.
Agreed, this will be fixed.

Thank you,
Per Hurtig

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Wed, 21 May 2014 08:28:58 +0000

Hi Per,

> for other types of traffic. 

Your draft focus on two different kinds of flows: a) on short flows and b) on flows
w/ low transmission rates. For the former you give two references [RJ10] and [FDT13],
but not for the latter. You say that „a considerable number of flows have such
properties“ and my question was, if you can backup this w/ some numbers. Additionally,
Yuchung reports that he wasn’t able to see much improvements while implementing your
scheme. Do you have some data that you can share to see how much your scheme helps to
improve the latency?

Also I’m not sure if we really focus on short flows. Is it not rather the case that we
concentrate us on tail losses? Your scheme will not only kick in for short flows, it
gets activated at the end of any stream. Or do I miss something here? (BTW [FDT13]
reports that 77% of the RXmits are RTO-based, it doesn’t say that 77% are short flows.)

> last subsection of the introduction of most drafts and RFCs.

This was only a nit. In German language we have the grammar rule that you cannot
introduce a subsection x.1 if you don’t have a second subsection in the same section.
While searching a little bit in the web, it seems that is also valid in English
(http://www.cs.berkeley.edu/~pattrsn/talks/writingtips.html). Anyway, it was only
a nit :-)

> Furthermore, it seems 

and RFC 5681 or RFC 6675 are counterexamples :-) Anyway, the question is more whether
or not we need an additional state variable in the TCB. If you think that they are cases
possible where ‚rrthresh‘ should not be initialized with ‚dupthresh + 1', then we should
introduce the state variable and explain why we need it. Otherwise, I recommend do
use ‚dupthresh + 1’ instead of 'rrthresh‘

> become more complex

Not really. You can 1) restart your RTO (as usual), 2) transmit new data,
3) re-arm your RTO with RTO - T_earliest if FlightSize < 4. In terms of „re-arming“
we did more or less the same in RFC6069…

> and the situation you mention is really a corner case that
> requires either (i) the cwnd to be exactly 3 segments large;

less than 4, no?

> or (ii) having a

Yes

> if it doesn’t work in this particular scenario it won’t break anything.

Sure, but if we exclude some traffic pattern which we can on the other hand
easily include by a small algo change, we should do that. Nevertheless, you
are right if we only speak here about rare corner cases (and I don’t know
the answer) we can ignore them.

> It will

Ah, OK I see. Could you please explain this in the draft? Is it valid to say
that RTO restart try to cover all cases where early retransmit does’t work?
I have the feeling that I not fully understand which cases should be covered by
which algo.