[Cake] Cake over satellite

[Cake] Cake over satellite

[Noven Purnell-Webb]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

I'm about to go on a mission to the outback, with one objective being to
tune a disappointing satellite link. Theoretically 6/1mbps, with RTTs
ranging from 700 - 1200ms. From the cake technical page
"The AQM layer has no configuration options. However, it is planned to add
simple tuning options for different prevailing RTTs that may be
significantly different from the Internet-scale 100ms currently assumed.
Satellite links tend to impose longer RTTs, and enclosed LANs tend to have
much shorter RTTs." Does this imply cake is not yet ready for use on
satellite links? Or merely that I'll get sub-optimal results but it's still
worth testing?
I see I could set the interval in sch_cake.c and recompile - is there any
reason why this would be a bad idea? Am I right in thinking with such
observed variation I'll get better results setting for the lower limit
(700) rather than the upper (1200)?
Any suggestions for a more sane target to set while I'm doing this?
Has anyone here already done testing on satellite links?

- Noven

-- 
- Noven Purnell-Webb
Creative Technology Consultant
+61 448 841 091
http://onecardme.com/NovenPWebb

[-- Attachment #2: Type: text/html, Size: 1551 bytes --]

Re: [Cake] Cake over satellite

[Dave Taht]

The current github/dtaht/sch_cake now has support for setting the rtt
(interval) parameter.

However, testing was to start... today. Taking it right to the outback
before then, well, that's a level of field test that I desire but...
wow!

On Mon, Oct 19, 2015 at 4:55 PM, Noven Purnell-Webb
<noven@liberant.com.au> wrote:
> I'm about to go on a mission to the outback, with one objective being to
> tune a disappointing satellite link. Theoretically 6/1mbps, with RTTs
> ranging from 700 - 1200ms. From the cake technical page
> "The AQM layer has no configuration options. However, it is planned to add
> simple tuning options for different prevailing RTTs that may be
> significantly different from the Internet-scale 100ms currently assumed.
> Satellite links tend to impose longer RTTs, and enclosed LANs tend to have
> much shorter RTTs." Does this imply cake is not yet ready for use on
> satellite links? Or merely that I'll get sub-optimal results but it's still
> worth testing?
> I see I could set the interval in sch_cake.c and recompile - is there any
> reason why this would be a bad idea? Am I right in thinking with such
> observed variation I'll get better results setting for the lower limit (700)
> rather than the upper (1200)?
> Any suggestions for a more sane target to set while I'm doing this?
> Has anyone here already done testing on satellite links?
>
> - Noven
>
> --
> - Noven Purnell-Webb
> Creative Technology Consultant
> +61 448 841 091
> http://onecardme.com/NovenPWebb
>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>



-- 
Dave Täht
Do you want faster, better, wifi? https://www.patreon.com/dtaht

Re: [Cake] Cake over satellite

[Loganaden Velvindron]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

On Mon, Oct 19, 2015 at 2:55 PM, Noven Purnell-Webb <noven@liberant.com.au>
wrote:

> I'm about to go on a mission to the outback, with one objective being to
> tune a disappointing satellite link. Theoretically 6/1mbps, with RTTs
> ranging from 700 - 1200ms. From the cake technical page
>

Hi Noven.

This has happened:

using tc-adv, you now have the RTT parameter.

The page needs to be updated to reflect that.



> "The AQM layer has no configuration options. However, it is planned to add
> simple tuning options for different prevailing RTTs that may be
> significantly different from the Internet-scale 100ms currently assumed.
> Satellite links tend to impose longer RTTs, and enclosed LANs tend to have
> much shorter RTTs." Does this imply cake is not yet ready for use on
> satellite links? Or merely that I'll get sub-optimal results but it's still
> worth testing?
> I see I could set the interval in sch_cake.c and recompile - is there any
> reason why this would be a bad idea? Am I right in thinking with such
> observed variation I'll get better results setting for the lower limit
> (700) rather than the upper (1200)?
> Any suggestions for a more sane target to set while I'm doing this?
> Has anyone here already done testing on satellite links?
>
> - Noven
>
> --
> - Noven Purnell-Webb
> Creative Technology Consultant
> +61 448 841 091
> http://onecardme.com/NovenPWebb
>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
>

[-- Attachment #2: Type: text/html, Size: 2768 bytes --]

Re: [Cake] Cake over satellite

[Sebastian Moeller]

Hi Noven,


On Oct 19, 2015, at 09:55 , Noven Purnell-Webb <noven@liberant.com.au> wrote:

> I'm about to go on a mission to the outback, with one objective being to tune a disappointing satellite link. Theoretically 6/1mbps, with RTTs ranging from 700 - 1200ms. From the cake technical page 
> "The AQM layer has no configuration options. However, it is planned to add simple tuning options for different prevailing RTTs that may be significantly different from the Internet-scale 100ms currently assumed. Satellite links tend to impose longer RTTs, and enclosed LANs tend to have much shorter RTTs." Does this imply cake is not yet ready for use on satellite links? Or merely that I'll get sub-optimal results but it's still worth testing? 
> I see I could set the interval in sch_cake.c and recompile - is there any reason why this would be a bad idea? Am I right in thinking with such observed variation I'll get better results setting for the lower limit (700) rather than the upper (1200)?
> Any suggestions for a more sane target to set while I'm doing this?
> Has anyone here already done testing on satellite links?

	I believe that interval/rtt is now settable via tc, BUT target is clamped to a max of 5ms, while in theory it should be 5-10% of rtt, so current cake might work well out of the box, or might require fiddling with target. It would be most excellent if you could actually test that aspect of cake for us ;)

Best Regards
	Sebastian

> 
> - Noven
> 
> -- 
> - Noven Purnell-Webb
> Creative Technology Consultant
> +61 448 841 091
> http://onecardme.com/NovenPWebb
> 
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Cake over satellite

[Dave Taht]

well, yes, but we can do it in the lab *this week*, before he takes
the dingos on....

Re: [Cake] Cake over satellite

[Sebastian Moeller]

Hi,

On October 19, 2015 10:24:01 AM CDT, Dave Taht <dave.taht@gmail.com> wrote:
>well, yes, but we can do it in the lab *this week*, before he takes
>the dingos on....

Good idea, als I am at A conference right now and will not find the time to make the changes to TC in time. I believe that cake should certainly A) set A reasonable target by default and B) still allow the user to explicitly request something else. Currently, I believe cake does only A)...

