Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Robust Explicit Congestion Notification (ECN) Signaling with Nonces (RFC3540)

IP.com Disclosure Number: IPCOM000016465D
Original Publication Date: 2003-Jun-01
Included in the Prior Art Database: 2003-Jun-24
Document File: 14 page(s) / 30K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

N. Spring: AUTHOR [+3]

Abstract

This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 9% of the total text.

Network Working Group� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � N. Spring

Request for Comments: 3540� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � D. Wetherall

Category: Experimental� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � D. Ely

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � University of Washington

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � June 2003

� � � � � � � � � � � � Robust Explicit Congestion Notification (ECN)

� � � � � � � � � � � � � � � � � � � � � � � � Signaling with Nonces

Status of this Memo

� � This memo defines an Experimental Protocol for the Internet

� � community.� It does not specify an Internet standard of any kind.

� � Discussion and suggestions for improvement are requested.

� � Distribution of this memo is unlimited.

Copyright Notice

� � Copyright (C) The Internet Society (2003).� All Rights Reserved.

Abstract

� � This note describes the Explicit Congestion Notification (ECN)-nonce,

� � an optional addition to ECN that protects against accidental or

� � malicious concealment of marked packets from the TCP sender.� It

� � improves the robustness of congestion control by preventing receivers

� � from exploiting ECN to gain an unfair share of network bandwidth.

� � The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in

� � the ECN field of the IP header, and requires a flag in the TCP

� � header.� It is computationally efficient for both routers and hosts.

1.� Introduction

� � Statement of Intent

� � � � � This specification describes an optional addition to Explicit

� � � � � Congestion Notification [RFC3168] improving its robustness against

� � � � � malicious or accidental concealment of marked packets.� It has not

� � � � � been deployed widely.� One goal of publication as an Experimental

� � � � � RFC is to be prudent, and encourage use and deployment prior to

� � � � � publication in the standards track.� Another consideration is to

� � � � � give time for firewall developers to recognize and accept the

� � � � � pattern presented by the nonce.� It is the intent of the Transport

� � � � � Area Working Group to re-submit this specification as an IETF

� � � � � Proposed Standard in the future after more experience has been

� � � � � gained.

Spring, et. al.� � � � � � � � � � � � � � Experimental� � � � � � � � � � � � � � � � � � � � � [Page 1]

RFC 3540� � � � � � � � � � � � � � � � � Robust ECN Signaling� � � � � � � � � � � � � � � � June 2003

� � The correct operation of ECN requires the cooperation of the receiver

� � to return Congestion Experienced signals to the sender, but the

� � protocol lacks a mechanism to enforce this cooperation.� This raises

� � the possibility that an unscrupulous or poorly implemented receiver

� � could always clear ECN-Echo and simply not ...