Re: [Tsvwg] ECN & PMTU

["La Monte Henry Piggy Yarroll" <[e-mail]>]

Jacob's comments are roughly correct.  Bits in the IP header are very
precious so we expend them only for a REALLY good reason, e.g. ECN.

Jacob Heitz <[e-mail]> writes:
> One reason: sending extra packets in the face
> of congestion will worsen the congestion.
> Congestion collapse could be a very serious possible
> consequence of sending extra packets.
> Notice the ECN does not go towards the sender,
> but in the other direction. I think the intention
> is to have the upper layer (transport) in the
> receiver withhold acknowledgements to cause the
> sender to back off. I'm making this up, so please
> correct me if I'm wrong.

You are correct that the transport layer is supposed to handle the
Congestion Experienced (CE) bits in the IP header.  In the case of
both SCTP and TCP the reaction is to include a transport-specific
congestion notification in the next ACK.  This allows the sending side
to back off just like normal congestion detection, but without losing
a packet.

> PMTU discovery does not face this problem. It's ok to send
> an extra packet back to the sender in this case.

I.e. there is no need to spend IP header bits on this function.

> Arun Prasad wrote:
> > 
> > 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 bet
ween 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 d
rops
> > is high....... The endpoints then correct their Congestion window according
ly and
> > help in reducing the Congestion in the intermediate router.....
> > 
> > Why, we adopt two different methods to carry out similar (in the sense, bot
h are
> > related to the Intermediate routers....)?????
> >     Why cant we generalise this stuff.... ie.,  the need here is some way t
o
> > 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 pa
cket set
> > with ECN-ECHO flag (as in present ECN procedure...)
> > 
> > or vice versa ( ie., adopt the method followed by ECN  for PMTU discovery a
slo,
> > that might be slighly tough, considering the Backward compatibility....)
> > 
> >     What we can achieve by this is the simplicity  in the router implementa
tion,
> > which doesnt need to do different procedure for different features of the T
ransport
> > 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
> > ****************************************************************
> > 
> > _______________________________________________
> > tsvwg mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> -- 
> // Jacob Heitz. Tel:[phone]
> 
> _______________________________________________
> tsvwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tsvwg