Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14

[Stewart Bryant <[e-mail]>]

> On 18 Jun 2020, at 12:01, Gorry Fairhurst <[e-mail]> 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 <[e-mail]> <mailto:[e-mail]>
> To:	Martin Duke <[e-mail]> <mailto:[e-mail]>
> CC:	tcpm <[e-mail]> <mailto:[e-mail]>, Review Team <[e-mail]> <mailto:[e-mail]>, Mark Allman <[e-mail]> <mailto:[e-mail]>, Last Call <[e-mail]> <mailto:[e-mail]>, Stewart Bryant <[e-mail]> <mailto:[e-mail]>, tom petch <[e-mail]> <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>
> 
> 
> 
>> On 17 Jun 2020, at 18:20, Martin Duke <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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