Besteht Regards
        Sebadtian


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Cake] Cake over satellite

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

On 19/10/15 20:05, Sebastian Moeller wrote:
> Hi,
>
> On October 19, 2015 10:24:01 AM CDT, Dave Taht <dave.taht@gmail.com> wrote:
>> well, yes, but we can do it in the lab *this week*, before he takes
>> the dingos on....
> Good idea, als I am at A conference right now and will not find the time to make the changes to TC in time. I believe that cake should certainly A) set A reasonable target by default and B) still allow the user to explicitly request something else. Currently, I believe cake does only A)...
>
> Besteht Regards
>         Sebadtian
>
>

As an FYI:


tc has a number of calculations for interval & target

If an rtt is specified then target is 5% of interval with 1uS
(microsecond!) and 5mS (millisecond) lower & upper bounds.

The keyword predefined rtt values are:

datacentre (100uS), lan (1mS), metro(10mS), regional(30mS),
internet(100mS), oceanic(300mS), satellite(1000mS), interplanetary(1hour!)
Corresponding targets are 5uS, 50uS, 500uS, 1.5mS and everything from
internet onwards as a 5mS target.

Although these are the values passed into cake from tc, that isn't the
final story with regard to calculations as cake qdisc has some further
sanity checks.

If a link bandwidth is specified then the target is set to the max of
'1.5 MTU's worth of link time' and the target value passed by tc.  The
interval is set to max of '8 times the calculated target' and interval
value passed by tc.

So whilst tc supplies an rtt/interval and a 5% calculated target, cake
itself will override this with sensible values if that makes sense for a
'slow' link.

Kevin


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Cake over satellite

[Benjamin Cronce]

[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]

Because planet very way too much and even a given planet will have a wide
range of much greater than one our RTTs. TCP probably won't even work for
those kids of RTTs. What about a Lunar RTT instead of Interplanetary? The
moon is about 1.3 light seconds away, one way. That's a minimum of 2.6sec
RTT.

On Tue, Oct 20, 2015 at 12:32 PM, Kevin Darbyshire-Bryant <
kevin@darbyshire-bryant.me.uk> wrote:

