Subject: [tcmtf] Multiplexing period as a metric

From: Mirko Sužnjević <[email-masked]>
Date: Sat, 25 May 2013 08:51:15 +0000

Hello everybody,
I have a question regarding the Multiplexing period we mention in our proposal.
Should we define it firmly as a metric, as instructed in the RFC 6390 Guidelines for Considering New Performance Metric Development? Could this period be considered as a full metric?
For me the most interesting questing in RFC 6390 is:
(i) the degree to which its absence would cause significant loss
      of information on the behavior or performance of the application
      or system being measured
I think that apsence of this metric does limit our information about system performance. Again Multiplexing period as such now is only defined by its limit. Also, it would be dependent on the employed techniques for particular network path and so on.

Do you think there is a need to define this as a metric?

Thanks for the advices.
Best regards,
Mirko Suznjevic

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 27 May 2013 13:16:35 +0200

Hi, Mirko. I have had a look to rfc6390, and it is really interesting. This
is my opinion:

- Performance metrics could be really useful for Draft B (
<http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/>
http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/). In fact,
the title of the draft is "Maximum Tolerable Delays ." so we should clearly
define that delays according to a metric.

- Regarding the question "should multiplexing period be defined as a
metric"? My answer is "no", but it should be considered as the delay added
by a "middlebox". If you see RFC 6390, 5.5.4:

5.5.4. Middlebox Presence

Presence of a middlebox [RFC3303], e.g., proxy, network address

translation (NAT), redirect server, session border controller (SBC)

[RFC5853], and application layer gateway (ALG), may add variability

to or restrict the scope of measurements of a metric. (. . .)

Multiplexing period is something that has an influence on overall delay: it
adds a new delay (half the period in average) and jitter (since packets
arriving at the beginning of the period are delayed more than packets
arriving just before the multiplexed packet is sent).

- The delay for a real-time service is a very important metric. If we are
able to characterize the modification of delay when a multiplexer is added,
we can have an estimation of the delay increase when multiplexing.
Multiplexing is something transparent to the two ends of the communication.
Packets may travel in a multiplexed way only in a certain network segment,
so the only noticeable effect for the extremes is additional delay and
jitter.

Well, in fact, the delay increase is easy to calculate: half the period. In
this paper
<http://diec.unizar.es/~jsaldana/personal/ccnc_2012_july_in_proc.pdf>
http://diec.unizar.es/~jsaldana/personal/ccnc_2012_july_in_proc.pdf we
calculated the modification of the jitter.

If we use a timeout instead of a fixed period, things are slightly
different:
<http://diec.unizar.es/~jsaldana/personal/letters_2011_in_proc.pdf>
http://diec.unizar.es/~jsaldana/personal/letters_2011_in_proc.pdf. We can
save more bandwidth, but we would add more jitter.

What do you think?

Jose

De: [email-masked] [mailto:[email-masked]] En nombre de
Mirko Sužnjevic
Enviado el: sábado, 25 de mayo de 2013 10:51
Para: [email-masked]
Asunto: [tcmtf] Multiplexing period as a metric

Hello everybody,

I have a question regarding the Multiplexing period we mention in our
proposal. 

Should we define it firmly as a metric, as instructed in the RFC 6390
Guidelines for Considering New Performance Metric Development? Could this
period be considered as a full metric?

      or system being measured

I think that apsence of this metric does limit our information about system
performance. Again Multiplexing period as such now is only defined by its
limit. Also, it would be dependent on the employed techniques for particular
network path and so on.

Thanks for the advices.

Best regards,

Mirko Suznjevic

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 27 May 2013 13:30:57 +0200

Just another Idea I had while reading RFC 6390. If you have a look to "5.2.
Definitions of a Performance Metric", you can see that metrics can be
defined as the composition of different metrics which can be obtained from
the network.

The idea is: it is clear that VoIP quality depends on Delay and Packet loss.
In fact, the MOS depends on that.

However, online games react differently to delay, packet loss and jitter.
For example, Quake III works perfectly with 35% packet loss, whereas Halo
stops working with 4% packet loss (1). And (2) talked about defining
different weights for calculating the MOS from delay, jitter and loss.

Perhaps we could consider the possibility of having an idea of the service
(game) we are multiplexing, and having some heuristics of the influence of
delay and jitter in order to select an appropriate multiplexing value.

Well, I don't know if this falls within the scope of the current draft, but
we could keep it in mind.

Thanks!

Jose

(1) S. Zander, G. Armitage, "Empirically Measuring the QoS Sensitivity of
Interactive Online Game Players". In Proc. Australian Telecommunications
Networks & Applications Conference (ATNAC 2004), Sydney, Australia, Dec.
2004.

(2) Ubicom White Paper, "OPScore, or Online Playability Score: A Metric for
Playability of Online Games with Network Impairments", 2005,
http://www.kevingee.biz/wp-content/uploads/2011/04/IP3K-DWPOPSCORE-10.pdf

Hello everybody,

      or system being measured

Thanks for the advices.

Best regards,

Mirko Suznjevic

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 29 May 2013 17:38:34 +0200

Mirko,

Regarding the use of "jitter", we could better use "delay variation" in the
Draft B:

RFC 5481 says:

   This memo uses the term "delay variation" for metrics that quantify a
   path's ability to transfer packets with consistent delay.  [
<https://tools.ietf.org/html/rfc3393> RFC3393]
   and [ <https://tools.ietf.org/html/rfc5481#ref-Y.1540> Y.1540] both
prefer this term.  Some refer to this phenomenon as
   "jitter" (and the buffers that attempt to smooth the variations as
   de-jitter buffers).  Applications of the term "jitter" are much
   broader than packet transfer performance, with "unwanted signal
   variation" as a general definition.  "Jitter" has been used to
   describe frequency or phase variations, such as data stream rate
   variations or carrier signal phase noise.  The phrase "delay
   variation" is almost self-defining and more precise, so it is
   preferred in this memo.

Best regards,

Jose

Hello everybody,

      or system being measured

Thanks for the advices.

Best regards,

Mirko Suznjevic