Dave,

Thx for cross-posting. It's quite possible there are aqm people not on tsvwg.

1) Did you have views on the ecn-encap-guidelines I-D itself? Is it helpful?
I think it's fairly non-controversial.

2) In case I'm misunderstood, I don't see much latency gain from ECN as currently defined (RFC3168). I'm still banging on about ECN in lower layers 'cos early tests show promise that we may have found a way to make the ultra-low queuing delay of data centre TCP incrementally deployable on the public Internet

        We = Mirja Kuehlewind, David Wagner, Juan Manuel Reyes Espinosa and I.

It can be deployed with most existing kit, without any new AQM implementation needed. We use WRED in an unusual configuration. The idea in a nutshell:
* For ECN-capable packets, shift the job of hiding bursts from network to host:
   - ECN-capable packets map to a WRED policy with queue smoothing turned off
   - so the network signals ECN with zero smoothing delay
- then the transport can hide bursts of ECN signals from itself (like DCTCP does)
   - the transport knows
     o that it's ECN-capable
     o whether it's TCP or RTP etc,
     o whether its in congestion avoidance or slow-start,
     o and it knows its RTT,
     o so it can know whether to respond immediately or to smooth the signals,
     o and if so, over what time
- then short RTT flows can smooth the signals with only the delay of their /own/ RTT
     o so they can fill troughs and absorb peaks that longer RTT flows cannot
   - a TCP only needs to smooth the signals if in congestion avoidance
     o in slow start, it can respond immediately, thus reducing overshoot

There's more to it - I've asked to present the whole story in Vancouver.



Bob

At 05:35 15/10/2013, Dave Taht wrote:
It is my general assumption that membership in the aqm wg is a subset
of tsvwg, but in case it isn't...


---------- Forwarded message ----------
From: Bob Briscoe <bob.bris...@bt.com>
Date: Tue, Sep 17, 2013 at 5:33 AM
Subject: [tsvwg] Guidelines for Adding Congestion Notification to
Protocols that Encapsulate IP
To: tsvwg IETF list <ts...@ietf.org>
Cc: Gorry Fairhurst <go...@erg.abdn.ac.uk>


TSV folks,

We've just posted an update to the guidelines for adding congestion
notification to L2 and tunnelling protocols, e.g. Ethernet, L2TP, GRE,
PPTP, GTP etc. Especially of current interest in mobile and separately
in data centres.

Pls read/review and send any comments to the list.
<http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>

It's currently still an individual draft; intended status: BCP.
We're looking for support for adoption as a item of work in tsvwg.

We've dealt with most of the outstanding issues from previous reviews,
esp. those from Gorry (see summary of diffs below).

--------------------------------
Summary of Diffs from -02 to -03

      *  Scope section:

         +  Added dependence on correct propagation of traffic class
            information

         +  For the feed-backward mode, deemed multicast and anycast out
            of scope

      *  Ensured all guidelines referring to subnet technologies also
         refer to tunnels and vice versa by adding applicability
         sentences at the start of sections 4.1, 4.2, 4.3, 4.4, 4.6 and
         5.

      *  Added Security Considerations on ensuring congestion signal
         fields are classed as immutable and on using end-to-end
         congestion signal integrity technologies rather than hop-by-
         hop.


Bob


> From: <internet-dra...@ietf.org>
> To: John Kaippallimalil <john.kaippallima...@huawei.com>,
>         Bob Briscoe
>         <bob.bris...@bt.com>,
>         "Bob J.Briscoe" <bob.bris...@bt.com>,
>         Pat Thaler
>         <ptha...@broadcom.com>,
>         Patricia Thaler <ptha...@broadcom.com>
> Subject: New Version Notification for
>         draft-briscoe-tsvwg-ecn-encap-guidelines-03.txt
>
>
> A new version of I-D, draft-briscoe-tsvwg-ecn-encap-guidelines-03.txt
> has been successfully submitted by Bob Briscoe and posted to the
> IETF repository.
>
> Filename:       draft-briscoe-tsvwg-ecn-encap-guidelines
> Revision:       03
> Title: Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP
> Creation date:  2013-09-17
> Group:          Individual Submission
> Number of pages: 29
> URL: http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-ecn-encap-guidelines-03.txt > Status: http://datatracker.ietf.org/doc/draft-briscoe-tsvwg-ecn-encap-guidelines > Htmlized: http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines-03 > Diff: http://www.ietf.org/rfcdiff?url2=draft-briscoe-tsvwg-ecn-encap-guidelines-03
>
> Abstract:
>    The purpose of this document is to guide the design of congestion
>    notification in any lower layer or tunnelling protocol that
>    encapsulates IP.  The aim is for explicit congestion signals to
>    propagate consistently from lower layer protocols into IP.  Then the
>    IP internetwork layer can act as a portability layer to carry
>    congestion notification from non-IP-aware congested nodes up to the
>    transport layer (L4).  Following these guidelines should assure
>    interworking between new lower layer congestion notification
>    mechanisms, whether specified by the IETF or other standards bodies.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat


________________________________________________________________
Bob Briscoe,                                                  BT


--
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Reply via email to