Subject: [Tsvwg] Not proceeding with U-SCTP

From: Qiaobing Xie <[email-masked]>
Date: Mon, 10 Sep 2001 17:14:44 -0500

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

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Thu, 13 Sep 2001 15:29:33 -0400

>Unreliable Data Mode Extension" proposal <draft-ietf-tsvwg-usctp-00.txt>

Q (and Scott and Allison),

I strongly believe that this would be a mistake - and I will outline my
objections (via in line comments below).

But - before I defend my objection - I'd like to acknowledge some of
the reasons why I SUPPORT DCP's DEVELOPMENT GOALS and
believe BOTH protocols should continue in their respective development.

It is clear that today's UDP applications that convey real-time media
with end-to-end delay constraints (e.g., VoIP) should have congestion
control. Although the prediction of Internet collapse via a
disproportionate amount of inelastic traffic (e.g., non-congestion
controlled UDP) has not occurred, I believe that having a
*RELATIVELY SIMPLE* UDP w/ congestion control protocol
is a prudent and required protection for IP networks in general.
Its development is perhaps overdue. Many of these application
developers (e.g., VoIP on non-mobile endpoints) do not need
all the flexibility of U-SCTP; and need not be "tempted to use"
some of the features of U-SCTP (such as limited retries and
multi-homing). Simplicity of use and lowering the probability
of "mis-application" of U-SCTP presents a strong case for
the development of another UDP-like protocol (e.g., DCP).

That being said - there are a variety of very important applications
that require both the semi-persistence of U-SCTP (i.e., a limited
number of transmission retries) and the multi-homing capabilities
of U-SCTP (w/ add-IP extension).

The simplistic comments that U-SCTP is architecturally impure
simply because it is not a "reliable" protocol ignores the cases
where TCP's "reliability" fails. When this happens - the application
typically "re-tries" TCP. U-SCTP attempts to handle this situation
in a variety of application environments in a way that actually
increases the probability of uninterrupted application layer
connectivity. And without the re-introduction of stale useless
information into a (perhaps) overloaded network. There are
*MANY SUCH APPLICATION ENVIRONMENTS* that can
use U-SCTP and I will address a few of these with my in-line
comments below.

Comments on my comments are welcome,

Michael Ramalho

>    the same as whether the transport protocol is complex to

This is an argument for developing DCP (for non-persistent
transport) - not for killing U-SCTP. More below.

>    are all or will soon be at the application designer's command.

This is true. But MANY applications:
1) require more than DCP provides (e.g., multihoming),
2) the data becomes stale after a finite amount of time (e.g., many
forms of context transfer, database update, or incremental state
blob update) and the "infinite persistence" of TCP
is actually a detriment (more on this below).

There are MANY APPLICATIONS that fall into this category - and
these application can typically can specify the usefulness of stale
information (and thus can specify the amount of time or the number
of times to re-transmit). In the case of delta-updates via U-SCTP,
once the data become "too-stale" ... the fallback is usually a
more lengthy update to re-synchronize the database or context.

Storage networks, context transfer and many forms of
routing/dial plan update applications have these characteristics.

>    flexibly than TCP could with data that arrives too late and

If the data is stale ... SCTP would still transmit it ... wasting
Internet bandwidth. Recall that a major benefit of DCP is to
flow control (unreliable) application streams and allows
packets to be dropped (i.e., NOT SENT).

Using the argument that you can use these SCTP features
to deal with "stale data" ignores the fact that you have
actually sent it! DCP "drops data" and flow controls the
stream" (the correct behavior for an overloaded network).
U-SCTP tries a few times (as per application direction) with
flow control. SCTP with flow control STILL (eventually)
SENDS THE DATA.

Are you really suggesting that the eventual sending of
stale, useless information (as SCTP would) to an overloaded
network (even if you are flow controlling your stream) is a
worthy goal? Entropy is not for free ... if you do this ... you
will unnecessarily delay information behind the stale
data (assuming your link is, in fact, congested and you
always have stuff to send).

>    the data arrived at the other end.

This is always the case for UDP. Thus ALF.

This is sometimes the case for TCP (at the protocol stack level)
when the links breaks! Until TCP times out ... the application
really *does not know* if the data made it.

So the application needs to take case of the case where
TCP IS UNRELIABLE. TCP IS NOT AN INFINITE PERSISTENCE
PROTOCOL (despite it being called a "reliable protocol").

