[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
