Re: [Tsvwg] ECN & PMTU

[Jacob Heitz <[e-mail]>]

First of all, I gave a reason why it is so.
If you think another way is better,
that's nice, but you won't change anything.

Source quenching was always controversial.
It is considered higher impact, because it adds
an extra packet to the network. Setting a CE
bit adds nothing that was not there before anyway,
so is considered to be safer, or lower impact.

Yes, it's slower than having the congested router
send an ICMP.

The end receiver sends an ACK anyway. Let it modify
or withhold that ACK. This is what the receiver can
do. It would send the ACK anyway, thus nothing
extra is added to the network.

But consider these points:

A network is made of different makes/models of routers.
A router may consider itself congested in all
directions at once when it runs low on buffer memory.
Then it may send ICMPs every which way.

If a path is congested at many routers, each may send
an ICMP in the reverse direction, resulting in a
multitude of ICMPs reaching the sender.

When congestion collapse looms, safety first is the
golden rule: add nothing more that was not already
there anyway.

Arun Prasad wrote:
> 
> hi jacob,
> 
> Jacob Heitz wrote:
> 
> > 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.
> 
>          I couldnt get the point of, sending extra packets during congestion.....
> Say if a Router decides that there will be congestion ( its not in congestion now...)
> then it decides to set the ECN bit in the IP header of certain packets in the Queue...
> These packets should reach the receiver endpoint.... then the receiver will
> send a ACK to the sender to indicate there is a congestion..... Doesnt this too
> long a process.... ie., anyway a SACK is to be sent from the Receiver to the
> sender....  In that case why not an ICMP packet from the router to the sender???
> 
> And also, since the extra packets are going to flow in the opposite direction
> of the actual congestion, I couldnt see any harm .... (I know this might be a
> wrong statemnent.... but I dont have the right justification...)
> 
> Atleast in Source Quenching method, the flooding of Data by the Sender can be
> controlled fast than the current ECN method...right!!
> 
> >
> > 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
> 
>         Why at all a receiver bother about the Congetion....  I see no reasons for the
> receiver to know about the congestion in the path.... because he cant do anything
> about that...
> And also by doing this by Source Quenching method.... its not mandatory that
> both the source and destination Transport layers support the ECN capability..
> If only sender is supporting, its more than enough... and there will be no necessity
> to negotiate the support of this feature, end to end....
> Router  also doesnt bother  whether an Endpoint is supporting  ECN or not...
> he can just send an ICMP message to the sender, whether he supports ECN or not...
> (slightly costly operation but thought its ok...)
> 
> Thanks
> -arun
> 
> >
> > correct me if I'm wrong.
> >
> > PMTU discovery does not face this problem. It's ok to send
> > an extra packet back to the sender in this case.
> >
> > 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 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
> > > ****************************************************************
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/tsvwg
> >
> > --
> > // Jacob Heitz. Tel:[phone]
> 
> --
> ****************************************************************
> V.Arun Prasad
> HCL Technologies Ltd.
> 51, Jawaharlal Nehru Road,
> Ekkattuthangal,
> Guindy Industrial Estate,
> Chennai - 600097.
> 
> Contact # : 9144 - 2334174
>             9144 - 2334181
>             extn : 233
> ****************************************************************

-- 
// Jacob Heitz. Tel:[phone]