In this sense ... TCP is really SCTP (with only one ordered
stream) with a really high number of re-tries ... the number of
which is a function of many variables (in essence comes
down to how many retries you can do in a fixed amount
of time given your link speed and network/window condition).

I completely disagree the inference that one has not had
to understand the dynamics of this case. Application
developers *must understand and appreciate* the
persistence properties of TCP for the case of link failure.
Any database update application sure needs to know
about it!

What to do about this case (i.e., try to open another TCP
connection) is entirely dependent on the application
programmer. Likewise with SCTP. And likewise for U-SCTP.

>We have no experience with how to
>    use such a feature in application development.

Not true ... as per my previous comment. The ("smart")
applications developers already need to take the case
into account. Only an academic would think otherwise.

(OK a low blow .... but I do desire Allison and Scott to comment :-).

>Yes, we've heard

This is worth the effort for the applications that need it.

>    complexity by offering only part of what is really needed for

Q .. Your email was cut off here ... what was your example?

Build DCP. Don't even temp DCP applications to use the
degrees of freedom being built into U-SCTP.

But don't stop U-SCTP development. Please. The Seamoby
WG definitely needs it.

I'd ask that Scott and Allison carefully consider these
comments.

>    - A more comprehensive extension of ECM?

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 13 Sep 2001 12:51:49 -0700

All,

I understand the reluctance at pursuing U-SCTP but I think that even
applications that do not need reliability are able to take advantage of the
stream feature offered by SCTP.  I would hate to see a back-step taken as a
result of considering streams too demanding to consider a new single stream
protocol as a better alternative.  If it needs a different protocol to
protect SCTP proper, then perhaps that would offer enough separation to
isolate any problems.

Doug

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 13 Sep 2001 14:07:21 -0700 (PDT)

> protect SCTP proper, then perhaps that would offer enough separation to

If reliability is not needed, then an app can easily provide the stream
capability.  The main benefit of stream in SCTP is to prevent head of
line blocking.  But without reliability, this is not an issue.  Or is 
your concern about other things?

							K. Poon.
							[email-masked]

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 13 Sep 2001 16:22:19 -0500

"Michael A. Ramalho" wrote:
...snip...
> Q .. Your email was cut off here ... what was your example?

H, Michael:

Nothing was cut off here. The "e.g." here refers to the two example
directions listed below. Sorry for the confusion in wording. 

...
> >    - A more comprehensive extension of ECM?

In summary, you comments seems to have pointed out three useful features
that are available with U-SCTP but missing in DCP: 

 - multi-stream support
 - multi-homing support
 - limited retransmission

regards,
-Qiaobing

---

From: Mark Handley <[email-masked]>
Date: Thu, 13 Sep 2001 14:30:40 -0700

>that are available with U-SCTP but missing in DCP: 

We intended DCP to be a minimal building block on which other things
are layered.  Limited retransmission and multi-stream support easily
layer on top of an unreliable protocol like DCP, so we don't think
they should be part of DCP itself.

However, multi-homing support cannot trivially be layered on top,
short of starting a new connection and handing over at the
application-layer.  We've been discussing whether it would be
desirable to add multi-homing and/or mobility support to DCP, but
haven't reached any real conclusion either way yet.  We'd welcome
feedback on this issue.

Cheers,
	Mark

---

From: Jacob Heitz <[email-masked]>
Date: Thu, 13 Sep 2001 14:59:02 -0700

Kacheong Poon wrote:
> 
> The main benefit of stream in SCTP is to prevent head of
> line blocking.

No, it isn't. It is to cause a single congestion window to
be shared among all the streams. If each stream had its
own association, there would also be no head of line blocking.

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 13 Sep 2001 14:21:09 -0700

> your concern about other things?

There is a fair amount of effort to provide any interface, and likely any
application will have a need to deliver more than one such stream.  By being
able to use structures developed for SCTP, the inertia and standardization
in this endeavor can help with this similar protocol that offers a lower
reliability criteria.  This effort being identified substantially by means
of a protocol number seems to offer protection for alternative stacks that
are otherwise unadulterated.  Head of queue blocking is but one aspect that
multiple streams provide.  View the API as being more significant.

Doug

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 13 Sep 2001 15:17:52 -0700 (PDT)

> multiple streams provide.  View the API as being more significant.

