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

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

Okay.

> 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".

Oops, yes, that's a much better way of phrasing it, thanks.

> 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.

The way it happened with TCP is that the network collapsed.  I think we'd
all prefer not to have that happen again.

> 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.

Those algorithms have nothing to do with TCP's 3-way handshake.

My concern is that the development of ESRO did not incorporate much of
the hard-won experiences of TCP.  The fact that the document does not
refer to TCP in any form is inauspicious in this regard.

		Vern
Main Index | Thread Index
Document Actions