Hi Gorry, General comment: The need for this and the technical approach seem solid to me, but the document seems to me to be guilty of what newspaper editors refer to as "burying the lead". It solves a very specific problem, but you have to read an awful lot of the document before you're sure that that, and only that, is what's being addressed. For a small, specific example, section 1.2 is called "Scope of the Problem to be Tackled" and lists three NAT traversal scenarios. The first one is not within the "Scope of the Problem to be Tackled", but it's pretty difficult to tell that. I think the background info is very good and useful, but you should consider a reorg so that the "Scope of the Problem to be Tackled" is obvious to a casual reader. Specific comments: Abstract: "The update adds a packet type, DCCP-Listen, which assists DCCP applications that need to communicate through one or more middleboxes (e.g. Network Address Translators, NATs, or firewalls), where establishing necessary middlebox state requires peering endpoints to initiate communication in a near-simultaneous manner." I think this hides some important points, but I'm having trouble giving you a reworded version. The important points are that this is really about servers that are behind NATs (not clients) and that it allows those servers to accept connections from clients that the servers have some out-of-DCCP-band knowledge about. I'm not sure how to reword this into a couple of succinct sentences though. Well, this is really the "burying the lead" problem, but I think that lead needs to come out strongly in the abstract. 1. Introduction "UDP Network Address Translator (NAT) traversal is well understood and widely implemented. NAT traversal for connection-oriented protocols (e.g. TCP) uses similar principles, but in some cases requires more complex and expensive solutions, such as data relay servers [TURN]." "Similar principles" -- similar to what? Not sure what the point is here. 1.1 Scope of this Document "This technique applies to scenarios where one or both DCCP peers are located behind a middlebox." Well, it applies when the server is behind a middlebox, and it doesn't matter whether the client is or isn't, correct? This sentence implies that the technique applies when the client is behind a middlebox and the server isn't. While the technique won't break that scenario, it isn't useful in that scenario. 1.2 Scope of the Problem to be Tackled I've already said something specific about this section, but in general, I don't emerge from reading this section with a clear feeling that I know the "Scope of the Problem to be Tackled". 2.2 DCCP-Listen Packet Format 'X' in the packet header format -- since 'X' can only be 1, maybe it should say that in the format. Or use the technique from RFC 4340 - "Generic header with X=1 (16 bytes) with Type=10 (DCCP-Listen)". That would then eliminate the need for some of the short sequence number discussion later. You could also specifically use 0 for the other fields that must be zero (such as CCVal). Top of page 6 -- "At the time of writing. there areo known uses of the header option ([RFC4340], sec. 5.8) with a DCCP-Listen packet." Typo -- extra period and I assume "areo" should be "are no" By "the header option" do you mean DCCP options? If so, I think "DCCP options" is clearer. I recall some discussion about options in the Listen packet, but don't recall the result. Should we have some requirements related to this? Perhaps "servers SHOULD NOT send DCCP Options in DCCP-Listen packets and clients MUST ignore options in received DCCP-Listen packets"? Or "servers MAY send DCCP Options and clients MAY ignore received options"? At any rate, the sentence you have seems to require something else to make it useful. I don't see any mention of what the destination IP address and port should be. I think it'd be nice if you listed each interesting field and described the usage. For example: "Source port -- the port on which the server is listening for connections from the IP address that appears as the destination IP address in the packet. CCVal -- must be zero (a connection has not been established)." And so on. 2.3.1 Protocol Method for DCCP-Server Endpoints "The update modifies the way the server performs a passive-open." Well, not necessarily. It adds a new alternative way for a server to perform a passive-open. Servers that are happy with the old functionality are not impacted. "Server endpoints SHOULD in general ignore any incoming DCCP-Listen packets. As an exception to this rule, a DCCP Server in state LISTEN MAY generate a Reset (Code 7, "Connection Refused") in response to a DCCP-Listen packet. This Reset is an indication that two servers are simultaneously awaiting connections on the same port." Well, yes it indicates that two servers are listening on the same port, but why should that be a problem? I think the first sentence is enough (without "in general"). 2.3.2 Protocol Method for DCCP-Client Endpoints "Clients MUST silently discard any received DCCP-Listen packets, regardless of their current state." I assume "their" refers to "clients", not "packets". Maybe "regardless of the clients' current state". Running out of time -- I'll get to the rest later :-). Tom P. -----Original Message----- > From: i-d-announce-bounces@xxxxxxxx [mailto:i-d-announce-bounces@xxxxxxxx] > On Behalf Of Internet-Drafts@xxxxxxxx > Sent: Monday, September 15, 2008 4:00 AM > To: i-d-announce@xxxxxxxx > Cc: dccp@xxxxxxxx > Subject: I-D Action:draft-ietf-dccp-simul-open-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Datagram Congestion Control Protocol > Working Group of the IETF. > > > Title : DCCP Simultaneous-Open Technique to Facilitate > NAT/Middlebox Traversal > Author(s) : G. Fairhurst, G. Renker > Filename : draft-ietf-dccp-simul-open-02.txt > Pages : 27 > Date : 2008-09-15 > > This document specifies an update to the Datagram Congestion Control > Protocol (DCCP), a connection-oriented and datagram-based transport > protocol. > > The update adds a packet type, DCCP-Listen, which assists DCCP > applications that need to communicate through one or more middleboxes > (e.g. Network Address Translators, NATs, or firewalls), where > establishing necessary middlebox state requires peering endpoints to > initiate communication in a near-simultaneous manner. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dccp-simul-open-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft.
