Re: [dccp] WG Last Call for Problem Statement

[Sally Floyd <floyd at icir.org>]

John -

>> >     We perceive a number of problems related to the use of unreliable
>> >     data flows in the Internet.  The major issues are:
>> >
>> >     o The potential for non-congestion-controlled datagram flows to
>> >       cause congestion collapse of the network.
>> >
>> > What is the likely-hood of this?  Pointers to studies, papers,  
>> > would be appreciated.
>> > What would be a more likely issue is that some links / subnets /  
>> > etc. could become
>> > overloaded with UDP traffic and cause a lot of problems for service  
>> > providers and
>> > network operators.  Think of an ISP deploying a VoIP and having  
>> > their access network
>> > become unmanageable due to too much UDP traffic.
>> 
>> Don't plan to do anything here.
>
>So even though you don't show any justification for the potential of congestion
>collapse of the
>network, you still list it as a problem you want to solve with DCCP?  That 
>seems a bit
>dubious to me.

We could cite Section 5 of RFC 2914, "Congestion Control
Principles", which described the *potential* for congestion collapse:

 "This section discusses congestion collapse from undelivered packets
 in some detail, and shows how unresponsive flows could contribute to
 congestion collapse in the Internet."

I don't know any citations, however, as to the *likelihood* of
congestion collapse, and I don't really think it is necessary in
this document.  However, we could always cite Section 2 of RFC 3714,
"IAB Concerns Regarding Congestion Control for Voice Traffic in the
Internet", for an argument that we need to design protocols to avoid
congestion collapse not only in the well-provisioned networks in
North America and Europe, but in other parts of the Internet as
well that might not be as well-provisioned.

...
[From Eddie:]
>> Added reference to RFC3758.
>> 
>> Can you be more specific please?  What exactly is inaccurate?   
>> There's no need to write text.  Just say what the problem is.
>
>The text says:
>
>    As a second concern, SCTP as currently specified uses TCP-like
>    congestion control, and does not provide support for alternative
>    congestion control algorithms such as TFRC that would be more
>    attractive to some of the applications currently using UDP flows.
>
>and further on says:
>
>    One could suggest adding support for alternative congestion control
>    mechanisms as an option to SCTP, and adding a fully-unreliable
>    variant that does not include the mechanisms for multiple streams.
>
>But PR-SCTP is already standardized, so this text is wrong.  There is
>the issue that SCTP/PR-SCTP cannot currently do congestion control
>negotiation, so I think just saying that is sufficient.
>
>further more, you say:
>
>    However, that path leads one to a choice between a ``kitchen sink''
>    protocol that tries to include options to accommodate all
>    applications (i.e., the modified version of SCTP), and a clean and
>    minimal protocol that provides only end-to-end congestion control
>    and any other mechanisms that cannot be provided in a higher layer.
>    We would argue against the ``kitchen sink'' approach in this case;
>    aside from the higher header overhead, a ``kitchen sink '' protocol
>    seems more likely to have unforseen interactions and difficulties in
>    making modifications down the road.
>
>    Applications that desire limited retransmission with multi-stream
>    support, or that desire multi-homing support, might be good
>    candidates for a semi-reliable version of SCTP such as U-SCTP.
>    However, we believe that variants of SCTP are not suitable for
>    fully-unreliable applications, or for the bulk of applications that
>    today use UDP.  We would argue that instead, an additional transport
>    protocol is needed for unreliable transfer.
>
>However, its a fact that PR-SCTP exists. What you are trying to say is that
>you think a lightweight, unreliable protocol with congestion control 
>negotiation is preferable to (what you see as) a more heavyweight
>protocol like SCTP.  I really think that this section could be collapsed
>down to one or two paragraphs and seem more reasonable.

Sure, we will update the section on SCTP, including saying that PR-SCTP 
is already standardized, citing RFC 3758.  But I would keep the
second paragraph largely as is, documenting that SCTP in fact
does not meet DCCP's goal of a minimal header size.  And I also
think we need to keep the third paragraph, saying that SCTP as
currently specified only uses TCP-like congestion control.
I agree we can get rid of the "kitchen sink" language, however,
which probably isn't necessary...

Thanks for the feedback.

- Sally