> On 19/10/15 20:05, Sebastian Moeller wrote:
> > Hi,
> >
> > On October 19, 2015 10:24:01 AM CDT, Dave Taht <dave.taht@gmail.com>
> wrote:
> >> well, yes, but we can do it in the lab *this week*, before he takes
> >> the dingos on....
> > Good idea, als I am at A conference right now and will not find the time
> to make the changes to TC in time. I believe that cake should certainly A)
> set A reasonable target by default and B) still allow the user to
> explicitly request something else. Currently, I believe cake does only A)...
> >
> > Besteht Regards
> >         Sebadtian
> >
> >
>
> As an FYI:
>
>
> tc has a number of calculations for interval & target
>
> If an rtt is specified then target is 5% of interval with 1uS
> (microsecond!) and 5mS (millisecond) lower & upper bounds.
>
> The keyword predefined rtt values are:
>
> datacentre (100uS), lan (1mS), metro(10mS), regional(30mS),
> internet(100mS), oceanic(300mS), satellite(1000mS), interplanetary(1hour!)
> Corresponding targets are 5uS, 50uS, 500uS, 1.5mS and everything from
> internet onwards as a 5mS target.
>
> Although these are the values passed into cake from tc, that isn't the
> final story with regard to calculations as cake qdisc has some further
> sanity checks.
>
> If a link bandwidth is specified then the target is set to the max of
> '1.5 MTU's worth of link time' and the target value passed by tc.  The
> interval is set to max of '8 times the calculated target' and interval
> value passed by tc.
>
> So whilst tc supplies an rtt/interval and a 5% calculated target, cake
> itself will override this with sensible values if that makes sense for a
> 'slow' link.
>
> Kevin
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
>

[-- Attachment #2: Type: text/html, Size: 3087 bytes --]

Re: [Cake] Cake over satellite

[Jonathan Morton]

> On 21 Oct, 2015, at 04:26, Benjamin Cronce <bcronce@gmail.com> wrote:
> 
> Because planet very way too much and even a given planet will have a wide range of much greater than one our RTTs. TCP probably won't even work for those kids of RTTs. What about a Lunar RTT instead of Interplanetary? The moon is about 1.3 light seconds away, one way. That's a minimum of 2.6sec RTT.

Nobody’s actually using TCP/IP on translunar distances either.  I put in “interplanetary” as a way to effectively disable the AQM layer, leaving everything else intact.

 - Jonathan Morton

Re: [Cake] Cake over satellite

[Sebastian Moeller]

Hi Kevin,



On Oct 20, 2015, at 19:32 , Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:

> On 19/10/15 20:05, Sebastian Moeller wrote:
>> Hi,
>> 
>> On October 19, 2015 10:24:01 AM CDT, Dave Taht <dave.taht@gmail.com> wrote:
>>> well, yes, but we can do it in the lab *this week*, before he takes
>>> the dingos on....
>> Good idea, als I am at A conference right now and will not find the time to make the changes to TC in time. I believe that cake should certainly A) set A reasonable target by default and B) still allow the user to explicitly request something else. Currently, I believe cake does only A)...
>> 
>> Besteht Regards
>>        Sebadtian
>> 
>> 
> 
> As an FYI:
> 
> 
> tc has a number of calculations for interval & target
> 
> If an rtt is specified then target is 5% of interval with 1uS
> (microsecond!) and 5mS (millisecond) lower & upper bounds.
> 
> The keyword predefined rtt values are:
> 
> datacentre (100uS), lan (1mS), metro(10mS), regional(30mS),
> internet(100mS), oceanic(300mS), satellite(1000mS), interplanetary(1hour!)
> Corresponding targets are 5uS, 50uS, 500uS, 1.5mS and everything from
> internet onwards as a 5mS target.
> 
> Although these are the values passed into cake from tc, that isn't the
> final story with regard to calculations as cake qdisc has some further
> sanity checks.
> 
> If a link bandwidth is specified then the target is set to the max of
> '1.5 MTU's worth of link time' and the target value passed by tc.  The
> interval is set to max of '8 times the calculated target' and interval
> value passed by tc.
> 
> So whilst tc supplies an rtt/interval and a 5% calculated target, cake
> itself will override this with sensible values if that makes sense for a
> 'slow' link.

	Thanks for elucidating this. I believe that cake should honor silly requests by the user as long as those were stated explicitly by the users and are possible (so target <= interval). It is great that cake has sane defaults and I also believe it would be helpful if cake noticed the user of unusual parameter configuration, but in the end the user should be able to control the parameters. (I am fine with having a —override_sane_cake_defaults command line switch to make it hard to do silly things accidentally). “Do the right thing by default, but allow unreasonable configurations if asked nicely” should be the goal here, I believe (but I admit Jonathan’s project, and hence his call)

Best Regards
	Sebastian


> 
> Kevin
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Cake over satellite

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]