I guess this again shows the different protocol design principles among
people.  Some people believe that if protocol support is not really
necessary for a mechanism to work, it should not be put into the protocol.
It can easily be abstracted into a library built on top of the protocol.
And there are some other people who believe that protocol should provide 
the maximum number of mechanisms for most, if not all, of the potential
protocol users.  It is just as easy to add any mechanisms to a protocol,
so why not do it.

So what do people think?  Should we create catch-all and for-all protocols 
or design protocols with specific need and purpose so that they are simpler?

							K. Poon.
							[email-masked]

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 13 Sep 2001 18:42:05 -0400

> that are available with U-SCTP but missing in DCP: 

Another one is in-order delivery.  It's a great simplification to the
ULP to be able to assume in-order even with unreliability.

Just like the other features, in-order could be built on top of DCP,
but is that the plan?  I personally don't care much whether its DCP +
intermediate protocol, or U-SCTP, but it should be only.  U-SCTP is a
fairly bounded proposal.  It seems like making DCP fill the same shoes
will require some additional sketching.  Perhaps y'all could hum a few
more bars of the DCP song so we can hear where you're going.

Or not.

Thanks,
  Steph

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 13 Sep 2001 15:45:38 -0700 (PDT)

> own association, there would also be no head of line blocking.

Well, what Jacob mentioned was the underlying assumption of the
head of line blocking issue in a reliable in-order delivery 
transport  protocol stream...  There is no issue to build a library 
on top of, say DCP, to do the streaming, while sharing the same 
congestion window...  And suppose we have ECM and TCP, all the TCP
connections to the same destination will share the same congestion 
window, and there is no head of line blocking issue.

So to say that the reason of having multiple streams in SCTP is to 
make sure that they all share the same congestion window does not
sound right...  It is not really a benefit...  Anyway, maybe it
is the way to look at a thing in different views...

							K. Poon.
							[email-masked]

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 13 Sep 2001 16:13:38 -0700

> is the way to look at a thing in different views...

You should view these transports as not specific to each and every
application.  A transport provides a means of exchanging information among
disparate applications.  Having a common API and structures is a major key
in getting these applications to operate in a compatible fashion.  Should
multiple streams not always carry information in a continuous fashion, then
there is an advantage in using a common congestion control in terms of both
performance/overhead and latency.  To use more connections for the same
exchange will be to the detriment of other applications and perhaps even the
same application attempting to use the multiple connections.  We could
discuss the normal deployment, but there is much gained by using both the
common structures and API.  Yes, each application could develop their own
structures, tailor their own congestion algorithm, develop a means of
isolating different payloads, or adopt a standard form and live with a few
otherwise unneeded items in some cases.  The standardization is of such high
merit to justify this approach.  Isolate this as a different protocol if
needed, but it would not mean rebuilding the majority of the functions
already available.

Doug

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 13 Sep 2001 16:59:42 -0700 (PDT)

> needed, but it would not mean rebuilding the majority of the functions

What was mentioned above did not necessitate that the support of 
streaming should be in a transport protocol.  What it is about is 
just the API...  Note that an API does not need to be bound to a 
protocol, which is implied by what was mentioned.  There are already 
APIs which can work with multiple protocols, e.g. RPC.  And as a matter
of fact, SCTP protocol spec does not include a real API...  We are 
talking about protocol here, not API issues, right?

							K. Poon.
							[email-masked]

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 13 Sep 2001 17:10:36 -0700

> talking about protocol here, not API issues, right?
You are correct that an API can be applied to any protocol if additional
structures are added to support the components found in the API.  There are
issues of interchange bound by these structures.  Those structures would be
a component of the transport or protocol.  As we move into the realm of
facilitating these transports, making changes to these structures would be a
detriment to this effort.  Constraining both the API and the protocol are
needed for interchange and OS independence.

Doug

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 13 Sep 2001 17:34:30 -0700 (PDT)

> needed for interchange and OS independence.

