celp

["Ayyasamy, Senthilkumar \(UMKC-Student\)" <saq66@umkc.edu>]

A new signaling protocol for negotiating the LP seems 
to me like a overhead. Actually, DCCP is exactly 
designed for that purpose ( negotiate cc schemes for 
unreliable transfer, security measures and MA support.) 
So, DCCP is just like celp but includes cc algorithm 
negotiations. I would rather convince DCCP folks to 
include a mechanism for sharing LP state (extend MA 
support for advanced features like sync, granularity, 
fairness problems) than create a brand new signaling 
protocol. 

Also, the draft states something about end point 
congestion management. The last time, I heard about ecm 
is sharing congestion related information between flows 
originated by a single interface (not even a single 
host.) The existing work on ecm like CM, ensemble TCP 
and TCP control block interdependence has its own 
limitations(refer RFC 2140.)


The MA support at transport level is not an architectural
problem rather a cc related problem. It has effect on
retransmission and other things( please check out UD folks 
research on difficulties in doing simultaneous transfer.)
As we expect network level solutions to not have negative
impact on aggregation and RT size, it is necessary that 
transport solutions should show its effect on cc 
algorithms (particularly RFC 2914.)

anyway, both SCTP and DCCP supports MA. TCP needs a
better MA support than the options approach. So, if we 
just fix the TCP issue, i don't see any need for new 
signaling protocol. Even if so, I can piggyback on DCCP
or MIDCOM or NSIS or HIP.