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.'
|
