Hi,
I have reviewed the document and have two comments. Otherwise the
documents looks okay and should be published.
1. Section 2.2.3:
If one makes a comparison here with STUN connectivity checks under ICE
we are missing an optimization here. That is the triggered DCCP-Request.
Before the client has received a DCCP-Listen or a regular response it
doesn't know that the path is open. Thus if one resent the request upon
receiving the Listen one knows that it can get through. A previously
sent request may have gotten through, but the client doesn't know that
until much later. So the question here is: Is this speedup of the
connection worth it? Is it congestion safe enough? I also assume this
will not create issues in the DCCP state machine.
The case this optimize is the following which isn't enumerated in the draft:
DCCP A DCCP B
------ NA NB ------
+------------------+ +-+ +-+ +-----------------+
|(1) Initiation | | | | | | |
|DCCP-Request --> +--+-+---X+ + | |
| |<-|-|----+-+--+<-- DCCP-Listen |
|DCCP-Request --> +--+-+----+-+->| |
|(Triggered) | <+-+----+-+--+<-- DCCP-Response|
|DCCP-Ack --> +--+-+----+-+> | |
| | | | | | | |
|(2) Data transfer | | | | | | |
|DCCP-Data --> +--+-+----+-+> | |
+------------------+ +-+ +-+ +-----------------+
Considering that the initial retransmission timer for DCCP-Request
messages are on the order of 0.5 to 1 seconds I think this could
substantially speed up session establishment in these cases.
2. Figure 5:
I think this figure might be a bit confusing or rather unclear on what
happens with the DCCP-Listen messages. For the DCCP-Listen messages to
arrive at DCCP-A the NA needs to have a binding (NAT) or opened pinhole
(FW) that is a result of traffic from DCCP-A on A's source port. If NA
is a NAT then some procedure to create that binding and learn the
external address and port will have to happened. If NA is a Firewall
then DCCP-A can still send that SDP to DCCP-B with its source address
and port and the traffic will be dropped by NA. Can you please document
the assumptions that result in the DCCP-Listen packets to reach the
DCCP-A instead of being dropped at NA.
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Färögatan 6 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED]
----------------------------------------------------------------------
