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