If I understand what Douglas mentioned above, this just gets back to my
original question about protocol design principles.  Everything should
be put in the protocol so that any API to a protocol can be written easily.
And as a consequence, most protocols should support similar set of
mechanisms such that the API does not need to be changed.  Since this is
not easy, there should probably be a catch-all protocol for this.  Well, as
I mentioned earlier, some people do not think this is a good way.

							K. Poon.
							[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 13 Sep 2001 17:53:59 -0700 (PDT)

> in getting these applications to operate in a compatible fashion.  Should

I don't understand what you are trying to say here.  Different apps can
have different app layer protocols.  Regardless of what the underlying
transport is, two different apps will not operate in a compatible fashion...
They won't talk to each other...

> same application attempting to use the multiple connections.  We could

We are talking about the head of line blocking issue with respect to
stream support.  As I mentioned earlier, this is not an issue if
in-order reliable delivery is not in the picture.  So it can easily
be done in DCP.  There is no need to have multiple DCP connections.
And as many people know about ECM, if deployed, there is only one
common congestion control...

> needed, but it would not mean rebuilding the majority of the functions

Note that I never suggested that each app should have their own
congestion control.  And different apps may want to use different
kinds of congestion congestion.  That' why DCP tries to support
that.

It seems that people are mixing API and protocol together here.
I don't think it is a good idea.  And I don't think IETF is a
good place to talk about standardization on API.  We may talk 
about simple API to protocols, but it should not be a standardization
effort.  Just my $0.02...

							K. Poon.
							[email-masked]

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 13 Sep 2001 18:02:11 -0700

> I mentioned earlier, some people do not think this is a good way.
Kacheong,

For those that wish to create their own unique techniques, UDP already
offers the minimal set.  As transports wish to include congestion control,
SCTP already provides a structure for doing so at the level of the packet
rather than byte as with TCP.  The question you seem to be asking; does SCTP
include too much otherwise.  From my perspective, the answer is no.  SCTP
does provide a clean solution for implementing most common APIs with a
sensible and extensible structure set.  There are many with motivation not
intent at achieving standardization, and so you again are correct.

Doug

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 13 Sep 2001 18:08:44 -0700 (PDT)

> haven't reached any real conclusion either way yet.  We'd welcome

I think we should step back and really think about the multihoming
issue in a transport, not just restricted to SCTP or DCP.  It seems
to me that SCTP is the first step we try to have multihoming support
in a transport protocol.  Please correct me if I am wrong about this.

But as Joe Touch mentioned in a previous thread, is it necessary to
have support in transport for multihoming to work?  What is meant by
"work?"  And if it is, what is the necessary mechanism?  And what 
kind of multihoming support should a transport has?  We learn from SCTP
that it is not an easy issue and have many problems.  Can people throw
in their ideas on this issue?  Some people already think that since 
transport cannot control routing or know too much about routing, 
supporting redundant paths or load balancing is difficult, if not 
impossbile, in a general setting (it works in an engineered network).
What do people think about this?  Does a transport need some support 
from IP to do this kind of things?

I think it is an interesting issue, definitely more interesting than
talking about API or adding new features (-:  If people know about
research done in this area, please post it to the list.

							K. Poon.
							[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 13 Sep 2001 18:25:13 -0700 (PDT)

> intent at achieving standardization, and so you again are correct.

I guess Douglas misunderstood what I said.  We learn from experience
that congestion control is crucial in today's Internet.  That's why
we want to have it in all new transports.  At least it seems to me
that this is what tsvwg is trying to do.  And that's why people
proposed ECM.  But the issue we are discussing here is if we should 
keep on adding features to a protocol, even if those features may not 
be in agreement with the original design of the protocol.  The latest 
example is ULP framing in TCP.  I believe Douglas is strongly opposing 
the idea.  And at this point, I think we are still not too clear about
multihoming issues, which is the fundamental block in SCTP, should we
add more things before we understand SCTP better?

And it is not that some people do not intend to have a common API.
The question is if it is appropriate?  And the second question is
if we should talk about it here at all.  Maybe the ADs can make it 
clear, should tsvwg be involved in standardizing API?  I think
we should not.  Maybe I am wrong.

							K. Poon.
							[email-masked]

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 13 Sep 2001 19:06:04 -0700

Kacheong,

If you wish to call SCTP complete, you can do so while also opening up new
extensions still based on SCTP structures and algorithms but using a
different protocol number.  This still allows the same APIs and structures
to be used although reliability features once conceived for use with SCTP
can still be offered in an experimental version.  I would far prefer seeing
this happen than reinventing flow control, payload identification, etc. and
this would go a long way to ensuring there is convergence on these issues.
I can not understand your point about APIs as there is on going efforts to
define SCTP in terms of both API and structures.  This API effort offers a
great deal of benefit in the area of OS independence where it has taken
years for other standards that have ignored this area to resolve OS issues.
Exclusion of the API from the standards will require modification of both
TCP and SCTP.  The little mentioned allows for these APIs to vary
considerably but I would not conclude that the API is extrinsic to these
standards.

Doug

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 13 Sep 2001 20:15:09 -0700 (PDT)

> this would go a long way to ensuring there is convergence on these issues.

I believe what is mentioned above is just one way of doing things.  Let's
suppose that we can define different functional areas of a transport and
create new protocols based on these components, we are not reinventing
anything.  As a matter of fact, assuming all apps want all features of SCTP
is not correct.  There are apps just do not want some features in SCTP or 
the way SCTP implements it (flow control being the one mentioned most
often).  Forcing them to use SCTP is very inefficient.  Or in this case, 
you can have SCTP do negotiation and checks everywhere in the protocol and
code to accomodate different needs.  IMHO, this is simply a bad idea.  As I
said, different people think in different ways.  Hey, IETF works by rough
consensus...

> considerably but I would not conclude that the API is extrinsic to these

I am not aware of any effort in standardizing an API for SCTP at IETF.
The tsvwg effort I am aware of is a proposal to extend the socket interface
for SCTP use.  It is informational and there is no conformance test at all.
It is definitely not a standardization effort.  As I said before, I think
tsvwg is not the place to standardize APIs.  I believe this is the way
IETF works.  The ADs can correct me if I am wrong in this.

							K. Poon.
							[email-masked]

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 14 Sep 2001 00:21:25 -0700

Kacheong,

> anything.  As a matter of fact, assuming all apps want all features of
> SCTP is not correct.  There are apps just do not want some features in
> SCTP or the way SCTP implements it (flow control being the one mentioned
> most often).  Forcing them to use SCTP is very inefficient.  Or in this
> case, you can have SCTP do negotiation and checks everywhere in the
> protocol and code to accomodate different needs.  IMHO, this is simply a
> bad idea.  As I said, different people think in different ways.  Hey, IETF
> works by rough consensus...

I disagree.  I was suggesting a means of allowing modifications to the SCTP
protocol to allow alteration of the reliability mode, as example, without
impacting SCTP proper through use of a different protocol number.  I do not
think there is great advantage adding different congestion algorithms
however.  SCTP structures do not represent inefficient use of the network
whereas adopting these structures offers an efficiency for facilitation and
standardization for interchange and ULP APIs.

> > I can not understand your point about APIs as there is on going
> > efforts to define SCTP in terms of both API and structures.  This API
> > effort offers a great deal of benefit in the area of OS independence
> > where it has taken years for other standards that have ignored this
> > area to resolve OS issues.  Exclusion of the API from the standards
> > will require modification of both TCP and SCTP.  The little mentioned
> > allows for these APIs to vary considerably but I would not conclude
> > that the API is extrinsic to these standards.
>
> The tsvwg effort I am aware of is a proposal to extend the socket
> interface for SCTP use.  It is informational and there is no conformance
> test at all.

There are components in both TCP and SCTP specifications that includes
aspects of how an API is to function.  These definitions are in extremely
general terms but are definitely aspects of an API and not how the protocol
functions with respect to the serial medium.  Page 53, 55, 63, 65, 69, 71,
72, 78, 79, 80, 83, 92, 99, and more explicitly in section 10 page 101-114
of SCTP is an example of API definitions.  I am fully aware of work to
provide detailed socket interface definitions in an informational document,
but that does not detract from the relationship an API has with respect to
either TCP or SCTP.  The major effort to standardize this API into specific
details is no small task which must conform to the more general definitions
found within the specifications proper.  Unless you wish to see such
information struck from these standards, then your statements about such
work is not correct.

Doug

---

From: Randall Stewart <[email-masked]>
Date: Fri, 14 Sep 2001 07:36:51 -0500

Kacheong Poon wrote:

A comment or two..

> add more things before we understand SCTP better?

I must take exception to your statement of "original design". We
did in fact have a feature very similar to the U-SCTP proposal
all the way up until the last version draft 13 it was a method
to cancel a data chunk. It was removed because the way we put
it in was that you started sending the data chunk with a 0 length
on retransmissions. Erik Nordmark pointed out that this would cause
a horrible conflict with the socket API which 0 length reads have
a specific meaning to... and one could not escape a 0 length read
since some apps might need to see the SSN was sent with no
data. We removed it at this point for lack of a better idea.

So the intent was always there in the protocol to have data that
would be "old" and not wanting to send it and skipping it.
If you think about ISUP call signalling at a certian point if
the DATA cannot be delivered (say a IAM message) it makes no
sense to keep on attempting to deliver it long after the
call is dropped due to switch timers.
 
The U-SCTP proposal just codified this proposal into something 
much better than the original design. 

You can read all of this in the email archives if your willing
to rummage through them all :>

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 14 Sep 2001 15:01:48 -0700 (PDT)

> standardization for interchange and ULP APIs.

Well, it is fine that you disagree with my opinion that what you proposed
is not a good idea (-:  But it is a fact that some people do want to
have different congestion control algorithms and other people do not think
some mechanisms in SCTP are suitable for some purposes.  I am just stating
the fact.  Please check the archive if you don't believe.  It is fine that
you disagree with those people.  As I said, IETF works by rough consensus. 
If most people agree with your proposal, it is fine.  If most people think
that your proposal is not a good idea, please refrain from repeating the 
same point.  I think this is the way it works at IETF...

> information struck from these standards, then your statements about such

I guess I'll leave it to the ADs to decide what are the appropriate things
to discuss here at tsvwg.  But one minor point I want to make is that
there are already discussions about removing the capability of sending
to specific streams in the socket extension draft.  And this feature
is clearly written down in RFC 2960.  As you can see, people do not confine
themselves to the "psuedo" API written in a spec.  Here at IETF, people
believe in working code.  If it is not a good idea, get rid of it.  Just
this simple.  Please correct me if this is not the way IETF works.

							K. Poon.
							[email-masked]

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 14 Sep 2001 23:14:40 -0700

Kacheong,

> same point.  I think this is the way it works at IETF...

Sorry about repeating my position, but you repeatedly misrepresented it.
Those wishing to introduce a new congestion algorithm have a greater burden
than just working code.  If everyone had the same opinion, there would be no
need for discussion.

> this simple.  Please correct me if this is not the way IETF works.

Odd, but now you seem to imply such API discussion is normal fair.

Doug

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Sat, 15 Sep 2001 07:33:48 -0500

Kacheong Poon <[email-masked]> writes:
...
> this simple.  Please correct me if this is not the way IETF works.

Could you please elaborate on "there are already discussions about
removing the capability of sending to specific streams in the socket
extension draft."?

As a coauthor I really should be current on such a discussion.  There
are three possible interpretations of your statement that I can think
of:

1) We do not plan to support a single stream on its own socket.

2) We plan to eliminate the ability to specify a default stream so
that you HAVE to use sendmsg() instead of sendto() or write().

3) We plan to eliminate the sid field from the ancillary data, thus
completely removing the capability from the end user.

We reached consensus on item 1 a very long time ago.  Item 3 would be
very bizarre.  Item 2 would be a strong limitation, and would break
TCP compatability.

Is there some other interpretation I should know about?

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 17 Sep 2001 09:36:00 +0200

Dear Kacheong, dear all,

Does this mean that (using a socketapi which is 'compliant' to the
socket api draft) a user can NOT make use of the streams feature 
of SCTP? In my opinion this is quite a restriction.

Best regards
Michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Sep 2001 00:41:30 -0700

Kacheong Poon wrote:

> issue in a transport, not just restricted to SCTP or DCP....
> 
> have support in transport for multihoming to work? ...

> research done in this area, please post it to the list.

I have examined multihoming in two separate designs:

     Multihoming to support production use of an experimental LAN,
     i.e., two NICs in a host, where one is preferred but unreliable:
     Dynamic Host Routing for Production Use of Developmental Networks
     J. Touch and T. Faber, Proc. ICNP '97, Atlanta, Oct. 1997,
     pp. 285-292.
     http://www.isi.edu/touch/pubs/icnp97/icnp97.ps

    Multihoming to support connection to multiple virtual networks.
    Dynamic Internet Overlay Deployment and Management Using the X-Bone,"
    J. Touch, Computer Networks, July 2001, pp. 117-135.]
    http://www.elsevier.nl/gej%2Dng/10/15/22/61/27/26/article.pdf

