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

From: Janet P Gunn <[email-masked]>
Date: Mon, 2 Feb 2004 17:12:48 -0500

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 <[email-masked]>                                            
                                               cc:      [email-masked]                                                          
                      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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Fred Baker <[email-masked]>
Date: Tue, 03 Feb 2004 15:37:55 -0800

At 02:12 PM 2/2/2004, Janet P Gunn wrote:
>[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.

I'll agree that it is elitist :^)

However, I'll submit that if there is bandwidth-aware CAC, there should not 
be a great amount of loss. Loss will come from periods in which variable 
rate codecs (VAD etc) happen to all have an "up" moment and go over the 
top, resulting in a few packets lost from each call, or from the normal 
conditions (say "wireless") that cause random loss in networks. If there is 
not bandwidth-aware CAC, then we are discussing the depth of 
overprovisioning - either you did enough or you didn't. If you did, I'm not 
sure what we're discussing - there is going to be plenty of bandwidth, and 
the SIP reason code and resource priority stuff handles call collisions. If 
you didn't, we're not talking about occasional dropped packets, we're 
discussing lost packet groupings in rough multiples of individual call 
volumes. In the latter case, one really wants to refuse or preempt calls.

The discussion of what packets to drop when on alternate Tuesdays the moon 
skips a beat in its orbit seems a very secondary consideration to 
delivering a solid service all of the time.

>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 

I don't know if you heard about the demo we showed DISA and others in 
December. I don't think anybody is arguing that the ETS/MLPP/whatever calls 
need to be intelligible. The issue is that the calls you keep are paying 
for their bandwidth too, and are not getting the service you sold them if 
you're heaving their packets willy-nilly. At the end of the day, depending 
only on packet dropping (and yes, Mike, I heard you say in private email 
that you like CAC too, but I'm looking for the architectural document that 
says that and I'm having trouble finding it) doesn't deliver that.