New DSCP target in CVS

[Henrik Nordstrom]

[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 
operation.

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.

Regards
Henrik Nordström
MARA Systems AB, Sweden