Subject: [Tsvwg] Re: Diffserv codepoint seems strange for Re-ECN <draft-briscoe-tsvwg-re-ecn-tcp-00>

From: Sally Floyd <[email-masked]>
Date: Thu, 15 Dec 2005 13:02:19 -0800

Bob -

My apologies for the long delay in responding to your email.  I
have finally read draft-briscoe-tsvwg-re-ecn-tcp-00, and will answer
your email as best I can.

>Your assumption/question about confining the re-ECN semantics for the 
>ECT(0) & ECT(1) codepoints solely to certain DSCPs threw me - I've realised 
>why - it doesn't make much sense (at least to me).

My disagreemenet at the WG meeting was about what I understood to
be your delaying the move of RFC 3540, Robust ECN Signaling with
Nonces, to Proposed Standard, and instead proposing the mechanism
in draft-briscoe-tsvwg-re-ecn-tcp-00 for the default semantics of
the ECT(0) and ECT(1) codepoints.

>The network /middleboxes currently don't read the nonce codepoints, only 
>the receiver. Diffserv codepoints are for reading by the network. 

Yep, but the entire point of your semantics for ECT(0) and ECT(1) is
for them to be used by droppers in the network, as I understand it.

>So I 
>assume your ECN-alternate-semantics draft only applied to marking 
>semantics, not to the (current) nonce ECT codepoint semantics which are e2e.

Yep, this is not about the ECN-alternate-semantics draft, this is
about the delaying of moving RFC 3540 to Proposed Standard.

>So, rather than a Diffserv codepoint, in the re-ECN draft I used the TCP 
>handshake to negotiate re-ECN capability between sender and receiver. I 
>give a compatibility mode where the re-ECN sender can work with a nonce 
>receiver, or basic ECN for that matter. It's optional, so if an implementer 
>doesn't do the compatibility mode a re-ECN sender falls back to basic ECN.

That is fine by me.

>But the re-ECN draft does suggest that the network/middleboxes read and 
>have semantics for these two codepoints. In the incremental deployment 
>section I explain how this would work with nonce senders and receivers. The 
>basic idea is that a nonce sender appears to be declaring 50% path 
>congestion to the network. So policers should be configured permissively on 
>first deployment. Then, they can be gradually tightened up to encourage 
>upgrade to re-ECN.
>
>Of course the word 'upgrade' assumes re-ECN is 'better' than the nonce.

Yep.  And that is my disagreement.

If re-ECN used diff-serv codepoints to signal to use of re-ECN to
droppers in the network, then RFC 3540 could still be used for the
default semantics for the ECN Nonce, and re-ECN could be the alternate
semantics.  This would not mean that the use of re-ECN would be
restricted to a single diffserv codepoint;  there could be a diffserv
codepoint for best-effort traffic that uses re-ECN, and other
diffserv codepoints for various diffserv traffic classes that wish
to use re-ECN.  (I could imagine that some diffserv traffic classes
might not want to be subject to packet dropping by re-ECN droppers in
the network, and other diff-serv traffic classes might want to use
re-ECN, or to have two variants with two codepoints, one with and
one without re-ECN.)

The question is, is the current ECN nonce in RFC 3540 of sufficient
value to be saved as the default semantics for ECT(0) and ECT(1)?
I think it is.

It is hard to evaluate draft-briscoe-tsvwg-re-ecn-tcp-00 completely,
since parts of it is incomplete.  However, in my view, the main
difference between the ECN-Nonce and re-ECN is that the ECN-Nonce
is used by the sender to prevent lying by the receiver, while re-ECN
is used by the ingress and egress droppers together to prevent
congestion control cheating by either or both of the end nodes.
That is, as I understand it, re-ECN is only of use with the droppers
in the network.

My experience to far in working on congestion control mechanisms
that require many interacting players is to have a significant
distrust of arguments of why all of the players will have an incentive
to act their part.  E.g., the SIGCOMM 2005 article on re-ECN outlines,
why the end-nodes will have an incentive to use re-ECN, and the
network operators will have an incentive to deploy ingress policing
and egress dropping.  I have to say that I am skeptical, and
personally, I have more confidence on mechanisms that require less
global consistency, when that is possible.  (Unfortunately, it is
not always possible, as we all know.) In particular, I have more
confidence in the use of the ECN Nonce by the sender to ensure that
the receiver is not lying about congestion feedback, and the use
of policers in the network that rely on locally available information
(e.g., packet drops at that point or upstream, ECN marks at that
point or upstream, etc.) to check that connections are using
appropriate end-to-end congestion control.

