Re: [e2e] ECN & PMTU
Marcel Waldvogel <marcel@news.m.wanda.ch> Wed, 10 April 2002 08:04 UTC
Message-Id: <3CB3F21A.2060006@news.m.wanda.ch>
Date: Wed, 10 Apr 2002 10:04:42 +0200
From: Marcel Waldvogel <marcel@news.m.wanda.ch>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
X-Accept-Language: de, 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: [e2e] 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; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 2355
Lines: 44
Arun Prasad wrote: > 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 like the idea of an "Inform-on-Fragmentation" bit, as this would get the PMTU right within one RTT *and* not require any retransmits. I do not agree with your DF/IF interaction, instead I propose my own rules (downward compatible, single RTT, no retransmit (exception below)): * IF overrides DF. Any IF-capable router will ignore DF on packets that have IF set. IF is more powerful than DF, but DF will be needed during a transition period. * Routers do not modify the IF/DF bits. When the sender sets IF and DF (probably the common case), there is no need for that. * Routers send back an "ICMP Fragmentation needed," indicating it was due to IF. This is preferably done only on the first fragment (i.e., offset=0). * IF-capable routers that don't want to/can't fully perform fragmentation (e.g., IPv6) shorten the packet into the first fragment. The "Fragmentation needed" message then contains the information that the packet needs to be resent. -Marcel
- 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