Use of ECN bit in WRED

[sarahr202]

Hi everybody,

I am reading about ECN and WRED. I  have a question as illustrated below:

Host1 (TCP)-------Router-s2/0---------HOST2( TCP)

Assume both TCP hosts  support ECN and mach class DSCP 47,  router is configured with :

Class map DSCP 47

match dscp 47

policy map DSCP 47

class DSCP 47

    random detect dscp 47 20 40 4

     random-detect ecn

Int s2/0

service-policy output DSCP 47

Assume queue depth is between 20-40, and router has determined this particular packet  p1 needs to dropped or its ECN bit need to be set.

My question is how does router determine whether to set ECN bit or drop the packet? In order to mark ECN bit, doesn't router need to snoop on TCP session when it first forms to determine if hosts supports ECN, and have to remember that information for the duration of the session ?

Thanks and have a nice weekend.

[willwetherman · Accepted solution]

Hi,

From my understanding WRED will set ECN only if the sender/receiver is ECN capable. WRED determines this by inspecting the two least significant bits in the DiffServ field in the IPv4 header. If a sender/receiver is ECN capable then it will set either of the two least significant bits to 1 (01 or 10) in all packets transmitted for a particular session.

If the minimum queue threshold is reached, and WRED determines that the sender/receiver is ECN capable, WRED sets ECN by setting the two least significant bits to 1 (11) which indicates congestion encountered.

If both least significant bits are set to 0 then WRED determines that the sender/receiver is not ECN capable and will randomly drop the packet instead.

WRED goes into full drop when the queue is full regardless if the sender/receiver is ECN capable or not.

Hope this helps

[willwetherman · Accepted solution]

I forgot to add that WRED also doesn’t inspect the TCP 3 way handshake to determine if a particular TCP session is ECN capable or not, but instead relies upon the TCP sender/receiver to mark the Diffserv bits in the IP packets (as explained in my previous response) that are carrying the TCP ECN capable session.

Hope this help

s