Subject: Re: [Tsvwg] please review changes

From: Bob Briscoe <[email-masked]>
Date: Fri, 23 May 2008 11:01:30 +0100

Fred,

[I've cc'd tsvwg as requested]

At 22:04 22/05/2008, Fred Baker wrote:

>On May 22, 2008, at 1:00 PM, Bob Briscoe wrote:
>>>In my original review comments, I had a whole tract about this
>>>(after the request to split the draft) that seemed to get glossed
>>>over. It included carefully considered alternative text for S.3.
>
>I'll go back and look for that.
>
>>>>- why isn't it sufficient to have a combination of a non-blocking
>>>>core and a non-meshed backhaul with call-counting into the VOICE-
>>>>ADMIT class?
>>>
>>>Because of the issues of multiple policies noted in section 2.3. Call
>>>counting is fine if you have a very static network that is carefully
>>>engineered and you are only trying to hit approximate limits. The
>>>engineering can make one crazy, and God help us if we add anything
>>>resembling mobility to it. Call counting was fine when Dale Skran
>>>proposed it in H.323 in 1995 (in the Yokosuka and Ipswich meetings, I
>>>was there) and it is carefully explained that one has to have a way
>>>to convince an IT manager that VoIP won't trash his LAN. If there are
>>>multiple codecs in use with multiple data rates, if one-way
>>>transmissions are in use (video), if ..., call counting is very
>>>difficult to correlate to actual usage.
>>
>>I used the example of a non-meshed backhaul meaning a single
>>logical link shared between multiple classes (e.g between access
>>mulitplexer (DSLAM) and access server (BRAS)). If two of these are
>>connected by a non-blocking core (fully meshed, which has been a
>>very influential one of BT's network designs), call counting is
>>reasonably sane (I don't like it for the reasons you give, but it's
>>not completely loony tunes). So it's a perfectly reasonable
>>scenario for VOICE-ADMIT.
>>
>>All I'm saying is this doc shouldn't tell perfectly sane network
>>engineers making perfectly rational engineering compromises that
>>they're wrong.
>
>There are long comments I could make here, but not short ones. Let me
>just say this: a "fully meshed non-blocking core" is not a great
>description of an "access path".

I didn't say that. I said two access paths either side of a 
fully-meshed non-blocking core, where both access paths are simple 
logical links - non-meshed. Quite a normal way of building a network 
- basically a star with a non-blocking centre. Then call counting is 
sufficient for the access paths, both counted together.

I'm not a fan of call-counting in the general case. I'm just saying 
there's no need to dis those that are fans of call-counting in a doc 
you're trying to get through last call, as it does have its place in 
specific networks.

Taking a pot at call-counting in a doc defining VOICE-ADMIT isn't 
relevant and actually needs to be said the other way round - in 
scenarios where call-counting is appropriate, VOICE-ADMIT will be necessary.

>>>>- similarly for bandwith brokers
>>>
>>>Again, mobility becomes an interesting discussion. This comes up
>>>especially in certain satcom networks that I'm not supposed to talk
>>>about. I pointed out Morita's foray into that - something not unlike
>>>PCN coupled with initial probing and a bandwidth broker, in
>>>http:// tools.ietf.org/html/draft-morita-tsvwg-pps. He dropped it
>>>because he
>>>tried it and MPEG-4 video was pretty much unmanageable using the
>>>approach.
>>
>>Again, the purpose of this doc is surely NOT to advise on how Fred
>>and co-authors think people should do admission control. It's just
>>to get a **** codepoint, after all.
>
>I actually disagree. If you want a code point, that was assigned in
>4594.

But, you want *another* codepoint. And surely you're meant to be 
defining the codepoint's semantics here, not giving all the reasons 
why certain admission control schemes don't work in certain corner 
cases (however big the corners).

>The problem is that it doesn't actually work for anything but
>the most basic service;

Why is that relevant to this doc? What if I'm a network providing the 
most basic service? THen I still need VOICE-ADMIT.

So please just make a clear distinction between
i) giving everyone words of wisdom on how to do admission control, and
ii) providing the world with a capacity-admitted codepoint

All we need in this doc is (ii) then however each of us operators 
chooses to do AC, we can do it better.

