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

["MORITA, Naotaka" <[e-mail]>]

Ruediger,

Thank you so much for your mail.

At 11:24 03/08/08 +0200, Geib, Ruediger wrote:
>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).

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.

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

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.

>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?).

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.

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

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.

>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

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
>T-Systems
>Systems Integration
>Senior Expert, Technologiezentrum
>Am Kavalleriesand 3, 64295 Darmstadt
>Germany
>Fon: [phone]
>http://www.t-systems.com
>
>
>_______________________________________________
>tsvwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/tsvwg

----------------------------------
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. [phone], ISDN-Fax [phone]
E-mail: [e-mail]
MSN messenger: [e-mail]
NTT home page: http://www.ntt.co.jp/about/e/index.html 



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