[e2e] [Fwd: ECN & PMTU]

[Michael Welzl]

Hi,


On Tue, 2002-04-09 at 08:00, Neil Spring wrote:
> Arun,
> 
> the congenstion control analogue to fragmentation required is
> called source quench.  these emails describe why it is not 
> useful for congestion control.

I agree that Source Quench is not a good idea in general. 
But, to quote from:

> 
> ftp://ftp.ee.lbl.gov/email/sf.97nov20.txt

"I would agree that there are special cases, mainly high-bandwidth flows
over very-long-delay satellite links, where there might be significant
benefit to shortening the feedback loop (as would be done with Source
Quench)."

I agree to that as well. Therefore, I wouldn't say it is "not useful".
It's just not the best congestion notification in the "normal case".


Here's a proposal:

At first, I misread the original posting and thought that Arun
considered using the Congestion Experienced bit in an IP packet
which carries an ICMP "MTU Exceeded" message. Apparently, that's
not what he meant - but why couldn't we do this?

If PMTU Discovery is initiated by the transport layer (this
possibility is mentioned in RFC1191), it might receive an early
congestion signal during the startup phase. That couldn't hurt,
could it?

Of course, this would require special implementation in the
stack ... we would need to "give" this to TCP without disturbing the
RTT estimation. Probably not worth the effort...

Regards,
Michael



> ftp://ftp.ee.lbl.gov/email/sf.98may7.txt
> 
> you may also find that this question has been asked before
> on this mailing list (and probably on all the other ones
> you sent this message to.)
> 
> http://www.postel.org/pipermail/end2end-interest/2001-February/000113.html
> 
> -neil
> 
> 
> On Tue, Apr 09, 2002 at 11:09:57AM +0530, Arun Prasad wrote:
> > 
> > 
> > --
> > ****************************************************************
> > V.Arun Prasad
> > HCL Technologies Ltd.
> > 51, Jawaharlal Nehru Road,
> > Ekkattuthangal,
> > Guindy Industrial Estate,
> > Chennai - 600097.
> > 
> > Contact # : 9144 - 2334174
> >             9144 - 2334181
> >             extn : 233
> > ****************************************************************
> > 
> 
> > Date: Tue, 09 Apr 2002 10:09:47 +0530
> > From: Arun Prasad <arun at netlab.hcltech.com>
> > Subject: ECN & PMTU
> > To: tsvwg <tsvwg at ietf.org>
> > Cc: tcp-impl at grc.nasa.gov, sctp <sctpimp at netlab.hcltech.com>
> > X-Mailer: Mozilla 4.72 [en] (WinNT; U)
> > 
> > Hi all,
> >     Some doubts on the procedure followed for PMTU (Path mtu) discovery and
> > ECN method.....
> >     The doubt is not related to the procedure as such, but the relation between the
> > two procedures stated above......
> > Tcp and Sctp uses ICMP message to handle the PMTU discovery procedure....
> > ie., the intermediate router will send an ICMP messge of "Message too Long"
> > to the end point sending the data packet of size greater than the MTU size of some
> > intermediate path to the destination.....
> > 
> > For ECN, the intermediate router should set the appropriate bits in the IP header
> > (if it supports ECN ....) whenever there is congestion and risk of packet drops
> > is high....... The endpoints then correct their Congestion window accordingly and
> > help in reducing the Congestion in the intermediate router.....
> > 
> > Why, we adopt two different methods to carry out similar (in the sense, both are
> > related to the Intermediate routers....)?????
> >     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....)
> > 
> >     What we can achieve by this is the simplicity  in the router implementation,
> > which doesnt need to do different procedure for different features of the Transport
> > layer..... and by maintaining this uniformity, the future extentions which demands a
> > similar requirement can use the same way......
> > 
> > I could have missed some points....
> > 
> > Any comments on this????
> > 
> > 
> > Thanks
> > -arun
> > --
> > ****************************************************************
> > V.Arun Prasad
> > HCL Technologies Ltd.
> > 51, Jawaharlal Nehru Road,
> > Ekkattuthangal,
> > Guindy Industrial Estate,
> > Chennai - 600097.
> > 
> > Contact # : 9144 - 2334174
> >             9144 - 2334181
> >             extn : 233
> > ****************************************************************
> > 
>