IETF BibXML

Viewing source data: draft-khademi-tsvwg-ecn-response indexed from relaton-data-ids
docid.id draft-khademi-tsvwg-ecn-response
docid.type Internet-Draft
docid.primary True
relation.type includes
relation.bibitem.formattedref.content draft-khademi-tsvwg-ecn-response-00
relation.bibitem.formattedref.format text/plain
relation.bibitem.docid.id draft-khademi-tsvwg-ecn-response-00
relation.bibitem.docid.type Internet-Draft
relation.bibitem.docid.primary True
relation.bibitem.id draft-khademi-tsvwg-ecn-response-00
relation#2.type includes
relation#2.bibitem.formattedref.content draft-khademi-tsvwg-ecn-response-01
relation#2.bibitem.formattedref.format text/plain
relation#2.bibitem.docid.id draft-khademi-tsvwg-ecn-response-01
relation#2.bibitem.docid.type Internet-Draft
relation#2.bibitem.docid.primary True
relation#2.bibitem.id draft-khademi-tsvwg-ecn-response-01
title.content Updating the Explicit Congestion Notification (ECN) Specification to Allow IETF Experimentation
title.format text/plain
title.script Latn
title.language en
abstract.content <p>This document relaxes recommendations and prescriptions from RFC3168 and RFC4774 that get in the way of experimentation with different ECN strategies. First, RFC3168 and RFC4774 state that, upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a single dropped packet. This document relaxes this rule in order to encourage experimentation with different backoff strategies. Second, this document allows future IETF specifications to use the ECT(1) codepoint in ways that are currently prohibited by RFC3168. Third, this document allows future IETF experiments to use the ECT(0) or ECT(1) codepoint on any TCP segment.</p>
abstract.format text/html
abstract.script Latn
abstract.language en
id draft-khademi-tsvwg-ecn-response