Re: [tcpm] Last Call: draft-ietf-tcpm-ecnsyn (Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets) to Experimental RFC

[Sally Floyd <[e-mail]>]

Anil -


On Apr 16, 2009, at 1:26 PM, Agarwal, Anil wrote:

> Here are a few comments and suggestions on draft-ietf-tcpm- 
> ecnsyn-08.txt.

Many thanks, and my apologies for the delay in getting back to you.

We made some of the changes that you suggested, but not others.
The details are below.

In general, we find that it is useful not to expand the scope of
standards documents more than necessary.

- Sally
http://www.icir.org/floyd/




> 1. Figure 1 -
> Should we replace "possibly ECT" by "ECT, since this doc is all  
> about SYN/ACK with ECT?

But in Figure 1, the response when the SYN/ACK packet is dropped
is the same for a SYN/ACk packet *without* ECT as it is for a SYN/ACK
packet *with* ECT.  So we have left it how it is.

> 2. Section 3.2, first para -
> Would be useful to clarify that the responder must not advance the  
> send sequence number, even though it has received an acknowledgement  
> for the SYN.

Done.

> Would be useful to explicitly state that the responder must restart  
> the retransmission timer.

Done.

> What timer value should the responder use - 3 seconds or the  
> measured RTT? I presume it is 3 seconds.

I added the following:

"The responder follows RFC 2988 in setting the RTO (retransmission
timeout)."

Thus, if the responder has a measured RTT, it uses that in setting
the RTO.

> 3. Figures 2 and 3 -
> Perhaps first Data/ACK should be labeled as ACK, since the initiator  
> is not allowed to send data at this point.
> Would be useful to show the subsequent Data segment as carrying ECT.

Thanks, done.

> 4. Figure 2 and last para of section 3.2 -
> Doesn't ECN-setup SYN/ACK packet include CWR bit by definition?

 From RFC 3168, an ECN-setup SYN/ACK packet has the ECE flag set,
but the CWR flag not set.

> The figure and text imply that the second ECN-Setup SYN/ACK packet  
> has the CWR bit set as a result of having received an ECN-echo  
> indication. Does not seem right.

Many thanks, you are right that this is a problem.

We have changed the specification so that the second ECN-Setup
SYN/ACK packet does not have the CWR bit set.  We have also specified
that on receiving the non-ECN-Capable SYN/ACK packet, the TCP
initiator clears the ECN-Echo flag on replying packets.

> 5. Section 3.2, 3rd para -
> Sentence "However, with ECN+/TryOnce the initiator does not advance  
> from the "SYN-Sent" to the "SYN-Received" state ..".
> A bit confusing. Normally, TCP advances to the Established state,  
> not SYN-Received state on reception of a SYN/ACK. Yes, TCP advances  
> to the SYN-Received state on reception of a SYN, but we are not  
> using that example here.

Thanks, we changed it to "Established" state.

> 6. Section 3.2, 3rd para -
> First line "However, with ECN+/TryOnce ..." seems confusing. The  
> previous para (and the rest of the doc) deals with ECN_/TryOnce  
> only, right?

Fixed.

> 7. Section 3.2, 3rd para -
>  "... initiator resets the retransmit timer..." would the word  
> "restarts" instead of "resets"  be more descriptive? Or do we really  
> mean "stop"?

Done (following the terminology in RFC 2988).
I also changed "retransmit timer" to "retransmission timer".

> 8. Section 3.2, 3rd para -
> Clarify what the initiator does on receipt of the SYN/ACK packet  
> with ECM-mark -
> Does it accept or ignore the contents of the SYN/ACK packet (ack  
> field, mss option, etc). Does it consider its SYN to be acked?
> Clarify what the initiator does while it stays in the SYN-Sent state.
> Does it behave as if it never received a SYN/ACK packet - not quite  
> true, since it sends ECN-echo on subsequent packets.
> Does it restart or stop the retransmission timer? If restart,  
> presumably it uses the 3 second value.
> Does it retransmit SYN if a timeout occurs?
>
> One suggestion is that the initiator should not make any changes to  
> its TCP state when it receives an ECN-marked SYN/ACK packet in the  
> SYN-Sent state (not sure of this is what is intended in the current  
> doc). It should not remember the ECN state for subsequent sending of  
> ECN-Echo flags. It should simply send the ACK with ECN-echo packet  
> and restart its 3-second timer.
>
> Similarly, the responder should make the following changes only to  
> its TCP state on receiving an ACK with ECN-echo packet in the SYN- 
> received state - set the initial window size to 1 segment, disable  
> sending of ECT with SYN segments and restart the 3-second timer  
> after sending the SYN/ACK segment.

