Quick-Start for TCP and IP
RFC 4782
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert Yes
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) (was Discuss) No Objection
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
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.
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) (was Discuss, No Objection) No Objection
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.
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection