Subject: [EToSat] Download Regression Tests

From: "Border, John" <[email-masked]>
Date: Tue, 3 Dec 2019 18:24:39 +0000

The following are the variables we play with:

  *   Delay - 600 milliseconds, 1000 milliseconds
  *   File Size - 1 MB, 10 MB, 100 MB, 1000 MB
  *   Packet Error Rate - 0.0%, 0.1%, 1%, 5%, 10%
  *   Plan Rate:
     *   Download (Internet to host)  - 10 Mbps, 25 Mbps, 100 Mbps, 250 Mbps
     *   Upload (host to Internet) - 3 Mbps, 10 Mbps, 25 Mbps

The ones in bold are the ones we focus on since all of the above result in a lot of combinations.  If I had to pick just two, right now I would go with:

  *   600 milliseconds, 1000 MB, 0.0%, 250 Mbps, 3 Mbps
  *   600 milliseconds, 1000 MB, 1.0%, 250 Mbps, 3 Mbps

600 milliseconds is the baseline delay.  Longer delays definitely happen during traffic peaks.  Longer than one second delays happen at traffic peak for traffic we classify as lower priority...

1 MB tests are web page object size tests.  1 GB tests are download tests.  (We would use 100 MB for upload tests but we have not really done any yet.)  We really have only been focusing large file sizes since we have been focusing on what we lose without TCP spoofing.

For error rates, I included 5% an 10% because they represent WiFi extremes (and we did try them).  But, those values barely work at all.  We mainly focus on 1%.  There are actually two variants of error rate.  One is loss between the client and the satellite terminal.  (This is the loss TCP spoofing helps with.)  The other is loss between the satellite terminal and the satellite gateway which connects to the Internet.  We focus mostly on client side loss.

We mostly have been testing with a 250 Mbps download plan rate so we can see how things work without being artificially limited.  We are easily able to fill this with TCP spoofing and ultimately we want QUIC to be on par with that.  (I think the best we have seen Google QUIC do in recent testing is ~30 Mbps but a few years ago it was only 3 Mbps so things are moving in a good direction.)   But, you cannot get plan rates like that outside of a lab right now.  In today's real world, we run with 25 Mbps download plans for customers.  Some providers use ~10 Mbps download plan rates.  We look at the higher rates anyway because we are trying to look ahead and satellite technology improves significantly over time.  We envision 100 Mbps download plans someday.

We have not done much upload testing to date.  So, the upload plan rate has mattered mostly for purposes of how much ACK traffic it can carry.  ACK reduction strategies are important for satellite but we have not done much with this yet other than to observe that 30 Mbps of Google QUIC download traffic fills the upload pipe.

Not sure if this is what you were looking for but...

John

---

From: Christian Huitema <[email-masked]>
Date: Wed, 4 Dec 2019 06:27:35 +0800

Thanks, that's very helpful.

I was doing test so far by simulating 600 ms delay, 100 Mbps download
and 100 Mbps upload (symmetric). I will switch the simulated
configuration to 250 Mbps upload and 3 Mbps download.

I am still working on the asymmetric link part, but I just did a test
with 1GB with 250 Mbps symmetric link. With 0 error, it completes in a
bit less than 36 sec on the Picoquic simulator -- effective data rate
would be 222 Mbps. Not a problem for a one-off test, but that's a bit
onerous for a non-regression test that shall run on every check-in.

I also tested 100 MB and 10 MB. The 100 MB test completes on the
Picoquic simulator in 8.24 sec, average rate of 97 Mbps, and the 10MB
test completes in 5.22 sec, average of 15 Mbps. The 10MB test is
dominated by connection establishment and rate ramping issues (slow
start, flow control, etc.) The 100 MB test has that, plus about 3
seconds of full speed transmission. I think 100MB is enough for the "non
regression" function. It provides a good mix of establishment and data
rate issues.

I guess the file size is a simple parameter. I have two additional
questions for setting up the simulations:

1) What is the maximum size of the buffer on the download path?

2) When simulating the 1% loss rate, is there a pattern to the losses,
or are they just randomly distributed with independent probability for
each packet?

-- Christian Huitema

