Subject: [Tsvwg] draft-karagiannis-ru-pdb-01: meaning of "multiple domains"?

From: Bob Briscoe <[email-masked]>
Date: Mon, 20 Mar 2006 10:26:59 +0000

Hannes,

This draft says it's applicable to either a single Diffserv domain or 
multiple domains. There are two main issues with multiple domains:
a) different choices of configuration and
b) conflicts of interests

Reading the two sections about multiple domains (7.2 & 7.4), you address 
(a) `different choices of configuration' sufficiently, but you don't seem 
to address (b) `conflicts of interest'.

My point is that we must be clear when claiming support for multiple 
domains. I believe protecting against the self-interest, accidents and 
deliberate malice of other domains are the more important (and much harder) 
issues when connecting multiple domains. If those issues aren't being 
addressed, I don't think the IETF should spend too much time on the 
protocol details of mapping between different domains' configuration 
choices. The British phrase for that is "not seeing the wood for the trees".

You might think you have addressed those issues in the security 
considerations section (9). You refer out to the general security 
considerations of Diffserv. But Diffserv border policing keeps the bulk of 
traffic within a pre-agreed TCA. I think you are assuming pipe rather than 
hose TCAs at borders (otherwise there is no need for RU). But this isn't 
sufficient for resource unavailability IMHO...

Hose TCAs say nothing about where the traffic goes once it has crossed the 
border. You can get focused overload on a link due to traffic coming 
through multiple Diffserv policers into a domain. That is the problem RU is 
trying to solve. But in a multi-domain scenario, the purpose of RU must 
also be to ensure an ingress domain (A) reacts correctly to focused 
resource unavailability in a downstream domain (B).

The RU protocols allow the downstream domain (B) to /tell/ all the upstream 
domains to reduce the traffic. But there is nothing to /make/ them. And 
nothing to /detect/ which one isn't complying with the request. Why should 
an upstream domain (A) cut back its customers when it can hold tight and 
wait for other domains to cut back theirs?

Worse, in a typical deployment, domain (B) would pre-configure some 
fraction of each interior link to (say) Diffserv EF, with the rest of each 
link assigned to other services. If a selfish upstream domain (A) did not 
respond to RU requests, its traffic would just eat into the capacity that B 
had set aside for other services. Two possible outcomes:
- If there was no Diffserv policing on B's overloaded link, this would be a 
successful theft of B's other services by A.
- If there was Diffserv policing on B's overloded link, all the flows 
through it would suffer random discard, allowing A to be able to destroy 
the EF service of B whenever it wanted, without easy detection.

If we have to put a statement in saying the domains trust each other to not 
be selfish, I don't think that really counts as multiple domains any more.

Bob

At 10:43 10/03/2006, Tschofenig, Hannes wrote:
>Title
>   Resource Unavailability (RU) Per Domain Behavior
>Abstract
>[...]This PDB can be applied in
>    association with either a single Diffserv domain or multiple
>    neighboring Diffserv domains. This specification is denoted as
>    Resource Unavailability (RU) PDB and it follows the guidelines given
>    in RFC 3086.
>http://www.ietf.org/internet-drafts/draft-karagiannis-ru-pdb-01.txt

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 20 Mar 2006 22:49:34 +0100 (MET)

Hi Bob

The observations on the multidomain are right, but please note that this
is
an example. However, we will clarify these issues in the next version of
the draft.

Best Regards,
Georgios