[dcp] flow window

[Alkis Evlogimenos <alkis@ftannei.com>]

Hi all,

I am an undergraduate student in UC Berkeley and currently working (along with 
3 other students) on a user space implementation of the DCCP protocol.

We believe that adding a flow window option to the DCCP protocol will be very 
beneficial in at least 3 areas: case of slow receiver, detection of valid 
sequence numbers and the requirement for acknowledgements of acknowledgemens 
and ack vector implementation. More specifically:

a) The case of slow receiver: since the sender will know the available window 
on the receiving side it will never overload the receiver with excess 
traffic. Without a flow window the protocol will simply send packets until 
the receiver drops one. At that point the congestion mechanism will kick in 
and slow down the sender, but at that point the receiver is already 
overloaded. It is also worth noting that a change in the rate of the sender 
must take at least one RTT from the time of the drop and this latency may be 
unacceptable in some situations.

b) valid sequence number: with a flow window it is easy to choose between 
valid and invalid sequence numbers. Everything inside is valid, otherwise 
invalid. This is currently an unsolved issue with the current specification.

c) acks of acks: With a flow window there is no need for acks of acks. Here 
are possible two issues with acks of acks:
i) Hard to keep track of what to send back in the ack vector. The receiver 
must keep state of what sender sequence number it acked with which packet, in 
order to be able to clear the state correctly. Even with that information at 
hand there are still some corner cases to take care of (section 7.8.3 in the 
draft). 
ii) If the link is severely asymmetricm the ack of acks requirement may cause 
throughput problems (with asymmetric I mean every asymmetry possible - 
asymmetry in bandwidth, rtt, loss percentage).
The proposal here is to require that ack vector is acknowledging a flow window 
worth of packets each time. This will guarantee a reliable transmition of all 
acks and also alleviate the need for acks of acks. It will also make the ack 
vector implementation much simpler.

Comments/ideas?

Thanks,

Alkis Evlogimenos
UC Berkeley

_______________________________________________
dcp mailing list
dcp@ietf.org
https://www1.ietf.org/mailman/listinfo/dcp