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

["Zimmermann, Alexander" <[e-mail]>]

Hi Yoshimumi,

> Am 06.02.2015 um 06:18 schrieb Yoshifumi Nishida <[e-mail]>:
> 
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> I reviewed the reordering detection algorithm document:
> https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02 <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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm