Hi Ching,
> On Oct 12, 2016, at 14:40 , ching lu <[email protected]> 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" <[email protected]>寫道：
> Hi Ching?
>
> > On Oct 12, 2016, at 12:17 , ching lu <[email protected]> wrote:
> >
> >
> > 2016年10月12日 下午6:05，"moeller0" <[email protected]>寫道：
> > >
> > > Hi Ching,
> > >
> > > > On Oct 12, 2016, at 11:35 , ching lu <[email protected]> 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 <[email protected]> wrote:
> > > >> Hi,
> > > >>
> > > >>
> > > >>> On Oct 12, 2016, at 10:11 , ching lu <[email protected]> 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
> > > >>> <[email protected]> wrote:
> > > >>>>
> > > >>>>> On 12 Oct, 2016, at 08:52, ching lu <[email protected]> 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
> > > >>> [email protected]
> > > >>> https://lists.bufferbloat.net/listinfo/cake
> > > >>
> > >
> >
>
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
