Subject: [tcpm] review of draft-zimmermann-tcpm-reordering-detection

From: Wesley Eddy <[email-masked]>
Date: Thu, 05 Feb 2015 14:48:33 -0500

I reviewed the reordering detection algorithm document:
https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02

The document is very well written.  The specification in the draft seems
quite clear and like it would be easy to implement directly from the
document.

The purpose of section 4.7 ("Placeholder for Response Algorithm") isn't
clear to me, especially in relation to the separate reaction draft
(draft-zimmermann-tcpm-reordering-reaction).

One thing that was unclear to me, and seems useful, is a discussion of
the potential sources of error.  In other words, what events would
cause the computed metrics to be wrong and how significantly wrong?
There are a number of different events and potential corner cases that
are already addressed in the algorithm, and it wasn't clear to me
"what's left" or if it's supposed to just work perfectly in all cases.
(I'm sure it's not!)

Obvious things that occurred to me were:
- different compositions of loss and reordering "features" in the
  forward path:
  - lossiness followed by reordering
  - reordering followed by lossiness
  - reordering followed by reordering somewhere else (and do we even
    care about this, since it's the state of the packets at the
    receiver that matters, and not how many times the order has been
    shuffled)
- loss and reordering in the ACK path

The sensitivity to these things, I think, matters in understanding the
utility of the computed metrics, and their feedback into a response
function.

-- 
Wes Eddy
MTI Systems

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 5 Feb 2015 21:18:27 -0800

Hi,
I also agree that this document is well written and we already have seen
some consensus to explore solutions for reordering issue in the WG.

However, I personally have the following high-level questions on the draft
in order to think about it more.

Q1: Do we think that measuring reordering extent can be an approach for
reordering issue?
    One thing I'm wondering is that measured reordering extent is a kind of
historic data. So, to utilize this data properly, we might need to
understand how previous reorder extent is relevant to present or future
trends. Do we have some understandings or consensus on this? Or, can we
utilize this data in other ways?

Q2: Even if we're not very sure about Q1, do we think we can proceed this
idea in order to explore the answers for Q1?

Thanks,
--
Yoshi

On Thu, Feb 5, 2015 at 11:48 AM, Wesley Eddy <[email-masked]> wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 06 Feb 2015 00:40:20 -0500

On 2/6/2015 12:18 AM, Yoshifumi Nishida wrote:
> However, I personally have the following high-level questions on the
> draft in order to think about it more. 
> 
>     One thing I'm wondering is that measured reordering extent is a kind
> of historic data. So, to utilize this data properly, we might need to

This is a good point, since reordering could be due to a transient
that occurs once during a connection and never again (e.g. some
change in the underlying path), or it could be persistent due to
properties of the path fixed for the life of the connection.

It's difficult / impossible to tell the difference on a shorter
connection, or even on many short connections between the same
hosts, but if you could tell the difference, that would determine
the proper use of the metrics.

In the 1st case, it doesn't seem like TCP should be doing anything
beyond just reversing state changes made due to a spurious decision.

In the 2nd case, the reordering metrics that are measured would be
useful to cache along with the other path metrics that are already
cached.

-- 
Wes Eddy
MTI Systems

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Fri, 6 Feb 2015 17:41:04 +0000

Hi Wes,

thanks a lot for looking into the draft! Comments below.

> Am 05.02.2015 um 20:48 schrieb Wesley Eddy <[email-masked]>:
> 

The purpose of section 4.7 is to have a hook for a further reordering
reaction algorithm. RFC 4015 has something similar. However, Eifel
reaction is maybe a bit more explicit and clear at this point (see step
(DET) in RFC 4015)

