Subject: Re: Bandwidth Brokers

From: Dae Young KIM <[email-masked]>
Date: Thu, 08 Jan 1998 08:51:12 +0900

Sorry for too late a cut-in, but:

Juha Heinanen 작성함:

> one reason why i don't like cl because it allows best effort packets to
> be sent out of order.  also, if i remember correctly, it didn't allow
> queueing of packets, but required them to treated as if the user would
> be alone on the internet.
>
> i must repeat that i'm very worried about the invasion that int-serv is
> trying to make to diff-serv.  we were supposed to be defining very
> simple delay and drop semantics (or corresponding mechanisms) for the ip
> header bits, but now the trend seems to be how to provide int-serv
> services with aggregate flow specs.
>
> i think it would be high time to create the diff-serv working group and
> select a chair that has had nothing to do with the (academic) int-serv
> effort. isp would have needed the diff-serv bits to be defined
> yesterday.
>
> any router vendors willing to go for an experimental rfc with one delay
> bit and one drop preference bit in order to get things moving and
> something deployable for the isps?
>
> -- juha

I'm not a vendor but seriously interested in QoS routers, and am strongly
for spinning off a new working group for Dff-Serv ASAP.

Let's admit that it's as good as you two groups believe in different
religions or ideolgies. Like we believe in having freedom of religion in
daily life, there should be a freedom of technical belief within IETF. What
authority does one have in keeping others pursuing their own idea? Remember
that Int-Serv and RSVP are both given birth to thanks to this freedom of
technical belief; I don't think everyone within the IETF agreed to the birth
of this stuff at the begining especially in regard to the advocates made in
the Int-Serv framework document(now RFC). Why don't you guys give the same,
and fair, opportunity to other believers?

And how can you start talking about mapping Int-Serv to Diff-Serv when
Diff-Serv is not yet clearly (in detail, I mean) defined yet?

I'm getting, along with others I'd assume, sick of this mailing list, losing
patience in reading the same old repeating of the same arguments, due
especially to advocators from IBM and Microsoft. Your products are fine. You
do your way and let others do their own ways.

Let something happen, if anything. Let's submit a petition for a new working
group for Diff-Serv.

--

Dae Young
--------------------
http://ccl.chungnam.ac.kr/~dykim/

---

From: Roch Guerin <[email-masked]>
Date: Thu, 08 Jan 98 13:00:56 -0500

Dear Mr. Young,

After hesitating for a while whether to respond to your note, I feel
compelled to do so to correct what I consider to be  unjustified
statements on your part (I'll overlook the rather offensive nature
of some of them).

You imply that "advocators from IBM and Microsoft" are, by repeating
"the same old arguments," preventing others from "pursuing their own idea",
i.e., diff-serv, and you are insinuating that we are preventing the 
Diff-Serv agenda from getting the "same and fair opportunity" that was 
given to Int-Serv.

I must admit being stunned by how you have managed to reach such conclusions
as well as by the manner in which you have expressed them.  First, none of
the postings that I am aware of have tried in any way to prevent the 
development of the Diff-Serv framework.  To the contrary, I believe that the
postings were to a large extent a validation of the fact that Diff-Serv
addresses important issues (scalability, simplicity, etc.) and will, therefore,
happen.  I certainly believe the latter.  The bulk of the postings that
mentioned RSVP and Int-Serv in relation to Diff-Serv was to point out the
benefits of trying to put some synergy between the two, i.e., avoid 
eventually a "Diff-Serv" vs "RSVP/Int-Serv" situation.  I personally 
think this can be done without impacting the goals of Diff-Serv, and while
allowing inter-operability if and when needed.  

I'm hard pressed to see how such a position can lead to the conclusions you
reached.  We may disagree on the need for such inter-operability, but I
don't see how this can be construed as an effort to deny the Diff-Serv 
effort a fair chance.  I personally think that RSVP/Int-Serv QoS requests, 
for example from hosts as Yoram Bernet mentions in his reply to your note, 
will become important even if they have a cost and complexity associated
with them.  As a result, I think it would be of mutual benefit to Diff-Serv
and RSVP/Int-Serv if they could leverage each other, i.e., benefit from the
scalability and simplicity of Diff-Serv while supporting what is likely to
become an important set of QoS users.  I hardly see this as the kind of
"religious" position that you were referring to.

Regards,

Roch
-----------------------------------------------------------------------------
Date: Thu, 08 Jan 1998 08:51:12 +0900
From: Dae Young KIM <[email-masked]>
To: Juha Heinanen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked]
Subject: Re: Bandwidth Brokers

(Unknown charset: <iso-2022-kr>)

--

Dae Young
--------------------

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 14 Jan 1998 23:08:45 +0900

> "religious" position that you were referring to.

Well, I wouldn't repeat what I have to say in reponse, but for most part, please to
my reply to Mr. Yoram Bernet's mail.

BTW, what I want to add is that a wish for a new separate working group for
diffserv was first expressed by another gentleman, and I just wanted to second the
motion. Or was I wrong again in interpreting the situation?

--

Dae Young
--------------------