On 19/10/15 16:15, Sebastian Moeller wrote:
> Hi Noven,
>
>
> On Oct 19, 2015, at 09:55 , Noven Purnell-Webb <noven@liberant.com.au> wrote:
>
>> I'm about to go on a mission to the outback, with one objective being to tune a disappointing satellite link. Theoretically 6/1mbps, with RTTs ranging from 700 - 1200ms. From the cake technical page 
>> "The AQM layer has no configuration options. However, it is planned to add simple tuning options for different prevailing RTTs that may be significantly different from the Internet-scale 100ms currently assumed. Satellite links tend to impose longer RTTs, and enclosed LANs tend to have much shorter RTTs." Does this imply cake is not yet ready for use on satellite links? Or merely that I'll get sub-optimal results but it's still worth testing? 
>> I see I could set the interval in sch_cake.c and recompile - is there any reason why this would be a bad idea? Am I right in thinking with such observed variation I'll get better results setting for the lower limit (700) rather than the upper (1200)?
>> Any suggestions for a more sane target to set while I'm doing this?
>> Has anyone here already done testing on satellite links?
> 	I believe that interval/rtt is now settable via tc, BUT target is clamped to a max of 5ms, while in theory it should be 5-10% of rtt, so current cake might work well out of the box, or might require fiddling with target. It would be most excellent if you could actually test that aspect of cake for us ;)
hi Noven,


The interval value is exposed as an rtt parameter, either as a time (say
700ms) or as some hopefully relevant pre-set keywords, may I suggest
'satellite' is suitable in your case (1000ms)   The target value is not
directly available from tc, however an API interface for it does exist
(like interval alias rtt and other parameters)   Target max is 5ms,
except for 'slow' links where a calculation using the time for an MTU
sized packet + overhead is used (there's little point in trying to
control latency to 5ms when it takes longer than that to actually send
the bytes out), other than that target is set to 5% of rtt.

Tell it the link bandwidth, any overhead bytes (PPP, ether-FCS, VLan and
the like) and the rtt 1000ms and she'll be right mate ;-)

Kevin

>
> Best Regards
> 	Sebastian
>
>> - Noven
>>
>> -- 
>> - Noven Purnell-Webb
>> Creative Technology Consultant
>> +61 448 841 091
>> http://onecardme.com/NovenPWebb
>>
>>
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Cake over satellite

[Sebastian Moeller]

Hi Kevin,

On October 19, 2015 10:48:26 AM CDT, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>
>
>On 19/10/15 16:15, Sebastian Moeller wrote:
>> Hi Noven,
>>
>>
>> On Oct 19, 2015, at 09:55 , Noven Purnell-Webb
><noven@liberant.com.au> wrote:
>>
>>> I'm about to go on a mission to the outback, with one objective
>being to tune a disappointing satellite link. Theoretically 6/1mbps,
>with RTTs ranging from 700 - 1200ms. From the cake technical page 
>>> "The AQM layer has no configuration options. However, it is planned
>to add simple tuning options for different prevailing RTTs that may be
>significantly different from the Internet-scale 100ms currently
>assumed. Satellite links tend to impose longer RTTs, and enclosed LANs
>tend to have much shorter RTTs." Does this imply cake is not yet ready
>for use on satellite links? Or merely that I'll get sub-optimal results
>but it's still worth testing? 
>>> I see I could set the interval in sch_cake.c and recompile - is
>there any reason why this would be a bad idea? Am I right in thinking
>with such observed variation I'll get better results setting for the
>lower limit (700) rather than the upper (1200)?
>>> Any suggestions for a more sane target to set while I'm doing this?
>>> Has anyone here already done testing on satellite links?
>> 	I believe that interval/rtt is now settable via tc, BUT target is
>clamped to a max of 5ms, while in theory it should be 5-10% of rtt, so
>current cake might work well out of the box, or might require fiddling
>with target. It would be most excellent if you could actually test that
>aspect of cake for us ;)
>hi Noven,
>
>
>The interval value is exposed as an rtt parameter, either as a time
>(say
>700ms) or as some hopefully relevant pre-set keywords, may I suggest
>'satellite' is suitable in your case (1000ms)   The target value is not
>directly available from tc, however an API interface for it does exist
>(like interval alias rtt and other parameters)   Target max is 5ms,
>except for 'slow' links where a calculation using the time for an MTU
>sized packet + overhead is used (there's little point in trying to
>control latency to 5ms when it takes longer than that to actually send
>the bytes out), other than that target is set to 5% of rtt.

       Since target max is clamped to 5ms, you effectively only get the 5% setting for rtt./interval below 100 ms. Which might or might not be correct for a long latency satellite link. All I want to emphasize is that somebody should test this ;)...

Best Regards
       Sebastian


>
>Tell it the link bandwidth, any overhead bytes (PPP, ether-FCS, VLan
>and
>the like) and the rtt 1000ms and she'll be right mate ;-)
>
>Kevin
>
>>
>> Best Regards
>> 	Sebastian
>>
>>> - Noven
>>>
>>> -- 
>>> - Noven Purnell-Webb
>>> Creative Technology Consultant
>>> +61 448 841 091
>>> http://onecardme.com/NovenPWebb
>>>
>>>
>>> _______________________________________________
>>> Cake mailing list
>>> Cake@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cake
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Cake mailing list
>Cake@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/cake

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.