That does not mean that I am opposed to re-ECN - I think it is
interesting, and has a fair amount of promise.  However, I don't
have sufficient confidence in it to think it superior to the ECN
Nonce, so my own preference would be for the use of re-ECN to be
signalled to policers and droppers by diff-serv codepoints, rather
than by a re-definition of the default semantics of the ECN Nonce.

More specific feedback on draft-briscoe-tsvwg-re-ecn-tcp-00 is below.

>This is all in the re-ECN draft - pls read the details there which I think 
>you'll find is less strange than using DSCPs. Perhaps strange is a little 
>too strong. But certainly confining re-ECN to certain DSCPs is 
>unnecessarily over-constraining.
>
>(The essence of this backwards compatibility was also in the re-feedback 
>SIGCOMM paper - don't know where the Diffserv idea came from).

It came from me, as described above.  An alternative mechanism,
proposed below, would be to uses the proposed CR flag in the IP
header for this.  Either one would allow the ECN Nonce to
proceed as is to Proposed Standard.

Regards,

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

--------------------------------------------------------------------
Feedback on draft-briscoe-tsvwg-re-ecn-tcp-00:

P. 4: 
"Policing is only truly effective at the first ingress into an
internetwork, but path congestion is only visible at the last
egress."

I disagree.  Policing, in the form of `traffic tickets' that discourage
flows from cheating about end-to-end congestion control, is effective
wherever it is done in the netowrk.  And path congestion is visible
at the congestion point, or anywhere downstream.  (My understanding
is that congestion these days is typically not in the core, but on
access links, exchange points, edge networks, and the like.)

P. 7:
"The assumption behind the ECN nonce is that a sender will want to
detect whether a receiver is suppressing congestion feedback.  This
is only true if the sender's interests are aligned with the network's,
or with the community of users as a whole.  This may be true for
certain large senders, who are under close scrutiny and have a
reputation to maintain."

The ECN nonce would be useful for more than just "certain large
senders".  For example, our measurement study of 80.000 web servers
("Measuring the Evolution of Transport Protocols in the Internet",
April 2005 CCR, "http://www.icir.org/tbit/") found only almost all
of the web servers use appropriate congestion contron in TCP
connections, halving the congestion window in response to packet
drops.  I would imagine that most of these 80.000 web servers would
also find the ECN Nonce useful to verify compliance from receivers.

P. 15: 
TCP connections with an ACK acking eight or more packets: As you
say in your proposal, when an ACK arrives acking eight or more
packets, re-ECN is unable to know whether none of the intervening
packets were ECN-marked, or if eight of the intervening packets
were ECN-marked.  As you say, this could use more investigation;
both the ultra-conservative response of assuming packets were
ECN-marked, and the optimistic response of assuming that no packets
were ECN-marked, could be problematic.  If it relied on past history,
the TCP sender could perhaps at least make a plausible inference.
[E.g.  it is unlikely that 8 packets will be marked in a RTT, when
it has never been the case that 4, 5, 6, or 7 packets have been
marked in a single RTT.]

P. 15:
"We expect Re-ECN would be deployed for some time before policers
and droppers start to enforce it."

Yep, from my experience, I would expect it to be a long time indeed.
And if re-ECN used a diff-serv codepoint to signal its use to
policers and droppers, then other traffic could proceed with the use 
of the ECN Nonce.

P. 20:
The proosed CR flag in the IP header:
It would be good to clarify in this document exactly what the CR
flag would entail.  The document says that "it will imply that the
transport understands and is using re-feedback of other fields in the
IP header, such as the TTL".  It would be nice if the CR flag
(if this last free flag in the IP header gets allocated to re-ECN)
would be used to signal to policers and droppers that this flow
was using re-ECN.  Then you would not have to use diff-serv
codepoints for this, and the ECN Nonce could advance to Proposed
Standard as the default semantics for ECT(0) and ECT(1).

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

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Thu, 15 Dec 2005 17:41:57 -0500

Sally,

Overall, I agree with most of your comments, but...

> also find the ECN Nonce useful to verify compliance from receivers.

I'm not sure I agree. Content providers mainly care about user
experience, which means the state of the network is only important when
it affects them and their receivers. If a sender has reason to believe
that competing flows at the bottleneck point will most likely be from
other sources, the sender may take its chances by not using ECN nonce.
On the other hand, if the competing flows are likely to come from the
same sender, then it definitely makes sense to try to enforce ECN
compliance from receivers.

-- 
Armando
www.armandocaro.net