Christian -
>This restriction affects the way we design protocol extensions. I see
>that as an argument for "in-band" signaling, e.g. parameters in TCP
>packets or in IP headers of TCP packets, by opposition to "out of band",
>e.g. ICMP messages.
Yes, that is the thought behind things like the proposal for QuickStart
("http://www.icir.org/floyd/papers/draft-amit-quick-start-02.txt";),
which would use an IP Option in the TCP SYN packet to find out if
the TCP sender would start off with a higher initial sending rate.
However, there is another section of our recent measurement paper,
Section V.C., with our measurements of paths that block known
and/or unknown IP options on paths to web servers:
"As Figure 5 shows, in many cases no connection was established when
the [IP] Record Route Option or the [IP] Timestamp Option was included in
the SYN packet. When IP Option X [a new IP Option; e.g., QuickStart]
is included in the SYN segment, the connection was not established
to over 70% of the web servers tested. This does not bode well for
the deployment of new IP options in the Internet."
Of course, this involves IP Options on SYN packets on the path *to*
the web server. If something like QuickStart was ever standardized,
the IP Option would only be needed on the path *from* the web server
to the browser. Presumeably if the web server wanted to use something
like QuickStart, it could have the firewall configured to allow the
IP QuickStart Option not to be blocked on the outgoing SYN packet?
And the receiver could have the firewall on their end configured
to allow the IP QuickStart option on the incoming SYN packet to
pass? I don't know. However, the fact that connections fail today
when unknown IP Options are used on the SYN from the browser to the
web server does not *necessarily* mean that there is no hope for
using IP Options for in-band signalling.
The good news is that known or unknown TCP options are not blocked
on paths to web servers. Or at any rate, the connection still
succeeds in being established...
- Sally
Measuring the Evolution of Transport Protocols in the Internet:
http://www.icir.org/tbit/
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf