Re: Hard questions (was: Diffserv PIB approved as InformationalRFC)

>
>
> I'm not sure what you two mean by "nailed up paths", but I do
> NOT believe this is "necessary" to support QoS guarantees. Are
> you assuming you'll assign one path and it will have zero
> probability of failure? What kind of guarantees are you looking
> at and what paths across a domain *won't* supply them? I suggest
> you approach the problem from that end, rather than thinking you
> must prefer some path that has the least delay by 20 nanoseconds.

Kathie,
I think you and I started to have this conversation once.  The problem is what happens to BAs in a
route flap, especially for VW-type PDBs.   Particularly since we assume that capacity for these kinds
of flows is allocated on a longer timescale than the lifetime of the flow (no per-flow signalling),
how does the network ensure that there are adequate resources along the new path?  If there are hard
upper bounds on delay [jitter], what prevents that bound from being exceeded during the route flap?
If the new path crosses a different set of DS-domain boundaries, what's to ensure that the same PHBs
are supported,  the correct DSCP mappings can be performed, and any other DS-edge functions performed
correctly?

The framework draft had some other, related, issues that escape me right now... and my copy got buried
somewhere when they moved my office.

Sometimes it best to just lock down the path and accept the possibility of a hard failure to meet the
SLS, than to have the SLS fail to be met in a transient fashion.

>
> By the way, using diffserv for cable data networks and wireless
> networks is rather different than using diffserv for a more
> mesh-y network cloud. What those folks are actually doing is
> creating PDBs that apply across their very specific network
> topologies.

I've gotten out of touch with the wireless folks.  The cable folks actually talk about using Diffserv
across their backbones, which are meshy (see
http://www.packetcable.com/specs/pkt-sp-iqos-i01-001128.pdf), although I think most of them now
understand the limitations of Diffserv and are either doing MPLS backbones or running their VoIP
traffic over ATM.


Dan


_______________________________________________
diffserv mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html