Re: [Tsvwg] ECN & PMTU

[Arun Prasad <[e-mail]>]

hi jacob,


Jacob Heitz wrote:

> 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.
>

    thats slightly harsh.....

>
> 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.
>

    Ya, I got the point.... The above point really justifies the reason of not
selecting Source Quenching for ECN..... ( That may be obvious, but I missed
it....).. Thanks for this...

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


Thanks
-arun

>
> 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]

--
****************************************************************
V.Arun Prasad
HCL Technologies Ltd.
51, Jawaharlal Nehru Road,
Ekkattuthangal,
Guindy Industrial Estate,
Chennai - 600097.

Contact # : 9144 - 2334174
            9144 - 2334181
            extn : 233
****************************************************************