Hi Ching,

> On Oct 12, 2016, at 14:40 , ching lu <lschin...@gmail.com> wrote:
> 
> There is no need for cleansing dscp for wan ingress, I think it is 
> unnecessary, too
> 
> In https://www.bufferbloat.net/projects/codel/wiki/Cake/
> 
> There is a statement:
> 
> “The only way we know how to “fix” bittorrent is to classify it somewhat, 
> somehow, as “background”."

        Which was true at the time. In the mean time cake grew new “isolation” 
modes that will attempt to provide on a first level per-(internal)-IP-address 
fairness and iside each internal IP-address “band” also per-flow fairness. This 
should allow to restrict the bad effect of bit-torrent traffic on the machine 
actually running the torrent client. Which seems like a goos compromise since 
most torrent clients allow configurations to alleviate the issue somewhat for 
that specific machine (like bandwidth limits). These additional modes do 
require a bit of testing and especially on ingress they will not be 100% robust 
(too many in-rushing bit-torrent connections might cause buffers upstream of 
the cake-managed link to fill and cause increased latency), but that just comes 
with instantiating a shaper on the wrong end of the real bottleneck. As a 
sidenote the more bandwidth difference exist between real bottleneck and the 
artifical cake-managed bottleneck the better ingress shaping will work…


> 
> But in fact, there is no simply way to classify bittorrent INGRESS traffic

        Yes, and no…

> 
> DSCP -> unreliable, easily spoofed by attacker, and the value is most likely 
> 0x0\

        Well, if BT clients would mark CS1/BK that would be a decent 1st step, 
except that will also tell ISPs which packets to drop first… (which might be 
actually in the users interest)

> firewall mark -> cake do not use firewall mark/connmark

        If you can firewall mark you can also re-map dscp… But I believe the 
real issue is that bit-torrent was designed to have no clear unambiguous 
signature so figuring out which packets belong to bit-torrent flows is the 
tricky bit…

> 
> Finally, I guess most likely home users will use bit torrent.

        But that is a guess? Numbers/real data would be better; that said with 
even windows update allowing peer-to-peer distribution of updates 
bit-torrent-like traffic probably is something most home-users will see 
occasionally.

Best Regards
        Sebastian


