Subject: [Tsvwg] draft-ietf-tsvwg-ecn-alternates-00 is now

From: Sally Floyd <[email-masked]>
Date: Thu, 12 Jan 2006 18:51:35 -0800

I have submitted a new version of draft-floyd-ecn-alternates-02.txt as
draft-ietf-tsvwg-ecn-alternates-00.txt, available from:
http://www.icir.org/floyd/papers/draft-ietf-tsvwg-ecn-alternates-00.txt

The only changes were the addition of Section 5.3 on "Proposals for 
Alternate-ECN with Edge-to-Edge Semantics", and the change of the
title to draft-ietf-tsvwg-ecn-alternates-00.  Section 5.3 is
appended below.

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

5.3.  Proposals for Alternate-ECN with Edge-to-Edge Semantics

    RFC 3168 specifies the use of the default ECN semantics by an end-
    to-end transport protocol, with the requirement 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" [RFC3168, Section 5].  In contrast, some of
    the proposals for alternate-ECN semantics are for ECN used in an
    edge-to-edge context between gateways at the edge of a network
    region, e.g., for pre-congestion notification for admissions control
    [BESFC05].

    When alternate-ECN is defined with edge-to-edge semantics, this
    definition needs to ensure that the edge-to-edge semantics do not
    conflict with a connection using other ECN semantics end-to-end.
    One way to avoid conflict would be for the edge-to-edge ECN proposal
    to include some mechanism to ensure that the edge-to-edge ECN is not
    used for connections that are using other ECN semantics (standard or
    otherwise) end-to-end.  Alternately, the edge-to-edge semantics
    could be defined so that they do not conflict with a connection
    using other ECN semantics end-to-end.

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