Re: [multimob] PMIP MC handover -- some thoughts

[<Dirk.von-Hugo at telekom.de>]

Hi Marco,
Thanks for the comments.
Please see inline ...


Best regards
Dirk von Hugo


Deutsche Telekom AG
T-Labs (Research & Development)
Dirk von Hugo
Deutsche-Telekom-Allee 7, 64295 Darmstadt
Germany
+49 6151 937-2536 (Tel.)
+49 6151 937-4611 (Fax)
+49 151 14620590 (Mobile)
E-Mail: dirk.von-hugo at telekom.de
www.telekom.com

Life is for sharing

Deutsche Telekom AG
Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman)
Board of Management: René Obermann (Chairman), Dr. Manfred Balz, Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, Claudia Nemat, Thomas Sattelberger
Commercial Register: District Court Bonn HRB 6794
Registered Office: Bonn
WEEE reg. no.: DE50478376
Big changes start small - conserve resources by not printing every e-mail.

-----Ursprüngliche Nachricht-----
Von: Marco Liebsch [mailto:Marco.Liebsch at neclab.eu]
Gesendet: Montag, 6. Februar 2012 18:28
An: von Hugo, Dirk; sarikaya at ieee.org; multimob at ietf.org
Betreff: RE: [multimob] PMIP MC handover -- some thoughts

Hi Dirk,

some additional points inline.

> -----Original Message-----
> From: multimob-bounces at ietf.org [mailto:multimob-bounces at ietf.org] On
> Behalf Of Dirk.von-Hugo at telekom.de
> Sent: Dienstag, 31. Januar 2012 17:26
> To: sarikaya at ieee.org; multimob at ietf.org
> Subject: Re: [multimob] PMIP MC handover -- some thoughts
>
> Hi Behcet,
> I think you have already summarized some comments from our discussion in
> September (e.g. by Luis). Good point added regarding required MLD
> extension ... Thanks!
> I'll try to add my thoughts - hopefully not doubling too much from last year's
> arguments - please see below:
>
> Best regards
> Dirk
>
> Von: multimob-bounces at ietf.org [mailto:multimob-bounces at ietf.org] Im
> Auftrag von Behcet Sarikaya
> Gesendet: Donnerstag, 19. Januar 2012 17:32
> An: multimob at ietf.org
> Betreff: [multimob] PMIP MC handover -- some thoughts
>
> Hi all,
>
> It is time to discuss our fast handover charter item and the proposed
> approaches.
>
> I copied below what Marco wrote on the list on Sept. 7, 2011.
> To Marco's points, I am adding one more as the last one below.
>
> I think that there is consensus on these points.
>
>
> - Why FHO-like forwarding between MAGs is beneficial for multicast?
>   It puts assumptions on inter-MAG operation and introduces overhead
> which
>   should be justified.
>
> > Dirk: Right - the expected performance improvement is not for free in
> > terms of complexity and protocol extensions (incl. MLD). Thus we have
> > to argue with dedicated services which benefit from disruption-free
> > mobile multicast receiption and may be asked for in large amount  so
> > that multicast will be economically viable
>
>
> - Does performance really benefit from forwarding? What's a typical use
> case:
>   Video broadcast, for example. Streaming applications may have some
>   buffered packets on the player. How does packet drop during handover
>   impact QoE compared to FHO-like forwarded MC packets? I guess they
>   have to be buffered at the target MAG before they can be delivered to
>   the MN, so latency is introduced whereas only packet drop is reduced.
>
> > Dirk: Agreed - the buffered content is received with delay, but since in pure
> multicast it would be lost to the mobile receiver otherwise, this is a gain.
> Thanks to increased processing power and storage capacity at handhelds the
> streamed IP Video is either already buffered at the terminal so a medium
> delay might be unnoticeable to the consumer (or he is anyway storing the
> video content for later consumption since on the move he cannot focus on
> viewing).

I am not really buying the use case of storing streamed video for watching it
later. AFAIK, if RTP is used in real-time streaming, which I see as main
application of MC, the player may drop packets if they arrive delayed
and continues playback of newer packets to keep the real-time notion.
Maybe my view is outdated ;-), but just take it into account when selling
the value of MC forwarding.

|Dirk: At least RTP in RFC 3550 allows 'considering that the receiver buffer must accommodate' delay and jitter variation ... So why not also store content for VCR-like replay and pause in case of live transmission (I think commercial IPTV already offers this within the set top box)
BTW, the dropout parameter in RFC 3550 can be as long as 1 minute i.e. (AFAIUIC) for forwarded packets up to such a delay it could still work ...

