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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> wrote:
From: tcpm <tcpm-bounces@xxxxxxxx> on behalf of Mark Allman <mallman@xxxxxxxx>
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tcpm
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux