Subject: Re: [tcpm] dctcp

From: Murari Sridharan <[email-masked]>
Date: Sat, 4 Dec 2010 17:03:26 +0000

Ok  here is how i plan to proceed. I will submit DCTCP as an experimental controller but make it general enough that it isnt strictly tied to any one congestion control (based on Wes' suggestion) to ICCRG. I will submit the IPR disclosures that protect DCTCP as well. If it moves to TCPM and there is interest towards a standards track then we can resubmit to TCP as a TCP extension. 

Thanks
Murari 

________________________________________
From: [email-masked] [[email-masked]] on behalf of Murari Sridharan [[email-masked]]
Sent: Tuesday, November 16, 2010 9:39 AM
To: Anantha Ramaiah (ananth); Joe Touch; Scheffenegger, Richard
Cc: tcpm; Andrew McGregor
Subject: Re: [tcpm] dctcp

I agree. We believe that DCTCP has certain properties that are generally applicable and personally I see DCTCP as an enabler for ECN even if in private or enterprise networks as it makes the switch side configuration rather trivial. I also think the ideas in the paper have broad applicability which is the reason why I wanted to present this to TCPM. Our goal has been to design DCTCP such that without ECN marks it behaves exactly like New Reno or whatever congestion control it is built on. In our case we built it as a modification to New Reno, I therefore think it is very much in scope for discussion. Whether it is in TCPM or ICCRG (treating DCTCP as an alternative congestion control algorithm) is for the WG to decide.

Remember if you are in a multi-tenant datacenter, algorithms like DCTCP are most effective especially at the switches only if all the senders are conformant to DCTCP, in that vein it is worth discussing at IETF.

If the WG and the chairs agree I intend to submit an ID explaining the changes. I propose two alternatives. One way to think of this is as a modification to the ECN RFC, to say that instead of halving in response to the *presence* of congestion; react to the *extent* of congestion by averaging the ECN marks which is what DCTCP does. Personally I believe this is a better approach however the alternative option is to submit DCTCP as a new congestion control algorithm. Thoughts?

Thanks
Murari

-----Original Message-----
From: Anantha Ramaiah (ananth) [mailto:[email-masked]]
Sent: Saturday, November 13, 2010 8:46 AM
To: Joe Touch; Scheffenegger, Richard
Cc: Murari Sridharan; tcpm; Andrew McGregor
Subject: RE: [tcpm] dctcp

Well,

My thoughts here are :-

- If someone is using a protocol defined by IETF, then it is desirable to abide by the standards, irrespective of the type of network.

- interoperability across different devices (may be coming from different vendors), using the same protocol, is one of the reason you need standards!

-  From an implementation perspective you don't want "private TCP" and "public TCP" in the same stack since the same stack needs to cater to TCP connections from *both* private and public networks!

- The problems and the solutions which are posed by the data center environments may not be unique. The question to ask is : "what is the problem and whether the problems and solutions would have a generic applicability.

- Also how do you draw a boundary as to a what is private network and what isn't ? Why is data center environment considered a "private network" ?

IMO, it is an issue that can be well addressed (if there is a need) by the IETF,  if changes are being planned with TCP protocol, yes TCPM is the right place for such efforts.

$0.02,
-Anantha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Friday, November 12, 2010 12:06 PM
To: Scheffenegger, Richard
Cc: Murari Sridharan; tcpm; Andrew McGregor
Subject: Re: [tcpm] dctcp

On 11/11/2010 3:51 AM, Scheffenegger, Richard wrote:
...
> Reading the TSVAREA material, it was also pointed out (storage teaser
-
> NFSv4, iSCSI) that TCPM may need to look closer at datacenter
> environments rather soon.

Tuning TCP for private networks (i.e., not using the Internet, or competing with Internet flows) seems out of scope for TCPM.

It might not even be relevant elsewhere in the IETF, except as an issue of common interest. Protocols running over private networks don't need to adhere to standards.

Joe
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

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