References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt

Comments in line.

----------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------

                      Fred Baker <fred                                                                                           
                      @cisco.com>              To:      Janet P Gunn <jgunn6@csc.com>                                            
                                               cc:      ieprep@ietf.org                                                          
                      01/27/2004 09:35         Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt              
                      PM                                                                                                         

At 12:32 PM 1/27/2004, Janet P Gunn wrote:
>As Fred Baker says in draft-baker-tsvwg-mlpp-that-works.00.txt, if call
>admission is working properly, traffic marking is not needed in normal
>operations.

lest I be misunderstood, let me restate that. What I wrote was:

    One will ask the value of the multiple DSCPs. They are, in fact, of
    limited to no value in normal operation, as all vice and video
    traffic should have been admitted, and therefore capacity will have
    been assigned to them. The behavior of this service will be
    indistinguishable from the EF PHB regardless of traffic marking.

In retrospect, I wonder what the vice traffic would be :^)

[jpg] Maybe all that "organ enlargement" spam?

This is not to be understood as saying "no traffic marking is required";
one still needs RFC 3246. But if bandwidth admission is operating
correctly, having N different marks will be operationally indistinguishable
from having a single EF mark, as the total number of bytes on the wire will
be the same.
jpg], I did understand that.  I was oversimplifying to make my point.

>It is in this context that ETS calls must be given a high probability of
>meeting the QoS criteria, even when network congestion and or damage are
>severe.

I wonder if we are communicating here. RFC 3246 is designed to operate in a
congested network, and to operate in a network in which routing may change.
The comment in the mlpp-that-works draft - which if it is giving cause for
confusion I will happily remove - is basically me bending over backwards to
be intellectually honest and see if I can find a case where CAC may be
insufficient.

[jpg] And I was blatantly taking advantage of your "bending over backwards"
- to identify a case where CAC may not be sufficient for the ETS Voice
application.

Think about this for a moment: the argument being placed for MLEF is that
even in the presence of some loss, voice is intelligible. If that is true,
then just after a route change, during the brief interval between the data
flow being switched to a new path and the CAC following that and either
OKing the flow or deciding to shut down the call, when there may be some
loss, voice should be equally intelligible, no?

 Or does the argument that voice is able to work around a modest level of
loss only work when it comes from the proponents of multiple code points?

[jpg] In the ETS voice scenario, I am NOT trying to say that "voice is able
to work around a modest level of loss".  I am taking the highly elitist
position that, if there is a situation where SOME "calls" are going to have
to lose packets, I want it to be the non-ETS calls (whether or not the
non-ETS calls remain intelligible or not) that lose packets, and not the
ETS calls.

[jpg] I further agree that, in any situation where "calls" are losing
packets, it is highly desirable to "do something" so that you have some
calls that remain up and intelligible, and so that other calls go away,
rather than using up bandwidth sending packets that are not "useful" from
the end user's perspective.  And whatever that "something" is, I want it to
be able (assuming the appropriate business agreements are in place) to
slant the odds in favor of the ETS calls being the ones that stay up and
intelligible.

Janet
<< Attachment Removed : C.DTF >>

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep