[Mobopts] Re: Comments on draft "Problem Statement and Requirement: Mobile Multicast"

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Fri, 16 November 2007 12:01 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 1IsztW-0000ye-Po; Fri, 16 Nov 2007 07:01:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsztU-0000xa-Mu for mobopts@irtf.org; Fri, 16 Nov 2007 07:01:56 -0500
Received: from mail1.is.haw-hamburg.de ([141.22.192.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsztQ-00066G-8o for mobopts@irtf.org; Fri, 16 Nov 2007 07:01:56 -0500
Received: from mailgate.informatik.haw-hamburg.de (isis.informatik.haw-hamburg.de [141.22.10.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.is.haw-hamburg.de (Postfix) with ESMTP id 99D0362DB2; Fri, 16 Nov 2007 13:01:47 +0100 (CET)
Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31937-01-4; Fri, 16 Nov 2007 13:01:47 +0100 (CET)
Received: from [192.168.178.22] (e178150017.adsl.alicedsl.de [85.178.150.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 2340C3C001B1; Fri, 16 Nov 2007 13:01:45 +0100 (CET)
Message-ID: <473D86A7.1010703@informatik.haw-hamburg.de>
Date: Fri, 16 Nov 2007 13:01:43 +0100
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Hui Deng <denghui02@gmail.com>
References: <1d38a3350711120108i2ca7303aked6af82209aa0161@mail.gmail.com>
In-Reply-To: <1d38a3350711120108i2ca7303aked6af82209aa0161@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de
X-Virus-Scanned: ClamAV at mailgate.haw-hamburg.de
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Cc: multimob@ietf.org, mobopts@irtf.org
Subject: [Mobopts] Re: Comments on draft "Problem Statement and Requirement: Mobile Multicast"
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

Dear Hui,

I've just gone through your draft and have some comments / remarks:

At first, I find it quite valuable to have a detailed description / 
discussion on Mobile IPTV over Multicast deployment issues. If we 
believe this to be a larger business / likely deployment case, we should 
look at it in detail. So your draft is a good starting point.

The title is misleading, though. I'd like to suggest putting Mobile IPTV 
into the title, e.g., "Problem Statement and Deployment Requirements: 
Mobile IPTV over Multicast".

In the document you are mentioning "Video service need much bandwidth" 
and the threat of network component overload. It would be helpful to 
present numbers ... if you consider some mobile phone with a display of 
QCIF size and an efficient codec, bandwidth can actually drop down 
drastically (well below 100 kbit/s) ... larger resolutions (requiring 
higher frame rates) and less efficient codecs increase bandwidth 
consumption nonlinearly (typically some power of 2-5).

In general, the dependence of the service on end user devices needs 
consideration, I believe.


In section 2.2 (6) you mention the differences in video packet relevance 
(I/P/B-Frames) and state "It is recommended to provide better guarantee 
for important packets." - this is actually a strong requirement, if you 
ask for network support. It means that forwarding components have to 
inspect the RTP extension profile/payload. I know that this is an old 
discussion in the QoS community ... but do we actually  know of any 
operator providing such complex, high-level service?

What one can do, of course, is to allow for Diffserv packet labeling at 
the content source. This would require appropriate service contracts 
between the content providers and the network operators.


In section 2.2 (7) you state "the mobile multicast should provide some 
machenism to ensure the synchronization of mobile IPTV streams" - what 
do you mean by that?
Typically, synchronization at the signaling level is provided by RTP ... 
and realized by buffers for RTP and play-out (as this is a streaming 
scenario).


Similarly in section 2.3 you stress "a precise time reference is needed 
in the multicast mobile network" for synchronization purposes. Normally, 
the synchronization problem is between source and receiver / conference 
parties. If the IPTV source is a foreign one, i.e., not located at the 
mobile network operator, an operator-based temporal synchronization does 
not solve the problem. Typically, NTP timestamps are provided by RTCP 
... so it appears rather as an issue of RTCP presence ... which is not 
fully trivial, e.g., feedback in unidirectional broadcast networks like 
DVB-H.


Best regards,

thomas

Hui Deng wrote:
> Hello, all
> 
> Please help to review our two drafts, and appreciate your comments,
> Many thanks
> 
> 
>   Title           : Problem Statement and Requirement: Mobile Multicast
>        Author(s)       : H. Deng, et al.
>        Filename        : draft-deng-multimob-ps-mobilemulticast-00.txt
>        Pages           : 14
>        Date            : 2007-11-8
> 
>   This document discusses the problem and requirement of multicast
>   solution in the mobile networks.  One current issue in mobile
>   multicast solution has been raised and requirements of mobile IPTV on
>   multicast mobility will also be summarized especially for some
>   mechanisms such as the tunneling, service capability and security
>   discussion which is basis of supporting the mobile IPTV applications.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-deng-multimob-ps-mobilemulticast-00.txt
> 
> 

-- 

° Prof. Dr. Thomas C. Schmidt
° HAW Hamburg, Dept. Informatik
° University of Applied Sciences
° Berliner Tor 7, D 20099 Hamburg
° Germany, Fon: +49-40-42875-8157
° http://www.informatik.haw-hamburg.de/~schmidt

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