Subject: [Monami6] comments on the problem statement -00

From: Pekka Savola <[email-masked]>
Date: Tue, 2 May 2006 16:25:46 +0300 (EEST)

Hi,

(Hopefully this gets through; I'm not subscribed.)

I read the -00 version of the problem statement.  I haven't followed 
the work, but thought I'd give some early review on this..

General comment:  for many of the scenarios, I might say, "Mm... I 
guess that might be happening in 10 years..", i.e., seem rather 
futuristic; or perhaps I'm a pessimist :-)

I'd also like to point out that quite a many scenarios include a 
satellite. I'm not sure how common that is, or will be, in 10 years, 
especially for data transfer (and not e.g. broadcast video feed) and 
especially in scenarios where you're also able to get wired-line or 
high speed wireless connectivity.

substantial
-----------

Section 3.3,

    She has noticed the 802.11b
    link is unreliable at some point in time during the day, so she
    chooses to send requests and periodic refreshments for joining the TV
    broadcasting via ADSL rather than 802.11b although it is free.  On
    the other hand, she has configured her network to use the 802.11b
    link at night to publish web content comprising video.  Once a week,
    she communicates with overseas peer staff by videoconferencing.
    Voice being the most important, she has configured her VoIP session
    over ADSL.  Video is sent at maximum rate when 802.11b is working
    fine, otherwise the video is sent at lower rate.

==> while I may agree that some might want to do this, I'm very 
skeptic from the operational point of view -- i.e., how the heck could 
this (very dynamic behaviour, behaviour that the user needs to 
configure manaually and update frequently) be made a feasible choice? 
If I was the publishing company, I'd rather pay "Nami" 10$ extra per 
month (or pay for the whole ADSL bill) so she doesn't need to play 
with her preferences all the time, but rather concentrate on getting 
more work done.

In other words, I think the problem statement while describing well the
technical possibilities doesn't give confidence that the problem is
sufficiently easily solvable in such a manner that the solution would 
make economic sense.

semi-substantial
----------------

3.5.  Need to Dispatch Traffic over Distinct Paths

    Max drives his car and constantly keeps some sort of Internet
    connectivity through one of the available access technologies.  His
    car navigator downloads road information from the Internet and his
    car-audio plays on-line audio streaming.  When his car passes an area
    where both high-data-rate WLAN and low-data rate cellular network are
    available, it distributes load to the WLAN access and the cellular
    network access.

==> this is a bad example, as there is no way WLAN could be a realistic
technique for cars; it just isn't sufficiently wide-area to be useful.  Some
variation of WMAN techniques such as WiMAX or Flash-OFDM or the like could
possibly be applicable though.

3.7.  Need to Accelerate Transmission

....

Roku uses a WLAN connection to
    download the necessary data.  However, there is not enough time and
    she decides to accelerate the download.  Her notebook is equipped
    with an additional WLAN interface.  She decides to use this
    additional WLAN interface to connect to another access point, and
    distribute the different download flows between the two wireless
    interfaces.

==> this scenario assumes that the download flows are separable, i.e.,
different flows.  In the specific case described here, this is not given,
and in the general case when you have something you'll need to finish ASAP,
I'm not sure if this kind of approach is applicable except possibly when
using p2p file sharing techniques.

    o  Aggregated Bandwidth: YES

       With multiple interfaces connected to a link, the node generally
       will be able to benefit from an increased aggregated bandwidth.

==> While true to some extent, I doubt this has any real significance in
most (if not all) scenarios.  While adding WLAN beside GPRS might give a
significant performance boost, multiply connecting to a same link (e.g., two
WLAN interfaces on a laptop) at maximum only doubles the capacity which
isn't a big deal.  Hence, I'm not sure how relevant this problem really is.

10.  References

==> needs to be split to normative and informative.

editorial
---------

    | Load Balalancing                  |   |   | o | o |   |   | o |

==> s/Balala/Bala/

       Ubiquitous access cannot be guaranteed when the node looses

==> s/looses/loses/

       The source address can be chosen according to preferences set up
       by the user, or according to preferences set up in the network
       (such as with the default router preferences option introduced in
       Router Advertisement [8], or by the ISP.

==> s/[8]/[8])/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Gábor Fekete <[email-masked]>
Date: Thu, 4 May 2006 21:05:04 +0300

On Tuesday 02 May 2006 16:25, Pekka Savola wrote:

[snip]

> high speed wireless connectivity.

[snip]

> sufficiently easily solvable in such a manner that the solution would
I think at this stage and time we can talk only about technical possibilities
and it is too early and hard to think about economic sense. The main issue
is we don't really know what end-users will need and how they will work in
the future. We can just guess and try to prepare for all kinds of scenarios,
thus the extreme examples of the problem statement draft.
Yes, sometimes I have the feeling that we're just trying to find the problem
for the solution.

Regards,
Gabor

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 5 May 2006 10:39:10 +0200

> Yes, sometimes I have the feeling that we're just trying to find the problem

Since I'm co-authoring the draft: I agree it's extreme examples, and the
idea is:

- to list the motivations for the MONAMI6 work (not the goals of
MONAMI6, but motivate why MCoA and policy exchange is needed - these 2
MONAMI6 output won't be enough to meet the scenarios listed in the
draft)

- to show what could be the possibilities in the future (the target
audience IS NOTIETFers) and investigate the forthcoming directions (i.e.
beyond MONAMI6, and possibly linking to SHIM6 and other WGs)

- to list potential issues (the target audience IS IETFers)

I will read carefully Pekka comments and we will see how to address
these in the draft. If more concrete scenarios of MCoA and Policy
Exchange is needed, I would be very much open to ADD this in the draft,
but I wouldn't like to remove the futuristic scenarios currently in the
draft as this can show what the next steps of MONAMi6 could be (if some
people think we should not list futuristic scenarios in IETF
informational documents, I would argue that some people outside the IETF
would be happy to get a better idea of what can be done in the future
with what issues). Of course, I do understand that not everyone share
this point of view.

Thierry.

-- 
Thierry ERNST, PhD
INRIA Rocquencourt Projet IMARA
+33 1 39 63 59 30