Subject: [Tsvwg] Comments on draft-morita-tsvwg-pps

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 8 Aug 2003 11:24:15 +0200

Hello Naotaka,

I think that pps is a good 
idea. Having not to maintain QoS signaling 
state in a backbone router is a pretty 
good thing to do.

Some comments on contents:

Section 4 suggests two stage monitoring 
of end-system behaviour. I agree that abuse 
must be prevented at the source. You don't 
talk of signaling there, but I guess it 
could be part of a two stage monitoring 
solution (you mention however a "declared 
peak bit rate" - sounds like signaling 
to me).

Section 5 is about system behaviour in the 
case of congestion. Would something like 
an "explicit congestion notification" of 
the backbone be useful? If end systems 
could, as a reaction on such a congestion 
indication, use codecs with lower bit rate 
for their MF-H traffic, additional calls 
may be accepted. 

Section 7.1: I'm not a queuing expert, but 
why would MF-M traffic see higher jitter? 
Aren't all MF packet in the same queue and 
those tagged as MF-M are discarded earlier? 
The result is higher loss probability, 
which is intended. But it shouldn't be 
higher jitter (don't earlier losses make 
it look like a "shorter" queue?).

Section 7.4 suggests the transmitter not to 
pause at the edge. ISPs may charge on volume 
and customers won't be happy if their 
terminal creates traffic while they aren't 
active. 
I understand the issue and I should offer 
an alternative. Some form of signaling based 
admission control in combination with 
measurements?

Section 7.5: The RMONMIB WG maintains some 
drafts promoting RAQMON. I'm not familiar with 
details, but your media monitoring server might 
require similar functionality. If you are 
interested:
http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-framework-02.txt

Regards, Rüdiger

Rüdiger Geib
T-Systems
Systems Integration
Senior Expert, Technologiezentrum
Am Kavalleriesand 3, 64295 Darmstadt
Germany
Fon: +49 6151 832138
http://www.t-systems.com

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "MORITA, Naotaka" <[email-masked]>
Date: Mon, 11 Aug 2003 13:25:00 +0900

Ruediger,

Thank you so much for your mail.

>peak bit rate" - sounds like signaling

Yes, you are correct.  In order to monitor or audit
the terminal behavior, I expect some signaling mechanism
to initiate two stage monitoring.
I am not yet clear enough whether new functions are necessary.
I will provide them in the revised ID, if any.

>for their MF-H traffic, additional calls

In section 4, I briefly touch on the possibility of
"explicit congestion notification."
At this stage, just for the sake of the simplicity and being easy to deployment,
I concentrate on "implicit" notificaiton such as packet loss.

>it look like a "shorter" queue?).

In case of one queue model, you are right.
But, I want to see the possiblity ot two queue model.
In such case, the jitter of MF-M will be higher than the MF-H.

>admission control in combination with

There are two ways of charging.
One is simply to count the number of packets.
The other is to measure the session duration, and multipiled by the 
declared rate.
Personally, I think the latter is easy to implement, but depends on
edge router's capability.

In any case, if the transmitter suspend and resume sending packets with a 
long interval,
it will impact on the mulplexed traffic characteristics.
If such impact is great, the edge router has to terminate the media to avoid
the big fluctuation.

>http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-framework-02.txt

Thank you so much.  I will review it.
One of the difference would be to audit the forward RTP flows as well as
backward RTCP flows and check the copprespondence between them.

Naotaka

>Regards, R$B—E(Biger
>R$B—E(Biger Geib

----------------------------------
Naotaka MORITA, Senior Research Engineer, Supervisor
Network Service Systems Laboratories
Information Sharing Laboratory Group
NTT
3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN
Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012
E-mail: [email-masked]
MSN messenger: [email-masked]
NTT home page: http://www.ntt.co.jp/about/e/index.html