> (I’m sure it's not!)

Very good point! I agree. We will add some text in the next version.

> - loss and reordering in the ACK path

+ packet duplication

> utility of the computed metrics, and their feedback into a response

I agree.

Have a nice WE
Alex

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Fri, 6 Feb 2015 18:24:16 +0000

Hi Yoshimumi,

> Am 06.02.2015 um 06:18 schrieb Yoshifumi Nishida <[email-masked]>:
> 
> Hi,
> I also agree that this document is well written and we already have seen some consensus to explore solutions for reordering issue in the WG.
> 
> However, I personally have the following high-level questions on the draft in order to think about it more.
> 
> Q1: Do we think that measuring reordering extent can be an approach for reordering issue?

Measuring reordering per se or the extent itself? It’s not a big deal to compute for example
the reordering delay too.

Basically, or draft compute the reordering extent of the IPPM RFC4737 on the transport layer.

>     One thing I'm wondering is that measured reordering extent is a kind of historic data. So, to utilize this data properly, we might need to understand how previous reorder extent is relevant to present or future trends.

Yes this is right. But this discussion belongs not to this draft. I belongs to the reaction draft.
It’s clear that all adaptive reordering „reaction“ algorithms have the problem that they need
a couple of old events to set the threshold right, which maybe too late for short TCP flows.
But have in mind, TCP-aNCR has two modi. We can run it w/ and w/o the adaptive
part. This is exactly the reason why at least the reaction draft is experimental. It should be
part of the experiment to investigate in which cases an adaptive algorithms makes more
sense than a non-adaptive one.

> Do we have some understandings or consensus on this?

IMO yes because we have an song consensus on the question if we would like to make
TCP more robust against reordering. The first step in this direction is to detected and
quantify the perceived reordering. This is what the draft is about. We do not change anything
at TCP layer (protocol, behavior). What we can discuss is if extent is the only metric we
should implement, but IMO we can do that after an adoption call.

> Or, can we utilize this data in other ways?

IPPM?

> 
> Q2: Even if we’re not very sure about Q1, do we think we can proceed this idea in order to explore the answers for Q1?

Yes, I believe so.

> 
> Thanks,
> --
> Yoshi
> 
> 
> On Thu, Feb 5, 2015 at 11:48 AM, Wesley Eddy <[email-masked] <mailto:[email-masked]>> wrote:
> https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02 <https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
>

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Fri, 6 Feb 2015 18:41:41 +0000

Hi Wes,

> Am 06.02.2015 um 06:40 schrieb Wesley Eddy <[email-masked]>:
> 

You are right. This discussion is currently missing in the (reaction
draft. I need to write a paragraph w/o a couple of recommendation in
which scenarios the non-adaptive mode may lead to better performance.
For example I run my experience in Linux, which has a (more or less)
proper undoing strategy. In case undoing is not implemented, the
adaptive mode could be have negative effects since you need a couple
reordering events (which will be let to spurious retransmissions) to
set the threshold appropriate.

Alex

---

From: Carsten Wolff <[email-masked]>
Date: Sat, 07 Feb 2015 09:17:36 +0100

Hi,

On Friday 06 February 2015 18:24:16 Zimmermann, Alexander wrote:
> Measuring reordering per se or the extent itself? It’s not a big deal to
> compute for example the reordering delay too.

I think the answer to this lies in RFC5681. The current approach counts 
dupacks with a threshold of 3 to distinguish loss from reordering. If a 
possible reaction algorithm stays with counting dupacks and adapting the 
threshold (like our proposed reaction), then the extent is the metric it 
needs. If the detection draft should want to keep the door open for a reaction 
that replaces the dupack-counting by e.g. a timer, then it would be needing a 
metric that measures time in the detection.

More generally, RFC4653 is a good approach at reordering without a detection 
and the reaction draft is based on it. Adding a detection and making the 
threshold adaptive is a way of fixing the problem of RFC4653 that it hurts 
performance in the common case where the path has loss and no reordering. 
Judging from old netdev-discussions, this always was the argument against 4653 
that kept people from implementing it for Linux.

Thanks for the review!

Carsten