In both cases the key to the solution is to recognize that a multihomed 
host looks like box INSIDE of which is a virtual host attached to a 
multihomed virtual router. Applications 'attach' to the virtual host; 
dynamic routing happens in the virtual router.

In the first case, where the multiple NICs are used as primary/backup, 
all applications attach to the same virtual host interface. In the 
second case, there are multiple virtual host interfaces which determine 
which virtual network is being used.

Both cases support dynamic routing. Neither case modifies transport, 
network, or routing protocols (although the latter case has a 
modification to IPsec which is described in 
draft-touch-ipsec-vpn-01.txt, which is currently being revised for the 
IPSEC WG)

Joe

---

From: Andreas Jungmaier <[email-masked]>
Date: Mon, 17 Sep 2001 13:44:46 +0200

Dear all, dear Kacheong,

> have support in transport for multihoming to work?  

No of course not, as TCP shows. But it is sure a necessary feature
if you need to rely on redundant network configurations.

BTW, SCTP also support Single-Homing :-)

> What is meant by "work?"  

Work means get data reliably from A to B, I suppose. Or from A1 to
B2, A2 to B1, A3 to B4, A4 to B3 and so on....

> We learn from SCTP that it is not an easy issue and have many problems.  
> Can people throw in their ideas on this issue?  