On 12/4/2019 2:24 AM, Border, John wrote:
>   * Delay – *600 milliseconds*, 1000 milliseconds
>   * File Size – *1 MB*, 10 MB, 100 MB, *1000 MB*
>   * Packet Error Rate – *0.0%*, 0.1%, *1%*, 5%, 10%
>   * Plan Rate:
>       o Download (Internet to host)  - 10 Mbps, 25 Mbps, 100 Mbps,
>         *250 Mbps*
>       o Upload (host to Internet) – *3 Mbps*, 10 Mbps, 25 Mbps
>
>  
>
> The ones in bold are the ones we focus on since all of the above
> result in a lot of combinations.  If I had to pick just two, right now
> I would go with:
>
>  
>
> 600 milliseconds is the baseline delay.  Longer delays definitely
> happen during traffic peaks.  Longer than one second delays happen at
> traffic peak for traffic we classify as lower priority…
>
>  
>
> 1 MB tests are web page object size tests.  1 GB tests are download
> tests.  (We would use 100 MB for upload tests but we have not really
> done any yet.)  We really have only been focusing large file sizes
> since we have been focusing on what we lose without TCP spoofing.
>
>  
>
> For error rates, I included 5% an 10% because they represent WiFi
> extremes (and we did try them).  But, those values barely work at all.
>  We mainly focus on 1%.  There are actually two variants of error
> rate.  One is loss between the client and the satellite terminal. 
> (This is the loss TCP spoofing helps with.)  The other is loss between
> the satellite terminal and the satellite gateway which connects to the
> Internet.  We focus mostly on client side loss.
>
>  
>
> We mostly have been testing with a 250 Mbps download plan rate so we
> can see how things work without being artificially limited..  We are
> easily able to fill this with TCP spoofing and ultimately we want QUIC
> to be on par with that.  (I think the best we have seen Google QUIC do
> in recent testing is ~30 Mbps but a few years ago it was only 3 Mbps
> so things are moving in a good direction.)   But, you cannot get plan
> rates like that outside of a lab right now.  In today’s real world, we
> run with 25 Mbps download plans for customers.  Some providers use ~10
> Mbps download plan rates.  We look at the higher rates anyway because
> we are trying to look ahead and satellite technology improves
> significantly over time.  We envision 100 Mbps download plans someday.
>
>  
>
> We have not done much upload testing to date.  So, the upload plan
> rate has mattered mostly for purposes of how much ACK traffic it can
> carry.  ACK reduction strategies are important for satellite but we
> have not done much with this yet other than to observe that 30 Mbps of
> Google QUIC download traffic fills the upload pipe.
>
>  
>
> Not sure if this is what you were looking for but…
>
>  
>
> John
>
>
> _______________________________________________
> EToSat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/etosat

---

From: Kuhn Nicolas <[email-masked]>
Date: Wed, 4 Dec 2019 08:14:55 +0000

Hi,

We had initiated a regression test description in the QUIC 4 SATCOM document.
https://github.com/NicoKos/QUIC_HIGH_BDP/tree/master/ietf-document/draft-quic-4-sat

An updated version in a more readable format than XML is attached and in the GITHUB repo.
The scenario that you propose in more challenging than the ones we had discussed with Gorry at Singapore.
I have added your scenario in the document - but you may not want to keep them all.

What do you think ?

I guess we can at least remove the 10 Mbps one.
However, keeping the 50 Mbps / 10 Mbps shows a different asymmetry and it may be interesting to keep it.

More comments inline.

Cheers,

Nico

De : Christian Huitema <[email-masked]>
Envoyé : mardi 3 décembre 2019 23:28
À : Border, John <[email-masked]>; Kuhn Nicolas <[email-masked]>
Cc : [email-masked]
Objet : Re: [EToSat] Download Regression Tests

I was doing test so far by simulating 600 ms delay, 100 Mbps download and 100 Mbps upload (symmetric). I will switch the simulated configuration to 250 Mbps upload and 3 Mbps download.

I am still working on the asymmetric link part, but I just did a test with 1GB with 250 Mbps symmetric link. With 0 error, it completes in a bit less than 36 sec on the Picoquic simulator -- effective data rate would be 222 Mbps. Not a problem for a one-off test, but that's a bit onerous for a non-regression test that shall run on every check-in.

