[tcpm] Review pt1/2: draft-bensley-tcpm-dctcp-00

[Bob Briscoe <[e-mail]>]

Stephen, Lars, Dave,

1) Applicability and Incremental Deployment
===========================================
Although it's called Data Centre TCP, you haven't said what it's 
deployment applicability is. Under "4. Deployment Issues" you mention 
a "heterogeneous datacenter". What does that mean? I believe DCTCP 
does not co-exist well with legacy TCP flows (it starves itself 
without special measures in the buffers). See 
<http://www.ietf.org/proceedings/88/slides/slides-88-tsvwg-20.pdf>

For instance, what would you say to these two areas of potential applicability:
a) My company operates a private network connecting the data centres 
of hundreds of companies. But it's infeasible to get everyone to 
change to DCTCP all at once. The above link to our slides at the last 
IETF is a proposal to deploy DCTCP incrementally, which could work on 
such a large private community of interest network and potentially on 
the public Internet as well:
b) We are considering using DCTCP within corporate LANs (at least 
where app-layer proxying means there are no (or very few) flows 
within the LAN that also cross the wide area).

2) "Intended Status: Standards Track"
=====================================
* Without having stated otherwise, Standards Track implies this could 
be for the public Internet.
* If solely for homogeneous data centres (to document an existing 
implementation for the record), then Informational would be appropriate
* If you are prepared to allow the spec to evolve as it progresses, 
then I would suggest Experimental would be appropriate.

3) Capability Negotiation of the new TCP wire protocol.
=======================================================
"
4. Deployment Issues
...
    DCTCP requires changes on both the sender and the receiver, so in a
    heterogeneous datacenter, all the endpoints should support DCTCP and
    should be configured to use it.
"
The ECN echoing behaviour of the receiver (S.2.2) alters the TCP wire 
protocol without any negotiation. In "a heterogeneous data centre" 
DCTCP and non-DCTCP implementations will not realise they are not 
built to interwork, and their different uses of ECE feedback will 
horribly confuse each other.

Slide 14 of the presentation linked earlier suggests a roadmap of 
standards actions necessary to deploy DCTCP in heterogenous data 
centres. Would you be happy to break DCTCP down into these parts?
         component. . . . . . . . . . . . .      IETF wg document
#1      redefine meaning of ECN CE . . . .      tsvwg   Expt update to RFC3168
#2      specify ECN behaviour in AQM algos      aqm     CoDel, PIE, (RED++?)
#3      specify change to TCP feedback . 
.      tcpm    draft-ietf-accurate-ecn-reqs
#4      specify change to TCP sender algo       tcpm    Expt update to RFC5861

If so, I suggest your draft could focus on #4 (specify change to TCP 
sender algo). In place of your S.2.2, you would need to cite some of 
the following for #3 (specify change to TCP feedback):
* draft-ietf-tcpm-accecn-reqs-05 identifies capability negotiation as 
a problem.
It is close to tcpm WGLC. The tcpm WG wanted a requirements doc 
before we could specify a protocol solution.
* draft-kuehlewind-accurate-ecn proposes a solution to capability 
negotiation (the one we originally specified and implemented for ConEx)
* draft-kuehlewind-accurate-ecn-option proposes alternative 
capability negotiation based on TCP options.

4) Flaw in receiver feedback algo.
==================================
The feedback algo in S.2.2 is badly flawed because of the possibility 
of losing pure ACKs. See 
<http://tools.ietf.org/html/draft-ietf-tcpm-accecn-reqs-05#appendix-A>. 
This is why we've suggested alternative(s).

I will send more examples offlist to show it is flawed in many more 
ways than just the one example.

5) Sender Algo
==============
I have a suggestion for an algo that naturally auto-configures to 
RTT. It would replace the algo in "2.3. Processing Congestion 
Indications on the Sender". Mohammad Alizadeh worked on similar but 
different ideas in his SIGMETRICS paper about DCTCP.

However, I'll send that in pt2/2 - got to rush now.



Bob



________________________________________________________________
Bob Briscoe,                                                  BT