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]

 



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.

> 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

Attachment: signature.asc
Description: OpenPGP digital signature

-- 
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