> On 18 Jun 2020, at 12:01, Gorry Fairhurst <go...@erg.abdn.ac.uk> 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 <stewart.bry...@gmail.com> > <mailto:stewart.bry...@gmail.com> > To: Martin Duke <martin.h.d...@gmail.com> <mailto:martin.h.d...@gmail.com> > CC: tcpm <t...@ietf.org> <mailto:t...@ietf.org>, Review Team > <gen-art@ietf.org> <mailto:gen-art@ietf.org>, Mark Allman <mall...@icir.org> > <mailto:mall...@icir.org>, Last Call <last-c...@ietf.org> > <mailto:last-c...@ietf.org>, Stewart Bryant <stewart.bry...@gmail.com> > <mailto:stewart.bry...@gmail.com>, tom petch <daedu...@btconnect.com> > <mailto:daedu...@btconnect.com>, draft-ietf-tcpm-rto-consider....@ietf.org > <mailto:draft-ietf-tcpm-rto-consider....@ietf.org> > > > >> On 17 Jun 2020, at 18:20, Martin Duke <martin.h.d...@gmail.com >> <mailto:martin.h.d...@gmail.com>> 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 <martin.h.d...@gmail.com >> <mailto:martin.h.d...@gmail.com>> 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 <mall...@icir.org >> <mailto:mall...@icir.org>> 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 Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
