Thanks Magnus,
I think these are helpful comments, and include an initial response
below. Although the WGLC has now closed, I'd also like to encourage
anyone on the list to also send comments to the list before the WG meeting.
It seems useful to use some of the time at the DCCP meeting to review
the questions and comments on this draft.
Gorry
Magnus Westerlund wrote:
> 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.
>
OK, seems relatively simple to add, with potentially good gains in some
deployment scenarios. If we did this, we would need to update the
wording that says a client ignores Listen packets, to allow processing
when a Request has been sent.
I'd suggest we also say that a client does this once only per
connection. That is, adding a flag to say that a client has responded -
thereby avoiding repeated responses, if repeated Listens are received.
> 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.
>
One issue is that we can also have a timing that could then result in an
exchange that looks like that shown below.
+------------------+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
|SDP +--+-+----+-+->| | State = INVITED
|(State = REQUEST) | | | | | | |
|DCCP-Request --> +--+-+- -+-+--| <-- DCCP-Listen |
| | | | \/ | | | |
| | | | /\ | | | |
| |<-+-+- -+-+->| |
|DCCP-Request --> +--+-+- -+-+--|<-- DCCP-Response| State = RESPOND
| (Triggered) | | | \/ | | | |
| | | | /\ | | | |
| |<-+-+- -+-+->| |
|(State= PARTOPEN) | | | | | | |
|DCCP-Ack --> +--+-+- -+-+--|<-- DCCP-Response|
| (Triggered) | | | \/ | | | |
| | | | /\ | | | |
| (ignored) |<-+-+- -+-+->| | State = OPEN
| | | | | | | |
+------------------+ +-+ +-+ +-----------------+
Note - an extraneous Request is generated, and also if I understand
DCCP (RFC 4340) correctly, this also triggers an extraneous Response.
The DCCP client and server know these are duplicates (from the sequence
numbers).
While I think on this, does anyone in the group have anything to add on
this topic: Do others think it is useful? Does it seem reasonable to add
to the Spec?
> 2. Figure 5:
>
> I think this figure might be a bit confusing or rather unclear on what
> happens with the DCCP-Listen messages.
>
My fault, I see.
> 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.
>
I suggest for consistency the diagram should show the DCCP-Request
from A, the discussion then follows that in figs 3 & 4 (I'll update the
text to reflect what you have written):
DCCP A DCCP B
------ NA NB ------
+----+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
| -->+--+-+----+-+--+--> SDP |
| | | | | | | | State = INVITED
| -->+--+-+---X| | | DCCP-Request |
| | | | | | | (dropped) |
| | | | | | | |
| |<-+-+----+-+--+<-- DCCP-Listen | Timer Starts
| | | | | | | | |
| | | | | | | | 1st Timer Expiry
| | | | | | | |
| |<-+-+----+++--+<-- DCCP-Listen | Timer Starts
| | | | | | | | |
| | | | | | | | 2nd Timer Expiry
| | | | | | | |
| |<-+-+----+-+--+<-- DCCP-Listen | Timer Starts
| | | | | | | | |
| | | | | | | | 3rd Timer Expiry
| | | | | | | |
| | | | | | | | State = LISTEN
~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | |
| -->+--+-+----+-+--+--> DCCP-Request |
| | | | | | | | State = RESPOND
| <--+--+-+----+-+--+<-- DCCP-Response|
+----+ +-+ +-+ +-----------------+
> 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: magnus.westerlund@xxxxxxxxxxxx
> ----------------------------------------------------------------------
>
Thanks again,
Gorry
