Hannes Tschofenig writes: [...] > - denial of service issues with the router alert option: it is true > that router alert option processing is slower than packets which do > not have the router alert option set. however, i am not sure whether > this is truely a big issue based on the most recent information i > saw (see http://www.welzl.at/research/projects/ip-options/). This study compares the delay experienced by packets with IP options to the delay experienced by packets without IP options, for a wide variety of Internet paths. It observes that on average, IP options introduce between 7% and 26% (for different sets of paths at different times) of additional delay. The article says that "In any case, the additional delay is clearly an order of magnitude smaller than the RTT." To some people, this may suggest that option processing overhead isn't a problem in today's Internet. I don't buy this at all. The problem is this: A large part of the measured baseline delay is due to propagation times (length of links/speed of light in fiber) and thus mostly independent of whether IP Options are used or not. If, as I suspect, the part of the delay that is actually due to per-hop processing is small (for the baseline no-options case), then a 7%-26% increase of the *total* delay could mean an orders-of-magnitude increase in per-hop processing overhead when IP options are used. To illustrate this, here are the results of Michael's "extended ping" test over a cross-town path with five GbE hops, sorted by RTT: NONE 64 bytes from 130.59.35.42: seq=10007, ttl=62, rtt=0.171 ms NONE 64 bytes from 130.59.35.42: seq=10009, ttl=62, rtt=0.172 ms NONE 64 bytes from 130.59.35.42: seq=10005, ttl=62, rtt=0.178 ms NONE 64 bytes from 130.59.35.42: seq=10001, ttl=62, rtt=0.202 ms NONE 64 bytes from 130.59.35.42: seq=10000, ttl=62, rtt=0.209 ms NONE 64 bytes from 130.59.35.42: seq=10008, ttl=62, rtt=0.211 ms NONE 64 bytes from 130.59.35.42: seq=10003, ttl=62, rtt=0.216 ms NONE 64 bytes from 130.59.35.42: seq=10006, ttl=62, rtt=0.220 ms NONE 64 bytes from 130.59.35.42: seq=10004, ttl=62, rtt=0.225 ms NONE 64 bytes from 130.59.35.42: seq=10002, ttl=62, rtt=0.233 ms NOP 64 bytes from 130.59.35.42: seq=20005, ttl=62, rtt=0.735 ms NOP 64 bytes from 130.59.35.42: seq=20003, ttl=62, rtt=0.769 ms NOP 64 bytes from 130.59.35.42: seq=20006, ttl=62, rtt=0.775 ms NOP 64 bytes from 130.59.35.42: seq=20000, ttl=62, rtt=0.803 ms NOP 64 bytes from 130.59.35.42: seq=20008, ttl=62, rtt=0.803 ms NOP 64 bytes from 130.59.35.42: seq=20004, ttl=62, rtt=0.816 ms NOP 64 bytes from 130.59.35.42: seq=20002, ttl=62, rtt=0.885 ms NOP 64 bytes from 130.59.35.42: seq=20009, ttl=62, rtt=1.749 ms NOP 64 bytes from 130.59.35.42: seq=20001, ttl=62, rtt=3.456 ms NOP 64 bytes from 130.59.35.42: seq=20007, ttl=62, rtt=4.288 ms The optionless packets have an RTT between 171 and 233 microseconds (other traffic on the path may explain the variance). The packets with NOP IP options have an RTT between 735 and 4288 microseconds. This strongly suggests that IP options cause slow-path processing on our routers. Most operators won't worry about the additional delay incurred by packets that use IP options. But they WILL worry about the total processing overhead in their routers when there are many such packets, because slow-path resources are usually shared with the control plane, and operators just hate it when control of the network is impacted by user traffic. I can see a few possible outcomes when IP options become more common: 1.) Routers implement option processing in the fast path - this will be expensive and/or take time if the fast path is "in hardware", e.g. mostly based on ASIC/FPGA/CAMs. I think it will be hard to motivate this. 2.) Router vendors implement rate-limits for packets with (router-alerting) IP Options. The rate-limiting must be done in the fast path, while options processing can remain in the slow path. Maybe the rate-limits can be differentiated by option/extension header type, maybe not. 3.) Operators configure their routers to ignore IP Options. 4.) Operators configure their routers to drop packets with IP Options. Regards, -- Simon. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf