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

[Carsten Wolff <[e-mail]>]

Hi,

On Friday 06 February 2015 18:24:16 Zimmermann, Alexander wrote:
> >
> > Am 06.02.2015 um 06:18 schrieb Yoshifumi Nishida <[e-mail]>:
> >
> > 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.

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