I think people have been throwing in their ideas for years. What is
your point ???

> research done in this area, please post it to the list.

We, among others, are trying to work on that. I suspect that you will
find more results soon...

Best regards,
Andreas

- -- 

- ------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier              |                         _
Computer Networking Technology Group      | ASCII ribbon campaign  ( )
University of Essen                       |  - against HTML email   X
http://www.exp-math.uni-essen.de/~ajung   |              & vcards  / \

---

From: Andreas Jungmaier <[email-masked]>
Date: Mon, 17 Sep 2001 14:00:07 +0200

Dear Kacheong, dear all,

On Saturday, 15. September 2001 00:01, Kacheong Poon wrote:
> to specific streams in the socket extension draft.  
> And this feature is clearly written down in RFC 2960.  As you can see, 
> people do not confine themselves to the "psuedo" API written in a spec.  
> Here at IETF, people believe in working code.  If it is not a good idea, 
> get rid of it.  Just this simple.  Please correct me if this is not the 
> way IETF works.

If I understand the way WE at the IETF work, then discussions like 
removing a very important feature from the basic OS specific API
description (as draft for an Informational RFC) should take place
in an open fashion. 

With all due respect I would strongly subject to removing this feature
from the draft. I have not seen anywhere dissussions thereof. Could
you please provide pointers to this discussion.
We (that is our group) currently try to produce working code that implements 
the socket API on top of our library implementation. 
We want to (and do) use streams.

