[ns]: RED treatment to SYN packet from TCP/ECN source

["Guo, Liang" <guol@cs.bu.edu>]

I'm reading tcp.cc/red.cc file and intrigued by the following questions.

Since tcp.cc in ns assumes one-way session, the first packet
will be serving as a SYN packet although in most time it is treated as
the first data packet. Here comes the problem. For ECN capable tcp,
here's the code from output() function:

        if (seqno == 0) {
                if (syn_) {
                        hdr_cmn::access(p)->size() = tcpip_base_hdr_size_;
                }
                if (ecn_) {
                        hf->ecnecho() = 1;
//                      hf->cong_action() = 1;
                        hf->ect() = 0;
			~~~~~~~~~~~~~~~~~~
                }


So the first packet will carry no ECT codepoint. I guess this is following
the specification from draft-ietf-tsvwg-ecn-03.txt which demands
"A host MUST NOT set ECT on data packets unless it has sent at least
   one ECN-setup SYN or ECN-setup SYN-ACK packet, and has received at
   least one ECN-setup SYN or ECN-setup SYN-ACK packet, and has sent no
   non-ECN-setup SYN or non-ECN-setup SYN-ACK packet."


However, at the RED queue, the queue only do ECN (marking instead of
dropping) to packets that carries ECT bit. Here's the code from
red.cc:

       hdr_flags* hf = hdr_flags::access(pickPacketForECN(pkt));
       if (edp_.setbit && hf->ect() && edv_.v_ave < edp_.th_max) {
                         ~~~~~~~~~~~~
                hf->ce() = 1;   // mark Congestion Experienced bit
                return (0);     // no drop
       } else {
                return (1);     // drop
       }


My question is, does this mean that the SYN packet is more likely to
be dropped than the data packet? This is horrible because dropping
SYN packet will cause a 6 seconds timeout even if the RTT is say
0.1 msec. Wouldn't it be nice if RED queue also protects these SYN
packets?

I'm not sure how it is implemented in real network products. 
But at least I've seen different implementation of RED on linux
machines. 

One more thing, why does TCP/ECN allows congestion window
to go below 1 (so if not using double precision, that means
cwnd could be 0)? Any special purpose for this to happen?



Guo, Liang 

guol@cs.bu.edu                     Dept. of Comp. Sci., Boston Univ.,
(617)353-5222 (O)                  111 Cummington St., MCS-217,
(617)375-9206 (H)                  Boston, MA 02215