* Re: [Cerowrt-devel] SQM Question #2: How does CeroWrt use info gleaned from the link layer adaptation?
2013-12-29 8:54 ` Dave Taht
@ 2013-12-29 10:52 ` Fred Stratton
2013-12-29 13:51 ` Sebastian Moeller
1 sibling, 0 replies; 5+ messages in thread
From: Fred Stratton @ 2013-12-29 10:52 UTC (permalink / raw)
To: Dave Taht, cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 3726 bytes --]
Providers differ across countries.
European competition laws are interpreted quite differently in different
countries. AFAIK, Deutsche Telekom and France Telecom are monopolies.
ISPs there therefore use the same infrastructure. BT is not. Here there
are differences between ISPs.
http://www.samknows.com/broadband/exchange/MRPOY
Shows service availability in the area where I am, immediately to the
south of the Manchester conurbation.
Recommendations are also affected by service cost. In this country, BT
increases its prices once or even twice a year by just below the ten per
cent threshold where the regulator takes an interest. Sky and TalkTalk
then follow. Individuals then have to make decisions based not just on
shaping policy, the type of CPE supplied, and TV channels specific to
the provider, but on cost.
Negotiation on cost involves a yearly conversation with the provider,
and cashback offers available elsewhere. Recommendations are therefore
problematic.
On 29/12/13 08:54, Dave Taht wrote:
> I would like it if we had a couple per-provider recomendations and
> relevant discussion.
>
> On Sat, Dec 28, 2013 at 11:36 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
>> Rich Brown <richb.hanover@gmail.com> wrote:
>>> QUESTION #2: How does CeroWrt use info gleaned from the link layer
>>> adaptation?
>> The link layer adaptations work in correcting the kernels estimate of a packets behavior on the wire. In the tc_stab case the kernel calculates the effective size of the packet on the wire, that is it pretends the packet is larger than it really is, so for a given bandwidth it estimates the correct time it takes for that packet to be actually transmitted. In the htb_private case the kernel keeps the packet's size (more or less) intact but adjusts its estimate of the packets transmit rate. Both methods boil down to the same idea, make sure the packet scheduler will only send packet N+1 after packet N has just cleared the wire.
>>
>>> Specifically, the link layer adaptation all seem to be designed to
>>> compute the actual time it takes to transmit a packet, accounting for
>>> Ethernet & PPPoE header bytes, other overhead, and ATM 48-in-53
>>> framing.
>> And the annoying size dependent padding of the last ATM cell.
>>
>>> How does CeroWrt use this time calculation? Does it simply make sure
>>> that the target time doesn’t get too low for a particular flow’s queue?
>> Thanks to the link layer adjustments (lla) cero now estimates the correct time each packet takes and will not send any faster than the shaped rate allows. If no lla is performed cero would overestimate the link capacity, send more than expected and potentially fill the modems bloated buffers. Traditionally people tried to reduce their shaped rate by >10% to at least account for the 48 in 53 framing, but failed miserably for small packets since overhead and padding can more than double the wire size of a packet. Note that ACQ packets typically are small as are voice over IP packets.
>>
>> I hope this helps
>> Sebastian
>>
>>> (I could imagine that a short packet over ATM would take 2x the (naive)
>>> expected/calculated time for a packet of that length, and that flow
>>> would be penalized. Is there more to it?)
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> Hi Rich
>> --
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
[-- Attachment #2: Type: text/html, Size: 5383 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cerowrt-devel] SQM Question #2: How does CeroWrt use info gleaned from the link layer adaptation?
2013-12-29 8:54 ` Dave Taht
2013-12-29 10:52 ` Fred Stratton
@ 2013-12-29 13:51 ` Sebastian Moeller
1 sibling, 0 replies; 5+ messages in thread
From: Sebastian Moeller @ 2013-12-29 13:51 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
Hi Dave,
On Dec 29, 2013, at 09:54 , Dave Taht <dave.taht@gmail.com> wrote:
> I would like it if we had a couple per-provider recomendations and
> relevant discussion.
I think this is a can of worms we should open carefully ;). In Germany several providers serve part of their area with their own infrastructure while reselling bitstream access provided by other carriers in other parts of their area, with potential differences in encapsulation. Also in the US at&t is in the process of relabeling their ADSL2 access as U-Verse High Speed Internet (the same label they use for VDSL as well) making it quite complicated to give proper recommendations… But to make a start here are only connections I actually measured (there is no guarantee that all connections of the same ISP use the same technology):
Date Country ISP nominal Speed D/U line type link layer access type overhead comment
2013-12-29 Germany Deutsche Telekom 16Mbit/s 2.8Mbit/s ADSL2+ ATM PPPoE, LLC/SNAP RFC-2684 40bytes 16M down also offered as VDSL version without ATM
2013-12-29 Germany Deutsche Telekom 2Mbit/s 0.2Mbit/s ADSL1 ATM PPPoE, LLC/SNAP RFC-2684 40bytes connections below 16M down are always ADSL, either v1 or v2+
2013-12-29 Germany Netaachen 18Mbit/s 1.0Mbit/s ADSL2+ ATM PPPoE, LLC/SNAP RFC-2684 40bytes
General Notes:
Deutsche Telekom; the network is slowly moved to fiber to the node/curb using VDSL2 (PTM) for speeds >= 16M down and ADSL2+ (ATM) for slower speeds . These new DSLAMs replacements are called MSANs, customers on
ADSL ports are still using ATM on the last mile and need the link layer adjustments.
Best Regards
Sebastian
>
> On Sat, Dec 28, 2013 at 11:36 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
>> Rich Brown <richb.hanover@gmail.com> wrote:
>>> QUESTION #2: How does CeroWrt use info gleaned from the link layer
>>> adaptation?
>>
>> The link layer adaptations work in correcting the kernels estimate of a packets behavior on the wire. In the tc_stab case the kernel calculates the effective size of the packet on the wire, that is it pretends the packet is larger than it really is, so for a given bandwidth it estimates the correct time it takes for that packet to be actually transmitted. In the htb_private case the kernel keeps the packet's size (more or less) intact but adjusts its estimate of the packets transmit rate. Both methods boil down to the same idea, make sure the packet scheduler will only send packet N+1 after packet N has just cleared the wire.
>>
>>>
>>> Specifically, the link layer adaptation all seem to be designed to
>>> compute the actual time it takes to transmit a packet, accounting for
>>> Ethernet & PPPoE header bytes, other overhead, and ATM 48-in-53
>>> framing.
>>
>> And the annoying size dependent padding of the last ATM cell.
>>
>>>
>>> How does CeroWrt use this time calculation? Does it simply make sure
>>> that the target time doesn’t get too low for a particular flow’s queue?
>>
>> Thanks to the link layer adjustments (lla) cero now estimates the correct time each packet takes and will not send any faster than the shaped rate allows. If no lla is performed cero would overestimate the link capacity, send more than expected and potentially fill the modems bloated buffers. Traditionally people tried to reduce their shaped rate by >10% to at least account for the 48 in 53 framing, but failed miserably for small packets since overhead and padding can more than double the wire size of a packet. Note that ACQ packets typically are small as are voice over IP packets.
>>
>> I hope this helps
>> Sebastian
>>
>>> (I could imagine that a short packet over ATM would take 2x the (naive)
>>> expected/calculated time for a packet of that length, and that flow
>>> would be penalized. Is there more to it?)
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>> Hi Rich
>> --
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 5+ messages in thread