On Oct 22, 2015, at 7:51 AM GMT+2, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > On Sat, 2015-10-17 at 17:34 +0200, Ralph Schmieder wrote: > >>> On Fri, 2015-08-14 at 18:59 +0200, Ralph Schmieder wrote: >>>> Here we go again. Thanks for the comments, hope that I got >>>> everything >>>> right. For getting the TCLASS I could have used the word instead >>>> of >>>> the longword, too. But I guess there's no penalty for doing it >>>> this >>>> way, or is there? And it could use some testing beyond the simple >>>> IPv4 in IPv4 use case of mine :) >>> >>> Thanks again for working on this, and apologies again for the >>> delay. >>> >>> I'm still slightly nervous about the whole concept ? we are >>> deliberately leaking information from the inner packet into the >>> outer >>> packet. So people will be able to *see* that we're doing VoIP >>> traffic.... which in practice they could have inferred quite >>> trivially >>> from the packet size and regularity anyway. >>> >>> But now I look harder, I see that OpenVPN does already have this >>> facility, at least for Legacy IP, with the --passtos option. It's >>> disabled by default though, and I wonder if we should do the same. >>> And >>> make the option have the same name too? >> >> changed the option to --passtos and given the name it's therefore >> also disabled by default > > This patch will currently modify the packets from the client to server > only. Wouldn't it be more efficient if that included a header to server > (e.g., X-DTLS-PassTOS = true), so that these packets include the tos as > well? That of course would only work with ocserv. > Could be an option. Both directions are totally independent, however. Since QoS is controlled also independently on both ends (and, more importantly, independent on everything in between, e.g. the WAN/ISP) it does not make a lot of sense to signal this setting to the server as the client has no control whatsoever on the server side. E.g. it can signal 'pass TOS, please" but even if the server then marks the packets it could have no effect at all since it might not be implemented on the server's network. An option to enable/disable this on the server side is still useful but since only the network / server admin on that side knows whether it is in fact useful or not I don't see a point in having the user ultimately control it. Also, on the ISP part: Most (all?) ISPs don't trust QoS markings of ingress traffic. They re-mark and set it to zero anyway. The significance of these markings is local only. E.g. it is important for my network that the TOS bits arrive at my WAN router so that I can queue / police the packets accordingly. My provider does not care and ignores my settings anyway. The same happens in the other direction. I have no influence whatsoever on the incoming packets and even if my headend marks e.g. voice traffic with EF, my provider on the public Internet does not care and clears the TOS bits. That's probably the reason why I wasn't sharing the concern about copying the TOS bits to the outer packet in the first place. Thanks, -ralph
