[Mobopts] Re: [multimob] Bar BOF in Chicago

"Hui Deng" <denghui02@gmail.com> Wed, 25 July 2007 14:59 UTC

Return-path: <mobopts-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiKP-00068G-2f; Wed, 25 Jul 2007 10:59:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiKO-00067z-HM for mobopts@irtf.org; Wed, 25 Jul 2007 10:59:04 -0400
Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDiKN-0000mW-OR for mobopts@irtf.org; Wed, 25 Jul 2007 10:59:04 -0400
Received: by wx-out-0506.google.com with SMTP id i29so173499wxd for <mobopts@irtf.org>; Wed, 25 Jul 2007 07:59:03 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MW2Z5VyToPkxBRMs2PuI2lxJnX9k5URApydgSO7gqLtHhbMgC5ZyLzahPjcWIoNxuKXEV6prNq3/zCJrzvj56buWG9WfqQSWcarNAaPIdun7gY8CzCx5tnCWBK/13Nm482CSdXPpLGYZY2WCr+LRoYP+s/Ievu81p/5nKsAcmSM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=alnRBs5r1bPk6imWa6DGmQjR3GCxkqnQfb4nuy9oHjlvkzNW4bUbNjjZSGs77ETLNiWrLFeXhEunNupJNlsdWnSnWQEj0jJPfnbiNCvZ/fvAyJDa+pGIV6ds4fu9uqAH1Y7fLwMYTo/M4GNPhDNReq6qDMn0P45MKHbnsZm6Ptg=
Received: by 10.90.104.14 with SMTP id b14mr570870agc.1185375543449; Wed, 25 Jul 2007 07:59:03 -0700 (PDT)
Received: by 10.65.84.9 with HTTP; Wed, 25 Jul 2007 07:59:03 -0700 (PDT)
Message-ID: <1d38a3350707250759ybf4f272hbe8adaa7f3b4559b@mail.gmail.com>
Date: Wed, 25 Jul 2007 09:59:03 -0500
From: Hui Deng <denghui02@gmail.com>
To: schmidt@fhtw-berlin.de
In-Reply-To: <46A61B54.201@fhtw-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="WINDOWS-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <761663.64740.qm@web84110.mail.mud.yahoo.com> <200707241121505934956@cernet.edu.cn> <46A61B54.201@fhtw-berlin.de>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: multimob@ietf.org, mobopts <mobopts@irtf.org>
Subject: [Mobopts] Re: [multimob] Bar BOF in Chicago
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Errors-To: mobopts-bounces@irtf.org

Hi, thomas,

Thanks for your paste and reply,
See below inline.

> ------------- snip ------------------------
> For the problems which mobile multicast faces
>
> • I think the main problems can be divided into
> 2 categories, and then we can explain the
> problems of multicast caused by mobility
> clearer:
> – For the User side, 2 main problems:
> • Multicast packet loss percentage mainly caused by
> handoff)
> • packer transmit delay (related Average to the path
> length of multicast packet, triangular routing would
> make parameter this worse)
>
> ------------- snap ------------------------
>
> TS => Yes, agree. Additional disturbances arrive from jitter, as
> discussed in the introduction of the draft.
>
> Another key issue: the address duality problem.
>
> The idea of the PS-draft is - from a fairly general level of abstraction
> - to look behind the scene, i.e., to identify issues and causes in more
> detail.
>
> The reason for this: The PS-draft is meant to serve as comprehensive
> overview and analytical fundament for future designers of mobile
> multicast protocols.
The problem statement which you wrote is good, and here what we would like
to suggest is that in the current stage, we may skip source mobility
since the needs are not strong and quite complicated. So if possible,
we may could define
more category like user and network side consideration.


> ------------- snip ------------------------
>
> For the problems which mobile multicast faces (con.)
>
> – For the Network side, 3 main problems:
> • Multicast packet efficiency (use delivery related to the of tunnel)
> • Multicast maintenance overhead (related to the design of mobile
> multicast scheme)
> • The stability of multicast tree (related the way of updating multicast
> tree after a handoff event)
>
> ------------- snap ------------------------
>
> TS => D'accord. Please don't forget convergence speed and robustness of
> the mobile multicast routing schemes.
Good suggestion, we cold clarify more in detail related to this

> Fairly central issues derive from deployment: We should closely look at
>  solutions which have a realistic chance for deployment, e.g., by
> staying close to unicast mobility management schemes.
This need more discussion on it.

>
> ------------- snip ------------------------
>
> For the solutions
> • Users always move around within a definite scope, such as within a
> building when they are working
> • Hierarchical structure is useful in mobile multicast
> – Can shield the local movement from outside
> – Can efficiently reduce the change of the main
> multicast delivery tree
> – Can decrease the multicast protocol overhead related handoff
> – It is an important category of mobile multicast
> solution and I suggest it be written in solution, the draft
>
> ------------- snap ------------------------
>
> TS => Yes, you're right. Actually this approach is taken in draft
> http://www3.tools.ietf.org/html/draft-schmidt-waehlisch-mhmipv6 , which
> is mentioned in the solutions section.
we are suggesting more hierachical solution other hmip solution since we
have to consider more deployment realistic.

> Of course, the brief survey over the solution space mainly consists in
> reference pointers ... to keep the document within readable bounds :-)
Sure,

btw, more suggestion, shall we consider as well pmip area?

Thanks

-Hui

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts