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