Subject: RE: [nemo] Re: BU storms when MR does RO on behalf of LFN's

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 6 Oct 2004 17:51:20 +0200

> 
> If we say, like the taxonomy draft says, that because MR sends BU to
> CN's then BU storms appear, the immediate thought is to think "don't let
> MR send BU's to CN's".

Sorry, that was not intended at all. 

> If we say, however, that an MR not using rate limiting may provoke BU
> storms (easier than MH would provoke), then the immediate thought is to
> think "use rate limiting".

One immediate thought is "design so that there's an absolute minimum amount of BUs to be sent".
Then, I do agree, shape the storm as much as you can. But any delay is a window for packet loss, so we must be very careful.

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Oct 2004 18:35:07 +0200

Pascal Thubert (pthubert) wrote:
>> If we say, like the taxonomy draft says, that because MR sends BU 
>> to CN's then BU storms appear, the immediate thought is to think 
>> "don't let MR send BU's to CN's".
> 

Ok.  And what _was_ intended by mentioning the BU storm?

>> If we say, however, that an MR not using rate limiting may provoke 
>> BU storms (easier than MH would provoke), then the immediate 
>> thought is to think "use rate limiting".
> 

Yes, that sounds like an Rx requirement (Rx like R1, R2... R3
requirements in the goals and requirements document).

IMHO, a problem should sound like this "the problem is that paths are so
long, really long".  It should not invite for a solution or a
requirement, just say the problem.

I'm usually very hesitant to talk about problems because whatever kind
of problem one may imagine then a solution pops up immediately, ending
in an argument that there is no problem, or worse, in a too early
competition of solution drafts (or "war") :-)

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 7 Oct 2004 17:18:06 +0900

> competition of solution drafts (or "war") :-)

Agree. Basically, I think we can be careful with the words we use,
trying to keep them general. This is hard, so we shouldn't elaborate the
description of the problem.

Also, we can assume the problems based on NEMO Basic Support, e.g.:
- multiple encapsulation when NEMO are nested
- disconnected operation between 2 MNNs in the same NEMO

Actually, I see the document as being as light as possible. 

What about such structure:
- problem using NEMO Basic Support
- types of RO
  -- MNN to CN in the fixed infrascture
  -- MNN to MNN (same NEMO)
  -- MNN to MNN (# NEMOs)
  -- etc
- design goals for RO solutions
- list of metrics / qualifier

Thierry.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Oct 2004 15:15:34 +0200

> Actually, I see the document as being as light as possible. 

Yes, let's go for 5 pages no more.

> - problem using NEMO Basic Support

Ok.

> - design goals for RO solutions

This is "design goals" and no "problem statement".

> - list of metrics / qualifier

This is too precise.  Who's going to use these metrics later?

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 8 Oct 2004 12:49:04 +0900

Hi,

> This is too precise.  Who's going to use these metrics later?

The people who will decide which solution may qualify for a WG standard,
if the WG decided to update its charter to work on RO solutions.