The document's basic outline seems fine. Using a new packet type for this
purpose seems fine. The document is not ready to publish yet, because of a
high typo load and lack of specificity in how packets are processed (i.e. no
explicit pseudocode changes). These problems can probably be addressed soon.
My opinion should have little weight as I am no longer an active member of
the WG
Comments and suggestions.
- 2.2.1: Do not refer to the "Allow Short Seqno" feature, simply say that X
must equal 1.
- "both Sequence Number fields" => There is only one Sequence Number field.
- "option values" probably was intended to be "feature values."
- It is not reasonable to restrict Listen packets to carry no options. A use
may be found for Listen options one day. It suffices to say that Listen
packets are currently ignored. This includes any options on Listen packets.
- "MUST NOT carry payload data" => No other DCCP packet has this restriction.
Simply say, as for the other packet types, that payload data is ignored.
- 2.2.1 "Data Offset is zero" => Wrong!! Data Offset is the header length. 0
does not mean no payload, it means no header. This should be 5 (20 bytes).
But as mentioned above this is not a reasonable restriction either. Data
Offset must be >= 5, allowing packets to contain options.
- 2.2.1 "CsCov MUST be zero" => Unreasonable restriction.
- 2.2.2 should state that, except for the generation of DCCP-Listen packets,
the INVITED state is treated exactly like the LISTEN state in the pseudocode.
It should probably include new pseudocode, additions and modifications to
RFC4340 Section 8.5, handling INVITED state and the receipt of Listen packets.
- 2.2.3 "ection 8"?
- Re: Magnus's suggestion on triggered Request packets, this should at most be
MAY behavior, and should be specified with explicit changes to the pseudocode
in RFC4340 Section 8.5.
- Typos throughout.
Eddie
Gorry Fairhurst wrote:
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
