Re: [tcmtf] Multiplexing period as a metric

["Jose Saldana" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] En nombre de
Mirko Sužnjevic
Enviado el: sábado, 25 de mayo de 2013 10:51
Para: [e-mail]
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?

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