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

[Wesley Eddy <[e-mail]>]

On 2/6/2015 12:18 AM, Yoshifumi Nishida wrote:
> 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?
> 


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