Re: Last Call for draft-ietf-rolc-apr-00.txt

Juha Heinanen <jh@lohi.dat.tele.fi> Thu, 26 October 1995 16:51 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16690; 26 Oct 95 12:51 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa16686; 26 Oct 95 12:51 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id MAA25422; Thu, 26 Oct 1995 12:23:55 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id MAA11135 for rolc-out; Thu, 26 Oct 1995 12:34:43 -0400
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id MAA11126 for <rolc@nexen.com>; Thu, 26 Oct 1995 12:34:41 -0400
Received: from lohi.dat.tele.fi (lohi.dat.tele.fi [193.167.64.161]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id MAA25414 for <rolc@nexen.com>; Thu, 26 Oct 1995 12:23:13 -0400
Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id SAA03317; Thu, 26 Oct 1995 18:26:34 +0200
Date: Thu, 26 Oct 1995 18:26:34 +0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Juha Heinanen <jh@lohi.dat.tele.fi>
Message-Id: <199510261626.SAA03317@lohi.dat.tele.fi>
To: curtis@ans.net
CC: curtis@ans.net, rolc@nexen.com
In-reply-to: <199510261620.MAA23016@brookfield.ans.net> (curtis@ans.net)
Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/ As I understand it, no assumption is made about how the traffic is actually treated. RSVP simply communicates traffic characterizations and requirements. What implementation do with that will vary. Best effort usually carries no reservation, as it is the default. What the router does to accomodate best effort traffic is outside of the scope of int-serv or rsvp. Of course some treatments will provide better service than others in terms of fairness, goodput, delay, etc.

   Perhaps you mean elastic traffic rather than best effort?

yes, i forgot that "elastic" was the closest rsvp term to "best effort".

so you say that rsvp doesn't have any notion of fairness built in the
service model.  if that is so, then it would make sense for the a to be
able to specify that he wants his elastic application to use a direct
abr vc instead of a path through rsvp routers, since he is sure that the
former provides isolation, but has no idea what might happen in the
latter case, where one udp video stream could screw up everything he
tried to do.  i consider this a big minus in the rsvp service model.
may be something can be done to fix it?

-- juha