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

[Yoshifumi Nishida <[e-mail]>]

OK. if there're no further opinions, I will do it.
--
Yoshi


On Fri, Jun 19, 2020 at 11:58 AM Martin Duke <[e-mail]>
wrote:

> Hi Stewart,
>
> I'm going to ship draft-16 to the IESG today. Any last concerns beyond the
> stated differences from WG consensus?
>
> Yoshi, please update the shepherd writeup to cover the flavor of this
> discussion.
>
> On Thu, Jun 18, 2020 at 7:18 AM Stewart Bryant <[e-mail]>
> wrote:
>
>> Here is how we should proceed.
>>
>> We make as much progress as we can agree on which will clear some of the
>> issue below.
>>
>> For any remaining issues for which you have wider consensus but where we
>> cannot agree, I modify my review and the IESG decides how they wish to
>> proceed.
>>
>> I am prepared to be in the rough but I have a duty to draw attention to
>> concerns.
>>
>> Best regards
>>
>> Stewart
>>
>>
>> > On 18 Jun 2020, at 14:32, Mark Allman <[e-mail]> wrote:
>> >
>> >
>> > Last comment first ...
>> >
>> >> We are getting there, but I would ask that you take the transport
>> >> hat off and look again from an infrastructure and packet transport
>> >> perspective.
>> >
>> > I don't view this as looking at it from a transport
>> > vs. infrastructure perspective.
>> >
>> > And, I am not disagreeing with your perspective.  My take is that
>> > the nub of what you're saying is that there are cases where we know
>> > something about the network.  And, that something let's us design a
>> > more savvy loss detection and response scheme.  E.g., because the
>> > link / path is known to be short and so using an initial RTO of 1sec
>> > is too long.  E.g., because the cause of loss is known or can be
>> > safely assumed to not be congestion.  And, I think that view is both
>> > correct and reasonable.
>> >
>> > However, ...
>> >
>> > (0) I do not view that view as inconsistent with this document at
>> >    all.
>> >
>> > (1) Because there are cases where we know more doesn't make a set of
>> >    default requirements for the general case when we don't
>> >    understand the path any less valid.
>> >
>> > (2) The document explicitly says alternates are fine modulo the
>> >    usual consensus.  I.e., in cases where we have more information
>> >    we can do things differently.  And, the cost of that is no
>> >    different than the cost today (i.e., specifying it and gaining
>> >    consensus).
>> >
>> > So, my view is that this all boils down to making it clear that this
>> > is not somehow THE (best) way to do time-based loss detection for
>> > all cases.  Rather, following the guidelines with result in a
>> > safe-for-general-use loss detector.
>> >
>> >> 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.
>> >
>> > Per this and Gorry's note, I will tweak this to use queuing, as that
>> > is what I meant.
>> >
>> >> 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.
>> >
>> > OK, let me see if I can foreshadow this a bit more and/or pull some
>> > from section 2 to earlier.
>> >
>> >> 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.
>> >> [...]
>> >>
>> >> In some cases you cannot tell the cause, but it is more important
>> >> to ignore the loss. OAM being a particularly good example.
>> >
>> > First, I don't think I can readily change this without going against
>> > the consensus the document has already gathered.  (I.e., this is not
>> > about the intro, framing, context, etc. bits, but the actual meat of
>> > the technical stuff.)
>> >
>> > Second, you are right that the IETF does not have a monopoly, but
>> > that doesn't make the statement in the document the wrong thing to
>> > say.
>> >
>> > Third, I doubt I should change it.  The problem here from the
>> > standpoint of a set of default guidelines is that we'd like a
>> > mechanism to determine the cause of loss to **actually work** before
>> > it's OK to avoid a congestion control response.  If a standardized
>> > mechanism is used then we have some confidence that the mechanism
>> > has been vetted as reasonable.  If the mechanism is not standardized
>> > then we have no idea if it actually works or if it is some
>> > ill-conceived scheme that is badly broken.  In this latter case, I
>> > don't think we want to bless this approach as OK within the default.
>> > It may be OK, but it should get some consensus that it is OK.
>> >
>> > allman
>>
>>