Subject: Re: [Tsvwg] Paradox in draft-baker-tsvwg-mlpp-that-works-01

From: "James M. Polk" <[email-masked]>
Date: Mon, 22 Mar 2004 21:20:46 -0600

At 04:19 PM 3/22/2004 -0800, Fleischman, Eric wrote:
>We have studied possible QoS configurations for some time. One of our 
>conclusions is that reservation-based IP QoS systems (including also the 
>EF PHB (RFC 3246), if my memory serves) significantly wasted available 
>capacity and should therefore be avoided in all situations where explicit 
>over provisioning was not possible -- unless one was willing to have the 
>reservation-based traffic deprecate everything else.

A T1 is all that is between two LANs with 100 phones each.

How many calls can exist between those two LANs if the codec is only G.711 
(to keep this part of the argument constant)? Roughly 18, some might say 19 
depending on the underlying protocols used.

What's to prevent 50 calls from being set up between those two 
LANs?  Remember, call signaling is topology unaware - and needs to be 
considered topology unaware for serial hops where the destination isn't 
known topologically by the initiator, or the initiator's server.

Diffserv doesn't solve this problem. Using Diffserv, the 19th call will be 
placed and acknowledged by the endpoints with ~ 1% packet loss of all 
calls, not just this one call. The next call set-up causes ~ 4% more packet 
loss for all calls across that T1. The 21st makes it worse, and so on and 
so on... What's an acceptable packet loss percentage for the G.711 codec in 
your opinion? What stops this from happening? That something has to be 
topology aware to know exactly where the congestion is and how to 
prioritize some calls over other calls, and when to error new call signal 
set-up attempts. Diffserv doesn't know to do that either.

One of your arguments is based on MANET, and I haven't talked about it yet. 
First, I want to solve this boundary issue that is a real problem existing 
between these two LANs (as an example that will be prevalent in many 
scenarios within this domain).

Your other argument against this proposal is State signaling, quoting you: 
"... reservation-based IP QoS systems significantly wasted available 
capacity and should therefore be avoided in all situations..."

How much extra BW does RSVP take between these two LANs across that T1?

Does it reduce the available capacity by 1 call's worth? 2 Calls? 10 calls?

I wouldn't consider the BW necessary to reduce the overall number of calls 
between the two LANs by 1 call to be "significant", but I would consider 
losing the BW to make 10 calls to be significant. What findings did your 
study produce wrt the amount of overhead RSVP took away from calls being 
placed?

Your last argument, if I read this message correctly, was that we shouldn't 
be proposing RSVP because many consider it "dead". I must say that was a 
highly technical argument  ;-)  yet I find myself wanting hard examples of 
where this protocol doesn't work - and not what some would call the hype 
against something that was designed and not used for a long time.... RSVP 
is being used more and more especially wrt Video where there is no silence 
suppression.

>Two IETFs ago I asked many of the luminaries who had led the IETF's 
>various Int-Serv and Diff-Serv efforts over the years concerning what 
>major lessons they believed that we as a community learned from 
>implementing QoS. The unanimous answer (of those I queried) was that "the 
>only guaranteed effective QoS is over provisioning."

Did very many of your "luminaries" have this many RFCs published into 
*both* the topics (like my co-author does)?

         RFC3289 Management Information Base for the Differentiated
                 Services Architecture (PS)
         RFC3175 Aggregation of RSVP for IPv4 and IPv6 Reservations (PS)
         RFC2998 A Framework for Integrated Services Operation over
                 Diffserv Networks (INFO)
         RFC2814 SBM (Subnet Bandwidth Manager): A Protocol for
                 RSVP-based Admission Control over IEEE 802-style networks (PS)
         RFC2747 RSVP Cryptographic Authentication (SP)
         RFC2597 Assured Forwarding PHB Group (PS)
         RFC2474 Definition of the Differentiated Services Field (DS Field)
                  in the IPv4 and IPv6 Headers (PS)
         RFC2382 A Framework for Integrated Services and RSVP over ATM (INFO)
         RFC2214 Integrated Services Management Information Base
                 Guaranteed Service Extensions using SMIv2 (PS)
         RFC2213 Integrated Services Management Information Base
                 using SMIv2 (PS)
         RFC2208 Resource ReSerVation Protocol (RSVP) -- Version 1
                 Applicability Statement Some Guidelines on Deployment (INFO)
         RFC2206 RSVP Management Information Base using SMIv2 (PS)

