Re: [dccp] dccp spec review (Rescorla)

[Sally Floyd <floyd@icir.org>]

Eric was just in Berkeley visiting ICIR for the afternoon, so Mark
and I talked with him about DCCP, and I am going to summarize for
the list.  This is in the form of a response to Eric's most recent
email about DCCP, which we hadn't responded to yet.

(Eddie wasn't here, since he was in Boston today.)

We had a good meeting, and good agreement on many issues.

Mobility:

...
>> We don't really see this from the rest of your comments. It seems like the
>> main modification you would like to make is described in Section 2.1
>> (response below). Is there something else?
>
>Well, mobility, for starters. Anyway, that was my attempt to sum
>things up. If you feel like the stuff I talked about isn't a substantial
>change (but do want to make it) then that's fine by me :)

There are two reasons to consider adding mobility to DCCP:
(1) Mobile IP might not be there at the lower layer, or
(2) DCCP might want a solution that is better adapted to the needs
    of DCCP, where minimizing delay is a priority, and the assumption
    is that one starts out with an existing connection.
    
The issue of adding mobility depends in part on whether you think
there will be a pressing need, in the future, for devices to change
providers mid-connection (e.g., from the cell-phone to the WIFI provider).

There wasn't clear agreement on the answers to these issues.

Multiple CCIDs:

...
>> The CCID-3 draft says "TFRC congestion control is appropriate for flows
>> that would prefer to minimize abrupt changes in the sending rate."
>Right, but it's not clear to me what applications would really 
>benefit from one or the other. What current applications do you
>believe have drastically different utilities from CCID-2 and
>CCID-3? Have you done simulations to observe the behavior?

We will add text to the draft about the motivations for multiple
CCIDs.  (CCID3 to minimize abrupt changes in the sending rate;
CCID2 to maximize bandwidth usage when halving the sending rate
is not a problem;  a new CCID in the future for audio, which
adapts the packet size instead of the sending rate.

MUST/SHOULD:

...
>> I would rather keep the MUST ignore/SHOULD be zero. That way, intrusive
>> middleboxes would be encouraged to really ignore the field, rather than
>> reset/drop on nonzero. Middleboxes will ignore this particular field
>> anyway, of course (because of CCID-specific values).
>What's wrong with MUST ignore/MUST be zero?

We will follow the guidelines of MUST being used only for
interoperability and network health, but will look for cases where
SHOULDs might need a little more text discussing the dangers
of not following the SHOULD.

...
>> > S 5.4:
>> > What's the motivation for using a 32-bit service identifier?  This
>> > seems like a false optimization, and it means that we absolutely need
>> > a registry. There's plenty of room here to have something more
>> > freeform. If you're really worried about bandwidth, have the high bit
>> > mean "variable length" and register in the low 31 bits.
>> 
>> Mark: I *want* a registry. But the space is intended to be big enough that
>> you can do FCFS allocation, without artificial space constraints.
>>
>> Eddie: We could make Service Name a mandatory variable-length option if
>> people feel strongly about this.
>My experience with registries is not good. That means registry policies,
>etc. What's the virtue of this?

Ah dear, we didn't talk about this one.

...
>> > Is there any reason why the Connection Nonces
>> > shouldn't be always exchanged in the initial handshake?
>> 
>> In case the Connection Nonces were generated out-of-band using some
>> cryptographic mechanism, for example. Maybe A and B have a shared key; they
>> hash that key with the source and destination ports to get the Nonces. Then
>> they know each other's Nonces without having to expose them in plaintext.
>Could you explain this in the text.

Will do.

...
>> > What's aliasing noise?
>> 
>> When the endpoints have slow timer granularity, so the elapsed time value
>> is always in a multiple of 1 ms, for example. Then a smaller value, like
>> 0.5 ms, would be represented by a sequence of 0 ms and 1 ms values.
>I think explaining this would be worthwhile.

OK.

CCID 1:

We will try to clarify the discussion of CCID 1.

>> We haven't, except for the thought experiments required to come up with
>> Section 8.9. Which cost(s) in particular are you worried about? Space?
>> Time?
>Well, there's a lot of optimization here, so I'm wondering if it's
>a particularly good optimization choice.

We didn't talk about this one either.

>> > S 11:
>> > This PMTU stuff worries me a bit. It seems like one might want
>> > to periodically probe and see if one could reincrease the 
>> > MTU. One good reason to do this is to prevent DoS attacks where
>> > the attacker drives your MTU down to zero.
>> 
>> They'd probably have to guess sequence numbers to do that, right? Because
>> of the embedded header in the ICMP NEEDFRAG?
>Yes, I would think so.

Again, we didn't talk about this one.

Middleboxes:

>> I believe that you are correct, middleboxes will do what they please; but
>> this section will provide guidance and warn middlebox designers about
>> potential ratholes. We could clarify that this is the intent of the
>> section; would that help?
>Maybe just remove the normative language.

Will do.

Partial checksums:

...
>I'm not convinced this is a real problem. Is there some network
>where this actually happens to a substantial degree where one wouldn't be 
>better off just using FEC?

There are a number of issues here:

(1) Are bit errors sufficiently frequent in the current Internet
to make partial checksums worth the trouble?  If so, it could be
because the app can make use of the errored data, or because the
app would prefer to know that this was corruption and not congestion,
and therefore avoid a congestion control response.

[Aside from Sally:  This is a case where our underlying models
affect our design.  If our conceptual model is one of a wireless
Internet with bit errors, then partial checksums seem more attractive.
If our model is one of a wireless Internet with lots of FEC and
such, in part to accommodate the needs of TCP, and therefore no bit
errors, the partial checksums seem less pressing.]

(2) If bit errors aren't sufficiently frequent in the current Internet,
would we like to enable future link level technologies that can
be just a touch more relaxed about allowing bit errors, or not?

I think we have an agreement about the issues regarding
partial checksums, even if there isn't clear agreement about
the answers.

...
>> > 4.0 Security Issues
>> > -------------------

Mark will send a summary to the list later on.  There was agreement
that there was a clear tradeoff here, between slightly better
security and slighly better transparency to middleboxes, without
an obvious call about which was the better path.

And Mark or Eric will feel free to correct anything that I missed
or got wrong.

- Sally

_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html