Mailing List Archive: exim: dev

DSCP for inbound connections

Index | Next | Previous | View Threaded

pdp at exim

Jun 2, 2012, 3:05 PM

Post #1 of 4 (277 views)
Permalink

DSCP for inbound connections

I'm thinking that the best way to have DSCP set for the packets outbound
from Exim as a server, when a client connects, is to have a
"control = dscp/$value"
option which can be set in the acl_smtp_connect ACL.

Thoughts? Does this seem sane?

In discussion with a user who wants/needs DSCP, am looks like there's a
need to be able to reference the DSCP value for inbound connections, so
something like $received_initial_dscp as a variable.

The _initial_ because theoretically I believe the DSCP/TOS/TCLASS can
change during a connection, but I don't know if we want to support that
in an ACL other than the initial one.

Although, I suppose if a user authenticates, we might want to let the
admin put them into a better traffic class, so perhaps it *should* be
adjustable from any SMTP ACL ...

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

pdp at exim

Jun 3, 2012, 6:58 AM

Post #2 of 4 (260 views)
Permalink

Re: DSCP for inbound connections [In reply to]

On 2012-06-02 at 18:05 -0400, Phil Pennock wrote:
> I'm thinking that the best way to have DSCP set for the packets outbound
> from Exim as a server, when a client connects, is to have a
> "control = dscp/$value"
> option which can be set in the acl_smtp_connect ACL.
>
> Thoughts? Does this seem sane?

Implemented that. Seems to work great. Easier to test than the
outbound too (we, er, won't mention how long I was scratching my head
for, forgetting that SMTP delivery re-execs Exim and that I hadn't set
exim_path in the test config).

> In discussion with a user who wants/needs DSCP, am looks like there's a
> need to be able to reference the DSCP value for inbound connections, so
> something like $received_initial_dscp as a variable.
>
> The _initial_ because theoretically I believe the DSCP/TOS/TCLASS can
> change during a connection, but I don't know if we want to support that
> in an ACL other than the initial one.
>
> Although, I suppose if a user authenticates, we might want to let the
> admin put them into a better traffic class, so perhaps it *should* be
> adjustable from any SMTP ACL ...

Variable: still not quite sure about exposing this, or if perhaps it
should be an expansion item rather than a variable, so that each time
it's expanded the value is fetched. Er, I'm also blanking on how to
*implement* this with a read()-based API, without switching our entire
SMTP read system to a readmsg()-based system, which I'm *very* reluctant
to do for such a minor feature.

ACL: I let this be adjusted from most ACLs, excluding only the non-SMTP
and the notquit.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

pdp at exim

Jun 3, 2012, 7:24 AM

Post #3 of 4 (265 views)
Permalink

Re: DSCP for inbound connections [In reply to]

On 2012-06-03 at 09:58 -0400, Phil Pennock wrote:
> Variable: still not quite sure about exposing this, or if perhaps it
> should be an expansion item rather than a variable, so that each time
> it's expanded the value is fetched. Er, I'm also blanking on how to
> *implement* this with a read()-based API, without switching our entire
> SMTP read system to a readmsg()-based system, which I'm *very* reluctant
> to do for such a minor feature.

Stevens, Unix Network Programming, volume 1 3rd edition (Stevens,
Fenner, Rudoff), page 215, under "IP_TOS Socket Option":

This option lets us set the type-of-service (TOS) field (which
contains the DSCP and ECN fields, Figure A.1) in the IP header for a
TCP, UDP or SCTP socket. If we call getsockopt for this option, the
current value that would be placed into the DSCP and ECN fields in the
IP header (which defaults to 0) is returned. There is no way to fetch
the value from a received IP datagram.

That last sentence clinches it, there will not be a
$received_initial_dscp or $received_dscp added to Exim.

As to ECN/DSCP bit fields, the second-next paragraph notes that the ECN
field should be specified as zero in the setsockopt value set with
IP_TOS.

Okay, that's that sorted. Someone who wants to distinguish inbound DSCP
values needs to enumerate the values they care about, have Exim listen
on multiple ports and have the router or system kernel packet filter
redirect to an appropriate port based upon DSCP in the inbound SYN
packet and maintain the flow thereafter, even if the DSCP value changes.

Fortunately, the MTA use-case for DSCP which I designed at
$a_former_employer only needs DSCP for outbound connections.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

jgh at wizmail

Jun 3, 2012, 8:51 AM

Post #4 of 4 (259 views)
Permalink

Re: DSCP for inbound connections [In reply to]

On 2012-06-03 15:24, Phil Pennock wrote:
> On 2012-06-03 at 09:58 -0400, Phil Pennock wrote:
>> Variable: still not quite sure about exposing this, or if perhaps it
>> should be an expansion item rather than a variable, so that each time
>> it's expanded the value is fetched. Er, I'm also blanking on how to
>> *implement* this with a read()-based API, without switching our entire
>> SMTP read system to a readmsg()-based system, which I'm *very* reluctant
>> to do for such a minor feature.
>
> Stevens, Unix Network Programming, volume 1 3rd edition (Stevens,
> Fenner, Rudoff), page 215, under "IP_TOS Socket Option":
>
> This option lets us set the type-of-service (TOS) field (which
> contains the DSCP and ECN fields, Figure A.1) in the IP header for a
> TCP, UDP or SCTP socket. If we call getsockopt for this option, the
> current value that would be placed into the DSCP and ECN fields in the
> IP header (which defaults to 0) is returned. There is no way to fetch
> the value from a received IP datagram.
>
> That last sentence clinches it, there will not be a
> $received_initial_dscp or $received_dscp added to Exim.

Seems like a lack in the available interface rather than anything
fundamental, but given how long those bit-positions have been lying around
unused in the ipv4 header I really doubt that many people care.

Should the position be (or become) different in some OS we want
to support we can revisit; as you note an expansion item would
be preferable to a variable (even if a first implementation
could only support the connect-time value, IMHO).
--
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads