Subject: Re: [nemo] [Fwd: I-D ACTION:draft-thubert-nemo-ro-taxonomy-04.txt]

From: Masafumi Watari <[email-masked]>
Date: Fri, 04 Mar 2005 08:09:54 +0900 (JST)

Hi Chan-Wah,

Thanks for the submittion of the updated draft.

> Oh, and yes, as always comments/criticisms on the RO-taxonomy draft is
> always welcomed, regardless of harsh, gentle, or otherwise :).

At the moment, I just have one comment on Section 5.1 where you
describe the effects of additional signaling overhead.  The effect
mentioned in the section is focused on the number of signaling
messages to construct the optimal path, but I think its also important
to mention what the effect of these messages causes on handoffs in
terms of delay.  Since some solutions require collaboration of the MRs
to construct the optimal path, the change of attachment point of
root-MR (or other MR as well) requires a reconstruction of the path
for RO.  In general, more signaling messages means more time before
the communication resumes, so we would want to keep this at its
minimum.

So I think that there could be section where we analyze the effects of
handoff in relations with delay, number of signaling messages, and
nest level.  Maybe somewhere in Section 5 since it's a tradeoff of
having RO.

What do you think?

regards,
watari

---

From: Chan-Wah Ng <[email-masked]>
Date: Fri, 04 Mar 2005 10:38:27 +0800

Hello Watari-san,

> nest level.  Maybe somewhere in Section 5 since it's a tradeoff of

I think you've made a valid observation, and an excellent suggestion.
The description regarding BU-storm is an (feeble) attempt on my part to
quantitatively analyze the effect of the so-called BU-Storm, but
obviously I have not take into consideration all the relevant factors.

Someone (I think its Alexandru) mentioned something about a paper that
quantify the effect of BU-Storm and found it to be not very significant.
I have yet to locate that piece of academic work.  Should anyone have
any pointer to it, I would be very grateful if this anyone could share
it with the WG.

/rgds
/cwng

---

From: Masafumi Watari <[email-masked]>
Date: Tue, 08 Mar 2005 06:22:21 +0900 (JST)

Hello Chan-Wah,

On Fri, 04 Mar 2005 10:38:27 +0800,

> obviously I have not take into consideration all the relevant factors.

Just to be clear, the problem is not limited to the so-called
BU-storm, assuming that the term "storm" refers to a case where there
are many MNNs.  Assume a scenario where only a single MNN needs the
RO.  If one solution requires N number of messages to construct the
optimal path for this MNN while another solution requires 2*N
messages, the latter would more then likely require more time for the
reconstruction of the path after a handoff.  Thus this N would become
the minimum time required for each MNN and therefore would want to
keep it at its minimum.

> any pointer to it, I would be very grateful if this anyone could share

I don't have a pointer either, but I do remember the discussion that
such BUs are not significant compared to packets sent by MNNs using
UDP stream applications which you have also listed in that section :)

watari

---

From: Chan-Wah NG <[email-masked]>
Date: Tue, 08 Mar 2005 07:38:21 +0800

Hello,

> the minimum time required for each MNN and therefore would want to
Of-course, ... given all things constant.  However, the question is that
how significant is the delay, and whether we are willing to sacrifice
something else (perhaps algorithm complexity) to get rid of the extra
overhead.  

> UDP stream applications which you have also listed in that section :)

Right, I think the discussion you mentioned is between Alex and myself,
leading to the text I included in the draft :)

/rgds
/cwng

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 8 Mar 2005 14:33:00 +0900

Dear all,

> > BU-storm, assuming that the term "storm" refers to a case where
> > there are many MNNs.  Assume a scenario where only a single MNN
> > needs the RO.  If one solution requires N number of messages to
> > construct the optimal path for this MNN while another solution
> > requires 2*N messages, the latter would more then likely require
> > more time for the reconstruction of the path after a handoff.  Thus
> > this N would become the minimum time required for each MNN and
> > therefore would want to keep it at its minimum.

Just one small note: there could be many CNs and only a few MNNs but
still a BU storm: imagine that someone set up a web server in a bus. OK,
that sounds stupid, I know, but it's just to get the picture. The fact
that it is reasonable or not to do it is orthogonal to the fact it may
happen.

> Of-course, ... given all things constant.  However, the question is
> that how significant is the delay, and whether we are willing to
> sacrifice something else (perhaps algorithm complexity) to get rid of
> the extra overhead.  
> 
> > > Someone (I think its Alexandru) mentioned something about a paper
> > > that quantify the effect of BU-Storm and found it to be not very
> > > significant. I have yet to locate that piece of academic work. 
> > > Should anyone have any pointer to it, I would be very grateful if
> > > this anyone could share it with the WG.
> > 
> Right, I think the discussion you mentioned is between Alex and
> myself, leading to the text I included in the draft :)

I beg to differ.  
There are 2 reasons why RO is desirable:

1. you have a high quantity of traffic and transmitting all these
packets via the home agent would consume to many network resources if
the CN is relatively closer to the MNN on the direct path.

