[e2e] ECN & PMTU

Marcel Waldvogel marcel at news.m.wanda.ch
Wed Apr 10 01:04:42 PDT 2002


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





More information about the end2end-interest mailing list