Subject: [multimob] Multicast Context Transfer

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 25 Jul 2011 14:45:07 -0400

Hi all,

unfortunately, we did not reach a conclusion or clear picture on the 
subject of context transfer during the meeting.

It seems good to work on settling objectives first.

Thus the question: Can we agree on the following two purposes of context 
transfer?

  1. Accelerate handover / make handover seamless
  2. Switch to dedicated multicast links in a vertical handover (e.g., 
select a cheap/high quality broadcast link ...)

Cheers,

Thomas
-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: <[email-masked]>
Date: Mon, 25 Jul 2011 20:57:45 +0200

Hi Thomas,
So if one understands "seamless" to include being lossless and more reliable, I would agree.
Since multicast in contrast to unicast mostly is not acknowledged by each receiver I would stress the options of context transfer to reduce loss of data during handover thanks to storage at p-MAG and perhaps also including AAA information or similar MN subscription details which could delay the completion of subscription process after handover.

And regarding synchronisation with unicast: cannot we imagine a combined context transfer of all uni- and multicast sessions?

Best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Thomas C. Schmidt
Gesendet: Montag, 25. Juli 2011 20:45
An: [email-masked]
Betreff: [multimob] Multicast Context Transfer

Hi all,

Cheers,

Thomas
--

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 25 Jul 2011 16:05:40 -0400

Hi Dirk,

I guess we need to carefully distinguish here: There is packet loss due 
to slow handovers (MN disconnect), and packet loss due to many other 
reasons (e.g., radio instability ...).

The latter we cannot address at all, the first is mainly a result of 
handover performance. So this improves with accelerated 
unicast+multicast handover performance.

Regarding context broadcasting: "cannot we imagine a combined context 
transfer of all uni- and multicast sessions?"

What would this be good for? I guess, context is always 
interface-specific (otherwise multicast content will be delivered to all 
interfaces simultaneously ...)

Cheers,

Thomas

--

---

From: Osvaldo Gonsa <[email-masked]>
Date: Tue, 26 Jul 2011 10:29:19 +0200

Hello Gentlemen,

just to ask for clarification on the actual "need" for context transfer
in the multicast application. Normally in commercial/standardised
systems there is no "handover" of the multicast stream. This was mainly
done to simplify things.  Now, another reason was that typical multicast
applications like streaming TV/radio or PoC can tolerate very well the
handover interruption due to radio instabilities. It was/is even
possible to receive multicast/broadcast data while the terminal operates
in Idle mode.
Then my question to you is, what kind of applications do you have in
mind that will benefit for having such context transfer for multicast.
And if you allow me one more question, wouldn't be sufficient that
higher layers take care of any retransmission if packet loss happens and
would this be noticeable to the end-user?

Best Regards

Osvaldo

On 25/07/2011 22:05, Thomas C. Schmidt wrote:
> Hi Dirk,
>
> I guess we need to carefully distinguish here: There is packet loss
> due to slow handovers (MN disconnect), and packet loss due to many
> other reasons (e.g., radio instability ...).
>
> interface-specific (otherwise multicast content will be delivered to
> all interfaces simultaneously ...)
>
> Cheers,
>
> Thomas
>
>> Since multicast in contrast to unicast mostly is not acknowledged by
>> each receiver I would stress the options of context transfer to
>> reduce loss of data during handover thanks to storage at p-MAG and
>> perhaps also including AAA information or similar MN subscription
>> details which could delay the completion of subscription process
>> after handover.
>>
>> And regarding synchronisation with unicast: cannot we imagine a
>> combined context transfer of all uni- and multicast sessions?
>>
>> Best regards
>> Dirk
>>

-- 
Dr-Ing. Osvaldo Gonsa (ECE)

Panasonic Frankfurt Laboratory
Panasonic R&D Center Germany GmbH
D-63225 Langen, Germany
Tel.:+49-6103-766-250
Fax :+49-6103-766-166
Email: [email-masked]
---------------------------------

The problem with the future is that it keeps turning into the present....
----------------------------------

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 26 Jul 2011 10:59:12 -0400

Dear Osvaldo,

thanks for the feedback.

On 26.07.2011 04:29, Osvaldo Gonsa wrote:

> done to simplify things.

Question: What kind of "commercial/standardised systems" do you have in 
mind?

> Now, another reason was that typical multicast
> handover interruption due to radio instabilities.

