Subject: RE: [Tsvwg] TCP ECN with nonces

From: [email-masked]
Date: Sun, 5 May 2002 20:59:59 +0300

Hi Neil!

	See my comments below...

> Hi Ivan,
> 
> Thanks for your comments.  Some of the issues you raise are
> addressed in the draft, and the others are intentionally
> left open as policy.
> 
> >	I think that in these cases, when the NS bit is
> > not set during connection set up, the data sender should
> > in fact not use ECN at all... In other words, the actual
> > initial negotiation should be:
> > 	- The SYN sender sets the CWR and ECE bits in the IP header...
> > 	- The SYN/ACK sender sets the NS and ECE bits...
> > 	- The ACK sender sets the NS bit...
> 
> I think this is what we specify in the last paragraph of
> section 5:
> 
>    The initial nonce sum is 1, and is included in the SYN/ACK 
> and ACK of
>    the three way TCP handshake.  This allows the other 
> endpoint to infer
>    nonce support, but is not a negotiation, in that the 
> receiver of the
>    SYN/ACK need not check if NS is set to decide whether to set NS in
>    the subsequent ACK.

	This is the point... The SYN/ACK does not have to be compulsorily set... so the peer is free to do whatever it wants...

	The draft tries to avoid a data sender to cheat about the reception of CE packets... However, if it really wants to cheat, it simply has to forget about this draft... I will behave as if it does not support this extension (and not supporting it in fact)...

	It is hard to say how tempted are the implementations to implement "illegal" ECN support... However, if you really want to be sure that the peer is not cheating, I think that you should not let the peer do whatever it wants... I hope you understand what I mean... If you want to stop a criminal to do any harm, invent the handcuff but don't let him choose if it wants to use them or not... :-)

	Thanks!

	BR Iván Arias Rodríguez

	PS: This is something I have just thought about... What if you send "probes" every now and then? I.e., you send every certain time a CE datagram (you set both). Then you check what the peer is doing... If you effectively receive the ECE, you simply ignore it and feel better, since the peer is not lying... This could be a nice way of keeping track of the behavior of hosts not supporting this draft...

	Ok, if a router is going to precisely set that packet you marked as CE when you sent it, you may not act properly upon receipt of the ECE for that packet and within a RTT (you can always sent a CWR packet right after that CE, so the data receiver stops marking the packets as ECE as soon as possible)...

	These probes should not be sent if the peer supported nonces...

	These are just maybe silly ideas... However, I have the feeling that I'm not precisely the first one to think about them... :-)

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Neil Spring <[email-masked]>
Date: Sun, 5 May 2002 18:11:18 -0700

Ivan,

I think we agree.  If the sender wants protection against
buggy or malicious receivers, it would have to demand the
nonce, and have to stop setting ECT after an incorrect
nonce or when a receiver claims not to support it.

The hard part we're discussing is how to reconcile the
ECN-nonce being optional when the ability to disable it
subverts its goal.

I think you're exactly right - stop sending ECT if the
nonce isn't supported.  But this isn't appropriate in
a world where both nonce-support and misbehavior are
uncommon.  If (malicious or buggy) misbehavior becomes
commonplace, the nonce provides an alternative to disabling
ECT.

To restate, for now, a sender should be tolerant of hosts
that claim not to support the ECN-nonce.  In a future
where misbehavior or nonce support are common, a sender
can be more careful and expect nonce support.

> PS: This is something I have just thought about... What
> if you send "probes" every now and then?

Yes, this has been suggested before, though I don't
remember where, and I don't remember seeing the CE followed
immediately by CWR trick.  A small catch is that it remains
hard to provide protection for short flows: it seems like
slow start would interact poorly with ignoring a congestion
signal or eating one for testing purposes.

thanks!
-neil

On Sun, May 05, 2002 at 08:59:59PM +0300, [email-masked] wrote:
> 	It is hard to say how tempted are the implementations to implement "illegal" ECN support... 
However, if you really want to be sure that the peer is not cheating, I think that you should not let the peer do whatever it wants... I hope you understand what I mean...  If you want to stop a criminal to do any harm, invent the handcuff but don't let him choose if it wants to use them or not... :-)
> 	BR Iv?n Arias Rodr?guez