FWD: Re: Experimental RFC to be: draft-stoica-diffserv-dps-01.txt

[Thomas Narten <narten@us.ibm.com>]

This did not make it to the IESG (forwarded with permission).

------- Forwarded Message

From: Bob Braden <braden@ISI.EDU>
To: istoica@EECS.Berkeley.EDU
Cc: narten@us.ibm.com, braden@ISI.EDU, rfc-editor@rfc-editor.org
Date: Fri, 14 Feb 2003 22:01:26 GMT
Subject: Re: Experimental RFC to be: draft-stoica-diffserv-dps-01.txt


  *> 
  *> The main issue here is that it is practically impossible for us to 
  *> convince you that our approach won't create serious problems in 
  *> the Internet if misused. There is no formal model of the Internet
  *> so we cannot formally prove that our approach is safe. This is 
  *> unfortunate because we recognize that ultimately the burden of 
  *> proof is on us.
  *> 
  *> Given all of these, we will reconsider the use of ip_off.
  *> 
  *> Ion
  *> 

Ion,

The issue you need to clearly focus on is the following: what was your
purpose in writing your document?   Are you trying to initiate action
to making DPS real, moving it towards adoption as an accepted Internet
mechanism?  There are several components of the actions that would
be needed to reach such an objective.

A document (RFC) represents one component.  Another component is more
(applied) research: building and testing realistics network prototypes
of DSP and making prototype code available, say for Unix systems, so
people can play with it themselves.  A third component is someone to
spend the time necessary to shepherd the work through the IETF
process.  Which parts of this are you proposing to do?

Perhaps you intent was only to drop DPS into the IETF, perhaps persuade
a few people that it is a really good idea, and then go back to other
research.   If so, your document at least needs to be more persuasive,
and less prescriptive.  I understand that DPS is a possible solution to
QoS without per-flow state in routers, but I don't think your document
made that point very clearly.  The in-your-face mathematics is OK
only if you give enough motivation, IMHO.

Your document would be more effective if it took a different tone.  You
should take Thomas' comments to heart; here is an experienced and
knowledgable expert in Internet protocols.  He is ready to listen, but
he has legitimate concerns about the implications of your document.
There are lots more like him.  Your document need to address the
concerns about encoding the DPS info.  I suggest that you survey the
possible approaches to this and honestly (to the best of your ability,
and considering Thomas' comments) assess the downsides (as well as the
upsides) of each.

In a practical sense, if the IETF were to move in the DPS direction, an
IETF WG would want/need to engineer a suitable choice; don't pre-judge
the outcome or invest in any particular choice.  You don't care, as
long as DPS is implemented somehow.

I would like to suggest another possible encoding technique: a layer
3.5 header, BTW.

The RFC Editor could publish your document over IESG objections,
with an IESG note, but considering the above it does not seem to
me to anyone's best interest to do that.  I therefore think you
need to revise your document, along the lines I have suggested,
before further consideration.  I hope you will do so, because
I do think that there is potential in this work.  I expect that
potential will take quite a long time to be realized, but I
would hope that we can put together a useful RFC in the near
future.

Bob Braden
(speaking with multiple hats on...)






------- End of Forwarded Message