I do not expect that it would be easy to add that.
I do not know whether getsockopt() will even allow one to access the DSCP, but even if it does, some interactions happen without the application being aware. Obviously, the SYN+ACK is sent before the app gets anything, for example.
Unfortunately it would seem you're looking for a change in TCP behavior, rather than thrulay behavior.
-- Stas
On Aug 26, 2008, at 8:40 PM, wrote:
Hi Stanislav,
Many thanks for the prompt response. I will test the 'Try starting thrulayd with the appropriate -D option maybe?' method to determine whether it successfully sets the QOS bits on the return stream, I'll let you know how things turn out. How easy/difficult would it be to add the reflection of DSCP bits into Thrulay as an option to the daemon?, as it would make things a lot easier running multiple tests without having to re-start the daemon for specific QOS streams.
Thanks Stanislav.
Derek.
| Stanislav Shalunov <> 27/08/2008 11:02 AM | | To | | | cc | | | Subject | Re: Support for QOS bits in Thrulay |
|
Derek,
The way TCP works is that the DSCP bits are not reflected back. Whether this is right or wrong, this is what thrulay ends up using. There are arguments both ways.
Try starting thrulayd with the appropriate -D option maybe? If not, start thrulayd on the box where you originally ran thrulay and run thrulay from the other direction (with -D).
-- Stas
On Aug 26, 2008, at 7:20 PM, wrote:
- From:
- To:
- Subject: Transfer of QOS fields from received (at server) stream to transmit stream
- Date: Tue, 26 Aug 2008 22:09:26 -0400 (EDT)
Hi, could any member of the Thrulay development group please comment on my
results when using Thrulay in conjunction with VLAN support, with regards to
the correct setting of DSCP bits (see below)?
Thanks. Derek Smith.
Hi Richard,
I began testing this morning, and the VLAN feature works as expected
(the vconfig command does raise a warning ('could not open
/proc/net/vlan/config') when configuring the first VLAN sub-interface, but it
does not seem to affect the operation of the VLANs). During testing I noticed
a slight decrease in throughput using Thrulay, typically around 1-2 Mbit/s,
when running through a VLAN sub-interface as opposed to using the 'normal'
non-VLAN interface (both active on the same physical interface, N.B. the
vconfig command will only create a VLAN sub-interface on an interface that is
up).
I also tested the mapping of the DSCP bits (set using the -D option of
Thrulay) into the VLAN QOS bits using the 'vconfig set_egress_map' and
'vconfig set_ingress_map' commands, and verified that they were being set
correctly using Wireshark (through a monitor port on a switch). However the
Thrulayd daemon does not appear to map DSCP bits received from a client, into
frames transmitted back to the client, which obviously prevents me from
performing a throughput test using the same QOS level in both directions.
Hopefully the Thrulay developers may be able to identify the cause of this.'
--
Stanislav Shalunov
<mime-attachment.gif>
========================================================================
Electricity Networks Corporation, trading as Western Power
ABN: 18 540 492 861
TO THE ADDRESSEE - this email is for the intended addressee only and may contain information that is confidential.
If you have received this email in error, please notify us immediately by return email or by telephone.
Please also destroy this message and any electronic or hard copies of this message.
Any claim to confidentiality is not waived or lost by reason of mistaken transmission of this email.
Unencrypted email is not secure and may not be authentic. Western Power cannot guarantee the accuracy, reliability,
completeness or confidentiality of this email and any attachments.
VIRUSES - Western Power scans all outgoing emails and attachments for viruses, however it is the recipient's responsibility
to ensure this email is free of viruses.
======================================================================== |
|