This basically depends on the handover delay/interruption (and the 
tolerance of the codec), I believe. Still, in a typical soccer game, the 
hot period of goal hitting is very brief. If your receiver looses the 
critical packets due to handover, the user will miss the exciting moments.

>It was/is even

I suppose you're talking about a non-IP world here: an IP node is not 
able to receive IP streams without an IP interface configured.

> would this be noticeable to the end-user?

There are many higher layer solutions that can compensate packet loss 
(on the multicast transport or the coding side). There are two 
limitations with it

  1. They need to be in place (and the IP layer is intended to work fine 
without special compensations at higher layers)
  2. They impose (partly significant) delays which make retransmissions 
etc. infeasible for real-time traffic s.u. conversational/interactive 
services (conferencing, games, ...).

Best regards,

Thomas

--

---

From: Osvaldo Gonsa <[email-masked]>
Date: Wed, 27 Jul 2011 09:09:45 +0200

Hello Thomas and many thanks for your reply.
Although I wouldn't like to argue about the cases you write below (goal
missing, etc), I would like to point to the fact that the multicast
broadcast systems that have been standardised (3GPP MBMS) do not utilise
any context transfer for the multicast. But as I also said, that was
done mainly to simplify the system. Obviously on those days the scenario
you mention about football was also considered and also discussed that
with the appropriate buffer levels this discomfort of missing the key
play will be minimised.
Some more comments below,

On 26/07/2011 16:59, Thomas C. Schmidt wrote:
> Question: What kind of "commercial/standardised systems" do you have
> in mind?
>
> tolerance of the codec), I believe. Still, in a typical soccer game,
> the hot period of goal hitting is very brief. If your receiver looses
> the critical packets due to handover, the user will miss the exciting
> moments.
>
>> It was/is even

A terminal that is in Idle mode still is configured at the IP level,
only its radio was configured to wake up at specific times when the
downlink multicast data were supposed to arrive. But nevertheless the
terminal had always its IP interface configured. Sorry for the confusion.

>  1. They need to be in place (and the IP layer is intended to work
> fine without special compensations at higher layers)

My thinking of higher layer solutions was thinking that TCP flows (which
IMHO are always "in place") have their re-transmission mechanism or UDP
flows could be well handled with appropriate buffering.
Interactive real-time communications (except for gaming) have less
strict requirements for delay and packet loss. I must admit that for
mobile multi-player gaming there may be a good case due to the strict
requirements on delay and packet loss, but besides that (and the
commercial viability of it) I couldn't think of a valid case requiring
the context transfer in multicast scenario, therefore my initial question.

Thank you very much for your time

with my Best Regards

Osvaldo

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 27 Jul 2011 13:29:44 -0400

Dear Osvaldo,

thanks for adding to the discussion!

On 27.07.2011 03:09, Osvaldo Gonsa wrote:
> done mainly to simplify the system.

Well, we are currently looking ahead of MBMS ... also, IETF claims to 
take the lead in developing L2.5++ protocols ;

> terminal had always its IP interface configured. Sorry for the confusion.

Thanks, I was confused. You are talking about L1/2 energy saving.

I guess this is unrelated to context transfer, but interesting: which L2 
technologies can support multicast reception in idle mode? (802.11 does 
not, I suppose).

> the context transfer in multicast scenario, therefore my initial question.

I guess conferencing is such a use case, as well. Conversational audio 
in particular is quite sensitive to disruptions and delays.

Best regards,

Thomas

--

---

From: <[email-masked]>
Date: Wed, 27 Jul 2011 21:48:50 +0200

Dear all,
Thanks! For me the discussion emphasizes that it is important to detail the actual use cases and applications for the multicast scenario:
Whereas there are applications which are very sensitive to delay (and slightly less to loss) as the conferencing mentioned by Thomas others are less sensitive to HO latency thanks to built in buffering mode, but can't cope with data loss (I think that applies for web AV streaming) and others can cope with both (e.g. multicast download of software updates for multitude of terminals) ... Just as examples.

To a certain extent such context may also be exchanged between MAGs and LMA as Carlos proposes.

Similarily application specifics were also discussed in the MEXT-related ad-hoc meeting this morning where an according prefix coloring and mapping to different application QoS constraints was proposed ... AFAIRC by Sri

Best regards

Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Thomas C. Schmidt
Gesendet: Mittwoch, 27. Juli 2011 19:30
An: Osvaldo Gonsa
Cc: [email-masked]
Betreff: Re: [multimob] Multicast Context Transfer

Dear Osvaldo,

Best regards,

Thomas

--