Hi Rich,

first attempt to send this was lost somehow…, so a re-send

On Jan 4, 2014, at 19:16 , Rich Brown <[email protected]> wrote:

> QUESTION #5: I still don’t have any great answers for the Link Layer 
> Adaptation overhead descriptions and recommendations. In an earlier message, 
> (see 
> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
>  and following messages), Fred Stratton described the overheads carried by 
> various options, and Sebastian Moeller also gave some useful advice.
> 
> After looking at the options, I despair of giving people a clear 
> recommendation that would be optimal for their equipment. Consequently, I 
> believe the best we can do is come up with “good enough” recommendations that 
> are not wrong, and still give decent performance.  

        Not wanting to be a spoilsport, but IMHO the issue is complicated hence 
no simple recommendations. I know that my last word was that 40bytes would be a 
good default overhead, but today I had the opportunity to measure the overhead 
on fast ADSL connection in Luxembourg and found that in this double-play 
situation (television and internet via DSL) that an other wise invisible VLAN 
was further increasing the overhead (from the 40 expected to 44 bytes). At 
least on faster links these combo packets (internet, phone and potentially 
telephone) are becoming more and more common, so maybe the recommendation 
should be 44 (hopping that FCS are truly rare).

> 
> In this spirit, I have changed Draft #3 of the “Setting up SQM” page to 
> reflect this understanding. See 
> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
> 
>       ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40

        While I prefer ATM, I think all deployed ADSL is on ATM so these are 
synonyms for our purpose. I prefer ATM since the most critical part of the link 
layer adjustments is caused by the impedance mismatch between what ATM offers 
and what the data transport layer requires. I have the impression that ADSL 
might still evolve to a different carrier, while ATM is basically in 
maintenance mode (not much new deployment if any).

>       VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8

        There are several issues with this; VDSL is not the direct predecessor 
of VDSL2 (rather VDSL2 is the successor of ADSL2+ with some similarities to 
VDSL). Lumping VDSL with VDSL2 will require us figuring out whether both behave 
the same. From my cursory reading of the standards of both I think VDSL is not 
unlikely to be using an ATM link layer, VDSL2 is unlikely to do the same, both 
seem technically able to use ATM. 


>       Other kind of link (e.g., Cable, Fiber, Ethernet, other not listed): 
> Choose “None (default)”, and set Per Packet Overhead to 0

        This is not going to be worse than today, so sounds fine (it would be 
good to know whether there is truly no overhead on these links in practical 
useage). 
        Quick vote: anyone on this list using ceroWRT on an VDSL/VDSL2 link or 
cable fiber whatnot that could do some quick testing for us? 
> 
> NB: I have changed the first menu choice to “ADSL/ATM” and the second to 
> “VDSL” in the description.

        I am fine with changing names, just see what the consensus is for the 
names.

> I would ask that we change to GUI to reflect those names as well. This makes 
> it far easier/less confusing to talk about the options. 

        Agreed.

> 
> As always, I welcome help in setting out clear recommendations that work well 
> for the vast majority of people who try CeroWrt. Thanks.

        I guess, we need a new wiki page detailing the procedure to figure out 
the link layer (and overhead if on ATM).

Best
        Sebastian

> 
> Rich
> _______________________________________________
> Cerowrt-devel mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Reply via email to