I also tested 100 MB and 10 MB. The 100 MB test completes on the Picoquic simulator in 8.24 sec, average rate of 97 Mbps, and the 10MB test completes in 5.22 sec, average of 15 Mbps. The 10MB test is dominated by connection establishment and rate ramping issues (slow start, flow control, etc.) The 100 MB test has that, plus about 3 seconds of full speed transmission. I think 100MB is enough for the "non regression" function. It provides a good mix of establishment and data rate issues.

[NK] That size seems a good trade-off to me

I guess the file size is a simple parameter. I have two additional questions for setting up the simulations:

[NK] We propose to set the buffersize to the BDP - to begin with

2) When simulating the 1% loss rate, is there a pattern to the losses, or are they just randomly distributed with independent probability for each packet?

[NK] The 1% loss rate is not really random since both congestion and random losses occur in a bursty way. We will try to share more details very soon

-- Christian Huitema

We mostly have been testing with a 250 Mbps download plan rate so we can see how things work without being artificially limited..  We are easily able to fill this with TCP spoofing and ultimately we want QUIC to be on par with that.  (I think the best we have seen Google QUIC do in recent testing is ~30 Mbps but a few years ago it was only 3 Mbps so things are moving in a good direction.)   But, you cannot get plan rates like that outside of a lab right now.  In today's real world, we run with 25 Mbps download plans for customers.  Some providers use ~10 Mbps download plan rates.  We look at the higher rates anyway because we are trying to look ahead and satellite technology improves significantly over time.  We envision 100 Mbps download plans someday.

John

EToSat mailing list

[email-masked]<mailto:[email-masked]>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 04 Dec 2019 11:02:18 +0000

