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
- To: Vern Paxson <vern@ee.lbl.gov>
- Subject: Re: Putting ESRO (RFC-2188) on the IETF standards track
- From: Mohsen BANAN <mohsen@neda.com>
- Date: Fri, 6 Nov 1998 14:56:11 -0800 (PST)
- Cc: Scott Bradner <sob@harvard.edu>, iesg@ietf.org, Pean Lim-mit <pean@alum.mit.edu>, RFC Editor <rfc-ed@isi.edu>, records@neda.com, Internet Architecture Board <iab@isi.edu>
- Content-Length: 1715
- Content-Type: text/plain; charset=US-ASCII
- In-Reply-To: <199811062127.NAA28901@daffy.ee.lbl.gov>
- References: <199811062127.NAA28901@daffy.ee.lbl.gov>
>>>>> On Fri, 06 Nov 1998 13:27:12 PST, Vern Paxson <vern@ee.lbl.gov> said: >> 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. Vern> The way it happened with TCP is that the network collapsed. I think we'd Vern> all prefer not to have that happen again. But had it not been for widespread publication of TCP, we would not have had a network at all. Here, we are talking about a brand new topic for the network and a brand new Informational RFC (or entry at lowest level of the Standards Track). Further, the author/editor himself is very sensitive to the problems that you are mentioning. >> 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. Vern> Those algorithms have nothing to do with TCP's 3-way handshake. My last sentence of the paragraph that you quoted from me was: >> However, not all of >> the established TCP experience is relevant. Why did you snip that paragraph? What aspect of the TCP experience do you think is relevant here? Vern> My concern is that the development of ESRO did not incorporate much of Vern> the hard-won experiences of TCP. The fact that the document does not Vern> refer to TCP in any form is inauspicious in this regard. Then, can you please help us make it better. I am not sure if I understand you. What were you expecting? Do you have any specific comments in that regard? ...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
- Prev by Date: Re: Putting ESRO (RFC-2188) on the IETF standards track
- Prev by thread: Re: Putting ESRO (RFC-2188) on the IETF standards track
- Next by thread: Keith Moore is currently unreachable via email
- Index(es):