Subject: [Seamoby] Problem Statement

From: "Christophe Jelger" <[email-masked]>
Date: Mon, 14 Jan 2002 18:00:39 +0100

Hi all,

I am new to the list so please forgive me if my points are out of the main
discussion subject. I also apologise if this has been discussed before.

In the draft context-transfer-problem-stat-04.txt in section 5.3, it is
stated that context transfer should be used when it establishes a service
faster than from scratch. While this is certainly good sense, it is also
mentioned that for certain types of services, e.g. multicast, context
transfer may not be suitable.

As I told you before I am new to the list so I don't know if this has been
discussed before. I believe that this statement makes little sense for two
main reasons:

1) First, there has been almost no studies at all about the join latency of
multicast communications and I find it inadequate to say that something is
better or worse than something that has not been evaluated (even if it may
intuitively be the case)

2) Second, the term "faster" or "quicker" has to be carefully defined to
have a strict sense. What I mean is that with context transfer, the process
of joining a multicast group (with respect to the nAR) can be anticipated
and therefore after the handoff completes the multicast traffic may already
be delivered in the new network and in that case the service disruption is
almost null. The whole process of context tranfer may be longer than a
native multicast join process from the new network but the service
disruption time may be shorter with context transfer.

Any comments/suggestions are welcome. Please also understand that my
intention is not to critisise the draft when I did not take part of any
prior discussions. I simply think that this point should be clarified.

Regards,

Christophe

-------------------------------------------------------------------------
Christophe Jelger - LSIIT                   [email-masked]
Université Louis Pasteur
Strasbourg - France                           Tel: +33 (0)3 90 24 45 90

http://www-r2.u-strasbg.fr/~jelger
-------------------------------------------------------------------------

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 14 Jan 2002 09:51:15 -0800

> better or worse than something that has not been evaluated (even if it
may

The draft doesn't say that it will be, it just says that it might. If
you have
evidence to the contrary, then please feel free to write a draft on it.

> disruption time may be shorter with context transfer.

If joining the service from scratch is faster than context transfer,
then
the join should be used by all means. Context transfer is not being
proposed as a replacement for everything, just those services (for
want of a better word) that would require a long transient to
restart from scratch.

            jak

---

From: "Christophe Jelger" <[email-masked]>
Date: Mon, 14 Jan 2002 19:01:23 +0100

Yep but that's exactly what I want to point out ... it may be faster to join
a multicast group in the traditional way but the service disruption should
be smaller with context transfer before the multicast delivery at the new
network can be anticipated. What I mainly want to say is that it's not a
matter of quick establishment or not, the main point is to minimize the
service disruption (in the case of multicast for example).

Christophe