Subject: [tcpm] ECN for SYN/ACK draft

From: Ted Faber <[email-masked]>
Date: Tue, 29 Nov 2005 11:40:11 -0800

Hi.

As those of you who were at tsvwg in Vancouver know, Sally Floyd has
proposed a draft adding ECN to SYN and SYN/ACK packets, which was not
allowed under the original RFC 3168 ECN spec.  The draft has not yet
popped out, but there are also relatively-permanent local copies at:

 http://www.icir.org/floyd/papers/draft-ietf-tsvwg-ecnsyn-00.txt
 http://www.icir.org/floyd/papers/draft-kuzmanovic-ecn-syn-00.txt

The advantage is that a SYN or SYN/ACK packet becomes eligible for
marking rather than being dropped and incurring a full RTO during set
up.  Details are in the draft, of course.

This was proposed in tsvwg and was accepted as a WG item there, but
eagle-eyed co-chair Mark pointed out that this the draft really
addresses a TCP issue and therefore falls under tcpm's umbrella not
tsvwg's.  When bleary-eyed (closed-eyed?) co-chair Ted was finally
roused from his stupor, he agreed.   After we hashed it out with the
tsvwg co-chairs, the consensus among the various ADs and co-chairs was
that the work should go through tcpm.  Whichever WG it goes through, the
WGLC will happen in both groups.

Given that many of the tcpm folks did see the presentation and were
among those agreeing to adopt this as a tsvwg work item, I'd like to
propose that tcpm adopt it as our work item.  N.B. this is a normal
request for rough consensus to take the item on, so feedback for
adopting it and for not adopting it are both important to see.

If accepted, I'd like to request that we move fairly quickly to get this
reviewed and on the publication path.  I think sending it up to the IESG
for Proposed Standard before Dallas would be reasonable, but you all get
the final say.  If we decide not to accept it, clear reasons need to be
given.

Comments?

Thanks,

Ted & Mark

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Sally Floyd <[email-masked]>
Date: Tue, 29 Nov 2005 12:20:09 -0800

>allowed under the original RFC 3168 ECN spec.  

The draft, based on a SIGCOMM 2005 paper by Aleksandar Kuzmanovic,
proposes allowing the use of ECN for SYN/ACK packets, but *not* for
pure SYN packets.

The draft is out as:
 http://www.ietf.org/internet-drafts/draft-kuzmanovic-ecn-syn-00.txt
but could transition any day to:
 http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecnsyn-00.txt
The only change is in the name.

We would really appreciate a few careful reviews, in the hopes
that this relatively-simple and straightforward proposal
could progress fairly quickly along the path to Proposed Standard.

Many thanks,

- Sally

Abstract:

   This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK
   packets to be ECN-Capable.  For TCP, RFC 3168 only specified setting
   an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK
   packets.  However, because of the high cost to the TCP transfer of
   having a SYN/ACK packet dropped, with the resulting retransmit
   timeout, this document is specifying the use of ECN for the SYN/ACK
   packet itself, when sent in response to a SYN packet with the two ECN
   flags set in the TCP header, indicating a willingness to use ECN.
   Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to
   the TCP connection, avoiding the severe penalty of a retransmit
   timeout for a connection that has not yet started placing a load on
   the network.  The sender of the SYN/ACK packet must respond to an ECN
   mark by reducing its initial congestion window from two, three, or
   four segments to one segment, reducing the subsequent load from that
   connection on the network.

Presentation in November at tsvwg:
  http://www.icir.org/floyd/talks/ECN-SYN-Nov05.pdf
  http://www.icir.org/floyd/talks/ECN-SYN-Nov05.ppt