Subject: RE: [Tsvwg] Not proceeding with U-SCTP

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 20 Sep 2001 05:26:53 -0700

Hi Qiaobing,

Would you be able to clarify the intention of this email for me.

Is this a statement from the authors of the existing U-SCTP draft that they
are withdrawing the proposal? 
Or, is this a statement from the WG that U-SCTP is, for the time being, no
longer being considered?
Or, is this a statement from the WG that it has been decided that U-SCTP
will not be accepted by the Working Group.

On a question of IETF procedure (and I'm not trying to be facetious here
Qiaobing), are these type of working group decisions normally made on the
mailing list or are decided by the area chairs/directors?

Regards,

Robert.

> -----Original Message-----
> From: Qiaobing Xie [mailto:[email-masked]]
> Sent: Monday, September 10, 2001 11:15 PM
> To: TSV WG list
> Subject: [Tsvwg] Not proceeding with U-SCTP
> 
> 
> Hi, all,
> 
> This is to communicate with you our intention of withdrawing the "SCTP
> Unreliable Data Mode Extension" proposal 
> <draft-ietf-tsvwg-usctp-00.txt>
> from TSVWG. 
> 
> There are concerns raised that this proposed extension may bring
> inconsistency to IETF's architectural view of the SCTP base 
> protocol and
> that it may be difficult to control the proper use of this 
> extension. It
> is felt that the architectural inconsistency and the potential risk of
> this extension being misused outweigh the technical benefits 
> it brings.
> 
> The following are some specific points talked about among the 
> authors, a
> number of other transport folks, and the ADs:
> 
> 1. Feedback from AAA and IPS, among others, is that SCTP application 
>    services are already fairly hard for application designers to 
>    understand, and that interoperability and mis-application problems 
>    can arise when a transport services is too complex (this is not 
>    the same as whether the transport protocol is complex to 
>    implement).
> 
> 2. Introduction of the U-SCTP services would add a major new
>    set of behaviors to SCTP, which already has protean services in 
>    that stream numbers, stream reading choices, 
>    flow control limits, and data ordering or non-ordering
>    are all or will soon be at the application designer's command.
> 
> 3. It is already a complicating factor that application 
> designers must 
>    not use out-of-order streams with TLS.
> 
> 4. SCTP can be seen as having as its defining character the multiple 
>    streams and ability to avoid HOL blocking that TCP has in loss.
>    (Its use of multiple address endpoints is another large
>    defining characteristic and is another reason that SCTP 
>    application design is complex).
> 
> 5. SCTP is the same as TCP in its congestion control algorithms
>    and we believe it should also be the same in its reliability -
>    all data gets from sender to receiver.  Receiving application 
>    should use the stream and out-of-order features to deal more 
>    flexibly than TCP could with data that arrives too late and 
>    is not desired.
> 
> 6. "Canceling a piece of data that has been sent but not-ACK'ed" is 
>    brand new, and the sending end has no clear understanding 
> of whether
>    the data arrived at the other end. We have no experience 
> with how to 
>    use such a feature in application development. Yes, we've heard 
>    the desire for such a feature, but no experience how well 
>    applications can actually make use of it (without adding another 
>    couple rounds of handshaking to sync up).
> 
> 7. Another transport protocol that uncouples from TCP's reliability
>    algorithms (while providing congestion control) is desired, but
>    many applications that would not care about reliable delivery
>    also cannot use TCP congestion control algorithms, but need 
>    something like TFRC. So the U-SCTP design would make a further 
>    complexity by offering only part of what is really needed for 
>    multimedia, e.g.
> 
>    Directions:
>    - A WG development of something like DCP?
>    - A more comprehensive extension of ECM?
> 
> Regards,
> -Qiaobing
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg
> 

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 20 Sep 2001 16:30:58 -0500

Hi, Robert,

See my answers below...

> are withdrawing the proposal?

Procedurally, yes.

> will not be accepted by the Working Group.

I think the answer should be "no" to the above two questions. My
original email was not intended to be a WG announcement.
 
> mailing list or are decided by the area chairs/directors?

I don't consider my email constitutes a WG decision or announcement. It
should be only read as a request or express of intention of withdrawal
from the draft authors with some reasoning. 

And I agree with you that the finally WG decision should only be made by
our ADs.

regards,
-Qiaobing