Re: [Tsvwg] ECN & PMTU
"Eric A. Hall" <ehall@ehsco.com> Tue, 09 April 2002 17:08 UTC
Message-ID: <3CB32023.2739D549@ehsco.com>
Date: Tue, 09 Apr 2002 12:08:52 -0500
From: "Eric A. Hall" <ehall@ehsco.com>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en-US,en
MIME-Version: 1.0
To: Jacob Heitz <jheitz@lucent.com>
Cc: Arun Prasad <arun@netlab.hcltech.com>, tsvwg <tsvwg@ietf.org>,
tcp-impl@grc.nasa.gov, sctp <sctpimp@netlab.hcltech.com>
Subject: Re: [Tsvwg] ECN & PMTU
References: <3CADF78E.D9E24D26@cisco.com> <3CB20DBE.3B687309@cisco.com> <3CB27092.7680BC16@netlab.hcltech.com> <3CB285B4.9E8FBBA4@lucent.com> <3CB2BB02.21AA779C@netlab.hcltech.com> <3CB2C285.FA4806AB@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1451
Lines: 45
[I promise not to get sucked into this again, but a few clarifications are in order.] Jacob Heitz wrote: > Source quenching was always controversial. > It is considered higher impact, because it adds > an extra packet to the network. Setting a CE > bit adds nothing that was not there before anyway, > so is considered to be safer, or lower impact. ...unless you also consider the TCP retransmissions to be expensive. > Yes, it's slower than having the congested router > send an ICMP. > The end receiver sends an ACK anyway. Let it modify > or withhold that ACK. This is what the receiver can > do. It would send the ACK anyway, thus nothing > extra is added to the network. > > But consider these points: > > A network is made of different makes/models of routers. > A router may consider itself congested in all > directions at once when it runs low on buffer memory. > Then it may send ICMPs every which way. Is it going to start dropping packets anyway? > If a path is congested at many routers, each may send > an ICMP in the reverse direction, resulting in a > multitude of ICMPs reaching the sender. Good point. > When congestion collapse looms, safety first is the > golden rule: add nothing more that was not already > there anyway. On half-duplex links, that is a good idea. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
- Unacceptable ACK in SYN_RCVD state handling Murali Bashyam
- Re: Unacceptable ACK in SYN_RCVD state handling(2… Murali Bashyam
- Re: Unacceptable ACK in SYN_RCVD state handling Bob Braden
- Re: Unacceptable ACK in SYN_RCVD state handling Murali Bashyam
- Re: Unacceptable ACK in SYN_RCVD state handling Bob Braden
- Re: Unacceptable ACK in SYN_RCVD state handling Murali Bashyam
- RE: Unacceptable ACK in SYN_RCVD state handling Robin Uyeshiro
- Re: Unacceptable ACK in SYN_RCVD state handling Murali Bashyam
- ECN & PMTU Arun Prasad
- Re: [Tsvwg] ECN & PMTU Jacob Heitz
- Re: [Tsvwg] ECN & PMTU La Monte Henry Piggy Yarroll
- Re: [Tsvwg] ECN & PMTU Arun Prasad
- Re: [Tsvwg] ECN & PMTU Jacob Heitz
- Re: [Tsvwg] ECN & PMTU Arun Prasad
- Re: [Tsvwg] ECN & PMTU Eric A. Hall
- Re: ECN & PMTU Srivathsa
- Re: ECN & PMTU Arun Prasad
- Re: [Tsvwg] Re: ECN & PMTU mbashyam
- Re: [e2e] ECN & PMTU Marcel Waldvogel
- Re: [Tsvwg] ECN & PMTU Kostas Pentikousis