Quick-Start for TCP and IP
Summary: Needs a YES.
Note: This ballot was opened for revision 06 and is now closed.
( Lars Eggert ) Yes
Jari Arkko No Objection
Comment (2006-10-11 for -)
This is a very interesting and great spec. But I still worry about the practical tradeoff for early deployers implied by the experimental results: Measurement studies of interactions between transport protocols and middleboxes [MAF04] show that for 70% of the web servers investigated, no connection is established if the TCP SYN packet contains an unknown IP option ... If the TCP sender doesn't receive a response to the SYN or SYN/ACK packet containing the Quick-Start Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet without the Quick-Start ... And the cost evaluation in Section 9.2 does not take this into account at all, as far as I can see.
( Ross Callon ) No Objection
( Brian Carpenter ) (was Discuss) No Objection
( Lisa Dusseault ) No Objection
( Bill Fenner ) No Objection
( Russ Housley ) No Objection
( Cullen Jennings ) No Objection
( David Kessens ) No Objection
( Dan Romascanu ) No Objection
( Mark Townsley ) (was Discuss, No Objection) No Objection
Comment (2006-10-11 for -07)
If the tunnel ingress for the simple tunnel is at a router, the IP TTL of the inner header is generally decremented during forwarding before tunnel encapsulation takes place. This is not true for L2TP tunnels, though I understand that the document is not making any specific claim about L2TP at this time. For IPinIP and GRE tunnels, the TTL is decremented on ingress and egress for each tunnel. For L2TP, it is only decremented at an LNS, which is typically the egress of the tunnel.