On 26.11, Pablo Neira Ayuso wrote: > > > ToS breaks useful things like ECN, and the more I keep reading docs on > > > the Internet, the more problem I have to see how the user can benefit > > > from this. > > > > We *match* on ToS, that cannot possibly break anything. Also I'm unsure how > > this could break ECN even otherwise, ToS does not even use the ECN bits. > > ToS bits overlap with ECN bits, from that original ToS 8 bit-field now > we use 6 bit for DSCP and 2 bits for ECN. Sure, but our ToS definition is wrong anyway, the ToS-bits are actually 3 + 3 + 2 unused bits (ECN). > > Its quite simple, if the user has old devices that set ToS values, he will > > be able to match on that without manually converting it to DSCP values. > > Given that our current tos definition is also not to practical for that > > since its too broad, I don't really care that much, although I think it > > should rather be fixed than simply thrown out. > > People that designed DSCP and ECN did not care about having some > reasonable backward compatible behaviour wrt. ToS. They just changed > the semantics of those bits long time ago. > > I can explore keeping this backward if you like, we can probably > accept ToS from the parser, then map it to DSCP, but that will no > achieve what the user expected on the network. I'm usually reticent to > break old stuff, but in this case I would skip. My thought was more fixing our ToS field definition, at that point the user can use whatever is actually used within his network. I mean, sure, you can map them to DSCP, but if you're using old devices that only support the ToS definitions its a lot easier to use the same values instead of mapping them. I don't know. I think it should be fairly easy to fix, so I'd prefer that way I guess. Your choice. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
