Re: Hard questions (was: Diffserv PIB approved as Informational RFC)

Brian E Carpenter wrote:
> Dan Grossman wrote:
> 
>>Brian E Carpenter wrote:
>>
>>
>>>Dan Grossman wrote:
>>>
....
>>>>It may even fill in some of the nagging
>>>>holes in the Diffserv architecture (for example, the ability to nail a path,
>>>
>>>Again, begging the question.
>>
>>As was pointed out many years ago in the framework draft, nailed up paths are a necessary
>>mechanism for supporting QoS guarantees.  I am mildly hopeful that NSIS will provide that bit of
>>machinery in their protocols.
> 

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.

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.

	Kathie


_______________________________________________
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