Personal tools
You are here: Home → communicationRecord → rfc2188OnStdTrack → Re: Putting ESRO (RFC-2188) on the IETF standards track
Navigation
Log in


Forgot your password?
 

Re: Putting ESRO (RFC-2188) on the IETF standards track

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Putting ESRO (RFC-2188) on the IETF standards track


Vern, 

Based on your response, I am making the final decision of NOT putting
the ESRO spec on Standards Track in the foreseeable future. 

We had chosen not to do that last year and revisiting this issue this
year was primarily a matter of closing the loop on Scott Bradner's
requests and was a way for me to keep my word on a promise that I had
made to Scott Bradner about putting ESRO on the Standards Track later.

This issue is now closed.

If/When we need to publish the next rev. of the ESRO spec. we'll put
it on Informational RFC track and go from there.

In the remainder of this message I clarify a number of points that you
may have missed.


>>>>> On Wed, 04 Nov 1998 00:25:57 PST, Vern Paxson <vern@ee.lbl.gov> said:

  Vern> Mohsen,
  Vern> I have attempted to review RFC 2188 but find it very difficult to read.
  Vern> This is because it is not written using standard Internet terminology.

There is no such thing as "standard Internet terminology". 
If there is an RFC that clearly and precisely defines the basic terms for
concepts and basics of data communication, please refer me to that
document.

The absence of such a document has not been a problem so far, because
the Internet is still in the "era of simple protocols".  I suspect
that lack of adequate models, architecture and terminology will become
a problem as we try to take the next steps out of the era of simple
protocols (I have CCed the IAB on this message because of this).

Refering to the traditional language of some RFCs as 
"standard Internet terminology" is extreme. To show you the other side
of that extreme, I would venture to guess that Bob Allisat would have
called the same: "Lingo of The Cult of Jon".

[That was just an example, I have a great deal of respect for Jon Postel]

My point is that there is no such thing as standard Internet terminology.
Refer me to that document and I'll eat my words.

Formality, precision and well defined terminology have never been
strong points of traditional Internet RFCs. This is well known by all
who have been around long enough.

On the other hand, the nearly 15 year old ISO-7498,
  "Open Systems Interconnection - Basic Reference Model"
-- also know as X.200 (red, blue, white, ... books)
is a very formal, precise and complete document that defines 
a very useful terminology  and basis for protocol specification. 

Even-though the ISO/OSI bunch did not produced many successful
protocols, they sure did produce good reference models.  It sure would
be quite stupid not to use any of that good work because of religious
preferences. I don't belong to the ISO/OSI, ITU, ... church, but why
not use their good stuff that is missing elsewhere.


RFC-2188 uses a very formal and precise language which uses the 
formal and precise language of ISO-7498.

It is unfortunate that you are not familiar with the OSI Basic
Reference Model, ISO-7498.

I am quite familiar with both Internet folklore and the OSI
terminology. Below I attempt to bridge the gap for you.

  Vern> I would expect to find most of the following words in the document, but
  Vern> none of them appear:

  Vern>         packet

N-PDU, ESRO-PDU

  Vern>         TCP

RFC-2188, does not use TCP. 

  Vern>         window

The "S" in ESRO stands for "Short". 
ESRO does not need or use "windowing".
If the communication requires "windowing" then ESRO is
not the right thing to use.

  Vern>         checksum

ESRO does not provide any checksum capabilities.
It relies on the lower layers.

  Vern>         fragment

Segmentation and Reassembly.

  Vern>         MTU
  Vern>         discover / discovery

MTU would map to Max-NSDU/NPDU.

ESRO makes the trade-off of not violating layering explicitly.
Such things as ESRO with UDP over GSM and even UDP over TCAP/SS7 were
anticipated in the early usage (realities of present day wireless world).

Now, adding MTU discovery to the next rev. of ESRO (with UDP over IP)
is a good thing.

  Vern>         flow

Flow control is supported, you just need to go through the state
tables. May be should also add more narrative text in the next
rev. and have an explicit flow control section.

  Vern>         congestion
  Vern>         rate
  Vern>         backoff / exponential / double / doubling
  Vern>         overlap
  Vern>         adapt / estimate / estimation
  Vern>         predict

Policies and Algorithms for retransmission timers in ESRO were meant
to be added to the protocol after gaining real world experience with
it. Same way that it happened for TCP. We have done a fair amount of 
work on that already. 

