> On 18 Jun 2020, at 12:01, Gorry Fairhurst <[email protected]> wrote: > > > > See a few comments (marked GF) from the perspective of other transport RFCs, > in case this helps you find text... > > -------- Forwarded Message -------- > Subject: Re: [tcpm] Genart last call review of > draft-ietf-tcpm-rto-consider-14 > Date: Thu, 18 Jun 2020 11:00:15 +0100 > From: Stewart Bryant <[email protected]> > <mailto:[email protected]> > To: Martin Duke <[email protected]> <mailto:[email protected]> > CC: tcpm <[email protected]> <mailto:[email protected]>, Review Team > <[email protected]> <mailto:[email protected]>, Mark Allman <[email protected]> > <mailto:[email protected]>, Last Call <[email protected]> > <mailto:[email protected]>, Stewart Bryant <[email protected]> > <mailto:[email protected]>, tom petch <[email protected]> > <mailto:[email protected]>, [email protected] > <mailto:[email protected]> > > > >> On 17 Jun 2020, at 18:20, Martin Duke <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Stewart, >> >> If there are no further objections, I'm going to declare consensus. >> >> On Thu, Jun 11, 2020 at 1:45 PM Martin Duke <[email protected] >> <mailto:[email protected]>> wrote: >> Stewart, >> >> do we need more cycles for this, or is draft-15 sufficient to address your >> concerns? >> >> On Mon, Jun 8, 2020 at 12:52 PM Mark Allman <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Stewart, et.al <http://et.al/>.! >> >> I just submitted a new version of rto-consider. Please ask the >> datatracker for diffs between this and rev -14. The highlights: >> >> - The diffs with the last rev are here: >> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt >> >> <https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt> > > In the general case, delay across a > network path depends not only on distance, but also a number of > variable components such as the route and the level of buffering in > intermediate devices. > > Its is more the contending/conflicting traffic rather than the buffering, or > perhaps the time spent in queues, but “buffering” is a link a transport > colloquial term. > > GF: The word being sought might be "queueing" (I think that buffering is > thought of as memory- and hence max queue).
SB> Queuing ins the word, thank you. > Since our wide-area network paths are best > effort, packet loss is a regular occurrence. > > No the best effort Internet experiences this. There ate many well engineered > WAN that do not. > > What I am not seeing is clearer text that distinguishes between user traffic > and “engineering” traffic that is used to make the network work, and between > the end to end traffic and traffic within an AS that may be there for other > purposes (high value service also offered by the provider) and WANs that are > well engineered. > > Perhaps we could include a clearer disclaimer regarding the > non-best-effort-internet-end-to-end traffic? > > You have some text on this down in section 2 but it is a bit buried. > > Perhaps something early on of the form: This document is specially concerned > with end to end behaviour over the best effort Internet. As noted in section > 2 it may not me applicable to other types of WAN, or to the traffic used in > affecting the operation of the Internet itself. > > GF: Actually, I do think a well-engineering WAN can be in scope of your spec. > The two wrods I was expecting were "controlled environment" or > "pre-provisioned" capacity, these might not see the same oath properties. A > DC is typically regarded in transport specs as a "controlled environment". SB> That works for me as well. > An exception to this rule is if an IETF standardized mechanism > determines that a particular loss is due to a non-congestion > event (e.g., packet corruption). > > That is a bit heavy. It should be “a protocol” there than an IETF > standardarized mechanism. The IETF does not have a monopoly on pre-blessing > protocols before they are deployed. > > GF: Unsure myself what is needed - isn't this guidance for design of protocol > mechansims? SB> .. and if that is the case the words used in the text are way over the top, and may actually cause harm to innocent protocols. SB> There is a bunch of concern in the industry that the IETF is now too illiberal and such words fuel that concern. Best regards Stewart
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
