<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Sebastian, List,<div><br><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span>That sounds quite promising. I would be delighted, if stability permits, if you could test the current AQM implementation and send me your feedback and or open questions. It seems I have been looking at the link layer issue for so long that I do not realize which information is required so please let me know if parts are to terse or too verbose.<br></blockquote><div><br></div>Thanks for making these changes. I was able to check the appearance (but not the performance) of the new GUI. My thoughts/comments/questions inserted between the screen shots:</div><div><div><br></div><div><img apple-inline="yes" id="B120D383-3048-4285-BDFB-D44FED7993D4" height="421" width="663" apple-width="yes" apple-height="yes" src="cid:163C908C-165F-47E5-AC49-4CAE93CC2DBE@home.lan"></div><div><br></div><div>The Basic Settings tab looks good. It’s all stuff I understand. I might like a More Info: link that tells me what the parameters are, and how I should set them. This is especially important because there’s a trick you need to know - set them to 85-90% of the link’s actual bandwidth. </div><div><br></div><div>The introductory text could also read, “With AQM you can enable traffic shaping and prioritisation on a *single* network interface, your uplink to the Internet. Once you set the download and upload speeds (below), most people can leave the other options set to their defaults.” (at least, if that’s true…)</div><div><br></div><div><img apple-inline="yes" id="B4FCAF6D-2590-4A2C-A632-AD726F4A18DA" height="327" width="637" apple-width="yes" apple-height="yes" src="cid:1A696ADC-0923-4016-8F04-427F07EBC463@home.lan"></div><div><br></div><div>It looks a little funny with just the bare un-checked box. But I’m not horrified: checking the box shows the screen below, which is certainly clear enough.</div><div><br></div><div><img apple-inline="yes" id="211C579B-13E2-4EBC-9028-7CFB87B7DA96" height="609" width="658" apple-width="yes" apple-height="yes" src="cid:53720EB2-4DC2-4043-919C-A64198A77EA6@home.lan"></div><div><br></div><div>- I like how fq_codel is labeled “default”. Since the other two controls are labeled with “default, should we do the same with the queue setup script (“simples.qos (default)”)?</div><div><br></div><div>- Do we include pfifo anymore? (just to see how bad things could be?)</div><div><br></div><div>- Should we tell which version of pie has been included? (I’ve heard the names piev3 and piev4)</div><div><br></div><div>- In the Basic tab, we talk about download/upload. In the ECN settings, we talk about inbound/outbound. Should we choose one pair of terms for consistency (perhaps, “ECN on downloaded/uploaded packets”?)</div><div><br></div><div><img apple-inline="yes" id="F041B270-D146-4004-82DC-93A71899FDF0" height="609" width="637" apple-width="yes" apple-height="yes" src="cid:AFD63BAD-1F2F-46BB-9BEC-CF52B4E99431@home.lan"></div><div><br></div><div>This tab forces us to confront all the sticky questions. The first question immediately makes me wonder, “Do I have DSL or ATM? Or both? What’s a ‘tc_stab'? How do I know?” And while trying to make an intelligent guess, I wonder how to map none/tc_stab into DSL and/or ATM; if adsl is the same as DSL; and where ethernet fits into the scheme of things. </div><div><br></div><div>It would be cool to set everything here automagically. Nonetheless, this is still a research project, and we probably don’t know enough to do that. Consequently, we should strive for good defaults that people can override while making experiments or if the defaults are wrong. I don’t know any answers here, or even where I’m going with this, but I’ll observe the following:</div><div><br></div><div>- (I believe) The Link Layer Adaptations help the router squeeze out the maximum performance accounting for peculiar link's transmission/framing method. If this stuff isn't set optimally, things will still work, at a (small?) loss of performance.</div><div><br></div><div>- The choices in the Protocol dropdown for the GE00 interface are:</div><div><br></div>Static address<br>DHCP client<br>Unmanaged<br>Dual-Stack Lite (RFC6333)<br>IPv6-in-IPv4 (RFC4213)<br>IPv6-over-IPv4 (6to4)<br>IPv6-over-IPv4 (6rd)<br>DHCPv6 client<br>PPP<br>PPtP<br>PPPoE<br>PPPoATM<br>UMTS/GPRS/EV-DO<br>L2TP<br><br>- (I believe) Only two “protocols” (above) require “link layer adaptation": PPPoE (DSL/ADSL) and PPPoATM (PPP over ATM). All the others seem to be some variation on Ethernet. (Please correct me if I’m wrong.) <br><br>- For each of those link layers, what customizations are required? Can we give guidance (on the wiki) for people who want to set them? (Although it would be slick if someone chose the PPPoE protocol, and this tab got set up properly, we may not know enough today to do this properly.) </div><div><br></div><div>Fussy GUI comments:</div><div><br></div><div>- Would it be correct to change the label to say, “Show Advanced Link Layer Options, (only needed if using large packets, MTU > 1500 bytes)”</div><div><br></div><div>- The “Which linklayer adaptation …” question runs outside its bounding box in the GUI. This only happens when I make the window narrow for the screen shot, so it probably isn’t worth perseverating about.<br><br></div><div>- I would be tempted make “Link Layer” two words in the GUI, unless it’s a term of art.</div><div><br></div><div>Thanks, all, for this good work!</div><div><br></div><div>Rich</div></body></html>