There is nothing in ESRO which precludes use of adaptive timers.

The ESRO 3-Way hand shake state tables are essentially same as the
connection establishment phase of TCP. Therefore some of the
experience of Slow Start, Congestion Avoidance, Fast Retransmit and
Fast Recovery Algorithms from TCP are applicable. However, not all of
the established TCP experience is relevant.

Use of ESRO has so far been mostly in wireless environments where the
network characteristics is generally stable. Even fixed timer
algorithms have provided us adequate results in those environments.

But, because of shortness of interactions, I don't think that anyone
is yet ready to finalize the algorithms. By shortness of interactions
I mean, in many cases by the time you have computed the round-trip
delay, the operation is complete.

The same way that RFC-2001 was published way after TCP was published,
the optimum timer algorithms for ESRO can be published after ESRO is
more widely used. I don't consider this a scalability problem. I refer
to the TCP analogy again. TCP scaled just fine and the likes of RFC 2001
made it scale better.

The key point to remember here is that ESRO at this time is the best
of breed in its class. If you don't agree, please tell me what
protocol is doing the same function in a better way.

  Vern> I am sorry to say that if you want ESRO considered for further progression
  Vern> on the IETF standards track, then the mandatory first step is to rewrite
  Vern> RFC 2188 using standard terminology. 

Again, it is quite unfortunate that you are not familiar with the 
formal terminology of the OSI Reference Model.

I am NOT going to lower the quality of RFC-2188 which uses a very
formal and precise language on top of the formal and precise language
of ISO-7498.


  Vern> This is an essential component of
  Vern> developing a specification that can be used by the Internet community.

That is simply not true.  ESRO is already being used by the Internet
community. There are many in the Internet community who are very
comfortable and familiar with the precise terminology of the OSI-RM
and ESRO. There are many in the Internet community who prefer that
well defined terminology over the folklore.

If your statement was:

  Vern> This is an essential component of
  Vern> developing a specification that can be accepted by the
  Vern> IETF/IESG for a Standards Track document.


I would have said: "fine".

Please, do not confuse the "Internet community" with IETF/IESG.

  Vern> Regarding the earlier words of apparent encouragement for RFC 2188,
  Vern> unfortunately they are rooted in a misunderstanding.  Scott wrote that
  Vern> the former Transport co-AD "feels that this ID represents a significant
  Vern> technical contribution," based on her stating that she felt it should
  Vern> be treated "seriously".  However, I checked with her now and she replied:

  >> I'm surprised that I came off as a proponent of ESRO.  I recall
  >> saying something like this RFC should be treated with seriousness,
  >> by which I meant that it needed just such an IESG note as it
  >> got, rather than to be published airily (meaning to pun).

Scott Bradner (then AD) was ready to put ESRO for Last Call as a 
Proposed Standard in August of 1997. That is not just 
"apparent encouragement for RFC 2188".

At this point I have heard so many conflicting accounts and reports
about the reasons for the mistakes made in the processing of RFC-2188
by the IESG that I can not take much of what you are saying
seriously. You guys really need to sit down and get your stories
straight.

You probably don't understand what I mean.

Because of all of those mistakes, I have prepared a detailed complaint 
against the IESG which I will send out shortly after this message.
Please, go over that carefully if you want to understand what I mean.

[That complaint is about the events of 1/15/97 to 9/10/97 and 
 has nothing to do with this email]

  Vern> As indicated by the terms listed earlier, as far as I can tell (given the
  Vern> different terminology), RFC 2188 does not address issues of congestion
  Vern> control (and even perhaps flow control), nor fundamentals such as MTU
  Vern> discovery, reassembly of out-of-order segments, and adaptive timers.
  Vern> These may all be in RFC 2188 using different terms, but one requirement
  Vern> for considering possibly advancing RFC 2188 is that it first be written
  Vern> in the standard terminology used for discussing IETF protocols.

  Vern> 		Vern

I have responded to all of these before.




Let's move forward.

Regards,

...Mohsen.
Replies
Re: Putting ESRO (RFC-2188) on the IETF standards track, Vern Paxson
Re: Putting ESRO (RFC-2188) on the IETF standards track, Vern Paxson
Main Index | Thread Index
Document Actions