Subject: Re: [tcpm] ECN for SYN/ACK draft

From: Ted Faber <[email-masked]>
Date: Fri, 13 Jan 2006 10:01:23 -0800

On Thu, Dec 08, 2005 at 02:39:17PM -0800, Ted Faber wrote:
> On Tue, Nov 29, 2005 at 11:40:11AM -0800, Ted Faber wrote:
> > 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
> [snip]
> > 
> > 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?
> 
> I realize that this is December and people have end-of-year holidays and
> end-of-semester chores taking their time, but Mark and I need some
> indication that this is a useful thing for us to do or it will go back
> to TSVWG.

OK, one more time.  It's no longer December.  This is a draft that TSVWG
originally took on, but is right in the TCPMi area.  The TSVWG and TCPM
chairs agree this is the right group to do this work, but that doesn't
matter if no one's interested in the work here.  I understand that
people from this group already hummed in TSVWG, but we need a show of
interest to take it on here in TCPM.  Please:

	* If you hummed in TSVWG and think it's good to do the work
	  here, send a note.  (Or if you don't think so, send that
	  note).  This needn't be a long message.
	
	* Please read the draft and let us know what you think, whether
	  you've read it or not.  Obviously we'd be delighted to see the
	  longer discussion.

If the deafening silence continues, we'll have to send the draft back to
TSVWG and our case for doing new work here will get muddier.  Even if
you think TCPM is a dumb place to do such work, please make that an
actual statement rather than somethign we have to guess from a dead
silence.

Thanks!

-- 
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: Mark Allman <[email-masked]>
Date: Fri, 13 Jan 2006 13:13:28 -0500

[speaking as an individual contributer]

I read through this I-D a week or so ago (along with the SIGCOMM paper
From which the idea came).  I think the general idea that ECT should be
allowed on the SYN+ACK is a good idea.  So, my opinion is that this
document should be a WG item.

(I am not sold on a host's response when a SYN+ACK is CE-ed by the
network that is currently given in the I-D.  I have iterated a little
with the authors about this and I may have more to say about this aspect
of the I-D in the future.  But, part of the WG process is in engineering
the scheme and so this sort of complaint has no bearing on whether I
think the draft ought to be a WG item.)

[chair hat on]

What Ted said.  More comments, please!

allman

---

From: Janardhan Iyengar <[email-masked]>
Date: Sun, 15 Jan 2006 15:35:44 -0500 (EST)

Ted/all,

> 	  note).  This needn't be a long message.

I somehow missed the last email asking for feedback on whether the draft 
belongs here---I had assumed that the draft was already in this WG. My 
bad, I forgot protocol. I think this work is meaningful as a TCPM WG item.

> 	  you've read it or not.  Obviously we'd be delighted to see the

I have read the draft, and it looks good to me except for one part that 
needs clarification. Section 4, last para:

    "As a final step, [ECN+] explored the co-existence of flows that do
    and don't set the ECN-capable codepoint in TCP SYN/ACK packets.  The
    results in [ECN+] confirmed that both types of flows can coexist;
    flows that apply the change improve their end-to-end performance,
    while the performance degradation for flows that don't apply the
    change, as a result of the flows that do apply the change, is
    marginal."

Is this comparison the one in Figure 10 in the SIGCOMM paper? If so, I'm 
not sure if it would be correct to say that the performance degradation 
for flows that don't apply the change is "marginal". I like "gradual" 
instead, as used in the paper. Maybe "gradually significant". Let me know 
if I'm way off.

Thanks!
jana

--------------------
Janardhan R. Iyengar
http://www.cis.udel.edu/~iyengar
Protocol Engineering Lab, University of Delaware

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 16 Jan 2006 23:37:40 +0200

I'm one who really intended to read the draft and respond to your call
earlier, but never got to it until now... Sorry!

> 	  note).  This needn't be a long message.

I didn't see it a problem to have the draft in tsvwg, because there have
been also other drafts on explicit transport signaling, even when
primarily discussing TCP. But tcpm would be fine for me as well, since
the draft is after all quite specific to TCP, as you said earlier.

> 	  you've read it or not.  Obviously we'd be delighted to see the

To me the proposal seems pretty straightforward and well justified, and
I'd be happy to see this going forward without delays.

This sentence got me puzzled in the last paragraph of Section 2:

   "If the sending node (node B) was going to use an
   initial window of one segment, and receives an ECN-Echo packet
   informing it of a Congestion Experienced indication on its SYN/ACK
   packet, the sending node MAY continue to send with an initial window
   of one segment, without waiting for a retransmit timeout."

I don't have opinion for or against this right now, but having TCP
sender not slow down its sending rate in this particular case got me a
bit alarmed. On the other hand, I realize this is a pretty minor thing,
and one motivation of the draft is to avoid retransmit timeouts for
SYN/ACKs, but maybe the draft could then say that this is not thought to
be a significant concern for the network? (Especially since RFC 3168
argues that it is necessary to slow down the sending rate also when
cwnd==1 and ECN-Echo arrives)

- Pasi

---

From: Ted Faber <[email-masked]>
Date: Wed, 18 Jan 2006 15:51:43 -0800

In light of the generally positive reaction on the list and in private
mail to the chairs and the complete lack of any negative indications,
TCPM will be taking the ECN for SYN/ACK draft on as a working group
item.  It will be included in the upcoming charter update.

Thanks for your input.