>it doesn't allow for multiple policies, and
>it doesn't give the SP any way to refuse a call. It allows one edge
>network to decide how *its* bandwidth will be carved up, but doesn't
>allow any interaction with how other edge network bandwidth is used.
>
>The only place I see where authentication to not be required is where
>it already exists by virtue of something else. For example, if I am
>on a DSL link offered by a provider, I can presumably get "random
>phone call" policy authorization by virtue of having paid my bill and
>having the service on. Authorization - the ability to say "no" -
>applies anywhere a service exists. You can say "no" in SIP if SIP is
>being handled by the ISP, but SIP has zero knowledge of bandwidth.
>
>Yes, this is *all* about admission control, which is to say
>authorization.
>
>>>>3/ Why don't you refer to the per-domain behaviour RFC [RFC3086],
>>>>or say anything about this being a PDB?
>>>
>>>To begin with, I am not much of a believer in them. I note that there
>>>is no RFC for a PDB for EF, and the one that Kathy published
>>>(tools.ietf.org/html/draft-ietf-diffserv-pdb-vw was eventually
>>>published in CCR) refers to RFC 2598, explicitly stating that RFC
>>>3246 is wrong. The only other PDB that I know of is for the scavenger
>>>service (RFC 3662). Let me ask this: in the absence of PDBs for
>>>anything we actually use apart from the scavenger service, why should
>>>I worry about a PDB for this one?
>>
>>The defining diff between your two EF PHBs is the edge (AC)
>>behaviour. That's precisely what a PDB is. If you think you can get
>>away without all the hassle of defining an admission control PDB
>>(which would be a fairly tedious and trivial exercise), go for it.
>
>Repeating my question. We don't even have a PDB for EF, which was
>originally written by the person who defined PDBs. Requiring a PDB
>for a derivative of EF seems over the top.

EF didn't particularly require a PDB (one could say RFC2475 defined 
EF's PDB). But when you introduce a second EF and the only way you 
can say why you need a different PHB (ie isolated or prioritised over 
the existing EF) is because of the behaviour at the domain level 
(admission control at the edges), then I'd have thought admission 
control /is/ the PDB.

I don't believe you need to go through all the pain of writing a PDB 
doc. It's one sentence (could be a simple mod to the opening para of 
the Intro): "The distinction between the two EFs is admission control 
at the domain level - in other words the per-domain behaviour (PDB 
[RFC3086]) for this new codepoint is  admission control, 
authorization etc. at the edges"

I'm not hung up on this point, I'm just suggesting you use previously 
defined concepts for what you're doing.

>>>>4/ Now I've re-read it, I see why we have another difference of
>>>>opinion:
>>>>* You want VOICE-ADMIT so that call priority mechanisms can't be
>>>>ruined by non-admitted traffic in the same class.
>>>>* I want VOICE-ADMIT so that admission controlled traffic (with or
>>>>without call priority) can't be runined by non-admitted traffic in
>>>>the same class.
>>>
>>>I actually want what you say you want. I'm not sure I see the
>>>disagreement. As I periodically point out, I want the admission
>>>policy to be in the control plane and allow for many different
>>>policies, potentially with different thresholds, in simultaneous use.
>>>One of those policies, one of many, is "normal everyday calls".
>>
>>The only disagreement is that you have unfortunately said (many
>>times) in the draft that it's not proper admission control unless
>>it has authentication and authorisation. As I also pointed out in
>>my review of -04, you only need to know who the user is if you're
>>doing precedence. If you're not, you don't (necessarily). I gave a
>>valid example of where an operator doing AC wouldn't need to know
>>user IDs in my review of -04 (might have got missed as well?).
>
>If you are talking about the two emails you sent on 19 March, I
>copied text directly from the first of them into this document (which
>is where the PCN-arch reference came from), and went through and
>addressed your comments point by point. I sent you an email saying I
>did so. Could you review the diffs I posted and see if you agree with
>the changes?

I'm v happy with your handling of all the points in my 'nits' email. 
It's the other one we're discussing now.

>Regarding the second, it looks like I stopped reading after the
>section that said "could we please break this into several
>documents?" It seems to me like we have several ISPs (at least AT&T
>and Verizon) and their vendor asking for something the ISPs are
>saying they need to provide a service that has multiple policies
>applied across an access network.

Are views from BT less important than from AT&T or Verizon? (you 
needn't answer that one - I know I'm in research so I don't count). 
We've committed completely to IP, so it's v important to us. I'm paid 
to make sure the things in the IP world that will get in our 
company's way as it evolves are sorted out in advance.

 From this standpoint, I can see that what you're trying to do has 
more general applicability. I'm just pointing that out for you, so 
you don't go precluding future stuff by unnecessarily excluding it.

>My discussions with you have been
>uniformly about getting PCN blessed in the document, something that
>is hardly proven in practice and is inapplicable in the access path.

Not at all. I've asked you not to dis other approaches I don't even 
like (because I want this to get through).

>I don't want too diss you, and I'm not trying to diss you, but good
>grief. Can I please build the technology using stuff that we in fact
>have operational experience that says it works?

Look we're not disagreeing - you've just missed some of my points, 
which I think you will agree with. They were designed to make sure 
this new faciliy (VOICE-ADMIT) gets through.

Because I know that docs get most of their blockages /during/ last 
calls, I'm trying to head likely disagreement off. You have to get 
through a full IETF last call after this WG last call.

>I'll go back and look at that note again.

Cheers - I think that will sort out a lot of this.

Bob

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196