We have put in an additional sentence:
"The responder also sets the retransmission timer."

> The responder should make the following changes to its TCP state  
> after timeout in the SYN-Received state - disable sending of ECT  
> with SYN segments.

The document is aiming at specifying behavior without specifying
implementation-specific state.  We made some revisions to this
section, but did not discuss it in terms of the state maintained
by the TCP initiator and responder.

> 9. Section 3.2, 3rd para, last sentence -
> "... initiator continues to set ECN-Echo flag ..."
> Since the initiator is waiting for a SYN/ACK packet, which would  
> arrive with the CWR bit set, under what circumstance would the  
> initiator resend the ECN-Echo flag?

I couldn't think of one, so I deleted that sentence.

> 10. Section 3.2, 3rd para -
> Packet duplication by a network can create some pathological cases  
> which might need to be clarified.
> * What if the initiator receives a second copy of the SYN/ACK packet  
> with CE?
> * What if the initiator receives a SYN/ACK packet with CE, and soon  
> thereafter receives a duplicate SYN/ACK packet without CE?
> * What if the initiator receives a SYN/ACK packet without CE,  
> transitions to the SYN-Received and the Established state and then  
> receives a SYN/ACK packet with CE. Should it do anything special?  
> Presumably not.

We added the following:
"The TCP hosts follow the standard specification for the response to
duplicate SYN/ACK packets (e.g., Section 3.4 of RFC 793)."

> 11. Section 3.2, 5th para -
> Last sentence seems garbled. Something is missing.

Thanks, we rephrased it.

> 12. Section 3.2 -
> There is an opportunity here for both initiator and responder to  
> update its RTT measurement and use it for subsequent timers. It can  
> provide some benefit. Should we make use of it?

We think this is outside the scope of this document.

> 13. Section 3.2 -
> The examples are very good in understanding the specification. Would  
> be useful to separately write the precise specification about what  
> the initiator and responder must/should and must not / should not do  
> for various events in different TCP states. See suggestion above.

While this comment is appreciated, we think we have to balance
between “overspecification” and having an ambiguous spec.
We have left it as it is.

> 14. General -
> It might be worth mentioning that if a SYN/ACK with ECT is lost or  
> its ACK response with ECN-Echo is lost - due to congestion - the  
> responder ends up not reducing its initial congestion window size to  
> 1.

This is illustrated in Figure 1, so we didn't think there was any
need to add this.

> Also, the initiator does not ever reduce its initial congestion  
> window size to 1 because of congestion.

We didn't add this.
This document does not discuss congestion on the forward path.

> 15. Section 8 or elsewhere -
> Might be useful to state that if congestion is in the initiator to  
> responder direction, then this enhancement does not provide any  
> benefits.
> If congestion is in the responder to initiator direction, and data  
> transfer is in the initiator to responder direction, this  
> enhancement provides some benefit, since the initiator does not have  
> to experience a 3 second timeout, if the SYN/ACK packet gets ECN- 
> marked instead of getting dropped by the network.

We thought this was clear from Section 6.1.

> 16. General -
> It might be useful to add counters (MIB variables?) for these events.

We didn't add this.  MIBs are usually addressed in separate documents.

> 17. Appendices - editorial comments -
> Some of the "Target Load" values are incorrectly stated as .95%,  
> 1.5%, etc.
> Table 2 - Target Load = 150% line is missing.

Thanks, fixed.

> 18. Section 1, Garbled sentence - "The sender of the SYN/ACK  
> packet ... (a router with the CE codepoint set in the ECN field of  
> the IP header)".
> Should it be "... (a packet with the ...)"?

Fixed.

> 19. Section 1, minor comment -
> Sentence - "RFC 3168 only specifies marking Congestion Experienced  
> codepoint on TCP's data packets".
> Might be better stated as "RFC3168 only specifies marking ECN- 
> Capable codepoint on TCP's data packets".

Done.

Many thanks for all of the feedback!