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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Mar 2004 05:32:26 +0200

Joseph, 

See in-line. 

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Jozef Babiarz
Sent: 25 March, 2004 3:13 AM
To: James M. Polk; Fleischman, Eric; [email-masked]
Cc: [email-masked]
Subject: RE: [Tsvwg] Paradox in draft-baker-tsvwg-mlpp-that-works-01

James M. Polk wrote: 
>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. 

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. 
[Romascanu, Dan (Dan)] 

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. 

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

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: Fred Baker <[email-masked]>
Date: Thu, 25 Mar 2004 12:18:34 -0500

At 05:32 AM 03/25/04 +0200, 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.

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.

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.

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.

And now, having described the issue in a policy-free context, we need to 
discuss the application of policy (this might be viewed as a restatement of 
Mike's last note in my words). Policies can be very simple, such as "have 
the calling and called parties both paid their bills? If not, no call." In 
the MLPP case, it is very complex: there are various priorities and the 
expectation is that someone can place a call when life is just really too 
interesting out in the network and some fairly specific things will 
deterministically happen, including chimes and preemption. To make such a 
policy work in a distributed fashion, wherein the telephones with no global 
knowledge decide which of them is going to respond to the onset of 
congestion in the network, in a deterministic manner is fairly complex.

And it lacks an important capability, which is the capability of the 
network manager to enforce the policy. It depends on the telephone's 
correct and un-hacked implementation of a carrier's policy by a device that 
is neither owned nor controlled by the carrier.

I'm sympathetic. But it just doesn't work.  

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 25 Mar 2004 13:58:57 -0700

Fred,

Please allow me to jump into this discussion and focus on a few things that
appear to be misconceptions about the telephone network.

Please see comments below...

> the phone. This absolutely rings the phone.

Think for a moment on what the telephone network does here.  In the old analog
in-band signalling network, the fact that this lady's phone was ringing meant
that there was verified metallic continuity between the calling and called
parties (at least from access ingress switch to access egress switch).  When
the PSTN was converted to digital transmission facility and SS7 this was no
longer immediately the case.  Just the fact that a circuit has been
provisioned between two switches does not mean that the transmission facility
is always available.  Often, digital multiplex equipment disrupts passing
carrier alarm information across the mux, and a transmission facility or
E1/T1/J1 span can be unusable without a switch having knowledge.  The solution
in the telephone network was to pass an in-band verification tone down the
speech path to verify continuity before call setup completed.

A phone using a packet network directly, or an access gateway, would be rather
naive to presume that a speech path existed at any grade of service just
because a signalling path exists.  This is not admission control, but simple
verification.  It can easily be performed at the phone or at an access gateway
by exchanging a verification pattern suitable to the target codec end to end
before completing call setup.  An RTP that also performs slow start and
congestion procedures would work well for this approach.  If a stricter
criteria for acceptance of verification is applied that is applied mid-call to
determine whether to abort a call due to unacceptable speech path grade better
stability in the face of excessive call offerings can be achieved.

> is neither owned nor controlled by the carrier.

I recall one carrier (when there was only one carrier) being concerned about
"hacked" telephone sets.  So much that they believe that no person should own
a telephone and, in fact, at the time, all telephones were owned by that
carrier.  Permitting someone to own a telephone consisted of placing a costly
but rarely necessary mediation circuit on the line card at the CO.  In a like
way, it is alway possible to police the policy at the access gateway, be it a
router or a SIP proxy, either through regulation or a technical interface.

I find it hard to believe, however, that this would be a problem in an MLPP
environment, where strict control of the terminal down to rigorous physical
access security is the norm.  Even gaining physical access to a common network
that carries flash-override traffic should require, as is typical, the highest
levels of clearance.  Access to flash-override-override facilities (which, to
my knowledge are never shared with lower precedence facilities) should even
require the physical absence of its intended user to preclude any remaining
possibility of service interruption.

> I'm sympathetic. But it just doesn't work.  

It sounds like you have stopped looking for solutions, when the simple
application of a few basic telephony principles at the terminal device, or
access gateways, would go a long ways toward addressing all of the MLPP
requirements.

If you think that RSVP or any network-level bandwidth allocation (instead of
just a next-hop approach) would be of benefit, consider that telephone
switches only perform next-hop routing themselves, and dynamic controlled
routing (DCR) in the long-distance network did not achieve much in this
regard, even with a restricted number of class 3 switches.  In general to try
to solve the NPH (traveling salesman) problem in real time can only at best
be approximated and only at long intervals for networks with a very small
number of nodes.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