On 04/12/2019, 08:14, Kuhn Nicolas wrote:
> I have added your scenario in the document – but you may not want to 
> keep them all.
>
> What do you think ?
>
[GF] I'd keep this for the moment. It's a simple enough test, and if you 
can fill 10 Mbps with a single stream, then that's pretty good.
> it may be interesting to keep it.
Gorry
>
> *De :* Christian Huitema <[email-masked]>
> *Envoyé :* mardi 3 décembre 2019 23:28
> *À :* Border, John <[email-masked]>; Kuhn Nicolas 
> <[email-masked]>
> *Cc :* [email-masked]
> *Objet :* Re: [EToSat] Download Regression Tests
>
> seconds of full speed transmission. I think 100MB is enough for the 
> "non regression" function. It provides a good mix of establishment and 
> data rate issues.
>
> */[NK] That size seems a good trade-off to me/*
>
> [NK] We propose to set the buffersize to the BDP – to begin with
>
> */[NK] The 1% loss rate is not really random since both congestion and 
> random losses occur in a bursty way. We will try to share more details 
> very soon/*
>
> -- Christian Huitema
>
>     result in a lot of combinations. If I had to pick just two, right
>     now I would go with:
>
>     happen during traffic peaks. Longer than one second delays happen
>     at traffic peak for traffic we classify as lower priority…
>
>     tests. (We would use 100 MB for upload tests but we have not
>     really done any yet.) We really have only been focusing large file
>     sizes since we have been focusing on what we lose without TCP
>     spoofing.
>
>     extremes (and we did try them). But, those values barely work at
>     all. We mainly focus on 1%. There are actually two variants of
>     error rate. One is loss between the client and the satellite
>     terminal. (This is the loss TCP spoofing helps with.) The other is
>     loss between the satellite terminal and the satellite gateway
>     which connects to the Internet. We focus mostly on client side loss.
>
>     We mostly have been testing with a 250 Mbps download plan rate so
>     we can see how things work without being artificially limited...
>     We are easily able to fill this with TCP spoofing and ultimately
>     we want QUIC to be on par with that. (I think the best we have
>     seen Google QUIC do in recent testing is ~30 Mbps but a few years
>     ago it was only 3 Mbps so things are moving in a good direction.)
>     But, you cannot get plan rates like that outside of a lab right
>     now. In today’s real world, we run with 25 Mbps download plans for
>     customers. Some providers use ~10 Mbps download plan rates. We
>     look at the higher rates anyway because we are trying to look
>     ahead and satellite technology improves significantly over time.
>     We envision 100 Mbps download plans someday.
>
>     rate has mattered mostly for purposes of how much ACK traffic it
>     can carry. ACK reduction strategies are important for satellite
>     but we have not done much with this yet other than to observe that
>     30 Mbps of Google QUIC download traffic fills the upload pipe.
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: François Michel <[email-masked]>
Date: Wed, 4 Dec 2019 14:13:22 +0000

Hello,

We also performed some experiments with PQUIC/Picoquic over a satellite 
link with Nicolas and Emmanuel. We analyzed the loss patterns and 
deduced some two-state Gilbert parameters from network traces for two 
different scenarios. This model is less general than the Gilbert-Elliott 
model but is allows us to represent bursty loss patterns: in the GOOD 
state, all the packets are successfully received. In the bad state, the 
packets are simply dropped.

Here are the two studied scenarios :

1) The client is connected to a wired network and its traffic towards 
the server is then routed through a satellite link.
2) The client is connected to a WiFi access point instead of a wired 
network. Its traffic towards the server is then still routed through a 
satellite link.

What differs between these two scenarios is that in 2) we can also 
encounter losses due to the WiFi communication.

We count the received packets at the receiver, knowing that the sender 
is configured to send packets with a contiguously increasing packet 
number: although it is feasible in QUIC, our Picoquic sender will never 
send packet n if it has not sent packet n-1. We provide the packet 
counts so that you can also do your own computations if needed.

Here are the packets count and estimated probability of transitions of 
the Gilbert model we deduced from our experiments :

For the scenario 1:
-------------------

from/to GOOD    BAD
GOOD    80709   1370
BAD     1370    86

This means that 80709 packets have been received while the previous 
packet was received (GOOD->GOOD), 86 packets have been lost while the 
previous packet was also lost (BAD->BAD), 1370 packets have been 
received while the previous packet was lost (BAD->GOOD) and 1370 packets 
have been lost while the previous packet was received (GOOD->BAD).

The average burst in the BAD state is quite small, but in our traces we 
still found one loss burst of 15 packets.

The estimated transitions probabilities of the Gilbert model:
P(GOOD->GOOD) = 0.9833087635083273
P(GOOD->BAD) = 0.016691236491672656
P(BAD->GOOD) = 0.9409340659340659
P(BAD->BAD) = 0.059065934065934064

For the scenario 2:
-------------------

from/to GOOD    BAD
GOOD    38700   700
BAD     699     385

P(GOOD->GOOD) = 0.9822335025380711
P(GOOD->BAD) = 0.017766497461928935
P(BAD->GOOD) = 0.6448339483394834
P(BAD->BAD) = 0.3551660516605166

Also quite isolated losses in general but we encountered more frequent 
bursts, and we encountered larger loss bursts such as one burst of size 
33 and one burst of size 30.
Keep in mind that these experiments are quite small and could be 
influenced by the period of the day during which they have been performed.

We hope this helps.

François

Le 3/12/19 à 19:24, Border, John a écrit :
>       o Download (Internet to host)  - 10 Mbps, 25 Mbps, 100 Mbps, *250
>         Mbps*
> The ones in bold are the ones we focus on since all of the above result 
> in a lot of combinations.  If I had to pick just two, right now I would 
> go with:
> 
> 600 milliseconds is the baseline delay.  Longer delays definitely happen 
> during traffic peaks.  Longer than one second delays happen at traffic 
> peak for traffic we classify as lower priority…
> 
> done any yet.)  We really have only been focusing large file sizes since 
> we have been focusing on what we lose without TCP spoofing.
> 
> rate.  One is loss between the client and the satellite terminal.  (This 
> is the loss TCP spoofing helps with.)  The other is loss between the 
> satellite terminal and the satellite gateway which connects to the 
> We mostly have been testing with a 250 Mbps download plan rate so we can 
> see how things work without being artificially limited..  We are easily 
> able to fill this with TCP spoofing and ultimately we want QUIC to be on 
> par with that.  (I think the best we have seen Google QUIC do in recent 
> testing is ~30 Mbps but a few years ago it was only 3 Mbps so things are 
> moving in a good direction.)   But, you cannot get plan rates like that 
> outside of a lab right now.  In today’s real world, we run with 25 Mbps 
> download plans for customers.  Some providers use ~10 Mbps download plan 
> rates.  We look at the higher rates anyway because we are trying to look 
> ahead and satellite technology improves significantly over time.  We 
> envision 100 Mbps download plans someday.
> 
> We have not done much upload testing to date.  So, the upload plan rate 
> has mattered mostly for purposes of how much ACK traffic it can carry.  
> ACK reduction strategies are important for satellite but we have not 
> done much with this yet other than to observe that 30 Mbps of Google 
> QUIC download traffic fills the upload pipe.
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fetosat&amp;data=02%7C01%7C%7Cc47c9ee8fadc4bc05bb908d7781e1768%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637109942949480777&amp;sdata=nbhVVrQcHaOLIUvQOuW5CA8UjXQCZXkz7SFyxoreGR0%3D&amp;reserved=0
>

---

From: Christian Huitema <[email-masked]>
Date: Thu, 5 Dec 2019 05:32:32 +0800

On 12/4/2019 7:02 PM, Gorry Fairhurst wrote:
> [GF] I'd keep this for the moment. It's a simple enough test, and if
> you can fill 10 Mbps with a single stream, then that's pretty good.
>>

Looking at the draft, I see that "the test should report ... The
downloading time of 100 MB on the download, The downloading time of 100
MB on the upload". I am a bit puzzled by the last sentence. Do you mean
"The uploading time of 100 MB on the upload"? And if you mean that, is
it really worth it measuring 100 MB there?

The 100MB upload certainly makes sense as a system validation test, but
it does not have a huge value as a non regression test. I mean, if we
can measure download on a 10/2 link, what do you believe will be learned
by measuring upload on a 50/10 link?

-- Christian Huitema

---

From: Kuhn Nicolas <[email-masked]>
Date: Thu, 5 Dec 2019 07:06:16 +0000

De : EToSat <[email-masked]> De la part de Christian Huitema
Envoyé : mercredi 4 décembre 2019 22:33
À : [email-masked]; Kuhn Nicolas <[email-masked]>
Cc : [email-masked]; Border, John <[email-masked]>
Objet : Re: [EToSat] Download Regression Tests

Hi,

What do you think ?

I guess we can at least remove the 10 Mbps one.
[GF] I'd keep this for the moment. It's a simple enough test, and if you can fill 10 Mbps with a single stream, then that's pretty good.

More comments inline.

Looking at the draft, I see that "the test should report ... The downloading time of 100 MB on the download, The downloading time of 100 MB on the upload". I am a bit puzzled by the last sentence. Do you mean "The uploading time of 100 MB on the upload"? And if you mean that, is it really worth it measuring 100 MB there?

The 100MB upload certainly makes sense as a system validation test, but it does not have a huge value as a non regression test. I mean, if we can measure download on a 10/2 link, what do you believe will be learned by measuring upload on a 50/10 link?

[NK] You are right - this is not really useful for a regression test. It was more a place holder in case we want to go more into the details of return link accesses in SATCOM that may impact end-to-end protocols. But I will keep that in my mind and remove it in the next version of the draft.

-- Christian Huitema

---

From: Kuhn Nicolas <[email-masked]>
Date: Thu, 5 Dec 2019 09:39:29 +0000

This surely helps ! 
Thanks a lot. 

I have updated the document with two possible loss patterns. 
https://github.com/NicoKos/QUIC_HIGH_BDP/blob/master/ietf-document/draft-quic-4-sat/draft-kuhn-quic-4-sat-03.txt 
If you have any views, please let us know. 

I guess there are still some open questions :
- should we keep all four scenarios ?
- should we propose two loss models or only one ?

Nico

-----Message d'origine-----
De : François Michel <[email-masked]> 
Envoyé : mercredi 4 décembre 2019 15:13
À : Border, John <[email-masked]>; Kuhn Nicolas <[email-masked]>
Cc : [email-masked]; Emmanuel Lochin <[email-masked]>
Objet : Re: [EToSat] Download Regression Tests

Hello,

We also performed some experiments with PQUIC/Picoquic over a satellite link with Nicolas and Emmanuel. We analyzed the loss patterns and deduced some two-state Gilbert parameters from network traces for two different scenarios. This model is less general than the Gilbert-Elliott model but is allows us to represent bursty loss patterns: in the GOOD state, all the packets are successfully received. In the bad state, the packets are simply dropped.

1) The client is connected to a wired network and its traffic towards the server is then routed through a satellite link.
2) The client is connected to a WiFi access point instead of a wired network. Its traffic towards the server is then still routed through a satellite link.

What differs between these two scenarios is that in 2) we can also encounter losses due to the WiFi communication.

We count the received packets at the receiver, knowing that the sender is configured to send packets with a contiguously increasing packet
number: although it is feasible in QUIC, our Picoquic sender will never send packet n if it has not sent packet n-1. We provide the packet counts so that you can also do your own computations if needed.

Here are the packets count and estimated probability of transitions of the Gilbert model we deduced from our experiments :

For the scenario 1:
-------------------

from/to GOOD    BAD
GOOD    80709   1370
BAD     1370    86

For the scenario 2:
-------------------

from/to GOOD    BAD
GOOD    38700   700
BAD     699     385

We hope this helps.

François

Le 3/12/19 à 19:24, Border, John a écrit :
>   * Delay - *600 milliseconds*, 1000 milliseconds
>   * File Size - *1 MB*, 10 MB, 100 MB, *1000 MB*
>   * Packet Error Rate - *0.0%*, 0.1%, *1%*, 5%, 10%
>   * Plan Rate:
>       o Upload (host to Internet) - *3 Mbps*, 10 Mbps, 25 Mbps
> 
> peak for traffic we classify as lower priority.
> 
> outside of a lab right now.  In today's real world, we run with 25 Mbps 
> Not sure if this is what you were looking for but.
> 
> John
> 
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 6 Dec 2019 04:27:10 +0800

I think the spirit is to use the loss scenario #2 in the "Wi-Fi +
satellite" simulations. That sounds like a good test case.

We can start with that, but I am still concerned about modelling
congestion losses as part of the loss pattern, especially Wi-Fi losses.
I can imagine situations in which the Wi-Fi link is the congestion
bottleneck, instead of the satellite link. In these situations, the end
to end goal would be to pick a transmission rate that does not saturate
the Wi-Fi link, and ensure a good flow of information end to end.

I am concerned that observations based on end-of-end transport flows mix
congestion losses due to sending faster than the Wi-Fi link can
transmit, and radio losses due to poor Wi-Fi transmission conditions. I
wonder whether we can do experiments that separate the two.

-- Christian Huitema

---

From: Kuhn Nicolas <[email-masked]>
Date: Fri, 6 Dec 2019 14:59:39 +0000

I have updated the document with a proposal  
- the burst model includes congestion and propagation losses
- the uniform random loss includes only wi-fi losses 
That may be a starting point for discussion. 

If we want to include the congestion at the wifi router (without AQM?), which is an interesting use-case, I guess we have to go more into the details of the architecture. 
A solution would be to include multiple machines and emulated SATCOM system with satellite terminal. 
We can surely add this kind of regression test, but I am afraid that it may be too complexed as a first step. 
Anyway, we can propose an optional more complexed scenario if you think his is relevant. 

Cheers, 

Nico

-----Message d'origine-----
De : Christian Huitema <[email-masked]> 
Envoyé : jeudi 5 décembre 2019 21:27
À : Kuhn Nicolas <[email-masked]>; 'François Michel' <[email-masked]>; Border, John <[email-masked]>
Cc : [email-masked]; Emmanuel Lochin <[email-masked]>
Objet : Re: [EToSat] Download Regression Tests

I think the spirit is to use the loss scenario #2 in the "Wi-Fi + satellite" simulations. That sounds like a good test case.

We can start with that, but I am still concerned about modelling congestion losses as part of the loss pattern, especially Wi-Fi losses.
I can imagine situations in which the Wi-Fi link is the congestion bottleneck, instead of the satellite link. In these situations, the end to end goal would be to pick a transmission rate that does not saturate the Wi-Fi link, and ensure a good flow of information end to end.

I am concerned that observations based on end-of-end transport flows mix congestion losses due to sending faster than the Wi-Fi link can transmit, and radio losses due to poor Wi-Fi transmission conditions. I wonder whether we can do experiments that separate the two.

-- Christian Huitema

On 12/5/2019 5:39 PM, Kuhn Nicolas wrote:
> https://github.com/NicoKos/QUIC_HIGH_BDP/blob/master/ietf-document/dra
> ft-quic-4-sat/draft-kuhn-quic-4-sat-03.txt
> De : François Michel <[email-masked]> Envoyé : mercredi 
> 4 décembre 2019 15:13 À : Border, John <[email-masked]>; Kuhn 
> Nicolas <[email-masked]> Cc : [email-masked]; Emmanuel Lochin 
> <[email-masked]> Objet : Re: [EToSat] Download 
> Regression Tests
>
> Hello,
>
> received while the previous packet was lost (BAD->GOOD) and 1370 
> packets have been lost while the previous packet was received (GOOD->BAD).
>
>
> The average burst in the BAD state is quite small, but in our traces 
> we still found one loss burst of 15 packets.
>
>> traffic peak for traffic we classify as lower priority.
>>
>> (This is the loss TCP spoofing helps with.)  The other is loss 
>> between the satellite terminal and the satellite gateway which 
>> connects to the Internet.  We focus mostly on client side loss.
>>
>> easily able to fill this with TCP spoofing and ultimately we want 
>> QUIC to be on par with that.  (I think the best we have seen Google 
>> QUIC do in recent testing is ~30 Mbps but a few years ago it was only 
>> 3 Mbps so things are moving in a good direction.)   But, you cannot 
>> get plan rates like that outside of a lab right now.  In today's real 
>> world, we run with 25 Mbps download plans for customers.  Some 
>> providers use ~10 Mbps download plan rates.  We look at the higher 
>> rates anyway because we are trying to look ahead and satellite 
>> technology improves significantly over time.  We envision 100 Mbps download plans someday.
>>
>> rate has mattered mostly for purposes of how much ACK traffic it can carry.
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fetosat&amp;data=02%7C01%7C%7Cc47c9ee
>> 8fadc4bc05bb908d7781e1768%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%
>> 7C637109942949480777&amp;sdata=nbhVVrQcHaOLIUvQOuW5CA8UjXQCZXkz7SFyxo
>> reGR0%3D&amp;reserved=0
>>

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Mon, 9 Dec 2019 11:28:20 +0100

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

---

From: "Su, Chi-Jiun" <[email-masked]>
Date: Mon, 9 Dec 2019 13:49:14 +0000

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 <[email-masked]> On Behalf Of Morten V. Pedersen
Sent: Monday, December 9, 2019 5:28 AM
To: [email-masked]
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,

All the best,

Morten

EToSat mailing list

[email-masked]

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/etosat__;!!Emaut56SYw!nyMSmIq-w8rvK073xEu_Ue8M3CDeZ-usJaecpU5a6t2316ScAZvAnRuAomAf2s8-Nw$

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Tue, 10 Dec 2019 22:03:14 +0100

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

---

From: "Su, Chi-Jiun" <[email-masked]>
Date: Wed, 11 Dec 2019 15:32:49 +0000

Hi Morten,

- Like Wifi and cellular, signal transmitted by Wifi access point, Cellular base station and Satellite Gateway is received by all the users in the coverage area.  Depending on where a user is located in the coverage area, the signal strength differs.
- In time-multiplexed DVB-S2 transmission from the gateway to the users in a spot beam in a Geo Sat system, transmission opportunity to multiple users (multicast) can be allocated more than that to a single user. That is, multicast data rate can be higher.
- for mobile satellite system with 3gpp protocol, MBMS may be supported 
- for fixed satellite system, multicast support can be proprietary.
- data in management and control plane in a satellite system is being broadcast/multicast to the users in a spot beam
- broadcast/multicast of user data requires "use cases". Nowadays, most user's content is encrypted and prevalent encryption limits use cases.  Multicasting in a satellite system can be accomplished as long as there is a strong use case.

Thanks.
cj
-----Original Message-----
From: EToSat <[email-masked]> On Behalf Of Morten V. Pedersen
Sent: Tuesday, December 10, 2019 4:03 PM
To: Su, Chi-Jiun <[email-masked]>; [email-masked]
Subject: Re: [EToSat] Multicast tools and scenarios

Hi CJ,

Thanks for your reply.

All the best,

Morten

EToSat mailing list

[email-masked]

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/etosat__;!!Emaut56SYw!iM0R0ruhykN0LLab2TFAZqnWEuwDgCq1_hitr6IuIjTJOErN0dUwtd-uXfnfszd1Tw$

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Fri, 13 Dec 2019 10:22:12 +0100

Hi CJ,
Thanks for this overview - makes sense.

All the best,
Morten