---- Original Message -----
From: Mark Allman mallman@xxxxxxxx
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
