Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-ecn-tunnel-02

From: Bob Briscoe <[email-masked]>
Date: Wed, 08 Jul 2009 13:43:18 +0100

Ingemar,

At 20:40 29/06/2009, Ingemar Johansson S wrote:
>Hi
>
>I have read draft-ietf-tsvwg-ecn-tunnel-02 and below some comments.
>
>Figure 4:
>  I wonder what will happen if we have a TCP 
> stack that implements ECN-nonce. Wouldn't the 
> rules in figure 4 lead to a faulty nonce-sum 
> with negative consequences for the TCP throughput. Or is this out of scope?.

Your point is certainly in scope, but I don't 
believe the criticism is correct. The transitions 
were designed to allow the nonce to work (in fact better than it did before).

If routers leave arriving ECT(0) or ECT(1) 
unchanged (as they should) the tunnel egress 
behaviour defined in Table 4 will also preserve 
ECT(0) & ECT(1). There will be no faulty nonce sum, and all will be fine.

The nonce is designed to detect a change of 
ECT(0) to ECT(1) or vice versa. The old (RFC3168) 
egress behaviour undid any change within a tunnel 
between either of these codepoints, so it 
couldn't be detected outside the tunnel. We've 
changed the egress behaviour so at least a change 
in one direction can be detected outside the 
tunnel. The security considerations section 
explains why we decided it was best to leave a 
change in the other direction undetectable (as it had been in RFC3168).

>Page 19: "sfaeguards" -> "safeguards"
>
>Page 22 bullet 4. (ECN nonce) "..no evidence 
>that anyone has implemented it beyond the 
>author's prototype". This one made me curios... 
>In general one get the feeling that it is not 
>good or recommended to use ECT(1) e.g as a light 
>congetsion indication (I believe it is written 
>in similar words in RFC3168), the main reason is 
>guess the ECN-nonce, this bullet says "don't 
>care about the ECN-nonce". Is there any 
>reference to a deeper discussion on around this?

RFC4774 gives guidelines for the possibility of 
multi-level ECN semantics. The behaviour in Table 
4 is designed to allow both Nonce-like behaviour 
and multi-level ECN behaviour to work, whereas in RFC3168 & RFC4301 broke both.

This bullet doesn't say "Don't use the ECN nonce" 
at all. RFC3168 and RFC4301 were both worse for 
the ECN Nonce. We've made them better in one 
case, but we couldn't in the other.

Specifically, RFC3168 broke the function of the 
ECN nonce for detecting changes between ECT(0) 
and ECT(1), but only changes within a tunnel. The 
Nonce worked and Table 4 allows it to still work 
for detecting changes by the receiver - it always 
did and still does. We've managed to at least 
make the Nonce work for a change in one 
direction, but fixing it for the other direction 
prevented use of multi-level ECN. This simply 
said, "We decided the corner-case of detecting a 
network operator suppressing congestion 
notification within a tunnel isn't as important 
as detecting cheating receivers or multi-level ECN."

The case left broken is such a corner case, I can 
see I'm going to have to make it clear that the 
Nonce still works in the normal cases, and in one more case than it did before.

>Page 29: "DIffserv" -> "Diffserv"

Tx for the comments (and the nits). I'll issue a 
new draft this week (also taking account of 
Gorry's longer review, which I will respond to shortly).

Cheers

Bob

>Regards
>Ingemar
>*******************************************
>Ingemar Johansson
>Senior Research Engineer, IETF "nethead"
>EAB/TVK - Multimedia Technologies
>Ericsson Research Ericsson AB
>Box 920 S-971 28 Luleå, Sweden
>Tel: +46 (0)10 7143042
>ECN: 852-43042
>ECC: 852-19042
>Mobile: +46 (0)730 783289
>Visit http://labs.ericsson.com !
>*******************************************

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research