Re: [dccp] dccp spec expert review (Minshall, main spec)

[Greg Minshall <minshall@acm.org>]

Eddie and Sally,

thanks for the detailed reply.  below are some comments on just a few of your 
comments.  i apologize for taking so long to compose these.

in summary, i would say the three biggest issues are: sequence number 
wrapping; making sure half-open connections close nicely; and how to treat 
congestion interior to the receiving node.

> But this may be a problem with the rationale, not the sequence number length.
> DCCP is designed for connections with congestion windows of at most a few
> hundred thousand packets; that is its design space. Sally, in particular,
> strongly believes that we don't know how to do congestion control with larger
> cwnds, and that entirely different mechanisms might be required. If at most
> 2^18 or 2^19 packets will be in flight during a given RTT, that still leaves
> 32-64 RTTs before sequence numbers wrap; and this might be sufficient for
> now.

> Nevertheless, your comments, and Eric's, make me think that we should specify
> some wrap mechanism now: for instance, an option or feature that announced
> the wrapping of sequence numbers. (In other words, we explicitly transmit the
> lower 24 bits of each sequence number, but the endpoints keep 32 or 64 or
> whatever, with the upper bits negotiated once the connection approaches
> sequence number wrap.) 

my concern is "PAWS", worrying about the sequence number wrapping and old 
segments being accepted.  i don't think the mechanism you think about in the 
second paragraph would protect against that, though maybe i'm missing 
something.

> Ouch. Should we specify exactly how the Loss Window is to be arranged?

i think so, yes.

> I disagree. Furthermore half-open connections are not relevant here (unless
> I'm missing something). The section describes what to do with a packet
> _belonging to an existing connection_ whose sequence number is invalid for
> that connection. The "closed" side of the half-open connection will properly
> ignore all packets but Requests. 

the "half-open" connection dance is one of the subtlest in TCP.  Figure 10, 
page 34, of RFC793, shows how it works.  it may be that all the steps of the 
tango are not necessary, though it's always seemed to me that they are.

i *think* you want to think carefully about this, and make sure it works in 
DCCP.  it isn't clear to me that it works, but i may be missing something.

> Congestion in the receiving node does not always merit the same heavy-duty
> response as network congestion.

i'll repeat that i think this a mistake.  at some extreme we would both agree 
to be idiotic there could be separate mechanisms depending on if it is the 
sending NIC, receiving NIC, receiving kernel buffer space, receiving kernel 
disk bandwidth for paging, etc., that is congested.

we have a mechanism for dealing with congestion, which is dropping (or, if we 
are able, marking but forwarding) packets which encounter that congestion.  it 
is conceptually simple.  i strongly suggest staying with this.  (i guess i've 
belabored this point.)

>> "A DCCP-Data or DCCP-DataAck packet may contain no data bytes if the
>> application sends a zero-length datagram.  Such zero-length datagrams
>> MUST be reported to the receiving application."  I can see some
>> utility in having this facility (framing, sending an EOF, etc.).  But,
>> I can imagine that some systems would have trouble implementing this
>> requirement (some systems might have to re-work their buffer
>> management code, the API between applications and the kernel, etc.).

> OK. MUST -> SHOULD? 

i would eliminate the requirement, even the suggestion.

> Here are a couple alternate mechanisms.

>   1. DCCP B must retransmit its Ack until it hears back from A'.
>   2. DCCP B must keep state for the connection under *both* A and A' for
>      a while. After five seconds (say) the entry for A will disappear.

i was thinking that one could use the *initial* addresses as permanent session 
identifiers (so, always be able to index into the table using those indices), 
but i suspect with DHCP, etc., there is no guarantee of the permanence of the 
initial addresses.  but, it would be nice if there was some unique session 
identifier which could be used as a last resort in these sorts of cases.  but, 
that isn't helpful.  sorry.

> Probably, but I think it's important to explicitly demonstrate that this is
> an allowed possibility. (Unless we want to disallow it.)

i would (mildly) suggest disallowing it.  allowing it makes for a more 
complicated state machine, and i can't quite see the real world utility.

> "A lower bound on the elapsed time"?

that would be zero.  "An upper bound on the elapsed time", presumably, would 
be say 200ms.

> Because the receiving application might still be sending data.

yes, it might be.  but, its peer appears to be misbehaving.  which one could 
argue would warrant resetting the connection.  again, here my objection is 
mild.

> Dumb firewalls. So far, there aren't any dumb firewalls that we know about
> that block packets due to the ECN field in the IP header, but the argument in
> RFC 3360, Inappropriate TCP Resets Considered Harmful, is that transport
> protocols now have to be designed to protect themselves against such
> possibilities. 

i haven't read 3360.  but, i don't think it is possible to design a transport 
protocol such that it is protected against every stupid box that might be 
created to stand in its way.  i agree that for an existing protocol, such as 
TCP, it makes sense to field upgrades in a way that doesn't break too badly in 
the face of stupid middleboxes.  but, the middleboxes are going to have to be 
rewritten to understand DCCP (i would assume); requiring them to not mess up 
ECN sounds to me like a good idea.

> Also, in general, the sender is a server with many active connections whose
> motivation generally is to use end-to-end congestion control, while the
> receiver often has a much stronger motivation for evading end-to-end
> congestion control. 

this is how some (currently prevalent) applications work.  it isn't how the 
prevalent application of 5 years from now will necessarily behave.

> Some firewalls don't let ICMP through. So the ICMP NEEDFRAG message that is
> required for PMTU wouldn't get through to the relevant endpoint.

> Injecting extra packet into the data stream -> A middlebox faced with that
> situation should probably drop the offending packet and send a NEEDFRAG to
> decrease the PMTU.

the above two fragments (from different comments) implicitly contradict each other (having cake and eating it too?).

> I really don't want middleboxes to change sequence numbers. It
> breaks a huge number of things, including Identification, and
> additionally makes the middleboxes' lives much harder.

i can't say many people have been happy with NAT boxes expanding TCP packets.  but, they have.  i'm not sure one should design to make it easier for middleboxes to do such things.  but, it is probably the case that no matter how hard you make it (modulo end to end crypto), they will.

thanks again.  Greg


_______________________________________________
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