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