Subject: Re: [Tsvwg] Admitted Real Time Services

From: Fred Baker <[email-masked]>
Date: Fri, 12 Jan 2007 04:50:34 +0100

On Dec 18, 2006, at 9:22 PM, [email-masked]  
wrote:

> i should have been more specific - the whole discussion about  
> signaling is beyond the scope this document whether performed at at  
> the network (RSVP) or the session layer (SIP) or any other  
> signaling technique being currently under discussion at IETF - this  
> doc. should not discuss about the call-level but stick to packet- 
> level processing and related operations (that should translated in  
> a DS configuration profile)

Given that we already have a class for voice in RFC 4594, and this is  
is creating one with the specific characteristic that it requires (as  
opposed to the existing-and-deployed one that merely recommends and  
in many cases doesn't use) capacity admission, I'm at a loss to  
figure out why you would want to remove capacity admission from the  
document.

Can you please state why you think this is as you see it?

---

From: [email-masked]
Date: Sun, 21 Jan 2007 21:43:46 +0100

> Can you please state why you think this is as you see it?

reasoning is rather simple i don't see in this document the 
real value to assume capacitive admission control (rather
than assuming it would bring any real value) 

henceforth, i don't see the reasoning for recommending any 
specific user-control driven (signaling) admission control

would it be possible that the reasoning behind such specific
recommendation is spelled out before comparing the different
protocol implementations that would fit any specific need

take an example of an exceptional calamity situation would
this approach provide any benefit ?

more fundamentally i tempted to say that all the techniques
that are spelled out in this document are reminiscences of
PSTN traffic control instead of considering the techniques
that are inline with packet-based networks

thanks,
- d.

Fred Baker <[email-masked]>
12/01/2007 04:50
 
        To:     [email-masked]
        cc:     "James M. Polk" <[email-masked]>, Lars Eggert 
<[email-masked]>, [email-masked]
        Subject:        Re: [Tsvwg] Admitted Real Time Services

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 Jan 2007 16:25:05 -0800

On Jan 21, 2007, at 12:43 PM, [email-masked]  
wrote:
> take an example of an exceptional calamity situation would this  
> approach provide any benefit ?
>
> more fundamentally i tempted to say that all the techniques that  
> are spelled out in this document are reminiscences of PSTN traffic  
> control instead of considering the techniques that are inline with  
> packet-based networks

well, yes, they are. In the PSTN, you have some number of circuits to  
hand out, and using the control plane to hand them out handles all  
conditions that happen - pretty well. In the Internet, we have some  
amount of bandwidth to hand out. I haven't heard any argument that  
doing so in a similar control plane would be ineffective. Field  
operational experience says that it in fact works.

Now, we can have a religious debate if you like. If your argument is  
"I don't wanna", you're right in there with a whole lot of people.  
But it's not a rational argument, it is digging heels in.

In the past couple of years, the working group has been over and over  
the ECN proposal, which is characteristic of a number of measurement- 
based algorithms. It has looked at Morita's document (http:// 
www3.ietf.org/proceedings/03jul/slides/tsvwg-2.pdf, http:// 
tools.ietf.org/html/draft-morita-tsvwg-pps, http://tools.ietf.org/ 
html/draft-morita-tsvwg-mfverify), and a variety of others. I won't  
repeat the various arguments, but I will note that Morita-san pulled  
his proposal when he worked out that it operationally wasn't adequate  
to handle MPEG-4 video even without thinking about differential  
policy, and I will note that while folks will generally agree that a  
guard band model (which is statistical and therefore depends on the  
law of large numbers) works when there are large numbers of flows and  
large bandwidths to carry them, this isn't necessarily true in access  
paths. Hence, ECN may be sufficient for optical backbones, but there  
is no guarantee that it does anything in access paths.

Says the guy who buys "business broadband" from Cox Cable, an AT&T  
subsidiary, at $94/month and gets 256 KBPS upstream capacity...

What you're arguing is in essence that RFC 4594's telephony class is  
sufficient for preferential call management. My co-author and ATIS  
working group chair says that ATIS and the companies that do their  
work there disagree...