[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dccp] WG Last Call for Problem Statement

Hi John,

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.

Well, your point 5) was the same as your point 3), to which the response was a cite to RFC 3714 (the document Sally mentioned also in her response). We could add cites to 3714 throughout the problem statement but it didn't seem that necessary. If you feel differently of course we'll add them, I could care less. I agree with you that this concern could be better justified, but RFC 3714 does as good a job as we're likely to get in an RFC reference any time soon.


7) 3.1.3.  The Evasion of Congestion Control

I'm not entirely convinced by this argument, the growth of p2p protocols and software
seems to indicate that there's enough coders out there who will go and implement
what they want, especially if they want performance. Also, a quick google of "reliable"
and "udp" shows that many folks want the reliability of tcp without its cost (aka
congestion control). I guess this section could be left in the document, but
it doesn't really seem to add much to the problem statement, imo.


Don't plan to change anything here.  The document is qualified enough
as it is.


I'd still say that this seems to be fairly unsubstantiated problem, and little evidence
that DCCP does anything here, but I don't feel strongly enough to argue with you
on this point. 

OK :)


8) Section 3.3.2 should be updated to talk about PR-SCTP: http:// www.ietf.org/rfc/rfc3758.txt
Also, unreliable SCTP references should be updated to "Partially Reliable SCTP." And on
further thought, it might be good to re-write this section, as its fairly inaccurate. i'd
be happy to try to re-write this section, in a fairly neutral, non-biased way, if it would
help.


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.

PR-SCTP certainly contains the mechanisms for multiple streams. PR- SCTP is also, as the name suggests, partially reliable, not "fully unreliable". For me the difference is that in PR-SCTP, the sender must explicitly tell the receiver to jump over a missing sequence number. This is very different from DCCP, where jumping is the default. So I think that, yes, one could suggest adding "a fully- unreliable variant that does not include the mechanisms for multiple streams", and such a protocol would differ substantially from PR-SCTP.


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.

I think the intent of these paragraphs was to say, not that PR-SCTP is a "kitchen-sink" protocol itself, but that PR-SCTP + fully- unreliable + single-stream would be a "kitchen-sink" protocol. But you're right that "kitchen sink" and "clean" are loaded words that say more than we mean.

I've condensed those paragraphs into these two.  What do you think?


Finally, the SCTP Partial Reliability extension
.CITE RFC3758
allows a sender to selectively abandon outstanding messages, which ceases
retransmissions and allows the receiver to deliver any queued messages on
the affected streams. This service model, although well-suited for some
applications, differs from, and provides the application somewhat less
flexibility than, UDP's fully unreliable service.

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. We would argue
against this. SCTP is well-suited for applications that desire limited
retransmission with multi-stream or multi-homing support. Adding support
for fully-unreliable variants, multiple congestion control profiles, and
reduced single-stream headers would risk introducing unforeseen
interactions and make further modifications ever more difficult. We have
chosen instead to implement a minimal protocol, designed for
fully-unreliable datagram service, that provides only end-to-end congestion
control and any other mechanisms that cannot be provided in a higher layer.


Thanks for your comments!
Eddie





John