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

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 <wes@mti-systems.com> wrote:

> 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
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>