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

[tom petch <[e-mail]>]

---- Original Message -----
From: Mark Allman [e-mail]
Sent: 05/06/2020 13:51:55

Hi Tom!

Sorry for the long RTT .... I had a deadline earlier this week and
am still trying to dig out.

>  It is the 'packets are lost due to congestion and that is THE
>  problem' that I see as the unstated assumption for this and many
>  IETF documents.  Is it correct?

Well, yes, I agree with the first part of the sentence.  However, I
disagree that is somehow an unstated assumption.  The document says:

    (4) Loss detected by the RTO mechanism MUST be taken as an
        indication of network congestion and the sending rate adapted
        using a standard mechanism (e.g., TCP collapses the congestion
        window to one segment [RFC5681]).

That seems pretty explicit to me.  And, yes, I fully understand loss
happens for non-congestion reasons.  But, as a default---which this
document is---I think this guideline is on firm ground.
<tp>
Mark, that is what I am questioning, 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.   I am saying that there are a number of places in the document where congestion is assumed to be the cause.  Thus 4(i) has
'when a network is already congested' which I think should be 'if the network is already congested' or the next paragraph about 'cause congestion control ' or in s.5 'detecting loss carries a requirement to invoke a congestion response'; no, only if the network is of a kind where loss is due to congestion, not other networks.
As Stewart put it better than I, this is BCP and so could be used wrongly 

---
New Outlook Express and Windows Live Mail replacement - get it here:
https://www.oeclassic.com/

against protocols where it is inappropriate because the scope of this I-D appears to be so broad.
Tom Petch


 


> A statement up front about the assumption of unreliability would
> address this.

I have added a note and will note in the intro that we take the
pessimistic (but realistic) assumption that the network is
unreliable and/or unknown.  Clearly if that is not the case one
could land somewhere else.

Thanks!

allman