Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice

Tom,

does draft-15 address your concerns?

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt

On Mon, Jun 8, 2020 at 1:28 AM tom petch <ietfa@btconnect.com> wrote:

> From: tcpm <tcpm-bounces@ietf.org> on behalf of Mark Allman <
> mallman@icir.org>
> Sent: 05 June 2020 17:16
>
> > Mark, that is what I am questioning,
>
> well ...
>
> > that by default loss implies congestion.  Historically true for
> > the IETF but I think that there are a growing number of cases
> > where it is not true as in a post I saw on another WG list this
> > week where a document was saying that loss MUST NOT be taken as an
> > indication of congestion so the MUST in this I-D I find too
> > strong.
>
> OK.  So, I am not sure what to do here.  I will say several things ...
>
> <tp>
> Mark, what I would like to see is a statement up front, Introduction or
> just after, along the lines that the document (mostly?) assumes that loss
> is due to congestion which has historically been the case in the Internet
> and is likely still largely the case in the Internet and the
> recommendations here are designed to reduce that congestion .  but that
> there will be networks where loss is not due to congestion in which case
> the recommendations here MAY adversely affect the performance of the
> network.
> I would not give an example but if one is needed, then it would be loss
> caused by a burst of interference where backing off simply slows down the
> rate unnecessarily.
>
> Tom Petch
>
> (1) I believe that as a general, default the document is quite right
>     in specifying a congestion response and exponential backoff.
>
> (2) I believe consensus of the WGs has been the same as my notion in
>     (1) for some time now.  So, even setting aside (1), I am not
>     sure I feel like I have carte blanche to change this.
>
> (3) I do not believe loss always means congestion and I do not
>     believe assuming such is always correct or should always be
>     done.  I don't think I know anyone who thinks that.  So, the
>     document explicitly says that is fine, just go get consensus
>     that some other approach is fine.  (And, that should be
>     happening regardless of this document, so I am not sure what the
>     big deal is here.)
>
> So, basically, I am not sure what to do here.  Maybe one of the ADs
> can help.  Or, maybe we can set this aside and I can do the things I
> told you I'd do and a little extra framing will make this better.  I
> am all ears for advice here.
>
> (BTW, I have a half response to Stewart, as well.  I am not ignoring
> his review.  I am just behind.)
>
> allman
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>