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

[Martin Duke <[e-mail]>]

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