Re: [Tsvwg] Re: ECN & PMTU
mbashyam <mbashyam@cisco.com> Wed, 10 April 2002 05:53 UTC
Message-ID: <3CB3D33B.D10D0E82@cisco.com>
Date: Tue, 09 Apr 2002 22:53:00 -0700
From: mbashyam <mbashyam@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Arun Prasad <arun@netlab.hcltech.com>
Cc: Srivathsa <sriva@lucent.com>, tsvwg <tsvwg@ietf.org>,
tcp-impl@grc.nasa.gov, e2e <end2end-interest@postel.org>,
sctp <sctpimp@netlab.hcltech.com>
Subject: Re: [Tsvwg] Re: ECN & PMTU
References: <3CADF78E.D9E24D26@cisco.com> <3CB20DBE.3B687309@cisco.com> <3CB27092.7680BC16@netlab.hcltech.com> <3CB3585A.7E7C670C@lucent.com> <3CB3BE57.2655E29C@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: 3439
Lines: 80
Arun Prasad wrote: > Srivathsa wrote: > > > > 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. > > > > Ya, I agree that...... But the method by which PMTU discovery is done > can be changed to avoid packet drops (if dropping a packet is costly... I think > yes, because it triggers Retransmissions....). We might rethink about implementing PMTU > discovery like the ECN like mechanism, with this new proposal..... The idea is > > there should be someother bit like the DF bit, say IF bit (Inform on Fragmentation) in the > IP header..... This IF bit will be set by the Transport layers if it is planning to do the PMTU > discovery..... The router upon receiving a packet of size greater than the MTU size of the > Egress interface and the IF bit is set in the IP header... then IP layer there will go ahead > fragmenting the packet and sending it to the destination..., but also send an ICMP > "Message too Long" message to the Sender..... The router also sets the DF bit, and > unsets the IF bit in the IP header of the fragment packets (which ensure no more > fragmentation is done on the packet....) ..................The sender upon receiving the ICMP > packet will just update his PMTU... Thus there is no Packet drops... so the procedure of > PMTU discovery will not trigger any Retransmissions.... (which is expensive, because > the transport layer shrinks the Congestion window if it senses that a packe is dropped...) I dont understand, PMTU discovery requires that TCP go into a retransmission of all its unacknowledged packets if there is a change in MSS. Also in ur scheme by forwarding the fragments with DF bit on won't u be triggering drops in a downstream router with a smaller next hop MTU than the just announced PMTU ? Murali > > > Not sure whether this is already discussed or proposed etc... > > Thanks > -arun > > > > > -Srivathsa > > -- > **************************************************************** > V.Arun Prasad > HCL Technologies Ltd. > 51, Jawaharlal Nehru Road, > Ekkattuthangal, > Guindy Industrial Estate, > Chennai - 600097. > > Contact # : 9144 - 2334174 > 9144 - 2334181 > extn : 233 > **************************************************************** > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg
- 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