Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT)

[Al Morton <[e-mail]>]

Hi Adrian,

Thanks for clearing your DISCUSS. As always, the memo reads better
owing to your efforts, and those of Dan and Sandra.

Here's what I added in section 4.4, with supporting modifications
elsewhere:

We add the following guidance regarding the responder process to
"send a Type-P packet back to the Src as quickly as possible".

A response that was not generated within Tmax is inadequate for any 
realistic test, and the Src will discard such responses. A responder 
that serves typical round-trip loss testing (which is relevant to 
higher-layer application performance) SHOULD produce a response in 1 
second or less. A responder that is unable to satisfy this 
requirement SHOULD log the fact so that an operator
can adjust the load and priorities as necessary. Analysis of 
responder time-stamps [RFC5357] that finds responses are not 
generated in a timely fashion SHOULD result in operator notification, 
and the operator SHOULD suspend tests to the responder since it may 
be overloaded. Additional measurement considerations are described in 
Section 8, below.

Ciao,
Al


At 02:04 PM 4/8/2012, Adrian Farrel wrote:
>Hello Al,
>
> > > > Although IPPM has never formalized a strategy, we have been repeating
> > > > security material in metrics RFCs. This allows new folks to read
> > > > and improve the text, rather than be referred to a fixed reference.
> > > > It seems to work.
> > >
> > >I can see how that would lead to the verbatim reproduction of 
> text. I have no
> > >problem with that per se, but I worry that the process has 
> become formulaic
> > >without any new consideration of security for the specific 
> document in hand.
> > >
> > >If you tell me that this is adequate for this document and no 
> refinement is
> > >needed in this case, I will clear and let the Security ADs and
> > >Directorate worry
> > >about the security details.
> >
> > I think it is. We are essentially conducting a two-way version of RFC 2680
> > (one-way loss), so all the same considerations apply. We have exposure in
> > two (possibly different) paths, but the threats are the same.
>
>OK. I cleared my Discuss.
>
> > > > > > 1. The phrase "as immediately as possible" that appears a couple of
> > > > > > times in the text (and that seems to originate in RFC 
> 5357) is a bit
> > > > > > unfortunate.  "Immediately" or "as quickly as possible" are better.
> > > >
> > > > This odd turn of phrase resulted from many hours of discussion
> > > > dating back to TWAMP's development.  We wear the scar proudly.
> > >
> > >Well, this is only a Comment, and you do not have to address it, but "as
> > >immediately as possible" is hogwash. It is a butchery of the
> > >language and means
> > >nothing!
> > >
> > >In fact, and as a general principle of writing standards, even 
> "as quickly as
> > >possible" would be poor. The English would be fine, but it is a subjective
> > >statement against which conformance cannot be measured.
> >
> > Under typical protocol development circumstances, we could write a
> > real requirement:
> >          The response MUST be prepared and sent on the wire in <X seconds.
> >
> > But that's not the case here.  Instead we have desire that the response
> > will be sent immediately, yet we understand that measurement systems will:
> >
> >   - occasionally execute higher priority processes that delay the response
> >     (processing routing updates comes to mind)
> >   - carry 2 time stamps that allow the tester to determine if the response
> >     was generated fast enough for the intended purpose
> >   - serve purposes with greater or lesser need for immediacy
> >   - either meet the variable needs for measurement immediacy or not, and
> >     this is a judgement that can be made on each and every 
> measurement packet
> >
> > Is it useful to explain some/all of this in the memo?
>
>I don't think so. I would just fix the text to say what you mean!
>
>I found key text in your mail to be:
>
> >     allow the tester to determine if the response
> >     was generated fast enough for the intended purpose
>
>Surely it is not enough to have the tester discard all response because they
>were not fast enough. Surely it is a good idea to give *meaningful* advice to
>the responder about how to respond so that the response is "fast 
>enough for the
>intended purpose."
>
>Clearly "immediately" is not what is meant since it is allowed for 
>this to be a
>background process. So perhaps the correct thing to do is warn the implementer
>of the responder about the expectations of the tester. Something like:
>
>A tester will normally find that a response that was not generated within 3
>weeks is inadequate for the purposes of a realistic test and will discard such
>responses. Therefore, a responder needs to ensure that at least 67.2% of
>responses are generated within 1 hour of receiving the request. A 
>responder that
>is unable to satisfy this requirement SHOULD log the fact so that an operator
>can adjust the load and priorities as necessary. A tester that finds that
>responses regularly are not generated in a timely fashion SHOULD notify the
>operator that the responder is compromising the tests, and SHOULD suspend
>sending requests to the responder since it is clearly overloaded.
>
>
>Ciao,
>Adrian