New DSCP target in CVS
Thu, 21 Mar 2002 10:24:32 +0100
[sorry Harald, but the topic is slightly more complex than that]
On Thursday 21 March 2002 03:35, Takuya Satoh wrote:
> Please can you explain further which bits in TCP header exactly?
See RFC2481. The use of IP ECN for TCP is negotiated with TCP flags.
IP ECN isn't activated unless the TCP endpoints agrees upon using it
(at earliest the syn-ack packet)
The only thing you can acheive by filtering the ECN bits in the IP
header is to signal to the network that "ECN is not to be used for
this specific packet". The other endpoint will still use ECN on it's
packets if TCP has negotiated the use of ECN. To control both
endpoints from one location you need to control the negotiation, not
the per-packet use.
> BTW does anyone know the difference between ECN and the
> PMTUBlackHoleDetect feature of Microsoft's TCP stack?.
Everything. PMTU Black Hole detection is an entirely different
matter related to ICMP, not the use of ECN.
> Also if I understood it correctly ECN doesn't work for
> anything else than TCP (e.g. UDP, GRE protocols), right? So no
> help on tunnels (VPN, IPSEC) using mainly UDP ...
ECN as such works at the IP level and thus in theory works just fine
for all IP protocols. But to be effective it needs help from the
upper protocol to perform flow control in response to ECN. Of the
standard IP protocols only TCP defines the term connection and flow
control, and thus the IP ECN standard only defines how TCP is to
negotiate and react to the use of ECN. It does not really make sense
to define the use of ECN in the other protocols at the IP level.
For tunnels such as GRE or IPSEC tunnels the recommended use is that
the tunnel echos the ECN bits in the encapsulated packets. Note: Some
IPSEC implementations is quite likely to get this wrong and
erronously include both ECN IP bits into it's AH calculation (ECT may
be OK, even if defeating part of this discussion).
For UDP each application has to specify how to negotiate the use of
ECN and how to react when detecting congestion. The UDP protocol do
not define any flow control and thus the details of ECN flow control
opearation at the endpoints cannot be specified, only the network
The net result being that to fully work around ECN blackholes the
ability to clear ECN bits BOTH in the TCP header and in the IP header
is likely to be required.
TCP header to fully work around ECN blackholes for TCP traffic.
IP header to try to work around ECN blackholes for other types of
traffic, but very likely will require such filters on both sides of
the blackhole to be effective. For things like IPSEC there is no
other option I think unless one has control of at least one of the
host endpoints to disable the negotiation of ECN.
MARA Systems AB, Sweden