Best regards, 

Andreas

- --

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Sep 2001 09:09:07 -0700

Andreas Jungmaier wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dear all, dear Kacheong,
> 
> 

Multihoming is required, but need not require modifications ot the 
transport protocol. The solutions we've documented, using virtual 
interfaces, allow switchover during a connection without effect on 
either the transport protocol or the application.

Joe

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 17 Sep 2001 12:34:33 -0500

> removing the capability of sending to specific streams in the socket

I guess what K meant to say was "discussions about removing the
capability of sending to a specific peer address," i.e., the ability
                                  ^^^^^^^^^^^^
for the user application to override the current primary destionation
address.

Am I right, Kacheong?

-Qiaobing

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 17 Sep 2001 12:44:57 -0700 (PDT)

> capability of sending to a specific peer address," i.e., the ability

Yup, Qiaobing was right...  That's what we were discussing on the list.
I somehow mistyped the whole thing )-:

							K. Poon.
							[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 17 Sep 2001 13:02:54 -0700 (PDT)

> Odd, but now you seem to imply such API discussion is normal fair.

Well, what I was always saying, and Douglas repeatedly failed to understand,
was about standardization on APIs in IETF...  I guess I should stop talking
about this issue...  I may once again make some stupid mistakes and everybody
will be confused (-:

							K. Poon.
							[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 17 Sep 2001 14:55:23 -0700 (PDT)

> if you need to rely on redundant network configurations.

I guess from now on, I should be more careful in sending mails to
the list...  The second sentence above was the intended question
I wanted to ask.  And I believe some people do not agree with what
Andreas said above.

> B2, A2 to B1, A3 to B4, A4 to B3 and so on....

To me, some people think that "work" means that there are really
redundant paths between two endpoints.  But as many people have raised
this question, is it possible for a transport to know about this?  So
that's why I asked the question.  Is it the main intention of using
multihoming to have completely redundant paths?  Is there other
benefits, say as provided in the current SCTP multihoming?

And a very simple clarification on the word "reliably" above should
be good.  To a lot of people, TCP already provides reliabiliy.  But
to other people, that's not the reliability they want.  So it seems
to me that it is better to actually state the intended "level" of 
reliability when people talk about it.  Well, I just make up the
"level" description.  I don't know if there is already a well accepted
word for that.  If there is, please let me know.

> I think people have been throwing in their ideas for years. What is

Good point (-:  My point is to ask people about their opinions.  There
are recent discussions on this mailing about issues such as congestion
control in multihoming in SCTP.  At least to me, there are issues which
people have not clearly stated before.  Maybe I am ignorant about the
years of effort.  But if there is, please share with the list.  Please
post the research papers/project reports on the list.  I think a lot
of people will be glad to know about them, I will (-:

							K. Poon.
							[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Mon, 17 Sep 2001 16:42:28 -0500

Andreas/All:

Being the first instigator of the sockets draft I was
quite shocked to see Kacheongs post... No one else that is
a co-author has proposed this or talked about this offline.
And we do get in to spirited off-line debate :>

The current next pass draft that I have in CVS STILL has
this feature and the BSD-KAME stack implementation that
we are working on will use it has currently written.

Unless Kacheong can convince all of the other authors (which
I doubt) don't count on this feature disappearing...

R

Andreas Jungmaier wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.5 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE7peXHd2Uw+xBvGUIRAqfFAKCRHoqbXYpUWhC1ALWp474alQ1EowCeLPXi
> Bl37oeuoFSISE36XKBarYeE=
> =cjGc
> -----END PGP SIGNATURE-----
>

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 17 Sep 2001 23:47:09 -0700

Kacheong,

I agree that detailed APIs are not the focus of the IETF and that a socket
interface is but one of many possible solutions.  The "pseudo" API, as you
describe it, is still important from the perspective of allowing application
design.  Defining the quintessence of this API information is germane to
IETF standardization and the tsvwg within the process of producing SCTP
related documents.  Creating the "perfect" transport and API for each and
every application is balanced against a proliferation of incremental
divergence.  Justifications for developing other transports is likely
quelled with minor adjustments to SCTP.  Time will tell.  At the risk of
repeating myself, I felt experimental modifications of SCTP could be
assigned a different protocol number to allow reuse of the associated APIs
and functions currently supporting SCTP.  You are correct, I have yet to
understand what I have said in error with respect to this suggested reuse
advantage.  If the "working code" shows problems, no harm done.

Doug

> Well, what I was always saying, and Douglas repeatedly failed to
> understand, was about standardization on APIs in IETF...  I guess
> I should stop talking about this issue...  I may once again make
> some stupid mistakes and everybody will be confused (-:
>
> 							K. Poon.
> 							[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Sep 2001 22:46:06 -0700

>    http://www.elsevier.nl/gej%2Dng/10/15/22/61/27/26/article.pdf

FYI, the preprint version of this paper (HTML and PDF) has now been 
posted at:

	http://www.isi.edu/touch/pubs/comnet2001/

The final version, however, is available only from Elsevier. I have a 
limited number of extra wood-pulp copies, which I can send to anyone who 
emails me their snail-mail address.

Joe

---

From: Andreas Jungmaier <[email-masked]>
Date: Tue, 18 Sep 2001 14:00:43 +0200

Dear Kacheong, dear all,

please see my comment below...

> of people will be glad to know about them, I will (-:

Well for one, we have looked at one special multihoming scenario, and
proposed a modification of the way the addresses are chosen where the
SACKs are echoed back, for better protocol performance. Which you can 
find at :
	A. Jungmaier, E.P Rathgeb, M. Schopp, M. Tüxen :
"SCTP - A multi-link end-to-end protocol for IP-based networks" ,
 AEÜ - International Journal of Electronics and Communications, 
 55 (2001) No.1, pp. 46-54 

You can download the paper from the link below:
http://tdrwww.exp-math.uni-essen.de/pages/forschung/sctp-aeu.pdf

Best regards,
Andreas

- --