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

From: "Mirja Kuehlewind" <[email-masked]>
Date: Fri, 15 Apr 2016 13:25:25 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tram-stun-path-data-03: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?
3) How big is the overhead when retransmitting several times?

Thanks!

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 16 Apr 2016 05:29:13 +0000

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: Saturday, April 16, 2016 1:55 AM
> To: The IESG
> Cc: [email-masked]; Simon Perreault; tram-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Mirja Kühlewind's Yes on draft-ietf-tram-stun-path-data-03: (with
> COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> measure ?
> 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. 

> 3) How big is the overhead when retransmitting several times ?

The overhead introduced by the new PATH-CHARACTERISTIC attribute is just 4 bytes.

-Tiru

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 16 Apr 2016 12:38:26 +0200

Hi,

see below.

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

Okay, it wasn’t clear to me if you would send more retransmissions just to measure loss. If you don’t, how much retransmission do you usually see and is this sufficient to get a reliable loss measure (see question one)?

> 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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 16 Apr 2016 13:20:11 +0000

> From: Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Sent: Saturday, April 16, 2016 4:08 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: The IESG; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Mirja Kühlewind's Yes on draft-ietf-tram-stun-path-data-03:
> (with COMMENT)
> 
> Hi,
> 
> see below.
> 
> >>
> >> 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.

 -Tiru

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sun, 17 Apr 2016 16:06:04 +0200

Hi,

see below.

> Am 16.04.2016 um 15:20 schrieb Tirumaleswar Reddy (tireddy) <[email-masked]>:
> 

Would it be possible to give some recommendation in this doc what an application needs to do to get an appropriate measure?

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sun, 17 Apr 2016 16:15:32 +0200

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) <[email-masked]>:
> 
> Hi,
> 
> see below.
> 
>

---

From: Varun Singh <[email-masked]>
Date: Sun, 17 Apr 2016 17:37:00 +0300

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) <
[email-masked]> 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
>
>
> >> 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
> >>
> >>>
> >>>>
> >>> 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/

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 20 Apr 2016 12:11:25 +0200

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 <[email-masked]>:
> 
> Hi Mirja,
> 
> I agree, the metric being measured is fractional loss, and not the loss rate. This should be fixed. 
> 
> To your other comment:
> 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) <[email-masked]> wrote:
> Hi again,
>