Hi Eddie, I'd like to take up your point about DCCP implementations doing reordering. As you point out, reordering involves delaying delivery. I hope that any DCCP stack that offers reordering would offer a way to disable it so that such delays could be avoided. So I tend to disagree with your parenthetical suggestion that the fact that the RFC doesn't REQUIRE reordering might have been a mistake. I even tend to think that reordering shouldn't be the default behavior of a DCCP stack. Duplicate suppression is another thing, as this function doesn't have any undesirable side effects that I can see and should be pretty easy to do. But I do believe that any DCCP application meant for any kind of general environment should assume that duplicates and reordered delivery are possible. Tom P. > -----Original Message----- > From: Eddie Kohler [mailto:kohler@xxxxxxxxxxx] > Sent: Monday, December 31, 2007 3:56 PM > To: Vladimir Moltchanov > Cc: dccp@xxxxxxxx > Subject: Re: Some general feedback on teaching DCCP > > Vladimir, Paul, > > My understanding is that the RFC ALLOWS stacks to suppress old and > duplicate > data, but does not REQUIRE them to do so. > > A DCCP application should be written to expect possibly out-of-order or > duplicated data. Like Ian says, it is "UDP with congestion control". For > ordering and duplicate suppression an app should use its own sequence > numbers, > or piggyback on DCCP's. > > A stack can, and probably should, attempt to arrange packets into sequence > and > to detect duplicates. But (possibly incorrectly) the RFC does not REQUIRE > implementations to do so. > > Ordering, in particular, is difficult: the POINT of dccp is to reduce the > latency inherent in providing in-order delivery; so an implementation that > received packets 1,3 should deliver 3 to the application quickly, rather > than > waiting a long time for a possibly-dropped, possibly-reordered 2. > > Eddie > > > Vladimir Moltchanov wrote: > > Hello Paul and Everybody, > > > > According to the RFC, its true that application could receive duplicate > > data. And, section 7.5.5 (sequence number attacks) states: > > > > .... > > Send DCCP-Data packets with random Sequence Numbers. If one of > > these packets hits the valid sequence number window, the attack > > packet's application data may be inserted into the data stream. > > .... > > > > Ofcourse, this is true for if guessed sequence number is greater then > > GRS (greatest received sequence number). But, I am quite surprised > > myself to see that even old but sequence-valid packet's data would > > qualify to be passed to an application (according to the pseudocode in > > section 8.5). There is only sequence validity check in step 6 (swl <= > > sno <=swh), and then data goes upstairs in step 16 with only restriction > > of no double data from request/response packets. > > > > Meaning that with apropriatelly big window (like 16) with the GSR 4, On > > the application one could see any give amount of data from packets with > > numbers 1,2,3 if some strange reordering/duplicating events on the > > network will take place? > > > > Can anybody clarify this issue? Was there a special purpose for such > > definition (like to allow higher layer protocols to handle the data) or > > am I missing something inb the rfc? > > > > B.R. > > Vladimir. > > > > > > On Fri, 30 Nov 2007, Paul D. Amer wrote: > > > >> First: > >> I'm teaching a graduate networking class that includes > >> DCCP as a new experimental protocol. I want to show > >> students various simple examples. In particular I want to show > >> which data is delivered (or read by the receiving application) > >> for different sizes of receive windows, and with/without > >> loss of DCCP packets. Best I can tell, > >> the RFC doesn't contain examples. Does anyone know > >> if any are available elsewhere? > >> > >> Second: > >> After reading the RFC, it's my understanding that > >> DCCP provides 'in-order, maybe-loss, no duplicate, > >> controlled/partial data integrity' service. > >> (TCP provides 'in-order, no-loss, no duplicate, full > >> data integrity' service.) > >> > >> Am I correct that the data delivered to the receiving > >> application will be in order and never have duplicates, > >> (albeit with some data missing, and possibly > >> some bits in error for those data fields not covered > >> by the checksum)? > >> > >> For example, if a sender sends DCCP packets 1,2,3,4,5,6, > >> the following are valid deliveries to the receiving app: > >> 1,2,3,4,5,6 > >> 1,3,4,6 > >> 1,6 > >> and the following deliveries may not occur: > >> 2,1,3,4,5,6 > >> 1,2,2,2,3,4,5,6 > >> > >> If my understanding is correct, it would help > >> the RFC intro to explicitly discuss that DCCP service provides > >> in-order and no-duplicates (just like TCP). If > >> my understanding is incorrect, it would help the > >> RFC to have an example or two showing how data > >> is delivered to the receiver out-of-order or > >> in duplicate. > >> > >> > >> Thanks, > >> Paul Amer, Professor > >> Univ of Delaware > >> > >> > >