2. you have a small quantity of traffic, but it is very sensitive to
delay, so you need the shortest path if the CN is relatively closer to
the MNN on the direct path.

With this in mind, and with a high number of CNs, the quantity of
signaling traffic may be very significant to the quantity of data
traffic. 

One example: an IPv6 sensor in a vehicle queried via SMTP every X
seconds. For some reasons, the number of CNs happens to be high. 
Although the data traffic is not significant, the signaling traffic may
well be high.

One last detail: in the new document, I've read in several places that
BU are sent to CNs whenever the MR changes its location. May I suggest
to reword that as BU should be sent not only when the MR changes its
location, but also regularly to refresh the cash ? To what I remember,
this keepalive frequency is quite frequent.

Thierry

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 08 Mar 2005 13:43:42 +0100

> leading to the text I included in the draft :)

Sidenote: the paper I was mentioning about BU storms stormy or windy was 
co-authored by Markus Pilz et alia, at that time with University of 
Bonn.  I can't find the paper right now, sorry.  The simulations were 
done with ns.

It may be worth exploring in which conditions would a real BU storm appear.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 08 Mar 2005 14:12:12 +0100

Thierry Ernst wrote:
> still a BU storm: imagine that someone set up a web server in a bus.

Ok, but just as a sidenote, and I don't try to interfere with the
discussion: isn't it that before BU is sent to CN, there should be a CoT
sent to it, at which point we may need to actually talk about a "CoT
storm"?  Something like "CoT storm" precedes any "BU storm" to CN?

> Although the data traffic is not significant, the signaling traffic
> may well be high.

Well, in this particular scenario, unless one could give a rough
comparison of packet sizes SNMP-BU, I would imagine that the potential
BU storm is preceded by an equally-sized SNMP storm.

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 9 Mar 2005 00:41:01 +0900

Hi,

On Tue, 08 Mar 2005 14:12:12 +0100
Alexandru Petrescu <[email-masked]> wrote:

> discussion: isn't it that before BU is sent to CN, there should be a
> CoT sent to it, at which point we may need to actually talk about a
> "CoT storm"?  Something like "CoT storm" precedes any "BU storm" to
> CN?

Let's call this a signaling storm then since we don't want the analysis
to focus on specific solutions.

> BU storm is preceded by an equally-sized SNMP storm.

May be, but I don't see the point Alex. The point is that the signaling
cost could be significantly high in both absolute values and in
comparison with the data cost.

Thierry

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 08 Mar 2005 20:00:06 +0100

Thierry Ernst wrote:
>>> Just one small note: there could be many CNs and only a few MNNs
>>> but still a BU storm: imagine that someone set up a web server in
>>> a bus.
>> 
>> discussion: isn't it that before BU is sent to CN, there should be
>> a CoT sent to it, at which point we may need to actually talk about
>> a "CoT storm"?  Something like "CoT storm" precedes any "BU storm"
>> to CN?
> 
> Let's call this a signaling storm then since we don't want the
> analysis to focus on specific solutions.

I tend to agree to not focus on a specific solution, but as long as we 
say MIP6 and BU to CN then we implicitly say RR anyways (which is 
understood as a specific solution as I see).

>>>  Although the data traffic is not significant, the signaling
>>> traffic may well be high.
>> 
>> comparison of packet sizes SNMP-BU, I would imagine that the
>> potential BU storm is preceded by an equally-sized SNMP storm.
>  
> May be, but I don't see the point Alex. The point is that the
> signaling cost could be significantly high in both absolute values
> and in comparison with the data cost.

Ok, I tend to agree.

Alex

---

From: Chan-Wah NG <[email-masked]>
Date: Wed, 09 Mar 2005 04:01:37 +0800

> understood as a specific solution as I see).

Agree on the term "signalling storm" being more appropriate than
BU-Storm.  As for specific solution, I guess we can avoid that by saying
something like "Route optimization between a few MNN and a large number
of CNs would also lead to a signalling storm".  No specific details like
"BU to CN" and "MIP6".

> > and in comparison with the data cost.

Sorry, but we are discussing NEMO RO, so SNMP packets are not signalling
packets, but data packets as far as NEMO is concerned (unless of-course
the SNMP packets are sent to achieve RO, but that is not what is said in
the example).   SO I don't understand where this is leading to.

Suffice to say I concur that "signalling storm" is a more appropriate
term than "BU storm".

/rgds
/cwng

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 9 Mar 2005 05:15:30 +0900

> > >>> One example: an IPv6 sensor in a vehicle queried via SMTP every
> > >X >>  seconds. For some reasons, the number of CNs happens to be
> > >high. >>  Although the data traffic is not significant, the
> > >signaling >> traffic may well be high.
> > >> 
> Sorry, but we are discussing NEMO RO, so SNMP packets are not
> signalling packets, but data packets as far as NEMO is concerned
> (unless of-course the SNMP packets are sent to achieve RO, but that is
> not what is said in the example).   SO I don't understand where this
> is leading to.

Please read the top of this mail, I just used this as an example to
demonstrate that in some situations the signaling cost is more
significant that it may sounds, and significantly important compared to
the amount of data packets.

Thierry