Subject: Re: new internet-draft has been submitted

From: Caitlin Bestler <[email-masked]>
Date: Thu, 27 Feb 2003 18:08:23 -0600

On 2/27/03, Katsuyoshi IIDA wrote:

>Hmm.. I don't think so. First, we are mainly focusing on
>heterogeneous wireless network, which means mobile
>computer has a number of wireless and different
>interfaces. In other words, we are trying to come up with
>seemless handovers in transport level using SCTP.  In our
>scenario, mobile computer needs to maintain error counter,
>cwnd and some other parameters for each wireless
>interface. But, in some situations, the current
>implementations cannot provide this because the parameters
>are prepared for each DESTINATION address.
>
>Moreover, yes, I know, the current implementations can
>solve the SPOF. But I don't think it is smart enough.
>According to our knowledge of the current solutions, when
>the host detects some faults on a source interface, it is
>going to change the next available source interface using
>the round robin algorithm. From our point of view, that is
>very ad-hoc. There is a possibility that the source
>interface may be selected many times, and it may be
>detected failures in the past... I think this is because
>endpoint don't have histories of unreachability of source
>interface you chosen.

The issue you are focusing on is worthy of attention, but I
think you are approaching it incorrectly.

The problem worthy of attention deals with how to optimize
source interface / address selection under special
networking situations. Specifically, in a wireless network
transient errors related to a specific *local* path are
predictable (indeed that is why there are multiple paths).

But that is one corner of the network. The nature of the
cloud is unchanged, and the nature of the destination
network is unchanged.

I suggest you review prior discussions on why congestion is
calculated based upon the destination address rather than on
a presumed "path". The issues are unchanged.

In particular knowing a "path" through the "cloud" is
hopeless. The cloud is unknown and subject to change without
notice. That is why PMTU discovery is a *process*, not an
attribute of the path object.

I believe an SCTP implementation can optimize for its end
being wireless interfaces and still be RFC2960 compliant.

Wireless networks are generally shared media that lack any
carrier sense capability. Basically, any given transmitter
has no way to know that it is colliding with another
concurrent transmitter.

Most solve this by time-slicing. A certain number of slots
are available via blind contention. These are used to
request permission to send an upstream message. The others
are assigned by a L1/L2 network controller.

The key is that the L1/L2 communications required to grant
permission to transmit will fully diagnose transmit
problems. If L2 permission to transmit can be achieved,
the IP datagram sent will generally be as reliable as with
a wired network (Especially when combined with Forward Error
Correction).

Additionally, wireless networks frequently employ forward
error correction downstream as well. This, and other signal
data, can provide a receiver with an early warning that a
given downstream path is becoming unreliable. Signal/Noise
ratios fall, the number of error corrections required rises.

In terms of transmission, this additional information can be
used when selecting a source address/interface.

The question is then whether it makes sense for a wireless
receiver to detect that one of its addresses is "going
down", and to notify its peer to switch the primary address
that is being used to reach it.

I haven't done an exhaustive analysis on this topic, but my
hunch is that this in not worthwhile. It is true that "early
warning" is a capability not usually found in wire networks,
and therefore ignored. But the time lags of correcting the
problem at the other end of the association strike me as
self-defeating. Correcting it at the local end where "the
Internet" is connected to the wireless network would make
more sense to me. An ARP-like function can be used to simply
route downstream IP datagrams to a new frequency or
transmitter.

Do you have an analysis of problem unique to wireless
networks that shows why it should be solved at the IP level
on an end-to-end basis? My initial reaction is that the SCTP
stack and the wired-to-wireless Router can solve these
problems using L1/L2 information.

Caitlin Bestler
http://asomi.com/CaitlinBestler/

---

From: "Seok Joo Koh" <[email-masked]>
Date: Fri, 28 Feb 2003 10:24:21 +0900

In this IETF meeting, Trigtran BOF will be open.

http://www.ietf.org/ietf/03mar/trigtran.txt

In my guess, its scope or issue seems to be also related to the SCTP
multi-homing behaviors.

Who can let me know some relationship or interactions between trigtran and
SCTP ?

Best Regards

Seok Joo Koh
[email-masked]
http://ectp.etri.re.kr/~sjkoh

---

From: Katsuyoshi IIDA <[email-masked]>
Date: Fri, 28 Feb 2003 10:27:47 +0900

Caitlin, thank you for your insightful comments.

On Thu, 27 Feb 2003 18:08:23 -0600

> a presumed "path". The issues are unchanged.

Thank you for your good suggestions. I will try to read the
discussions.  (Actually, we had finished to read the SCTP book written
by Randall R. Stewart and Qiaobing Xie in half year ago. I don't
remember the details, so I will read again when I return my home
country. I am now in business trip..)

> attribute of the path object.

Yes, I understand you want to say. But, our assumption is that the
most nearest link to the endpoints are the most critical links. How do
we recover the packet fault on such link? is our question. Again, I
will try to read the prior discussions to get full understanding.

> problems using L1/L2 information.

No, we don't have it yet. Actually, this work is a part of two
master's thesis under my supervision. In the defense presentation,
some thesis advisors asked the same question. Why don't you use the L1
and L2 information. Yes, we would like to do that. But, the current
work is just a first step. We will enhance our work.

By the way, we have some primary simulation results, where the link
characteristic (including packet loss, delay, and bandwidth) is
changing in time. But the characteristic changing are not followed by
wireless characteristic but just artificial setting. Moreover, the
document is written in Japanese. Since we are now preparing to submit
an international conference quite soon, I will give you the document
when we finish it.

Thanks again for your insightful comments. Since we would like to
contribute something in this community, we will refer to your
advises.
--
Katsuyoshi IIDA <[email-masked]>