Re: [nemo] Comments on draft-ietf-nemo-ro-problem-statement-00.txt

[Masafumi Watari <[e-mail]>]

Hello Carlos,

Thanks for your comments.  Please see my reply inline;

On 2005/07/07 17:06, Chan-Wah Ng wrote:
> On Thu, 2005-07-07 at 09:08 +0200, Carlos Jesús Bernardos Cano wrote:
> 
>>Hi all,
>>
>>After taking a look at this I-D I've have some comments.
>>
>>First of all I want to say that the draft looks pretty good to me. Now
>>it is closer to achieve the goals that are in the charter.
>>
> 
> Thanks for reading the draft, and your kind comments.
> 
>>After saying that, here are my comments:
>>
>>- Section 2.1. I would add some comments on TCP performance in the
>>paragraph that deals with the longer route leading to increased delay...
>>The increased delay has not only a significant effect on real-time
>>multimedia streaming applications (here the effect of the delay is more
>>obvious and maybe it is the kind of application most affected, but it is
>>not the only one). The delay has also a severe effect on the obtained
>>throughput by TCP applications, since the throughput is related to the
>>RTT, therefore, if the RTT is inflated due to the MRHA tunnel, then an
>>application may experience a low TCP throughput compared to hosts that
>>communicate directly. Then, if a Route Optimisation mechanism allows to
>>overcome this tunnel (and reduce the delay) that would help at improving
>>the overall TCP performance. We have performed some measurements in a
>>testbed, showing the performance decrease.
>>
> 
> You are right. We would add something there too.  About your test
> results, any paper we can reference?
> 
> 
>>- Section 2.2. I think that this section could be an additional bullet
>>in Section 2.1. I see the HA being a single point of failure (and the
>>Home Network a bottleneck) as a direct consequence of the MRHA tunnel
>>introduced by the NEMO Basic Support protocol, so I don't see why it has
>>to be in a different subsection.
> 
> 
> True.  The authors had a similar discussion too.  It was my editorial
> decision to separate the two, since (1) we don't want to bloat sect 2.1,
> and (2) the nature of the problem is slightly different in that sect 2.1
> views the problem from the perspective of a single flow and Sect 2.2
> view the problem from the home perspective which is the aggregation of
> multiple flows. 
> 
> One other point worthy of note is that Sect 2.1 will happen to any flow
> that pass through the MRHA tunnel, whereas Sect 2.2 may happen only if
> there is a lot of flows.  Conversely, the implications of Sect 2.2 is
> more severe, as it will affect all flows, even those that does not pass
> through any MRHA tunnel.
> 
>>- Section B. Typo: I think it should be "involve" (second line) instead
>>of "involves".
>>
> 
> OK.
> 
>>- Section B.1.3. I would remove the last paragraph (the one starting
>>with "Providing Route Optimization..."), since it is related to the
>>solution space, not to a problem statement.
>>
> 
> I would discuss this with Watari-san, but I don't see any concern why
> not.

Yes, this should have been removed.
Thanks for pointing this out.

>>- Section B.4.3. I would add a comment clarifying that a VMN could also
>>communicate with a node using its CoA as source address (Mobile IPv6 and
>>RFC3484 offer also the possibility of using the MN's CoA as source
>>address). In Case L , there are some communication scenarios that seem
>>to be very convenient for the VMN to choose its CoA address instead of
>>its HoA (for example if the communication is known to be short-lived in
>>advance, like in DNS queries for example).

Right... I missed this one from my previous draft.
Thanks for the reminder.

regards,
watari