> But other broad- or multicast services like large scale synchronisation (social
> network data, anti virus sw updates, newsfeed distribution, ...) demand
> mainly error-free delivery rather than real-time character

Ok, so you say that forwarding should be used to avoid packet loss in
software updates which rely on MC for distribution?
True, this is not a real-time service anymore. But if reliability is the
main objective, I'd expect other transport mechanisms, such as
reliable multicast, to recover from packet losses. Not sure forwarding
outperforms reliable MC. In particular for software distribution with MC,
reordering and packet dup may be an issue to resolve if MC forwarding
is used.

|Dirk: I see that RMT specified both a 'NACK-Oriented Reliable Multicast (NORM) Transport Protocol' (RFC 5740) tolerating lossy conditions occurring in many mobile networks and also RFC 5775 'Asynchronous Layered Coding (ALC) Protocol Instantiation' (with FEC) which however introduce additional delay and bandwidth demand.
Which one performs better surely depends on the exact scenario ...

>
> - Is packet re-ordering an issue (forwarded packets between MAGs vs direct
>   packets)? Well, RTP may help on the player if it's used. Or is re-ordering
>   resolved on the MAG by means of scheduled delivery to the MN?
>
> > Dirk: Yes, and if the actual serving MAG is controling forwarding from
> > previous one the direct packets will be correspondingly postponed
>
> - Maybe CTX of multicast context is sufficient. Proactive CTX may help.
>   Whereas the benefit of reactive CTX needs to be compared against the
>   performance of the Multimob base approach for PMIPv6
>
> > Dirk: Again this depends on the application/use case - base Multimob does
> not care for lost packets during handover, right?
>
> - If forwarding between MAGs is adopted, we may consider it optional
>
> > Dirk: I tend to agree with Luis - subscription forwarding is more
> > important than content forwarding

With subscription forwarding you mean transfer of the MN's subscription context, right?
I agree. This is really valuable if it can be done proactively. So we have two cases
here: In case the nMAG has subscribed to the MC group already, the stream is
received at the nMAG  before the MN's handover. Having the MN's listener state
through proactive CTX, the nMAG can buffer these packets for later retrieval and
I don't see a benefit in MC forwarding from the pMAG. Forwarding could be of
advantage if the nMAG is not yet subscribed to the MC groups of interest to the
MN, as the subscription may take long. Such information could be exchanged
during CTX, which can be used as key to enable or disable forwarding for this
handover session.

marco

|Dirk: Yes, so we agree that proctive multicast subscription support can reduce delay and loss without requiring additional re-ordering and forwarding effort.
Thanks!

>
> - If forwarding between MAGs is not really beneficial, what is the right way
> for CTX?
>   2 approaches are being discussed: inter-MAG CTX (as per RFC4067) and
>   CTX via LMA. Can we assume efficient paths between MAGs in operator
>   networks? CTX via LMA puts less assumptions on SAs between MAGs and
>   link characteristics between MAGs. In particular beneficial when LMA
>   stores some multicast context.
>
> > Dirk: agree that LMA-MAG can already be assumed as established whereas
> for inter-MAG tunnel we need to set up. But if MAGs are owned by same
> operator and we think of a future scenario: LMAs may be quite centralized to
> save deployment and operational costs - so the delay and burden of
> processing all multicast contexts might be great. On the other hand future
> base stations (e.g. 3GPPs LTE-Advanced, but perhaps also 802.11..?) need
> direct links to synchronize and exchange link state information anyway (e.g.
> for Coordinated multi-point (CoMP), Multicell MIMO) so they could be re-
> used ...
>
>
> - Transferring context assumes that multicast state can be established at the
> proxy/querier without receiving corresponding join messages from MNs.
> This is an extension to MLD.
>
> > Dirk: I am afraid you are right  - unless it is possible for the pMAG
> > or LMA to act on behalf the MN and kind of 'spoof the MN join message'
> > ...? ;-)
>
> Regards,
>
> Behcet
> _______________________________________________
> multimob mailing list
> multimob at ietf.org
> https://www.ietf.org/mailman/listinfo/multimob
> _______________________________________________
> multimob mailing list
> multimob at ietf.org
> https://www.ietf.org/mailman/listinfo/multimob