I bring this up because you mentioned that your sample of luminaries had 
the unanimous opinion that RSVP is "dead".... and I find that opinion 
interesting - mostly as to who you might have asked (which you don't list) 
in Vienna.

>The recent ID published by Fred Baker and James Polk (both of Cisco) , 
>identified in the subject line above, acknowledges these lessons learned 
>to the extent of dividing the world's networks into those that can be over 
>provisioned ("10:1 over provisioning is often the cheapest and surest 
>solution" they wrote) and those operating within tight bandwidth 
>constraints. This ID, when combined with 
>draft-baker-tsvwg-mlef-concerns-01, jointly describe a very interesting 
>problem apparently confronting military networks of how to ensure that 
>only the more important communications are preferentially delivered in 
>times of crisis and/or congestion.
>While sympathizing with the military's problem, I am skeptical about Fred 
>and James' plan to use RSVP. While acknowledging that four years ago the 
>IETF's recommendation was "Int-Serv at the edge and Diff-Serv in the 
>core", which is exactly what Fred and James are now proposing, I want to 
>point out that other than NSIS (see 
>http://www.ietf.org/html.charters/nsis-charter.html) and some remaining 
>Telecom (SS7-like) and governmental (e.g., DISA) enthusiasts, I am not 
>aware of anybody anywhere else wanting to use RSVP, such that I have 
>considered the protocol to be essentially "dead". [Does anybody know of 
>ANY actual deployment actually using RSVP in any production network 
>anywhere in the world?  (I certainly don't.) If so, please educate me 
>about that deployment.] There are many reasons for this, including (1) 
>RSVP security is a real mess, lacking interoperable "standards" (e.g., no 
>defined key management -- see Section 5 of RFC 2747) such that there is no 
>guarantee that different vendor's products can interoperate if "secured". 
>(2) RSVP increases "state" in the middle of the network (rather than at 
>its edges), with the well-known problems associated with doing so. 
>(Introducing state in the middle is hard to do right, forcing developers 
>to make difficult (tragic?) choices.) My point being that if RSVP has not 
>previously worked in the past, why do the author's believe that it could 
>work now, especially for life-and-death military traffic?
>Yet I am wandering off-target. A paradox of Fred's and James' I-D posting 
>is that capacity constrained networks are singularly poorly equipped to 
>use capacity-wasting technologies such as reservations, since doing so 
>further reduces the available capacity of that network, thereby further 
>reducing the available capacity over what it would have been had no 
>reservations been used at all. Of course, James and Fred may simply argue 
>that this is for their customers to decide, and their customer have stated 
>a requirement to have a small very high priority subset be delivered 
>rather than risk the non-delivery of those critical items. OK, I admit 
>that this is a winning argument -- it is indeed the customer who 
>determines these types of things.
>However, this issue becomes more significant once one considers that many 
>of these capacity constrained networks may well be wireless networks 
>operating in MANET (mobile ad hoc network) environments. One of the facts 
>of life for fielded MANET devices is their network availability 
>performance is constrained due to signal interference by foliage, 
>landforms, and other causes. Many current suggests that 80% network 
>availability for MANET deployments is towards the high end of the scale.
>Because of this, one must question the use of a real-time signaling 
>protocol such as RSVP within such low availability networks, especially if 
>the reservation is to occur over multiple hops (i.e., assuming 80% local 
>availability, then two hops would be .8 * .8 = .64 local availability for 
>that circuit). I don't know what network diameter Fred and James are 
>envisioning, but I suggest that this approach is poorly suited to MANET 
>networks. Rather, a latency-friendly approach (e.g., EF PHB) would be a 
>much better design choice for such low availability environments.
>And this brings up a second paradox of Fred's and James' I-D: their design 
>for the resource constrained networks is primarily suited to the 
>high-availability characteristics of networks that can be overprovisioned, 
>and which therefore do not need to benefit from their approach. Rather, 
>for the class of networks needing the MLPP services they are addressing, 
>they need an approach that would cleanly work within low availability 
>environments.
>--Eric
>
>
>_______________________________________________
>tsvwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/tsvwg

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

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

---

From: [email-masked]
Date: Tue, 23 Mar 2004 10:57:16 EST

In a message dated 3/22/2004 10:24:55 PM Eastern Standard Time, 
[email-masked] writes:

I always love to see this admission in print. With circuit switched, we 
always get 23 calls across a T1 using G.711 (24 if the signaling is on a separate 
network, like SS7). And we don't have the unsolved problems that are detailed 
in the rest of this discussion (lack of topology aware call limiting 
algorithms, security.)

In a message dated 3/22/2004 10:24:55 PM Eastern Standard Time, 
[email-masked] writes:

So, if Diffserv can't solve this problem, why is it proposed as the 
"solution"?

Until there is a real solution to these problems, mission critical networks 
can't use VoIP.

Mike Pierce

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 24 Mar 2004 08:49:45 -0800

>known topologically by the initiator, or the initiator's server.

Your argument assumes that because telephony signals do call setup and 
reservations using SS7, that the underlying IP network of VoIP systems 
should behave in a similar same way. I am alarmed at this argument. As 
a former telephone guy, I understand where you are coming from, but 
the gulf between that position and IP and the Internet is so large, that 
I just don't want to go there. Rather, I want to point out instead that 
INTERNET protocols using IP usually seek to do admission control at the 
APPLICATION LAYER, not at the network layer. Furthermore, all attempts 
to do so to date at the IP Layer (e.g., Int-Serv) FAILED due to 
scalability reasons, and did so damaging the performance/resilience 
of the rest of the IP deployment.

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 24 Mar 2004 09:33:15 -0800

From: Ken Carlberg [mailto:[email-masked]] wrote:
<snip>

>Citing MANET is a good educated guess, but a bit off the mark.  Existing
>MLPP systems (in both military and commercial arenas) that are targets
>for migration from non-IP to IP based technology are not based on MANET
>characteristics -- ie, networks of nodes (hosts/routers) moving in
>relation to each other.  I also feel that discussions on anticipated
>network technologies and characteristics runs the risk of turning into a
>rat hole, so I'll stop here.  

I appreciate the wisdom within your comments, Ken, including the material 
I snipped above. However, speaking as a long term Operations guy, we end 
users are increasingly worried about end-to-end performance. I believe 
that the system that Fred and James are designing solely considered wired 
networks, without giving any thought to tactical field deployments. Worse,
the approach is unlikely to work in field environments, thus failing the 
critical end-to-end requirement.

>The focus of the discussion on these drafts (I feel) should be the
>technical strengths or weaknesses of protocols proposed as opposed to
>tangent topics of discussion such as market acceptance or network
>technologies/characteristics.  While I share your philosophical concerns
>(for lack of a better term) about reliance of RSVP due to lack of
>deployment across autonomous domains, I don't have *technical* concerns
>about RSVP as it is presented in these drafts.

I disagree with your point here, Ken. Had this community been seeking to 
explore novel (well, in this case, very old) ideas, then this draft could
be performing a valuable research function. But James and Fred introduced 
their topic as being a practical solution to an active military problem. 
This changes things into real world network operations. Within this 
milieu, mindshare (market acceptance) is very important because there are 
technical reasons, which often are not visible to researchers, which 
impact whether a technology can fly or not. Therefore, when somebody 
proposes a technology that has repeatedly failed to be deployed into real 
world networks, then one has to wonder why they think that this previously 
failed idea would work in this case (i.e., what has changed?).

--Eric

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 24 Mar 2004 11:42:05 -0600

At 08:49 AM 3/24/2004 -0800, Fleischman, Eric wrote:
>reservations using SS7,

You're the only one bringing up SS7 BTW...

>that the underlying IP network of VoIP systems
>should behave in a similar same way.

No, I'm not. I can have those 50 phones be SIP based without any server - 
meaning each phone signals its own set-up across that T1 to a phone on the 
other LAN.

In this scenario, how is the application layer of any device supposed to 
know the admission control parameters of the T1 and any other capacity 
constraints?

>I am alarmed at this argument. As
>I just don't want to go there.

If we are to understand each other - you might have to "go there" as you 
are the one making claims without any math, and math wins.

>Rather, I want to point out instead that
>APPLICATION LAYER, not at the network layer.

So... you are stating that the SIP phones themselves need to do some form 
of admission control between them in my example? I think that won't work.

Do the SIP phones know how many other SIP phones are on their LAN? no

Do the SIP phones know how much capacity there is on the LAN? "no - SIP 
doesn't care about BW" is the real answer, but the phone itself knows its 
connection rate on the LAN. It doesn't know if this rate is increased or 
decreased at any point between it and the called SIP phone - therefore the 
real answer is in fact "no". Each SIP phone is independent to one another, 
therefore none of the phones know at any given point in time whether any 
other SIP phones are taking any otherwise available BW fro themselves.

Can the SIP phone ever know about a constrained link between it and the 
other SIP phone (the one it calls)? No, it has no knowledge of the T1 and 
its limitation of BW.

If you add the dimension of priority levels determine which calls get 
through that T1, and you are really in the dark.

Ever single question and scenario I've mentioned is addressed by RSVP, yet 
you claim that protocol is a failure for unsubstantiated, non-technical 
reasons.

>Furthermore, all attempts
>scalability reasons,

You state Int-Serv "failed" (again) without the "why it failed". What 
studies are you referring to? What tests are you referencing? Can we (the 
list) have access to these references?

You're declaring something that isn't being proven on this thread.

I guess you don't want to know that one of our smaller routers scales to 
150,000 simultaneous RSVP flows.... but you will probably still claim 
that's a scaling problem.

>and did so damaging the performance/resilience

By how much did it damage the performance?

By what percentage or ratio did you find the performance degraded in your 
studies when RSVP was used vs. when it was not used?

By how much did it damage the resilience?

How did you measure this?

cheers,
James

                                *******************

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 24 Mar 2004 09:39:18 -0800

The "luminaries" didn't say that "RSVP is dead". That is my own conclusion since 
I am not aware of even a single deployment that has successfully used it. Hence 
my request to the list to please educate me should such a deployment exist. 
[Note: the only people I am aware of actually using RSVP experimentally today 
are telephony people who I suspect are trying to make IP evolve towards SS7. 
I haven't heard of any successes from their camp, but I lack visibility into 
it, and so would welcome evidence proving my conclusion wrong.]

It is true that I didn't speak with Fred at the IETF, but I did indeed speak 
with the authors of many of your listed documents. The unanimous conclusion of 
those I did speak with was that "the only guaranteed effective QoS is over 
provisioning."

Please note that I am not trying to state dogma or form a religion. I am merely 
explaining the view from my knot hole and questioning why you think your approach 
will succeed any better than all of the other people who have unsuccessfully tried 
that approach in the past. So please educate me: What is different about your 
approach such that you believe that it will succeed?

-----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: Monday, March 22, 2004 7:21 PM
To: Fleischman, Eric; [email-masked]
Cc: [email-masked]
Subject: Re: [Tsvwg] Paradox in draft-baker-tsvwg-mlpp-that-works-01

<snip>

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 24 Mar 2004 20:12:58 -0500

>other SIP phones are taking any otherwise available BW fro themselves.

I think there is a simple approach that can be used to notify end
applications like SIP phones if the traffic load threshold has been reach
along the path end-to-end. How about configuring a router to measure the
amount of VoIP traffic is flowing on a BW constrained links in the network
and set bit 6 or 7 of the DS Field in the IP header of VoIP packets to
indicate to the application (SIP phone) when the BW limit of the number of
VoIP flows along that path as been reached. Application (SIP) looks at bit 6
or 7 of the DS Field in IP header to determine if it should or should not
admit new flow. 

>other SIP phone (the one it calls)? No, it has no knowledge of the T1 and 

Using the above method it can.

My view is that the network needs to inform the application of congestion or
that configured traffic load level threshold has been reached and have the
application performs admission control.  

Regards, Joe.
Jozef Babiarz

---

From: "Jozef Babiarz" <[email-masked]>
Date: Fri, 26 Mar 2004 00:53:34 -0500

[Romascanu, Dan (Dan)] Wrote:

I am afraid that this would not work. Adding semantics to the don't care DS
field bits is not enough. One of the reasons is that network conditions can
change, and as a result packet routes in an IP telephony session can change
during a session. The SIP original session establishment session is not
re-done in these conditions, exactly because from session control point of
view the call continues 'in the cloud' and SIP is 'agnostic' to topology or
media conditions. You have no guarantee actualy that the initial session
establishment and the subsequent IP telephony traffic follow the same path.
This is why the reservation mechanism and soft-state maintained the RSVP
routers have been put in place. 

You can insure that the test flow during call setup takes the same path as
VoIP packet will once the application (call admission control) determines
it's OK to do so. The end devices (SIP phones or other) can start sending
what I call probe RTP packets or flow and once the path has been verified
the application enables sending of real voice packets which will use the
same protocol, IP address and port number. The sending of probe RTP packets
during call setup adds about one RTT to call setup which is usually less
then 80ms in carrier network for calls within North America. Significantly
less time than any other method that can be used to make BW reservation in
the network end-to-end.

Now if there is a route change after the call has been established, yes a
path (link) may reach or surpass the bandwidth allocation threshold that is
engineered for VoIP traffic. However, reaching or surpassing this threshold
is not and indication that VoIP packets will be dropped or delayed in
queues. All it means is that the VoIP service is oversubscribed on that and
BW is borrowed from other non real-time services until such time as the
application or the network can respond. If it does happened that VoIP flows
exceed engineered BW threshold the router sets bit 6 or 7 of DS Field and
provides indication back to the application to take action. Depending on the
application and the type of serves being offered, different actions can be
taken. For VoIP one possibility would be to change reduce encoding rate from
G.711 to G.729, other could be turn on silence suppression, in some case
terminate the flow, etc.  Normally, I would engineer the bandwidth threshold
for VoIP service and the network so that route changes do not affect quality
of the established VoIP flows in the network.

Regards, Joe. 
Jozef Babiarz

---

From: "Jozef Babiarz" <[email-masked]>
Date: Fri, 26 Mar 2004 00:55:40 -0500

Fred Wrote:
>Well, yes, and let me take the comment a step further.

>I assume that Josef was in fact referring to the use of the CE field, which

>is bits 6 and 7 of the TOS byte, the remaining two bits of the byte not 
>consumed by the DSCP, as described in RFC 3168. The telephone would set one

>of the ECT values, perhaps alternating, and the router that passed the 
>traffic would set CE.

>There are some issues in the definition. RFC 3168 cuts across three layers 
>in a rather unfortunate manner - it specifies what TCP does, what IP does, 
>and how the driver or bit of hardware out on an interface card sets the 
>flag. In the last, it specifically associates ECN with AQM, which EF 
>recommends that people not use. So we need to extend the definition
somewhat.

Not quit but similar concept. As VoIP traffic is real-time and does not use
TCP therefore a new syntax and treatment needs to be defined for VoIP and
other real-time traffic. Fred you are correct that what is defined in RFC
3168 will not work for VoIP or other real-time traffic. The ECN treatment is
applied on per DSCP so in a network both can exist, one defined in RFC 3168
and one that needs to be defined for VoIP and other real-time flows. By the
way, I'm not suggesting that AQM be used for VoIP traffic. Also the term
Explicit Congestion Notification (ECN) is not best way to explain the
function.  

>There are also issues in the codecs: some codecs are variable rate, and 
>even the fixed rate codecs can be used with Voice Activity Detection (VAD).

>In such cases, the presence or absence of congestion is highly variable - 
>as various speakers start and stop speaking, loads change.

Measurement techniques exist today and are used in packet networks to
measure aggregated voice flows for variable and fixed rate codces with or
without VAD. However, it does require careful selection of parameters and
understanding the effect VAD, variable rate codecs, new voice flows starting
and ending, etc. This problem exits also in any system that performs BW
reservation, what you reserve normally does not equal actual BW used.  

>The effect of Josef's proposal, I think would be to allow the phone to 
>ring, the lady to jump out of the shower, grab a towel, run to the kitchen 
>to grab the phone, and then have the call be dropped because it is running 
>across a congested line. Yes, I'm being melodramatic, but I am doing it for

>a reason. RFC 3312 was written the way it was for a very specific reason: 
>if the phone call will not be successful, they really don't want to ring 
>the phone. This absolutely rings the phone.

Fred, I do not think you understand my proposal. Simply put, there is a test
using RTP flow that is performed during and for every VoIP call setup. If
the results is that the BW that has been allocated for VoIP traffic along
the path that VoIP packets will take has been reached the application
(admission control function in a SIP proxy)is notified by one of the so
called ECN bits. So if the engineered BW limit of actual calls along the
path has been reached, new call will not be admitted, the telephony will not
ring, ...

Joe.