Re: [EToSat] Multicast tools and scenarios

Hi CJ,
Thanks for your reply.

The delay part makes sense.

On the data-rate, I find that quite interesting, is it typical to use 
higher data-rates for multicast? Is this to use less airtime? On WiFi 
the situation is quite messy and multicast is not very well supported 
(low data-rates etc.) - do you know how the support is for satellite?

All the best,
Morten

On 12/9/19 2:49 PM, Su, Chi-Jiun wrote:
> Hi Morten,
>
> - delay will be the same since it is dictated by law of physics excluding queuing delay
> - data rate can be higher than per-terminal download data rate.
>
> Thanks.
> cj
>
> -----Original Message-----
> From: EToSat <etosat-bounces@ietf.org> On Behalf Of Morten V. Pedersen
> Sent: Monday, December 9, 2019 5:28 AM
> To: etosat@ietf.org
> Subject: [EToSat] Multicast tools and scenarios
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> Dear all,
>
>
>
> Following up on the "Download Regression Tests" thread. Which focuses on
>
> unicast (as far as I can tell). We are looking at multicast over
>
> satellite (in particular for file delivery). I'm not a satellite expert
>
> so I was wondering if similar parameters with respect to delay,
>
> data-rate etc. are valid there?
>
>
>
> Also what (if any) would be the state-of-the art solution for that?
>
>
>
> All the best,
>
> Morten
>
>
>
> _______________________________________________
>
> EToSat mailing list
>
> EToSat@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/etosat__;!!Emaut56SYw!nyMSmIq-w8rvK073xEu_Ue8M3CDeZ-usJaecpU5a6t2316ScAZvAnRuAomAf2s8-Nw$
>