> 
> 2016年10月12日 下午8:04,"moeller0" <moell...@gmx.de>寫道:
> Hi Ching?
> 
> > On Oct 12, 2016, at 12:17 , ching lu <lschin...@gmail.com> wrote:
> >
> >
> > 2016年10月12日 下午6:05,"moeller0" <moell...@gmx.de>寫道:
> > >
> > > Hi Ching,
> > >
> > > > On Oct 12, 2016, at 11:35 , ching lu <lschin...@gmail.com> wrote:
> > > >
> > > > How to archive "cake follows iptables"? is it “wan ingress -> iptables
> > >
> > > Yes.
> > >
> > > > -> wifi egress/LAN egress -> ifb egress -> cake”?
> > >
> > >         Except that if you instantiate cake on the interface connecting 
> > > to the outers LAN/WLAN side (lets call this LAN for short), cake will 
> > > reside on that interfaces egress and hence you require no ifb for traffic 
> > > coming in from the internet (as a plus cake will even without the fancy 
> > > new deNAT options see the full intrnal IP addresses, useful for dual and 
> > > triple isolation options). In the direction facing the internet you can 
> > > instantiate cake on an ifb interface for LAN and then put the iptables 
> > > DSCP cleaner on the WAN egress side (and the WAN ingress side, unless you 
> > > trust your ISP to deliver reasonable DSCP values, which should be like 
> > > never*)
> >
> > The bandwidth shaper won’t work correctly if cake(s) are registered on 
> > multiple LAN interface, ifb is necessary
> >
> > e.g. if ingress bandwidth limit is 100M, then setting 50M on wifi, and 50M 
> > on LAN ?
> 
>         Yes that seems true, if you instantiate cake on br-lan (which I 
> believe would be the relevant interface) you will shape both wireless and 
> wired traffic, but most likely also internal traffic… But that can be solved 
> by one more router/AP ;)
> 
> >
> > I think the diffserv support of cake model is not suitable for home network 
> > currently.
> 
>         I have no real opinion on that, but could you explicitly state what 
> short coming you see that is a showstopper? DSCP cleaning on ingress is BTW 
> not really required to happen before cake, as long as cake is set to 
> besteffort it will ignore DSCP markings anyway, and if you want to 
> re-map/re-classify packets vie DSCP on ingress you are pretty much out of 
> scope for a typical home network. Cleaning up on egress, as to not leak 
> internal configuration to the upstream seems indeed sub-optimal, but cake is 
> not alone in that regard…
> 
> > The setup is much more complex
> 
>         Well, DSCP setup is complex no matter how you slice and dice it… but 
> maybe you have an idea what a shaper (like cake) could/should do to make this 
> simpler?
> 
> Best Regards
>         Sebastian
> 
> >
> >
> >
> > >
> > > Best Regards
> > >         Sebastian
> > >
> > > 8) DSCP are only ever guranteed to be meaninful inside a dscp domain, and 
> > > in reality your home net is a different domain from the ISP’s. It would 
> > > have been nice if the DSCP field would have been separeted into 2 3bit 
> > > fields, the first for the actual sender to request one of 8 differential 
> > > classes and the other 3bits for the current domain to store its actually 
> > > used DSCP bits. I claim the 3 bits should be enough for anybody  ;)
> > >
> > >
> > > >
> > > >
> > > > On Wed, Oct 12, 2016 at 5:10 PM, moeller0 <moell...@gmx.de> wrote:
> > > >> Hi,
> > > >>
> > > >>
> > > >>> On Oct 12, 2016, at 10:11 , ching lu <lschin...@gmail.com> wrote:
> > > >>>
> > > >>> For egress, setting DSCP field should work.
> > > >>>
> > > >>> iptables -> wan egress -> cake
> > > >>>
> > > >>> But is it possible to set DSCP to 0x0 after cake's classification? i
> > > >>> do not know how ISP handle non-zero DSCP, there seems to be no
> > > >>> standard for this.
> > > >>
> > > >>        Interestingly cake, at some point in the past offered exactly 
> > > >> that functionality, but it got removed due to added complexity with 
> > > >> very little practical applicability (and a potential layering 
> > > >> violation, but one could equally argue that the current layering is 
> > > >> partly sub-optimal/wrong and hence violating it to better reflect 
> > > >> reality might be acceptable). But current cake does not offer this. If 
> > > >> you are willing to daisy-chain two routers, you could run cake on the 
> > > >> respective egress interfaces connecting both routers, and do the DSCP 
> > > >> cleaning on the outer router’s egress interface toward the internet…
> > > >>
> > > >>>
> > > >>>
> > > >>> For ingress, DSCP field may not be set by network peer at all, and i
> > > >>> have multiple LAN interfaces
> > > >>>
> > > >>> AFAIK, the order is "wan ingress -> ifb egress -> cake -> iptables"
> > > >>>
> > > >>> The trick of setting DSCP by iptables do not work because cake comes 
> > > >>> first
> > > >>
> > > >>        Hence Jonathan’s recommendation to make sure that cake follows 
> > > >> iptables, by setting it up on egress interfaces only…
> > > >>
> > > >> Best Regards
> > > >>        Sebastian
> > > >>
> > > >>>
> > > >>> On Wed, Oct 12, 2016 at 3:26 PM, Jonathan Morton 
> > > >>> <chromati...@gmail.com> wrote:
> > > >>>>
> > > >>>>> On 12 Oct, 2016, at 08:52, ching lu <lschin...@gmail.com> wrote:
> > > >>>>>
> > > >>>>> I deprioritize bittorrent traffic by marking related connections in
> > > >>>>> iptables (e.g. detect by port number) and route them to 
> > > >>>>> corresponding
> > > >>>>> HTB class and qdisc.
> > > >>>>>
> > > >>>>> How can i archive the same goal using the cake qdisc?
> > > >>>>
> > > >>>> Modify your iptables rules to set the DSCP rather than a 
> > > >>>> kernel-internal mark.  You probably want "-j DSCP —set-dscp-class 
> > > >>>> CS1”, as CS1 is the “bulk low priority” code.  Cake’s default 
> > > >>>> Diffserv mode will pick that up appropriately.
> > > >>>>
> > > >>>> You also need to make sure Cake sees your packets *after* they’ve 
> > > >>>> been through the firewall, which generally means attaching it to the 
> > > >>>> egress port in each direction, not the ingress port.  You’ve 
> > > >>>> probably already done this, if you’re happy with your HTB setup.
> > > >>>>
> > > >>>> If you have multiple LAN interfaces (eg, both Ethernet and wifi), 
> > > >>>> you should loop the inbound traffic through a common IFB device (and 
> > > >>>> attach Cake to that instead of the physical interfaces) to simplify 
> > > >>>> configuration.
> > > >>>>
> > > >>>> - Jonathan Morton
> > > >>>>
> > > >>> _______________________________________________
> > > >>> 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

Reply via email to