Re: I-D Action:draft-ietf-dccp-simul-open-02.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks,

These all seem reasonable requests. I'm picking-up the editorial job from Gerrit and will prepare a new rev. after we receive your comments on 2.3 and following.

Gorry.

Phelan, Tom wrote:
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.




[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux