Subject: diff-serv for reliability

From: Dae Young KIM <[email-masked]>
Date: Wed, 26 Nov 1997 03:25:30 +0900

As I suggested a while ago, reliability can be a service router can
offer to end host users. See, for example, our newly posted
Internet-Draft

　　　
ftp://www.ietf.org/internet-drafts/draft-lim-ip-reliable-multicast-00.txt

--

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

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 26 Nov 1997 09:32:56 +0000

>ftp://www.ietf.org/internet-drafts/draft-lim-ip-reliable-multicast-00.txt

as i read it, this scheme could be more easily implemented by thinking
in terms of diff-serv for reliability a different way

if congestive loss happens because you overload a net, but you
introduce a premium service so that peopel that pay more see less
congestion, and more throughput, then you don't need to invoke
a reliability mechanism  very often for premium service traffic -
so it may as well be an end2end scheme anyhow.....since the extra
delay incurred will only be incurred extremely rarely and wil
ltherefore be tolerable (and FEC is a better technique if yo uare
REALLY worried about ARQ/retransmit delays, since even a hop-by-hop
recovery mechanism such as you propose incurs some delays...)

another way to look at it is that instead of proposing to _add_
apscific buffereing for a retransmit cache of packets in the router, 
i would _subtract_ buffering from the 2nd class service traffic so
that the first class reliable multicast simply doesnt see loss the
first time around....instead of adding buffering to save it for
possible later retransmit, when it might see congestion again
anyhow....

i.e. multidrop x.25 was not a very nice idea after all? 

 cheers

   jon

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 27 Nov 1997 22:04:47 +0900

Jon Crowcroft wrote:

> sImplicitID6ftp://www.ietf.org/internet-drafts/draft-lim-ip-reliable-multicast-00.txt
>
>
>

According to some original thoughts on diff-serv, the premium delay
service (D=1) is meant for delay-sensitive or quasi-real-time traffic
while the normal delay service (D=0) is for delay-tolerant traffic. For
example, in a conference, one would select the premium-dealy service for
the audio or video, whereas the normal-delay service would be selected
for the white board which should be delivered error-free. For the
premium-delay service, you might get better throughput, in general, and
so less congestion, as you pointed out.    Now, my problem is with the
white board. Instead of wholy relying on a reliable multicast transport
protocol, I'd like to have the multicast routers in the network do any
simple things they can do to effectively improve the multicast
reliability. In this example, the white board packets will be tagged
with (D=0, R=1; R for reliability), and the mechanism I propose would be
turned on in the routers for these packets.

Therefore, the throuput or delay issue is more or less orthogonal to the
reliability issue. This is where I want the proposed mechanism to come
into play.

Put into other words, delay is the end of the service, int-serv or
diff-serv, story, although most of folks in this mailing list seem to
have exclusively confined themselves to it; delay represents only one
axis of the whole QoS story. And reliabily might be the next target we
might want to plant into the routers.

> possible later retransmit, when it might see congestion again

Well, the question might be whether one would get a net gain with this
resource (buffer) reallocation in the routers. The net gain can be seen
when we consider the latency of end-to-end RM protocols compared to
immediate local recovery by the responsible routers if they can. If the
congestion is of a very short duration, say a single packet or two, then
the proposed mechanism will be quite useful; instead of having the
receiving end host to finally decide that a packet must have been
dropped and start the RM recovery, the the dropped packet is quite
immediately recovered just where it was dropped and the end host will be
free from the otherwise necessary transport-RM-based recovery mechanism.

If the congestion is longer, then the buffer router of the proposed
scheme comes into play, and again some net gain can be obtained.

If the congestion last really long, the proposed mechanism will
collapse. But fine, because we never meant to promise full reliability.
Atfer all, the mechanism operates on the unreliable IP platform, and so
full reliability can never be provided by the network. Rather, the
proposed mechanisum would provide us with semi-reliable service with
minimal extra resource in the routers and with resultantly plus net gain
in regard to the end-to-end effective througput; the slower the error
recovery, the smaller the effective throughput.

> i.e. multidrop x.25 was not a very nice idea after all?

The propose mechanism is nothing near CO race. It is not a hop-by-hop
error recovery scheme like X.25. I do believe in IP datagram, and what
we added to it is as small as, or quite smaller than, what other folks
added in favor of diff-serv or int-serv.

--

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

---

From: [email-masked] (Kathleen Nichols)
Date: Thu, 27 Nov 1997 14:34:13 -0800

At 10:04 PM 11/27/97 +0900, Dae Young KIM wrote:
>while the normal delay service (D=0) is for delay-tolerant traffic. 

Although I don't want to jump into the "diff-serv for reliability" fray,
the above brought up something I do want to jump into: the issue of
tying types of traffic to types of differentiated services. I think this
is not a mindset we want to get into. If a customer wishes to use a 
low-delay, peak bw-limited Premium service for a high-quality video
conference, that is one quite reasonable use. On the other hand, if
a customer wishes to use that low-delay, peak bw-limited Premium service
for file transfers or web-browsing as though over a virtual leased line,
those are equally valid, equally well-supported uses. The same customer
could run the same applications as drop priority (what we called Assured)
traffic or as best-effort. I don't believe we should have the uses in
mind when we design basic primitive services. I've heard Dave Clark give
a very nice talk on how IP doesn't care what runs over it and that is
why it's been so successful over time, even as the applications of the
Internet have changed; this seems to be the right model here, too.

	Kathie