Re: [tram] Mirja Kühlewind's Yes on draft-ietf-tram-stun-path-data-03: (with COMMENT)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Varun,

Thanks. That’s helpful. If the following statement is true, I’d also would like to see something added like this:

„No additional messages should be sent for measurement purposes only.“

Thanks,
Mirja


> Am 17.04.2016 um 16:37 schrieb Varun Singh <[e-mail]>:
> 
> Hi Mirja,
> 
> I agree, the metric being measured is fractional loss, and not the loss rate. This should be fixed. 
> 
> To your other comment:
> > Would it be possible to give some recommendation in this doc what an application needs to do to get an appropriate measure?
> 
> Would the following proposal work? 
> 
> According to rfc5389, the path characteristic is measured when the first STUN transaction is complete for each ICE candidate pair during connectivity establishment. If more measurements are needed, this STUN extension MAY be applied to the STUN consent checks defined in [rfc7675].
> 
> 
> On Sun, Apr 17, 2016 at 5:15 PM, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
> Hi again,
> 
> one more point: When I was reading the doc, I was assuming that you aim to measure something like the path loss rate, as you talk in the whole doc always about 'the path characteristics like round-trip time (RTT) and packet loss‘. However, after the discussion with you, I believe what you actually do with this extension is to get the ability to detect signal packet losses (rather than something like an actual meaningful rate). If that’s the case, that should probably be more clarified in the whole doc.
> 
> Mirja
> 
> 
> > Am 17.04.2016 um 16:06 schrieb Mirja Kuehlewind (IETF) <[e-mail]>:
> >
> > Hi,
> >
> > see below.
> >
> >
> >> Am 16.04.2016 um 15:20 schrieb Tirumaleswar Reddy (tireddy) <[e-mail]>:
> >>
> >>> -----Original Message-----
> >>> From: Mirja Kuehlewind (IETF) [mailto:[e-mail]]
> >>> Sent: Saturday, April 16, 2016 4:08 PM
> >>> To: Tirumaleswar Reddy (tireddy)
> >>> Cc: The IESG; [e-mail]; [e-mail];
> >>> [e-mail]; [e-mail]
> >>> Subject: Re: Mirja Kühlewind's Yes on draft-ietf-tram-stun-path-data-03:
> >>> (with COMMENT)
> >>>
> >>> Hi,
> >>>
> >>> see below.
> >>>
> >>>>>
> >>>>> A few questions that could potentially be further clarified in the
> >>>>> document:
> >>>>>
> >>>>> 1) How often should the request be retransmitted to get a qualified
> >>>>> loss measure ?
> >>>>> 2) What's the frequency of the retransmissions/pacing or wating
> >>>>> between retransmissions ?
> >>>>
> >>>> A STUN client retransmits a STUN request starting with an interval of RTO,
> >>> doubling after each retransmission. Retransmissions continue until a
> >>> response is received, or until a total of Rc requests have been sent. It is
> >>> discussed in https://tools.ietf.org/html/rfc5389 in detail.
> >>>
> >>> Okay, it wasn’t clear to me if you would send more retransmissions just to
> >>> measure loss.
> >>
> >> If there is response then there is no need to retransmit the STUN request.
> >>
> >>> If you don’t, how much retransmission do you usually see and
> >>> is this sufficient to get a reliable loss measure (see question one) ?
> >>
> >> If there is no response then the request is retransmitted, the rate of retransmissions and number of retransmissions are dependent on the protocol using STUN (e.g. ICE calculates retransmission timer (RTO) differently for media and non-media streams). It's up to the application if it wants to try just one transaction or NNN number of transactions to measure the path characteristics.
> >
> > Would it be possible to give some recommendation in this doc what an application needs to do to get an appropriate measure?
> >
> > Mirja
> >
> >
> >>
> >> -Tiru
> >>
> >>>
> >>>>
> >>>>> 3) How big is the overhead when retransmitting several times ?
> >>>>
> >>>> The overhead introduced by the new PATH-CHARACTERISTIC attribute is
> >>> just 4 bytes.
> >>>
> >>> Okay, again, wasn’t clear to me if you would need more request than usually
> >>> or not.
> >>>
> >>> Mirja
> >>>
> >>>
> >>>
> >>>>
> >>>> -Tiru
> >>>>
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>
> >>
> >
> 
> 
> 
> 
> -- 
> Founder, CEO, callstats.io
> http://www.callstats.io
> Analytics and Optimizations for WebRTC.
> 
> We are hiring: www.callstats.io/jobs/