Re: ECN & PMTU
Srivathsa <sriva@lucent.com> Tue, 09 April 2002 21:08 UTC
Message-ID: <3CB3585A.7E7C670C@lucent.com>
Date: Tue, 09 Apr 2002 17:08:42 -0400
From: Srivathsa <sriva@lucent.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Arun Prasad <arun@netlab.hcltech.com>
Cc: tsvwg <tsvwg@ietf.org>, tcp-impl@grc.nasa.gov,
sctp <sctpimp@netlab.hcltech.com>
Subject: Re: ECN & PMTU
References: <3CADF78E.D9E24D26@cisco.com> <3CB20DBE.3B687309@cisco.com> <3CB27092.7680BC16@netlab.hcltech.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: 2675
Lines: 54
Arun Prasad wrote: > > Hi all, > Some doubts on the procedure followed for PMTU (Path mtu) discovery and > ECN method..... > The doubt is not related to the procedure as such, but the relation between the > two procedures stated above...... > Tcp and Sctp uses ICMP message to handle the PMTU discovery procedure.... > ie., the intermediate router will send an ICMP messge of "Message too Long" > to the end point sending the data packet of size greater than the MTU size of some > intermediate path to the destination..... > > For ECN, the intermediate router should set the appropriate bits in the IP header > (if it supports ECN ....) whenever there is congestion and risk of packet drops > is high....... The endpoints then correct their Congestion window accordingly and > help in reducing the Congestion in the intermediate router..... > > Why, we adopt two different methods to carry out similar (in the sense, both are > related to the Intermediate routers....)????? Arun, I dont really see how the 2 situations are similar. In the PMTU case, the network is in normal state. In the ECN case, there is a congestion at the router. The router cant afford to pump more packets into the network. In the earlier internet, the source quench mechanism was used to combat congestion (i.e router sends an ICMP to the source). In a quick evolution, routers started using a packet-drop mechanism to combat congestion (It didnt make sense to pump more packets into a congested network). Now, ECN is being recommended to combat congestion VERY EARLY. i.e PMTU-like-mechanism cant be used for ECN. > Why cant we generalise this stuff.... ie., the need here is some way to > communicate between the intermediate router and the endpoint.... Not sure > which of the two ways is advantageous, but cant we use the same method for > both..... ie., > As for the PMTU discovery, the intermediate router can send an ICMP message > to the endpoint carrying a message "CONGESTION", by receiving this the > endpoint will do all appropriate actions as it does when it receives the packet set > with ECN-ECHO flag (as in present ECN procedure...) > > or vice versa ( ie., adopt the method followed by ECN for PMTU discovery aslo, > that might be slighly tough, considering the Backward compatibility....) > You cant use a ECN-like-mechanism for PMTU discovery. As soon as an intermediate router discovers that the packet (with DontFragment bit set ) is too large for one of its outbound interfaces, it will have to discard the packet. I.e it cant relay the packet to the destination. In ECN scenario, packet can still be relayed further. -Srivathsa
- 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