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

I was tempted to continue the discussion with Dan, but then decided
to put my WG Chair hat on and slap myself over the wrist for discussing
non-charter items. We're on a fairly deep disagreement here... I will
respond to Dan over on the diffserv-interest list, to avoid further
filling the 3000+ inboxes connected to this list.

   Brian

Dan Grossman wrote:
> 
> >
> >
> > 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