Re: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-rfc5405bis-18: (with COMMENT)

["Eggert, Lars" <[e-mail]>]

Hi,

On 2016-10-14, at 17:46, Stephen Farrell <[e-mail]> wrote:
>> I'm happy to take out the references to GSS-API and/or AH, but note
>> that they are only listed as options. I also note that they are not
>> historic or obsolete, AFAICT.
> 
> They're not. But they're probably also not that useful as
> they're not much used for UDP applications afaik. Text about
> how to successfully use DTLS would be more useful these days
> I'd say. Or maybe JOSE or COSE stuff. Sorry no to have good
> text.
> 
> If you want, I can ask on saag or you can just go ahead
> if you'd prefer not wait.

if someone from saag can go over the current text by - say - the end of next week, *and* we can be sure that the resulting edits are such that they have obvious consensus in SAAG, TSVWG, the IETF and the IESG (such that we don't need to redo all the consensus calls) - sure. Feasible?

>>> - 3.1.1: "Latency samples MUST NOT be derived from ambiguous
>>> transactions" - I don't understand how that MUST NOT can be
>>> universally applied, maybe that's just a use of 2119 terms for
>>> emphasis?
>> 
>> I don't follow. Of course this can be universally applied?
> 
> Well, the MUST NOT assumes that there's an unambiguous
> definition of "ambiguous transaction" and I'm not sure
> there is, is there?

If you define protocol with transactional semantics (i.e., request/response) you *know* whether you can unambiguously relate request packets with response packets. If there can be ambiguity in some cases (as with TCP), then as long as you can identify those cases, you MUST NOT derive latency samples from them. If you can't relate request and response packets at all, you have designed a protocol that will make it very difficult to do any sort of congestion control for :-) including being able to compute an RTT.

Lars