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

[[e-mail]]

Janet and all

I have been biting my tongue (ops fingers) for some time now with
regards to the MLPP service for supporting ETS in IP networks. As this
service has a potential problem as shown by the following scenario:

If a call/session is in progress between a non authorised ETS user and a
emergency service then this should never be subject to pre-emption by a
authorised ETS user, it could have fatal consequences. This by extension
could be applied to a call/session in progress between non authorised
ETS users, as this contact could be the only point of hope for someone
in trouble.

In other words the only justification for a pre-emption by a authorised
ETS user is that it is only applied to call/session if both the content
and context have been analysed. This seems to be a lot of work in a
congested network.

I have no problems with multiple precedence's or priorities if they are
required but I only see the need for two a 'normal' call/session and a
'ETS' call/session. 

This shows that there maybe a need to take into account the consequences
of the requirement to support MLPP especially in regard to pre-emption. 

Regards

Steve Norreys  
Signalling and Protocols
Tel:       [phone]
email    [e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Janet P Gunn
Sent: 02 February 2004 22:13
To: Fred Baker
Cc: [e-mail]
Subject: 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
<[e-mail]>                                            
                                               cc:      [e-mail]

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

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