[OPSAWG] Tsvart last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11

[Wesley Eddy via Datatracker]

Reviewer: Wesley Eddy
Review result: Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.


Thank you for responding to my prior review comments; the latest copy looks 
fine to me.


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[Wesley Eddy]

On 1/17/2024 3:34 AM, mohamed.boucad...@orange.com wrote:
[Med] This can be part of regular code updates. Please note that this 
is not unusual in ipfix (see for example ipv4Options, natevent, etc. 
in https://www.iana.org/assignments/ipfix/ipfix.xhtml which depend on 
an IANA registry).


Ok; do you think the document should explain this in a sentence or two 
for implementers?


If they are not all familiar with details of how ExIDs are used, then it 
seems like a stretch to assume they'll all understand that products need 
to be designed to periodically update ExID definitions.


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[Wesley Eddy]

On 1/16/2024 11:10 AM, mohamed.boucad...@orange.com wrote:


Are you expecting the implementation to have an exhaustive list of all 
of the ExIDs in use to understand the difference between 2 and 4 byte 
usage?


*/[Med] Yes because otherwise an implem can’t unambiguously identify 
and extract ExIDs. We do provide a pointer to the registered ExIDs:/*


*//*

*/==/*

Additional Information:  See assigned ExIDs at [IANA-TCP-EXIDs].

*/== /*

*//*

*/Please let me know if you still think a clarification is needed to 
the draft. Thanks./*


New ExIDs are able to be added to the IANA registry at any time, just 
via requesting them.  Is an IPFIX implementation expected to 
periodically fetch the registry and reload its known values?




___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[Wesley Eddy]

The changes look good to me; I just want to make sure you understand one 
of my questions that doesn't look like it was clear enough:


On 1/15/2024 4:13 AM, mohamed.boucad...@orange.com wrote:

- The way an implementation understands the TCP ExIDs may benefit
from slightly more explanation:
   -- In 4.2 and 4.3, is the idea that the implementation is just
sampling the
   16 or 32 bits following the experimental option kind being
indicated, and
   assuming those 2 or 4 bytes to be ExIDs?  From Section 6.2, I
got the sense
   that the implementation is aware of particular ExID values
specifically, to
   know if they should be reported as 2 or 4 byte values.

[Med] 2-byte IDs are reported in tcpSharedOptionExID16 while 4-byte IDs are 
reported in tcpSharedOptionExID32.
Are you expecting the implementation to have an exhaustive list of all 
of the ExIDs in use to understand the difference between 2 and 4 byte 
usage?  I don't quite understand how this is supposed to work at the 
sampling point, since it's the TCP implementation that interprets the 
option and determines whether it is to be interpreted as containing (1) 
no ExID, (2) a 16-bit ExID, (3) a 32-bit ExID. This information is not 
available within the protocol to a third party.  The third party would 
need a list of ExIDs in-use in order to understand them.___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[Wesley Eddy via Datatracker]

Reviewer: Wesley Eddy
Review result: Ready with Issues

Comments:

- The document is well-written and easy to read.

- Section 6 is really nice and helpful!

Issues:

- The way an implementation understands the TCP ExIDs may benefit from slightly
more explanation:
  -- In 4.2 and 4.3, is the idea that the implementation is just sampling the
  16 or 32 bits following the experimental option kind being indicated, and
  assuming those 2 or 4 bytes to be ExIDs?  From Section 6.2, I got the sense
  that the implementation is aware of particular ExID values specifically, to
  know if they should be reported as 2 or 4 byte values. -- Will any values
  present be reported, or only those which show up in the IANA registry?  I
  assume any values will be reported, even if they are not registered ExIDs,
  since the registry changes over time, and implementations probably don't grab
  periodic updates of it.

Questions:

- This may be alright, but it seemed to me like for interoperability there
should be some way to indicate what an implementation of this IE is doing with
regard to this text in Section 3.1 (where maybe "may" should be "MAY"?):

  Several extension header chains may be observed in a Flow.  These
  extension headers may be aggregated in one single
  ipv6ExtensionHeadersFull Information Element or be exported in
  separate ipv6ExtensionHeadersFull IEs, one for each extension
  header chain.

- In Section 3.3, it seems backwards to me that this Limit IE being True means
that no limitation was applied, whereas False means that it was limited.  If
the WG and implementers are okay with this, I'm not questioning it, but it
seems odd, so I just wanted to make sure this was the intention.

Nits:

- The first paragraph in section 1 should probably mention the specific RFC(s)
for the specified IEs with the noted problems, since it sounds from the
beginning paragraphs of section 3 and 4 like some of those are already being
addressed by the separate ipfix-fixes document.

- Section 1.1, "do no correspond" -> "do not correspond"


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[alto] Iotdir telechat review of draft-ietf-alto-new-transport-17

[Wesley Eddy via Datatracker]

Reviewer: Wesley Eddy
Review result: Ready with Issues

I only found 1 real "issue" in reading this document, and a few smaller nits,
described below.  None of these comments are specifically related to IoTDIR
type of concerns, and it doesn't seem like the protocol would be intended for
use in IoT.

Issues:

1) The placement of TIPS relative to other ALTO standards is unclear.  This
became evident to me on page 4, reading the bottom paragraph with "Despite the
benefits, however, ...".  Is the gist of this paragraph supposed to be that the
WG does not think that TIPS should totally replace ALTO/SSE?  It's not clear to
me what the recommendation or applicability statement for these is in practical
terms.  The WG should convey more clearly what it believes implemenentations
and deployments should be using, under what circumstances.  If both protocols
are maintained as standards track, then it should be clearly stated why that
needs to be the case and that this does not obsolete ALTO/SSE.  It seems to be
created as another option, with unclear guidance provided to implementers about
what to do.

Nits:

1) page 4
from
"no capability it transmits incremental"
to
"no capability to transmit incremental"

2) I don't know if this is typical for other ALTO documents, but the usage of
the term "transport protocol" in the first paragraph of section 1 is not
consistent with the Internet architecture where "transport protocols" are TCP,
UDP, SCTP, etc., nor is it "transport" in the sense of MPLS, etc.   I would
suggest using the alternative term "transfer" to be less jarring.  Of course,
if this is already the standard terminology for ALTO that the IETF has
accepted, then this comment can be ignored.

3) In the section 5.4 example, should "my-networkmap" in some of the "uses"
values by "my-network-map" that was defined at the top?



___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[spring] Tsvart last call review of draft-ietf-spring-sr-replication-segment-14

[Wesley Eddy via Datatracker]

Reviewer: Wesley Eddy
Review result: Almost Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.

(1) Since this defines a behavior where one incoming packet can create N
outgoing packets, I was surprised that there is nothing mentioned in the
security considerations about how access to replication nodes and ingress for
them should be protected in order to prevent abuse.

(2) The intended use seems mainly to be where some outer control system is
responsible for making sure that the replication operation will put packets
onto distinct network paths, and not create congestion either locally or on
some potential shared network segment downstream.  It might be more clearly
stated that it's assumed that building a proper multicast tree, managing group
membership, and performing multicast congestion control need to be performed
elsewhere.

(3) I didn't recognize the syntax or pseudocode conventions in section 2.2.1;
maybe this is common or defined somewhere else that could be referenced to be
clear?


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[bess] Tsvart last call review of draft-ietf-bess-evpn-lsp-ping-08

[Wesley Eddy via Datatracker]

Reviewer: Wesley Eddy
Review result: Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.

Some comments:
(1) Is there an 'e' missing at the end of this sentence in Section 1?:
validate data plane against the control plan.
->
validate data plane against the control plane.

(2) It seems like some words are missing in this sentence in Section 4.1:
The EVPN MAC/IP Sub-TLV identifies the MAC or ARP/ND for an EVPN
->
The EVPN MAC/IP Sub-TLV identifies the target MAC address for ARP/ND for an EVPN

(3) For IP address used for examples (e.g. in Section 6.1), consider using the
documentation prefix (RFC 5737).



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[OPSAWG] Tsvart last call review of draft-ietf-opsawg-vpn-common-09

[Wesley Eddy via Datatracker]

Reviewer: Wesley Eddy
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.

This document basically looks good to me, though I have a small number of
comments:

(1) I think this comment impacts only the narrative and not the YANG model
itself.  The list of possible underlay-transport values seems to be a mixture
of expected types of encapsulations, but then a couple of things at the end
that are signaling and not encapsulations per-se.  The last 2 entries in the
list on page 6 are what seem out of place to me - RSVP and BGP.  I don't think
it's quite correct to refer to these two as the underlay-transport.

(2) This is a YANG model question, that I'm unsure of.  I want to make sure
that in the match-type when match-flow is used that a combination of L3 and L4
attributes can be used.  It appears like either L3 or L4 can be indicated,
mutually exclusive, but I don't quite understand how it would then be possible
to properly represent the combination of IP, transport protocol, and ports that
identify a flow.  It seems like a list of criteria from both L3 and L4
components is what's needed to express a flow, rather than a choice of L3 or L4.


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Tsvart last call review of draft-ietf-opsawg-vpn-common-06

[Wesley Eddy]

Your response all sounds good to me, thanks.

On 4/1/2021 3:14 AM, mohamed.boucad...@orange.com wrote:

Hi Wes,

Thank you for the review.

Please see inline.

...


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Tsvart last call review of draft-ietf-opsawg-vpn-common-06

[Wesley Eddy via Datatracker]

Reviewer: Wesley Eddy
Review result: Almost Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.

(1) I noticed in the "qos-classification-policy" there is "l4" support either
TCP or UDP.  It isn't clear if other transport protocols are purposefully not
included.  Should this also support SCTP and/or DCCP, or other transport
protocol numbers in general?  Are the QUIC aspects that might be matched
contained within the UDP fields supported?

(2) Is the allowable MTU another aspect of VPN services that should be able to
be expressed?

(3) ICMP isn't mentioned as an identity type, and I wondered if this should be.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Wesley Eddy]

Hi, Dave, strangely it looks like nobody has been copying TSVWG on this 
thread, even though that is where the L4S work is happening in the IETF!  :)


I just wanted to respond to one part of your message since I am 
currently acting as document shepherd for the L4S drafts in TSVWG, and 
it seems like maybe you don't know where to find all of the IETF 
materials in order to participate (based on the "stalled out 
indefinitely" comment below).  So in case it's helpful here are some 
pointers to where things are kept.


The 3 base L4S documents were adopted in the TSVWG WG, and have been 
regularly updated.  You can find the charter and milestone dates 
(currently June 2019) quite easily on the WG datatracker page: 
https://datatracker.ietf.org/group/tsvwg/about/ and of course the 
"Documents" tab there takes you to the copies of all the documents.


There have been updates on L4S and presentations/discussions at the IETF 
meetings (with minutes and charts posted to the proceedings), as well as 
L4S draft reviews and comment threads on the TSVWG list whose archives 
are under "List archive".  You can find meeting minutes and slide decks 
also readily linked from that WG page: 
https://datatracker.ietf.org/group/tsvwg/meetings/


There are source code repositories, papers, videos, etc. that the 
proponents have also made very easy to find, e.g. 
https://riteproject.eu/dctth/#code (and as linked in meeting materials).


Since we (TSVWG chairs) are looking for inputs towards WGLC readiness to 
proceed on these, hopefully this information is helpful for you.



On 3/15/2019 6:46 AM, Dave Taht wrote:
> ...
>
> Some background to this: after the L4S/TCP Prague/and dualpi 
experiments appeared stalled out indefinitely in the IETF, and with our 
own frustration with IETF processes, bufferbloat.net project members 
publicly formed our own working group to look into the problems with 
ecn, back in august of last year.


___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

[6lo] Tsvart last call review of draft-ietf-6lo-nfc-12

[Wesley Eddy]

Reviewer: Wesley Eddy
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.

The use cases for this are not described well.  For instance, section 3.1 talks
about sharing contact information and files with a touch between devices, but
then subsequently talks about sending over the Internet.  It doesn't follow
logically that sharing data locally with a peer on the link somehow requires
IPv6 connectivity to the Internet.  This section mentions "card emulation,
peer-to-peer, and reader/writer" modes of operation for NFC, but not which ones
might be relevant for running IPv6 over top of, or how they would differ in
usage.  There seems to be an implicit assumption that the passive end of an NFC
connection might want to communicate with the Internet, but why this would ever
be the case is not discussed.  This would be relevant to understanding how
transport and applications are implemented on the passive devices, for instance.

Section 3.2 leaves out a lot of details about how the link operates.  For
instance, it mentions connectionless and connection-oriented exchanges without
much clarity on what they would be relevant for for IPv6 transport, and also
mentions the "symmetry procedure" without explaining what that is or why it is
important.  It does not mention how the data rates are selected and controlled
or might vary, which would be relevant to transport protocols.

Section 3.4 seems to be saying that the default MTU for NFC is 128 bytes, which
would not be sufficient for IPv6.  If I'm understanding correctly, this section
should really be saying that an implementation MUST utilize the MIUX NFC
extension in order to provide a suitable MTU relevant for IPv6.  Instead, the
document seems to indicate that it's okay to go with the 128 byte default? 
Section 4.8 later on seems to be more clear about this and makes it seem like
the implementer has a choice to either (1) use MIUX to support at least 1280
byte MTUs, or (2) use the FAR functionality to achieve the same.  Stating this
more clearly and consistently across the document is needed.

Some questions not addressed:

(1) Are there relations that need to be considered between IP header bits like
the DSCP or ECN signalling relevant to NFC links, or is it expected that NFC
links/hosts would not be able to utilize these meaningfully?

(2) How are upper layers made aware of the MTU supported on the link if it
could established via either MIUX or FAR?  TCP and other protocols need the
correct information in order to send packets properly.

(3) The data rate ranges are mentioned, but not whether IP over NFC links would
be expected to have some type of delays or variation in delays associated with
them or typical frame loss rates, etc. that might be of interest in properly
configuring transport protocols.  One could imagine this might be the case with
passive targets.


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Iotdir early review of draft-ietf-6lo-deadline-time-02

[Wesley Eddy]

Reviewer: Wesley Eddy
Review result: Ready with Issues

The draft is easily readable and can be understood and should be simple to
implement by someone working in the area.

I only have one technical issue that I think should definitely need to be
resolved, and a few small editorial comments.

Technical issues:

- The point of the D-bit is confusing.  It is supposed to indicate whether the
packet MUST be dropped when the deadline is exceeded.  However, if the D-bit is
zero, the document says that a 6LR "MAY" forward the packet anyways.  Since
this uses MAY rather than "MUST" or "MUST NOT", it seems like there should be
some example use case, scenario, or rationale for why an implementer would
choose one way or the other, or how they would include logic to make the
decision when the D-bit is 0.  Fundamentally though, I'm also unsure why a
sender would include a deadline and then set the D-bit to 0 ... is it maybe
something like they still want the packet to be delivered so that network
measurements of current latency or other properties can be measured using the
packet?  If the deadline is missed due to congestion/contention causing
increased delays, then it seems prudent to always drop the packet, in which
case the D-bit would not be needed.

Editorial comments:

- In Section 1, 2nd paragraph, it would probably be good to explain what an
elective RH is and define 6LoRHE as an elective 6LoRH here, before "6LoRHE" is
used in the Deadline-6LoRHE name.

- In Section 1, last paragraph, it would be good to add informative references
for the last two sentences mentioning Bluetooth and Wi-SUN work in this area.

- In Section 4, last paragraph, it might be worth mentioning for clarity that
there are also potentially long serialization delay and MAC layer contention
delays in some of the relevant network types.  These could dominate propagation
and queueing that are mentioned, in some feasible cases.

- The "Length of DT field" and "Length of OT field" descriptions seem a bit
light, although from the examples it is clear, but they could be replaced with
something more clear like "Length of DT field as an unsigned 3-bit integer,
encoding the length of the field in octets, minus one."


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: statement regarding keepalives

[Wesley Eddy]

Hi Kent, I agree with the spirit of the statement / guidance you've drafted.

You might want to tweak some of the wording, e.g. "test more aliveness" 
could be "test more layers of functionality" or something like that, but 
this is just a nit.


I think the footnote recommending short-lived connections should be more 
clear about why that's the recommendation.  What is the risk/danger/etc 
of longer-lived connections.  That recommendation seems a bit naked as 
currently described, and actually should probably be more than just a 
footnote.




On 7/12/2018 8:37 PM, Kent Watsen wrote:

Dear TSVAREA,

The folks working with the BBF asked the NETMOD WG to consider modifying 
draft-ietf-netconf-netconf-client-server to support TCP keepalives [1].  However, it 
is unclear what IETF's position is on the use of keepalives, especially with regards 
to keepalives provided in protocol stacks (e.g.,  over HTTP over TLS 
over TCP).

After some discussion with Transport ADs (Spencer and Mijra) and the TLS ADs 
(Eric and Ben), the following draft statement has been crafted.  Spencer and 
Mijra have requested TSVAREA critique it before, perhaps, developing a 
consensus document around it in TSVWG.

It would be greatly appreciated if folks here could review and provide comments 
on the draft statement below.  The scope of the statement can be increased or 
reduced as deemed appropriate.

[1] https://mailarchive.ietf.org/arch/msg/netconf/MOzcZKp2rSxPVMTGdmmrVInwx2M

Thanks,
Kent (and Mahesh) // NETCONF chairs


= STATEMENT =

When the initiator of a networking session needs to maintain a persistent 
connection [1], it is necessary for it to periodically test the aliveness of 
the remote peer.  In such cases, it is RECOMMENDED that the aliveness check 
happens at the highest protocol layer possible that is most meaningful to the 
application, to maximize the depth of the aliveness check.

E.g., for an HTTPS connection to a simple webserver, HTTP-level keepalives 
would test more aliveness than TLS-level keepalives.  However, for a webserver 
that is accessed via a load-balancer that terminates TLS connections, TLS-level 
aliveness checks may be the most meaningful check that could be performed.

In order to ensure aliveness checks can always occur at the highest protocol layer, it is 
RECOMMENDED that protocol designers always include an aliveness check mechanism in the 
protocol and, for client/server protocols, that the aliveness check can be initiated from 
either peer, as sometimes the "server" is the initiator of the underlying 
networking connection (e.g., RFC 8071).

Some protocol stacks have a secure transport protocol layer (e.g., TLS, SSH, 
DTLS) that sits on top of a cleartext protocol layer (e.g., TCP, UDP).  In such 
cases, it is RECOMMENDED that the aliveness check occurs within protection 
envelope afforded by the secure transport protocol layer.  In such cases, the 
aliveness checks SHOULD NOT occur via the cleartext protocol layer, as an 
adversary can block aliveness check messages in either direction and send fake 
aliveness check messages in either direction.

[1] While reasons may vary for why the initiator of a networking session feels 
compelled to maintain a persistent connection.  If the session is primarily 
quiet, and the use case can cope with the additional latency of starting a new 
connection, it is RECOMMENDED to use short-lived connections, instead of 
maintaining a long-lived persistent connection using aliveness checks.

Re: [aqm] Status of the GSP AQM?

[Wesley Eddy]

On 12/14/2017 4:35 PM, Roland Bless wrote:

Hi folks,

I was wondering what happened to the GSP AQM proposal
(draft-lauten-aqm-gsp see
(https://tools.ietf.org/html/draft-lauten-aqm-gsp).
Discussion seems to have ended after IETF 93 and we probably
missed the point of discussing WG adoption.
IMHO this AQM should also be documented as RFC. It performs extremely
well in some settings (better than CoDel or PIE) and its implementation
complexity is also lower. Wolfram, are you interested in finishing this?
Should we continue in tsvwg?



I mentioned GSP as a possible work item, back when we were discussing 
rechartering, but apparently it was not compelling to the group at that 
time.


When we did the AQM algorithm adoption call ~2014, GSP appeared to be 
basically viable technically, but there wasn't evidence that multiple 
parties were interested in working with it enough to go forward (not 
just working the document, but implementing, simulating, testing, 
analyzing, deploying, etc).   There is a thread in the archives with 
subject "[aqm] adoption call: algorithm drafts".


I haven't noticed a change in activity around GSP since then, but 
apologize if I'm just ignorant of it!



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] codel and fq_codel drafts

[Wesley Eddy]

On 7/6/2017 11:49 AM, Dave Taht wrote:

It appears that the codel draft is still not done?

I am not attending this ietf, but if there is any way to to incent the
authors to finish this up - feeding 'em beer and cookies, or strapping
'em to a chair with bungie cords in front of a laptop - or all three!
I'd be *very*
supportive.



It's passed the IESG balloting and approved, but (I believe) waiting on 
the editors to make some improvements that were noted during the IESG 
review, described here:

https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ballot/


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] WG status

[Wesley Eddy]

I think there are no surprises here, but as there is an IETF meeting 
coming up, I wanted to make sure the AQM WG status is clear.


The final working group document (on CoDel) is now in IETF Last Call, on 
the main IETF list.


AQM does not plan to meet in Chicago, and should be closed down as the 
CoDel draft becomes published.  HOWEVER, the work on L4S and DualQ that 
has been discussed here is continuing in the TSVWG.  People that are 
interested in this should definitely be joining the TSVWG list and 
discussing it there:


https://www.ietf.org/mailman/listinfo/tsvwg

TSVWG has agenda time planned in Chicago for L4S, so you may wish to 
participate there.


For any additional or future work on AQM algorithms, implementation, 
etc., I think there will be several possible options that can apply 
depending on what the work is, including: ICCRG, TSVWG, AD-sponsoring, 
individual submissions, etc.  As usual, ask the ADs when in doubt :)




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Wesley Eddy]

On 2/22/2017 1:58 PM, David Mazieres wrote:

Wesley Eddy  writes:


1) edge cases where you're communicating with non-ENO hosts, that do not
discard data on SYNs (for whatever reason), and may pollute the data
stream delivered to the application, breaking the goals of TCPINC to
work without impacting the application's TCP mapping

2) cases where other TCP extensions (perhaps yet to-be-defined) do
something in conflict with that data

Can you make concrete suggestions for wording changes?  In particular,
we intended to address the points you raised with the following language
of section 4.7:

1)

 If a host sends a SYN-only SYN+ENO segment bearing data and
 subsequently receives a SYN-ACK segment without an ENO option,
 that host MUST reset the connection even if the SYN-ACK segment
 does not acknowledge the SYN data...



Saying "reset the connection" is interesting to me, because technically 
there is not yet any connection (there are TCBs at each side, but 
neither has entered ESTABLISHED state).  The reset that's sent should 
probably *not* acknowledge any data that may have been on the SYN-ACK, 
which seems important to state.  That way, if some application's 
transaction erroneously started due to data on the SYN, any response 
piggybacking the SYN-ACK would not be acknowledged, and the RST should 
cause the application transaction to fail.




 To avoid unexpected connection resets, ENO implementations MUST
 disable the use of data in SYN-only segments by default.



In my opinion, it might be better to disable the use of data in SYN-only 
segments unless the peer's ENO capability is already known through some 
means (e.g. TCB cache from prior connections).



___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Wesley Eddy]

I haven't been following the WG discussions closely, so apologize in 
advance if this has been beat to death ... In reviewing the present 
draft, section 4.7 seems awkward to me.


I think the WG should consider taking a position that data-on-SYN for 
TEPs should only be permitted to be sent if you have some prior 
indication that ENO is understood by the other end (e.g. via a cache 
entry from a previous connection, or other means).


While the draft correctly says that discarding data on SYNs may already 
be a common practice, it seems to me that there could be two issues, 
including:


1) edge cases where you're communicating with non-ENO hosts, that do not 
discard data on SYNs (for whatever reason), and may pollute the data 
stream delivered to the application, breaking the goals of TCPINC to 
work without impacting the application's TCP mapping


2) cases where other TCP extensions (perhaps yet to-be-defined) do 
something in conflict with that data


I think it goes along with being 'conservative in what you send' to only 
include TEP data on the SYN if ENO is highly likely to be supported by 
the other side.




On 1/23/2017 6:15 PM, Kyle Rose wrote:
This is a working group last call for the "TCP-ENO: Encryption 
Negotiation Option" draft available at 
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/. Please 
review the document and send your comments to the list by 
2017-February-15.


-Kyle and David



___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc


___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [aqm] I am setting up a per holiday cron job

[Wesley Eddy]

Hi Dave, thanks for asking :)

Since I've been the assigned shepherd for both, here's an update for the 
working group on status:


- The fq-codel draft cleared the working group last call, IETF last 
call, and IESG reviews, and has been waiting in the RFC Editor's queue 
on the codel draft (in RFC editor cluster #288: 
https://www.rfc-editor.org/cluster_info.php?cid=C288 ).


- The codel draft cleared the working group last call, and is in AD 
review, with some comments back and forth between Mirja and the 
editors.  As I understand, there is a question about compatibility 
between the IETF Trust statements at the beginning and later text in the 
document that talks about copyright and licensing of code snippets, 
which they are working through and getting advice on.




On 2/14/2017 1:30 AM, Dave Taht wrote:

the template:

For [INSERT HOLIDAY], I'd really love to see a codel & fq_codel RFC published.






___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [Bloat] Fixing bufferbloat in 2017

[Wesley Eddy]

On 11/28/2016 10:12 AM, Dave Taht wrote:

On Mon, Nov 28, 2016 at 4:48 AM, David Collier-Brown  wrote:

A short RFC with a clear summary would change the ground on which we stand.
Include me in if you're planning one.

Call me grumpy. Call me disaffected. But it's been 4 years into the
IETF RFC process with codel and fq_codel with still no end in sight.




Hi Dave, while it's been undeniably slow, "no end in sight" is not 
really accurate.  Here is the correct status, since I am document 
shepherd for both:


- The fq-codel draft is completely and totally done in terms of IETF 
process, and has been in the RFC Editor's queue simply awaiting the 
codel draft to arrive.  This is what the "MISSREF" state indicates in 
that IETF datatracker tool.  It completed the IETF last call and IESG 
balloting in March/April earlier this year.


- The codel document completed AQM working group last call, and I 
believe is awaiting the authors to make changes requested by the Area 
Director in order to go for IETF Last Call and IESG balloting.


The end is most definitely within sight!


___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [aqm] Fwd: New Version Notification for draft-ietf-aqm-codel-05.txt

[Wesley Eddy]

Hi Dave, we sent the publication request on 11/1, and Mirja quickly 
performed an AD review with comments on 11/2, that I think she's waiting 
for resolution on in order to take it to the IETF-wide LC and IESG 
telechat.




On 11/21/2016 2:03 PM, Dave Täht wrote:

Are we done here? Can we just publish this and the fq_codel draft soon?

On 10/31/16 5:12 PM, Jana Iyengar wrote:

Hi all,

We've submitted an updated version of the draft. I believe this
addresses all outstanding comments on the draft.

Specifically, it addresses all the nits Wes pointed out. It also
addresses the two concerns raised on the list earlier:
1. Inconsistency between text and algorithm on 1.1 x interval. We've
changed the text to be consistent with the pseudo-code, which is 1.0 x
interval.
2. We've added some text around the frequency and importance of
re-entering dropping state. Specifically, the last two sentences in the
following para of Sec 4.1:
   "Additional logic prevents re-entering the dropping state too soon
after exiting it and resumes the dropping state at a recent control
level, if one exists.  This logic is described more precisely in the
pseudo-code below.  Additional work is required to determine the
frequency and importance of re-entering the dropping state."

Thanks,
- jana

-- Forwarded message --
From: ** mailto:internet-dra...@ietf.org>>
Date: Mon, Oct 31, 2016 at 4:59 PM
Subject: New Version Notification for draft-ietf-aqm-codel-05.txt
To: Kathleen Nichols mailto:nich...@pollere.com>>,
Janardhan Iyengar mailto:j...@google.com>>, Andrew
McGregor mailto:andrewm...@google.com>>, Van
Jacobson mailto:v...@google.com>>



A new version of I-D, draft-ietf-aqm-codel-05.txt
has been successfully submitted by Janardhan Iyengar and posted to the
IETF repository.

Name:   draft-ietf-aqm-codel
Revision:   05
Title:  Controlled Delay Active Queue Management
Document date:  2016-10-31
Group:  aqm
Pages:  28
URL:
https://www.ietf.org/internet-drafts/draft-ietf-aqm-codel-05.txt

Status: https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/

Htmlized:   https://tools.ietf.org/html/draft-ietf-aqm-codel-05

Diff:
  https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-codel-05


Abstract:
This document describes a general framework called CoDel (Controlled
Delay) that controls bufferbloat-generated excess delay in modern
networking environments.  CoDel consists of an estimator, a setpoint,
and a control loop.  It requires no configuration in normal Internet
deployments.  CoDel comprises some major technical innovations and
has been made available as open source so that the framework can be
applied by the community to a range of problems.  It has been
implemented in Linux (and available in the Linux distribution) and
deployed in some networks at the consumer edge.  In addition, the
framework has been successfully applied in other ways.

Note: Code Components extracted from this document must include the
license as included with the code in Section 5.




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




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Fwd: New Version Notification for draft-ietf-aqm-codel-05.txt

[Wesley Eddy]

Thanks; I've completed the shepherd write-up now, and sent it to Mirja 
for AD review.


I noticed that references [6] and [7] are duplicates, and the text 
citing them is mangled ... but this can be noted for bundling with other 
fixes that may result from AD review, IETF last call, or IESG review.




On 10/31/2016 8:12 PM, Jana Iyengar wrote:

Hi all,

We've submitted an updated version of the draft. I believe this 
addresses all outstanding comments on the draft.


Specifically, it addresses all the nits Wes pointed out. It also 
addresses the two concerns raised on the list earlier:
1. Inconsistency between text and algorithm on 1.1 x interval. We've 
changed the text to be consistent with the pseudo-code, which is 1.0 x 
interval.
2. We've added some text around the frequency and importance of 
re-entering dropping state. Specifically, the last two sentences in 
the following para of Sec 4.1:

  "Additional logic prevents re-entering the dropping state too soon
   after exiting it and resumes the dropping state at a recent control
   level, if one exists.  This logic is described more precisely in the
   pseudo-code below.  Additional work is required to determine the
   frequency and importance of re-entering the dropping state."

Thanks,
- jana

-- Forwarded message --
From: mailto:internet-dra...@ietf.org>>
Date: Mon, Oct 31, 2016 at 4:59 PM
Subject: New Version Notification for draft-ietf-aqm-codel-05.txt
To: Kathleen Nichols >, Janardhan Iyengar >, Andrew McGregor >, Van Jacobson >




A new version of I-D, draft-ietf-aqm-codel-05.txt
has been successfully submitted by Janardhan Iyengar and posted to the
IETF repository.

Name:   draft-ietf-aqm-codel
Revision:   05
Title:  Controlled Delay Active Queue Management
Document date:  2016-10-31
Group:  aqm
Pages:  28
URL: https://www.ietf.org/internet-drafts/draft-ietf-aqm-codel-05.txt 

Status: https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ 

Htmlized: https://tools.ietf.org/html/draft-ietf-aqm-codel-05 

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-codel-05 



Abstract:
   This document describes a general framework called CoDel (Controlled
   Delay) that controls bufferbloat-generated excess delay in modern
   networking environments.  CoDel consists of an estimator, a setpoint,
   and a control loop.  It requires no configuration in normal Internet
   deployments.  CoDel comprises some major technical innovations and
   has been made available as open source so that the framework can be
   applied by the community to a range of problems.  It has been
   implemented in Linux (and available in the Linux distribution) and
   deployed in some networks at the consumer edge.  In addition, the
   framework has been successfully applied in other ways.

   Note: Code Components extracted from this document must include the
   license as included with the code in Section 5.




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




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of codel WGLC

[Wesley Eddy]

In my opinion, point 1 would be a research topic to mention in section 9 
(or other suitable place).  Since we want to encourage wide 
experimentation, it's a good idea to be explicit about what some of the 
open questions/topics are.




On 9/29/2016 12:29 PM, Jana Iyengar wrote:

Hi Wes, Roland,

There are two issues in that email:
1. The importance of reentering state. This is clearly a matter for 
evaluation, and further evaluation will surely yield more results. We 
cannot and won't be perfect in this draft, but I encourage further 
evaluation and work that can perhaps even lead to a future update to 
this draft. We don't intend to address this point in the draft.
2. Consistency of drop_next_. We should be consistent, this was an 
oversight. We'll fix the algorithm to be consistent with the text.


We'll send out a revised draft early next week.
- jana

On Wed, Sep 21, 2016 at 12:55 AM, Bless, Roland (TM) 
mailto:roland.bl...@kit.edu>> wrote:


Hi Wes and all,

Am 14.09.2016 um 15:26 schrieb Wesley Eddy:
> Hi, for awhile, the CoDel draft was in working group last call. Some
> comments were received, and the authors made an update some time
ago.
> There hasn't been much follow-up discussion.  I assume this
means the
> current draft meets people's expectations?  If not, now is a
good time
> to shout, because I'm working on the shepherd write-up so that
it can be
> submitted to the IESG soon.

No, still some issues that were raised here:
https://mailarchive.ietf.org/arch/msg/aqm/ENA1VZmcFVXCJWrMIbmey4wAYnw
<https://mailarchive.ietf.org/arch/msg/aqm/ENA1VZmcFVXCJWrMIbmey4wAYnw>

that are not fixed yet.
I pointed that out at the mic within the AQM session @IETF96.
Andrew said that they need to do the changes and then resubmit.

Regards,
 Roland


___
aqm mailing list
aqm@ietf.org <mailto:aqm@ietf.org>
https://www.ietf.org/mailman/listinfo/aqm
<https://www.ietf.org/mailman/listinfo/aqm>




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of codel WGLC

[Wesley Eddy]

The idnits issues link should have been: 
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-aqm-codel-04.txt


Apologies for the copy-paste error.


On 9/14/2016 9:26 AM, Wesley Eddy wrote:
Hi, for awhile, the CoDel draft was in working group last call. Some 
comments were received, and the authors made an update some time ago.  
There hasn't been much follow-up discussion.  I assume this means the 
current draft meets people's expectations?  If not, now is a good time 
to shout, because I'm working on the shepherd write-up so that it can 
be submitted to the IESG soon.


https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/

There are a few small things I noticed while doing the shepherd write-up:

1) I thought the ADs and WG were happy to go Experimental rather than 
Informational 
(https://www.ietf.org/mail-archive/web/aqm/current/msg01727.html ) ... 
was there a reason from the authors that it didn't change?


2) Idnits has some minor issues 
https://www.ietf.org/mail-archive/web/aqm/current/msg01727.html


a) it doesn't like the reference "[CODEL2012]" in the abstract

b) for referencing RFC 896, there's inconsistent "RFC896" vs 
"RFC0896" (use the zero or don't, but it should match)


c) the "[CMNTS]" reference is unused

d) some of the obsolete references should be checked.



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] status of codel WGLC

[Wesley Eddy]

Hi, for awhile, the CoDel draft was in working group last call. Some 
comments were received, and the authors made an update some time ago.  
There hasn't been much follow-up discussion.  I assume this means the 
current draft meets people's expectations?  If not, now is a good time 
to shout, because I'm working on the shepherd write-up so that it can be 
submitted to the IESG soon.


https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/

There are a few small things I noticed while doing the shepherd write-up:

1) I thought the ADs and WG were happy to go Experimental rather than 
Informational 
(https://www.ietf.org/mail-archive/web/aqm/current/msg01727.html ) ... 
was there a reason from the authors that it didn't change?


2) Idnits has some minor issues 
https://www.ietf.org/mail-archive/web/aqm/current/msg01727.html


a) it doesn't like the reference "[CODEL2012]" in the abstract

b) for referencing RFC 896, there's inconsistent "RFC896" vs 
"RFC0896" (use the zero or don't, but it should match)


c) the "[CMNTS]" reference is unused

d) some of the obsolete references should be checked.

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [tcpinc] TCP's treatment of data in SYN packets

[Wesley Eddy]

On 7/29/2016 2:47 PM, Joe Touch wrote:

FWIW, IMO the best wording would:

- start with the simplest case, i.e., NOT trying to optimize EDO to use
SYN data

- present the use of SYN data with EDO as an optimization
 that optimization might be a MAY or SHOULD, but not a MUST

Otherwise, you're needlessly complicating your spec for an optimization.



Just to be clear, this is actually talking about ENO, and not EDO, 
correct?  (I'm assuming a repeated typo in your message)


SYN data with EDO does not need any special discussion, because EDO only 
alters DO semantics for later (non-SYN) segments.  So, how a stack deals 
with data on SYN is un-related to EDO (but more critical for ENO).





___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

[aqm] meeting update

[Wesley Eddy]

There's an update pending to the agenda for the AQM meeting.

It is currently planned for AQM to use the last 45 minutes of the TSVWG 
timeslot on Friday morning.  The ADs have send a request to update the 
agenda, and the TSVWG agenda includes it already: 
https://datatracker.ietf.org/meeting/96/agenda/tsvwg/


There didn't appear to be any top-order scheduling conflicts with this 
move, and it was assumed that most of the people interested in the AQM 
meeting were planning to be in TSVWG as well. Apologies if this was a 
bad assumption.


Sorry for any confusion this will cause!  We'll try to make sure it's 
marked clearly on the agenda site.


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Berlin meeting

[Wesley Eddy]

Thanks to those who provided feedback.

We will plan to go ahead with the face-to-face meeting since several 
people are interested and will post an agenda shortly.


As always, please continue to also discuss topics on the mailing list.  
Several people have shared some thoughts on rechartering topics, though 
it's not clear that there is yet much agreement on specific topics that 
there would be common energy for.




On 6/29/2016 10:06 AM, Wesley Eddy wrote:
Hello, as you might have noticed, for Berlin, the AQM group is 
scheduled to meet on Friday: 
https://datatracker.ietf.org/meeting/96/agenda.html


The main goal of having the in-person meeting is to talk about closing 
the WG or rechartering.


As this is in the last slot, on the last day, and many people are 
likely to be trying to return home, we need to make sure there will be 
a critical mass to meaningfully hold a meeting, and not waste time.  
We are also having trouble getting both WG chairs present, in addition.


To gauge if it will be productive to meet, or if we should pursue 
other options, we created a Doodle poll:


http://doodle.com/poll/tht446xwu25uywat


Your feedback will be appreciated.

Note that more than one option can be selected.

A more verbose explanation of the options is:

1) "In-person meeting in Berlin" - this means we go along with the 
current plan and hold the meeting in Berlin


2) "Webex meeting in August" - this means the chairs would setup a 
webex to discuss rechartering in the month following the IETF meeting


3) "Mailing list only" - means you think we can figure out what to do 
from the mailing list only


4) "Close the WG; no interest to discuss rechartering" - means that 
you don't think we need to talk about this at all, and think the WG 
can spin down



Thanks for your help in this!




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] Berlin meeting

[Wesley Eddy]

Hello, as you might have noticed, for Berlin, the AQM group is scheduled 
to meet on Friday: https://datatracker.ietf.org/meeting/96/agenda.html


The main goal of having the in-person meeting is to talk about closing 
the WG or rechartering.


As this is in the last slot, on the last day, and many people are likely 
to be trying to return home, we need to make sure there will be a 
critical mass to meaningfully hold a meeting, and not waste time.  We 
are also having trouble getting both WG chairs present, in addition.


To gauge if it will be productive to meet, or if we should pursue other 
options, we created a Doodle poll:


http://doodle.com/poll/tht446xwu25uywat


Your feedback will be appreciated.

Note that more than one option can be selected.

A more verbose explanation of the options is:

1) "In-person meeting in Berlin" - this means we go along with the 
current plan and hold the meeting in Berlin


2) "Webex meeting in August" - this means the chairs would setup a webex 
to discuss rechartering in the month following the IETF meeting


3) "Mailing list only" - means you think we can figure out what to do 
from the mailing list only


4) "Close the WG; no interest to discuss rechartering" - means that you 
don't think we need to talk about this at all, and think the WG can spin 
down



Thanks for your help in this!


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] working group status and rechartering vs. closing

[Wesley Eddy]

Hello; the AQM list has been mostly quiet recently, other than 
discussion around the IESG comments on our drafts as they progress 
through the IESG review, so I thought it would be a good time to send a 
status snapshot and start more discussion about rechartering.


The datatracker page tells the story well, I believe: 
https://datatracker.ietf.org/wg/aqm/documents/


The main thing we need to work on before closing/rechartering is getting 
the CoDel draft finished.  I believe the editors have the working group 
last call comments and are planning an update to address them.  The goal 
should be to close the loop on these with the reviewers and get this 
into the IESG's queue before the next meeting in July.


We are planning for a 1-hour meeting at the next IETF meeting in July, 
in order to discuss next-steps for the working group, which could be 
either shutting down or rechartering.


We succeeded early on in getting RFC 7567 published and it looks like 
we'll soon have Experimental RFCs for 2 of the algorithms most people 
have worked with to-date.  Both specs became more clear and were 
improved through the WG reviews.  Additionally, we also have RFC 7806, 
the ECN benefits document, the characterization guidelines, FQ-CoDel, 
and DOCSIS-PIE descriptions that were completed.


We should think about what would be needed going forward.  Some 
questions for rechartering might be:


-  What would the group expect to advance algorithms from Experimental 
to Standards Track?  (e.g. more data from real deployments, more 
analysis of edge cases, etc) ... and are there people with time and 
support to meet whatever those expectations are?


- Are the current couple of algorithms all that's needed for the 
Internet, or are there other algorithms building on these, learning from 
experience with them, or making other improvements which we should work 
on?  (e.g. we have the DualQ draft, and recently the GSP draft has been 
updated)


- Are there ongoing field deployments, research projects, and other 
efforts that it will be good to discuss together in the working group, 
towards improving or advancing the current algorithms, or towards new 
algorithms?


- Is there other operations experience or considerations that should be 
documented?


Of course, this is not a complete list, but I thought formulating a few 
questions like this could help in determining if a recharter is 
justified rather than simply closing.  Your thoughts on these and any 
other relevant topics will be useful to hear on the mailing list and in 
Berlin.



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC

[Wesley Eddy]

On 3/24/2016 9:01 AM, Toke Høiland-Jørgensen wrote:

Dave Cridland  writes:


Well, I have to ask why, in this case, it's Experimental and not
Standards-Track?

Heh. Well, I guess the short answer is "because there wasn't WG
consensus to do that". Basically, the working group decided that all the
algorithms we are describing will be experimental rather than standards
track, at least for now. Because they are queueing algorithms and not
protocols (and so do not have the same interoperability requirements),
this was deemed an acceptable way forward, and a way to get it "out
there" without having to have to agree to push for The One True AQM(tm).

(This is my understanding; I'm sure someone will chime in and correct me
if I'm wrong).


Personally, I would have no problem with this being standards track :)





I am one of the WG chairs and document shepherd.  The AQM charter does 
allow for publication on the Standards Track, but at this point in time 
there did not seem to be a consensus that this was necessary, plus given 
some of the open research questions, it seemed like a prudent choice.  
We can always go stronger and make a standard later on.


I think Bob's concerns here, and the disagreement about what happens in 
reality, make it very obvious that Experimental is the right choice!  
The indications so far are that this has a lot of promise to help, but 
there are questions, and it could benefit from even more experience 
deploying in the wild, and watching what happens.



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] I-D Action: draft-ietf-aqm-codel-03.txt

[Wesley Eddy]

On 3/21/2016 5:10 PM, Polina Goltsman wrote:


First of all our feedback regarding different "re-entering dropping 
state" in the document and in the Linux implementation 
(http://www.ietf.org/mail-archive/web/aqm/current/msg01686.html) was 
not addressed.





Thank you for double-checking; the editors should look into this and 
respond.



As FQ-CoDel  relies on CoDel, this issue is also (partly) relevant for 
the FQ-CoDel document. In the introduction FQ-CoDel references ns-3 
and Linux implementations where the first one uses the re-entering 
logic from the CoDel document while the second from CoDel Linux 
implementation. The algorithm that has seen widespread testing 
according to Section 7 is (I suppose) the Linux version. Is this 
situation acceptable for an algorithm specification?



This is a good question.  I believe for "Experimental", it's acceptable, 
but greater clarity would obviously be good.



/[since this comment was supposed to be sent before the end of 2015, 
feel free to (silently) ignore it]/


Since there are still some things that need to be tweaked in the 
document, there is still time to make constructive comments, so thanks 
for providing them!// I'd like the editors to examine them and respond./



/


Second, unlike Rasool Al-Saadi (see 
http://www.ietf.org/mail-archive/web/aqm/current/msg01693.html) I do 
not like the document. Although I agree that the pseudocode is 
sufficient to create a working implementation, however, in my opinion, 
the rest of the document makes implementing CoDeL more confusing (at 
least without reading [CODEL2012] first). Is it normal for a RFC, 
which, as I assume, should primarily contain an algorithm 
specification to contain the algorithm specification ONLY in form of 
pseudocode?



To be clear, the RFC doesn't need to completely "stand alone" (there is 
an Informative References section for good reason), however, it should 
certainly be internally clear.I definitely think the editors should 
consider and respond to your specific comments that were below this, as 
they seem like they might help improve clarity.


Thanks for your feedback!



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] I-D Action: draft-ietf-aqm-codel-03.txt

[Wesley Eddy]

It looks like the WGLC feedback on the document body is incorporated, so 
this is good.


Is there a reason to stay with Informational and not Experimental like 
we've done with PIE an d FQ-CoDel?


Also, idnits has some problems with the references that should be fixed 
(e.g. "NATAL2010" is probably supposed to be "NETAL2010"):

https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-aqm-codel-03.txt





On 3/15/2016 8:00 PM, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Active Queue Management and Packet Scheduling 
of the IETF.

 Title   : Controlled Delay Active Queue Management
 Authors : Kathleen Nichols
   Van Jacobson
   Andrew McGregor
   Janardhan Iyengar
Filename: draft-ietf-aqm-codel-03.txt
Pages   : 28
Date: 2016-03-15

Abstract:
This document describes a general framework called CoDel (Controlled
Delay) [CODEL2012] that controls bufferbloat-generated excess delay
in modern networking environments.  CoDel consists of an estimator, a
setpoint, and a control loop.  It requires no configuration in normal
Internet deployments.  CoDel comprises some major technical
innovations and has been made available as open source so that the
framework can be applied by the community to a range of problems.  It
has been implemented in Linux (and available in the Linux
distribution) and deployed in some networks at the consumer edge.  In
addition, the framework has been successfully applied in other ways.

Note: Code Components extracted from this document must include the
license as included with the code in Section 5.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-aqm-codel-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-codel-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] Fwd: Re: [Gen-art] Gen-art LC review of draft-ietf-aqm-fq-codel-05

[Wesley Eddy]

FYI -


 Forwarded Message 
Subject:Re: [Gen-art] Gen-art LC review of draft-ietf-aqm-fq-codel-05
Date:   Thu, 10 Mar 2016 08:07:06 +1300
From:   Brian E Carpenter 
Organization:   University of Auckland
To: 	Elwyn Davies , 
draft-ietf-aqm-fq-codel@ietf.org

CC: General area reviewing team 



On 10/03/2016 06:12, Elwyn Davies wrote:

I am the assigned Gen-ART reviewer for this draft.


And I am another Gen-ART reviewer who saw this go by:

...

Minor issues: Treatment of packets that don't fit into the hashing 
classification scheme:  The default FQ-CoDel hashing
mechanism uses the protocol/addresses/ports 5-tuple, but there will be packets 
that don't fit this scheme (especially ICMP).
There is no mention of what the classification would do with these packets.  I 
guess that one extra queue would probably
suffice to hold any such outliers, but it would be wise to say something about 
how the packets from this/these queue(s) would
be treated by the scheduler.  It might also be useful to say something about 
treatment of outliers in other classification
schemes, if only to say that the scheme used needs to think about any such 
outliers.


For IPv6 there is another issue here: the well-known difficulty in finding
the protocol and port numbers at line speed when extension headers are present.
Which is of course why IPv6 senders are supposed to set the flow label, which
should in turn provide a handy 3-tuple (addresses/flow label) that would be
ideal for CoDel. The operational facts today are that most hosts don't set
the flow label and many paths through the Internet drop packets with extension
headers, but the fact that the 5-tuple is problematic in this way might be
worth mentioning.

Brian




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] Fwd: Gen-art LC review of draft-ietf-aqm-fq-codel-05

[Wesley Eddy]

FYI - some of Elwyn's comments may be of interest to the working group:


 Forwarded Message 
Subject:Gen-art LC review of draft-ietf-aqm-fq-codel-05
Date:   Wed, 9 Mar 2016 17:12:41 +
From:   Elwyn Davies 
To: General area reviewing team 
CC: draft-ietf-aqm-fq-codel@ietf.org



I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-aqm-fq-codel-05.txt
Reviewer: Elwyn Davies
Review Date: 2016/03/06
IETF LC End Date: 2016/03/17
IESG Telechat date: (if known)  2016/03/17

Summary:
Almost ready.  There are a couple of minor issues that are barely above 
the level of nits plus a fair bit of editorial work.


I notice that the draft is on the IESG agenda on the day that last call 
ends.  If the authors wish to sort out the nits before the end of last 
call, I will be happy to work with them on this.


Major issues:
None.

Minor issues:
Treatment of packets that don't fit into the hashing classification 
scheme:  The default FQ-CoDel hashing mechanism uses the 
protocol/addresses/ports 5-tuple, but there will be packets that don't 
fit this scheme (especially ICMP).  There is no mention of what the 
classification would do with these packets.  I guess that one extra 
queue would probably suffice to hold any such outliers, but it would be 
wise to say something about how the packets from this/these queue(s) 
would be treated by the scheduler.  It might also be useful to say 
something about treatment of outliers in other classification schemes, 
if only to say that the scheme used needs to think about any such outliers.


s6.2, last para:  The proposal to add flow related marking to 
encapsulated packets needs to come with a very well exposed security and 
privacy health warning.. [It occurs to me that it might be possible to 
confine these markings to out of band notifications within the 
originating host which would allow fq_codel or similar to Flow Queue the 
packets getting them into a sensible order on the outgoing link.  Once 
the packets had been ordered in this way, a subsequent box (maybe an 
ADSL modem or suchlike) linking a home environment to the outside world 
could work purely on source address, thereby interspersing the packets 
from different hosts onto the external link but not needing to reorder 
the packets from each individual host.  Not sure if this is a sensible 
idea but it looks like a way to avoid the privacy issues.]


s11:  Internet Drafts are not scientific papers as such and do not 
usually have a Conclusions section.  I think it would be useful to move 
the paragraph in s11 as is to s1.  Since this draft is targeted for 
Experimental RFC status, it would be useful to suggest (maybe in s7) 
that experiments along the lines noted in s7 might be carried out and 
there results reported (where?  AQM WG?).  Given the developments with 
Cake, I am not sure whether the authors expect this version of FQ-CoDel 
to make it onto standards track or BCP, but to set out some sort of 
expected trajectory is desirable.


Nits/editorial comments:
General: s/i.e./i.e.,/, s/e.g./e.g.,/

Draft Title: The acronym CoDel with an uppercase D is used everywhere 
else in the document - Suggest the title should be FlowQueue-CoDel


Abstract:   Need to expand AQM. [DNS and and CPU are 'well-known' - 
http://www.rfc-editor.org/materials/abbrev.expansion.txt]


General: It would be helpful to capitalize Quantum throughout (or at 
least from s3 onwards)  to emphasise that it is a configured value.  
Likewise Interval and Target parameters.  Maybe also Flow and Queue as 
they a defined terms.


s1, para 1: It would be helpful to give the full title 
(FlowQueue-CoDel), expand AQM (again), provide a refernece explaining 
the term bufferbloat and give references for AQM, basic CoDel, DRR and 
the ns2/ns3 network simulators.


I would think one or both of the following would be useful (long term 
stable) refs for bufferbloat (the first is useful because the article is 
publically available rather than needing a sub to IEEE or ACM):


Jim Gettys. 2011. Bufferbloat: Dark buffers in the Internet. IEEE 
Internet Comput. 15, 3 (2011), 95–96. 
DOI:http://dx.doi.org/10.1109/MIC.2011.56 (freely available at 
http://www.bufferbloat.net/attachments/27/IC-15-03-Backspace.pdf)


and/or
Jim Gettys and Kathleen Nichols. 2012. Bufferbloat:Dark buffers in the 
Internet. Commun. ACM 55, 1 (2012), 1–15. 
DOI:http://dx.doi.org/10.1145/2063176.2063196


Suggest:
OLD:
   The FQ-CoDel algorithm is a combined packet scheduler and AQM
   developed as part of the bufferbloat-fighting community effort.  It
   is based on a modified Deficit Round Robin (DRR) queue scheduler,
   with the CoDel AQM algorithm

Re: [aqm] I-D Action: draft-ietf-aqm-pie-05.txt

[Wesley Eddy]

FYI - I believe this update addresses everything from the working group 
last call, and I plan to complete the shepherd writeup and forward it to 
our AD later this week.




On 3/1/2016 3:16 PM, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Active Queue Management and Packet Scheduling 
of the IETF.

 Title   : PIE: A Lightweight Control Scheme To Address the 
Bufferbloat Problem
 Authors : Rong Pan
   Preethi Natarajan
   Fred Baker
Filename: draft-ietf-aqm-pie-05.txt
Pages   : 26
Date: 2016-03-01

Abstract:
Bufferbloat is a phenomenon where excess buffers in the network cause
high latency and jitter. As more and more interactive applications
(e.g. voice over IP, real time video streaming and financial
transactions) run in the Internet, high latency and jitter degrade
application performance. There is a pressing need to design
intelligent queue management schemes that can control latency and
jitter; and hence provide desirable quality of service to users.

This document presents a lightweight active queue management design,
called PIE (Proportional Integral controller Enhanced), that can
effectively control the average queueing latency to a target value.
Simulation results, theoretical analysis and Linux testbed results
have shown that PIE can ensure low latency and achieve high link
utilization under various congestion situations. The design does not
require per-packet timestamp, so it incurs very small overhead and is
simple enough to implement in both hardware and software.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-aqm-pie/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-aqm-pie-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-pie-05


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] AQM plans

[Wesley Eddy]

Hi, I'm now sorry that we didn't schedule an AQM meeting slot in Buenos 
Aires.  We can certainly pre-load an agenda for Berlin with these topics 
though.  That is a long way in the future, however, so please use the 
mailing list to discuss tests and metrics, share results, advertise 
papers, etc, in the meantime on these topics!




On 2/26/2016 6:23 AM, De Schepper, Koen (Nokia - BE) wrote:

Hi Wes,

Just to let you know that we are still working on AQMs that support scalable 
(L4S) TCPs.
We could present some of our latest results (if there will be a meeting in 
Buenos Aires, otherwise in Berlin?)

* Performance of HTTP Adaptive Video Streaming (HAS) with different TCP's and 
AQMs
o HAS is currently ~30% of Internet traffic, but no AQM testing so far has 
included it
o the results are very poor with a particular popular AQM
Presenter: Inton Tsang
Duration: 10mins
Draft: Comparative testing of draft-ietf-aqm-pie-01, 
draft-ietf-aqm-fq-codel-04, draft-briscoe-aqm-dualq-coupled

For experiment write-up, see Section 3 of 
https://riteproject.files.wordpress.com/2015/12/rite-deliverable-3-3-public1.pdf

* PI^2: PI simplified with a square
o PIE embeds some auto-tuning and heuristics, which can be removed by 
simple transformation of a variable
o Allows PIE to control also scalable congestion controls (DCTCP, ...)
Presenter: Koen De Schepper
Duration: 15mins
Draft: (probably impacted)  draft-ietf-aqm-pie

* DualQ update
o extensive additional tests, including different RTTs and mixed RTTs, 
better visualization
o using other AQMs than Curvy-RED for 'Classic' traffic, e.g. PI^2
Presenter: Koen De Schepper
Duration: 20min
Draft: draft-briscoe-aqm-dualq-coupled-01

Regards,
Koen.



-Original Message-
From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Wesley Eddy
Sent: woensdag 10 februari 2016 20:27
To: aqm@ietf.org
Subject: [aqm] AQM plans

Hello AQMers, this is just a quick note to be clear on working group
status and forward planning.

Currently, all of the active drafts are either in WGLC, or in the
process of shepherd writeups to go the the AD.

Once we get the current set of drafts out for publication, there are a
few things the WG can do:
- close down
- remain open to continue coordinating and advance algorithms (e.g.
within the standards track)
- remain open as a venue for potential new work (e.g. the DualQ Coupled
AQM)

I think we should discuss this and plan to make a decision after the
IETF 96 meeting in Berlin (July 17-22).  We can have a "closing or
re-chartering" meeting in Berlin if it will benefit from face-to-face
discussion.


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-11.txt

[Wesley Eddy]

On 2/15/2016 4:52 AM, Kuhn Nicolas wrote:

All,

This updated version integrates some typos correction (based on Greg Skinner's comment) 
and some reformulation in the "goal description section" based on Polina's 
personal email.




Hi, I've started the shepherd write-up for this and am planning to 
submit it in the next week.  I mention this in case there are still 
comments or concerns that someone has.


In the write-up, I will explain:
- how it changed scope a few times over its lifetime
- that ideally there would be running code (as mentioned by Dave, among 
others) for performing the characterizations
- that where it sits now, it's suitable as Informational guidance, but 
it's not a prescriptive and fully defined spec, like for an IPPM metric


I think this will be sufficient, but would like to know if anyone still 
has further thoughts, or strong feeling that this should be held for 
some other update before AD review?





___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of PIE drafts WGLC

[Wesley Eddy]

On 2/10/2016 3:13 PM, Klatsky, Carl wrote:

Wes,

If the 'algorithm' drafts (CoDel, FQ-CoDel, and PIE) are targeted as Experimental, 
does that mean at some time later their status moves onto either PS (if real-world 
testing & use pans out) or Informational (if no activity further proves it out 
but the authors want to keep the info out there for the community)?  If so, how 
does that occur of the WG closes down?




If there's thrust to go Standards Track this can be done in a number of 
ways, mostly up to the discretion of the Area Directors:

1. done by AQM if it stays open longer-term
2. done by another relevant working group (e.g. TSVWG), if AQM is closed 
down
3. done by a re-incarnation of AQM working group (e.g. a PIE or CODEL 
working group)

4. done by "AD-sponsoring" of an update

In any case, the ADs need to be supportive of the path.

If for some reason any document needed to be deprecated, this could be 
done without the WG, and simply by marking as Obsolete in the RFC Editor 
database.  This would ideally be accompanied and requested by an RFC 
that describes what was found to be wrong, and what the impact is.


So ... in general, I think there's no real limitation imposed on the 
options of what can happen in the future.  However, things are 
definitely easier to do confidently when the working group is open and 
active, because consensus is simpler to judge.


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of PIE drafts WGLC

[Wesley Eddy]

On 1/22/2016 10:01 AM, Wesley Eddy wrote:
Hello; the working group last call on the PIE drafts generated some 
emails, but I don't think I've seen any response from the editors. 
Specifically, there were a couple of emails with algorithm description 
questoins and technical comments from Rasool Al-Saadi and Ilpo 
Jarvinen, both with specific points that should be addressed.


For the most part, as I understand the comments, these are things that 
can be relatively simply fixed up or the intent clarified, and not 
catastrophic issues that would prevent the PIE docs from being 
publishable.  Please correct me if I misunderstand though.


If the editors can respond and work up a revision that addresses the 
comments to the satisfaction of Rasool and Ilpo, I'd like to keep the 
PIE documents moving forward.





To be clear also, I think at this stage, the feedback received from the 
working group isn't supporting Proposed Standard, and that the next 
update should be targeted "Experimental".   I can mark it that way in 
the datatracker, but can't edit the document header myself, and these 
need to be consistent before going to the IESG.


I've heard a couple other people seem to agree with going Experimental 
for the CoDel, FQ-CoDel, and PIE drafts and getting all three into the 
RFC Editor's hands sooner rather than later. (DOCSIS-PIE will be 
Informational.)  I've not yet heard folks saying that they really need a 
PS now and that PIE should be a PS now.


Definitely shout and correct me here if I'm wrong here, but I think this 
is the fastest path forward.





___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] AQM plans

[Wesley Eddy]

Hello AQMers, this is just a quick note to be clear on working group 
status and forward planning.


Currently, all of the active drafts are either in WGLC, or in the 
process of shepherd writeups to go the the AD.


Once we get the current set of drafts out for publication, there are a 
few things the WG can do:

- close down
- remain open to continue coordinating and advance algorithms (e.g. 
within the standards track)

- remain open as a venue for potential new work (e.g. the DualQ Coupled AQM)

I think we should discuss this and plan to make a decision after the 
IETF 96 meeting in Berlin (July 17-22).  We can have a "closing or 
re-chartering" meeting in Berlin if it will benefit from face-to-face 
discussion.



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Experimental vs informational vs standards track

[Wesley Eddy]

On 2/4/2016 9:18 PM, Dave Täht wrote:

Pie itself is proposed as standards track, despite the lack of field
data, a 15 page criticism from bob briscoe of the public implementation,
and other open issues like that. Personally I've been waiting for an
actual modem to test on before bothering to explore more deeply results
from pie than we already have. (There is a study starting up soon where
I hope to finally A/B the stuff)


Before going to the IESG, we need to make sure there is consensus on 
that publication track for PIE.  As you have seen, I'm trying to address 
that for each document as all of the technical WGLC comments are 
addressed and closed out.  I think the PIE editors would like Standards 
Track, if I understand correctly.  I do feel like the working group 
needs to speak up about whether they agree, because as a chair, I 
haven't heard much feedback about it.




And:

I've only recently discovered the pain that "experimental" can cause
when other ietf standards are attempted to be layered on top of it (in
the nascent babel wg). It didn't sound like informational would cost the
same pain. Am I wrong in that assumption?


I'm not familiar with this case, but was on the IESG in the past, and am 
not aware of Experimental causing any real issues for layering or 
referencing in other standards.  This is simply called out in the IETF 
Last Call as a downref, recorded in the downref registry, and life goes 
on.  The running code doesn't care how the document is labelled either :)


IMHO, Standards Track carries more weight to say that there are no sharp 
corners, and the IETF is pretty sure this works well. Experimental is 
more cautious saying this looks pretty useful, and you should consider 
trying it out, but it might have some rough edges (e.g. like open 
research questions, identified in several of the AQM drafts).


Just my 2 cents.

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Experimental vs informational vs standards track

[Wesley Eddy]

Dave, here is a longer answer to your specific questions; I hope this 
helps calibrate where I'm coming from at least:



On 2/4/2016 8:22 PM, Dave Täht wrote:

I realize now that there was a call as to what status it should be
a while.  I figured silence meant there was consensus on informational,
so I was a bit surprised when it was changed. You got my attention!


I think we had discussed focusing on document quality and collecting 
evaluations, test results, etc., and then when ready to publish each 
algorithm, deciding what document track to go on.


For the DOCSIS one, I'm pretty sure there was never any other option 
than Informational, since it was not something IETF was working on. I 
think it is similar in a way to RFC 6057, and others.




so, what criteria apply for experimental vs informational vs standards
track?


For Informational vs Experimental, there is the IESG statement:
https://www.ietf.org/iesg/informational-vs-experimental.html

For the relation with the standards track, I don't know anything that 
describes Experimental vs Standards Track outside of RFC 2026.


AQM's charter allows us to publish on the Standards Track.  I haven't 
seen very much push to do so, personally, and IMHO the standards track 
is not to be taken lightly.  If a lot of people say "yes, definitely, 
algorithm X should be on standards track, and we're comfortable with 
that", that will be convincing ... but the feedback is really light so far.




What blockers apply later, were, for example, another RFC to rely on an
experimental vs informational fq_codel rfc? For example, right now,
fq_codel is the defacto fq+aqm for homenet...

vs standards track?



I don't think there's really any distinction there.  For the IESG, 
Standards Track (or BCP) is definitely better to normatively reference 
from other documents going onto Standards Track, since otherwise the AD 
has to do explain and catalogue the "downref" for IETF Last Call.  
However, this is not uncommon, or very burdensome. There is a running 
list of downrefs, and once an RFC is on it, that can be referenced for 
future IETF LCs:

https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry




No field data exists for docsis-pie. Most of the data on pie is from
sims.  Outside of the docsis standard I know of no deployments of pie
and no hardware support for it (please, someone? is there a roadmap from
any manufacturer with pie in it?).


I don't know about this, but it sounds like a good reason why 
Informational and Experimental tracks would be preferable at the moment 
to Standards Track.




and conversely, since the fq-codel draft describes what has already been
done in linux, deployed in systemd, openwrt, the edgerouter products (as
what it is), as part of more than a few other products, (rebranded),
inside several major cos, and with at least one well known deployed ISP...

...

I regarded fq_codel as experimental 4 years ago. it has survived the
test of time with no substantial changes. Certainly I'd like it to be
self tuning below 2.5mbits, but pie does badly there also without tuning.

...


I believe the Experimental vs Standards Track decision on FQ-CoDel is 
independent of anything to do with PIE.




As for declaring a "proposed standard", it seems as though pie's
standardization status itself has not yet been discussed on this list,
either.


I also would like to see more discussion of what people want to do with 
these documents.  I've tried to be clear about my own thoughts.  As a 
chair, my default is to NOT go standards track unless there's explicit 
push from the working group.




My vote is for docis-pie, pie and fq_codel to have the same status,
whatever it winds up being. Informational seemed fine, across the board.
I'm all in favor of more deployment experience.



Understood, though I'm doubtful that our publication track will impact 
deployment.  I believe we need to make the proper choice for each 
algorithm on its own merits, and not tie them together, personally.  
However, if the working group wants to keep everything at an even status 
though, please shout and tell us what that status is!





___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Experimental vs informational vs standards track

[Wesley Eddy]

On 2/4/2016 8:26 PM, Wesley Eddy wrote:


There is IESG explanation of the distinction here:
https://www.ietf.org/iesg/informational-vs-experimental.html



Quoting from that, I think this is the criteria that makes it most clear 
Informational is appropriate for DOCSIS-PIE:

"""

1. If it's not going to be changed no matter what the result is, it's
   Informational. This is typically the case with vendor protocols; the
   vendor will publish it for the good of the community, but retains
   full change control, and gives no promises about listening to
   community feedback. Case in point: "Microsoft Point-To-Point
   Encryption (MPPE) Protocol" (RFC 3078).

"""

It's simply what was done elsewhere, and not going to be changed.  Greg 
was kind enough to write it up, and it's useful information for the 
community, so the WG had decided to put it forward as Informational.


Does that make sense?



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Experimental vs informational vs standards track

[Wesley Eddy]

On 2/4/2016 8:22 PM, Dave Täht wrote:

I do not really understand how this criterion promotes docsis-pie from
experimental to informational (or the reverse: demotes fq_codel from
informational to experimental, which happened this morning...


Hi Dave, I'm not ignoring the rest of your message, but do need to 
correct one misconception first.


There is no higher or lower relationship between Informational and 
Experimental.


There is IESG explanation of the distinction here:
https://www.ietf.org/iesg/informational-vs-experimental.html


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of PIE drafts WGLC

[Wesley Eddy]

Since none of the questions outstanding from WGLC seem to impact the 
DOCSIS PIE draft directly, I think that it is ready to move forward:

https://datatracker.ietf.org/doc/draft-ietf-aqm-docsis-pie/

Since it's describing what has already been done in DOCSIS, the 
Informational status seems appropriate, and consistent with other 
similar RFCs, so I think we're good there.


There are some small editorial nits found by "idnits" that we need to 
correct (add a security considerations section, add an IANA 
considerations section, and split references section into 
normative/informative):

https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-aqm-docsis-pie-01.txt

I think that is all that needs to be done.




On 1/22/2016 10:01 AM, Wesley Eddy wrote:
Hello; the working group last call on the PIE drafts generated some 
emails, but I don't think I've seen any response from the editors. 
Specifically, there were a couple of emails with algorithm description 
questoins and technical comments from Rasool Al-Saadi and Ilpo 
Jarvinen, both with specific points that should be addressed.


For the most part, as I understand the comments, these are things that 
can be relatively simply fixed up or the intent clarified, and not 
catastrophic issues that would prevent the PIE docs from being 
publishable.  Please correct me if I misunderstand though.


If the editors can respond and work up a revision that addresses the 
comments to the satisfaction of Rasool and Ilpo, I'd like to keep the 
PIE documents moving forward.




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] status of codel WGLC

[Wesley Eddy]

Hi, in December, we started a working group last call on:
https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/
(the -02 version of the document)

A couple of small comments that I've seen since then, but don't think 
were addressed are in:

https://mailarchive.ietf.org/arch/msg/aqm/0NM0D2PtrF08XzTk5M9TLkkybyc

I think based on Dave's responses in that thread, they might be easy to 
address with simple editorial changes, but would like the editors to 
respond or post an update.


Also, the editors should take a quick look at the "idnits" output and 
fix a few errors/warnings (which should be easy):

https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-aqm-codel-02.txt
- need a table of contents
- check the references

I didn't see any feedback about document publication tracks (e.g. 
Standards Track, Informational, Experimental, etc).  We talked to the 
ADs briefly about this, and I think we are comfortable with Experimental 
for this document.  That is the appropriate track if the AQM working 
group thinks this is safe to deploy widely while experimenting with on 
the Internet (which has been happening for quite some time already).  
So, I think version -04 should be labelled with "Intended Status: 
Experimental".


My plan is to complete the shepherd writeup for this document in the 
next couple weeks, and if the editors push the -03 version of the draft, 
I think it will be ready to proceed for AD review.


Please shout if you have further comments.

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] status of WGLC on fq-codel

[Wesley Eddy]

Hello, we started a working group last call for comments on this draft in 
December:
https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/
(this is the -03 version currently)

Some comments were received since then, and Toke updated the document:
https://kau.toke.dk/ietf/draft-ietf-aqm-fq-codel-04.html
(draft -04 version)

I think this update addresses all of the comments received.

I didn't see any feedback about document publication tracks (e.g. Standards Track, 
Informational, Experimental, etc).  We talked to the ADs briefly about this, and I think 
we are comfortable with Experimental for this document.  That is the appropriate track if 
the AQM working group thinks this is safe to deploy widely while experimenting with on 
the Internet (which I think is consistent with what section 7 describes -- it has already 
been widely deployed, though there are some items identified for future enquiry).  So, I 
think version -04 should be labelled with "Intended Status: Experimental".

My plan is to complete the shepherd writeup for this document in the next 
couple weeks, and if the editors push the -04 version of the draft, I think it 
will be ready to proceed for AD review.

Please shout if you have further comments.




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-09.txt

[Wesley Eddy]

On 1/22/2016 2:17 PM, Fred Baker (fred) wrote:

On Jan 22, 2016, at 10:47 AM, Wesley Eddy  wrote:

I do also (personally) think that if there's a desire to go standards-track 
(rather than just experimental) with AQM algorithms, that having a fairly 
explicit evaluation of the algorithms with regard to the guidelines would be 
very helpful, exactly as Polina asked about.  But I don't think this has really 
happened, and don't think it's necessary at all for experimental RFCs.

As I recall the discussion, we decided up front that since there is no 
interoperability requirement among AQM algorithms (the requirement is that they 
interoperate well with TCP and UDP based applications; the AQM algorithms don' 
actually talk to each other, and the point is to drop or mark at the right rate 
and with the right pattern to encourage transport layer sessions to behave 
well), we didn't need to recommend a single AQM algorithm for all equipment or 
all uses. What we did need to do was identify some AQM algorithms that actually 
worked, and give guidance to the vendors and operators on their use.


I agree with all of this.  The characterization guidelines are aimed at 
helping to identify the AQM algorithms that actually work, or cases 
where they don't work as well (i.e. where some harmful or unintended 
consequence results).



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-09.txt

[Wesley Eddy]

On 1/22/2016 1:32 PM, Klatsky, Carl wrote:


Wes and all,

My comment is in regard to Polina’s comment “The WG currently has two 
AQMs (dropping/marking policy) in last call. Did someone evaluate 
these AQMs according to the specified guidelines?”.  As I read over 
draft-ietf-aqm-eval-guidelines, I did not think the objective of this 
memo was to arrive at consensus to select one specific AQM.  I thought 
the objective was to publish guidelines for implementers & service 
providers on how they can select an AQM that is best for their 
environment. And further that both AQMs in last call would complete 
the process as valid AQMs for implementers & service providers as 
available to use in their environment, with the guidelines helping 
them to decide which is best for them. Some may chose PIE, some may 
chose FQ_CODEL.  And possibly other future AQMs would go through the 
IETF process for publication, and that would be an additional option 
for implementers & service providers to evaluate according to the 
guidelines as best for their environment.


Is my understand of draft-ietf-aqm-eval-guidelines correct?




Yes, you're correct!  My assumption is that someone like a service 
provider would have an idea of some of the ranges of values (rates, 
delays, asymmetries, etc) appropriate for their environment, and would 
be able to use the evaluation guidelines effectively.


I do also (personally) think that if there's a desire to go 
standards-track (rather than just experimental) with AQM algorithms, 
that having a fairly explicit evaluation of the algorithms with regard 
to the guidelines would be very helpful, exactly as Polina asked about.  
But I don't think this has really happened, and don't think it's 
necessary at all for experimental RFCs.




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] status of PIE drafts WGLC

[Wesley Eddy]

Hello; the working group last call on the PIE drafts generated some 
emails, but I don't think I've seen any response from the editors. 
Specifically, there were a couple of emails with algorithm description 
questoins and technical comments from Rasool Al-Saadi and Ilpo Jarvinen, 
both with specific points that should be addressed.


For the most part, as I understand the comments, these are things that 
can be relatively simply fixed up or the intent clarified, and not 
catastrophic issues that would prevent the PIE docs from being 
publishable.  Please correct me if I misunderstand though.


If the editors can respond and work up a revision that addresses the 
comments to the satisfaction of Rasool and Ilpo, I'd like to keep the 
PIE documents moving forward.




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-09.txt

[Wesley Eddy]

On 12/14/2015 4:09 AM, Kuhn Nicolas wrote:


Dear Polina, all,

1)The explanation was mostly on why parameters are not specified in 
the document because the words unspecified was in a bold font in your 
email ; this made me think that this was your concern about the document.


2)I think it is not an issue to have some parameters specified in the 
document.


You do not “have to” write a longer review. Do it  only if you think 
it is necessary and helpful in having a better document J.


As Gorry said at IETF93, “this doc will never be perfect”[1].




With my co-chair hat on, I agree with this sentiment that it will never 
be perfect.To my knowledge, there aren't other resources that have 
better information and guidance than this document when it comes to the 
topic of characterizing AQMs.  The goal has been to produce something 
useful to the community, compared to the current guidance available 
(which is basically nothing), so I'm hopeful that we can get a version 
of it with rough consensus to go forward.


Please do correct me if I'm wrong about this though.



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-09.txt

[Wesley Eddy]

On 12/7/2015 7:32 AM, Polina Goltsman wrote:


In the abstract, the document says that it describes characterization 
guidelines for an AQM proposal, to decide whether it should be adopted 
by the AQM WG. The WG currently has two AQMs (dropping/marking policy) 
in last call. Did someone evaluate these AQMs according to the 
specified guidelines?





In my opinion, for "standardization" it would be good to have crisp 
guidelines.  For simply publishing RFCs that are experimental (not 
standardized), it is much less important.




Moreover, it seems to me that the WG is about to conclude. What 
exactly is the purpose of standardizing this document then ?





It's definitely true that the activity level has been low, and so we're 
trying to wrap up the outstanding work items before it flattens 
completely.  This document is not proposed for standards track, only 
"Informational".  The current goal as I see it (with co-chair hat on) is 
to see if we have rough consensus that this is a useful contribution to 
the community going forward, and that any small issues can be addressed.


As I understood your review (please correct if I'm wrong), a main issue 
you see is that there isn't specific guidance about numeric values or 
ranges to use in evaluations?  Nicolas explained why this might be a bit 
difficult to do in general (and specific values published in 2016 may be 
moot by 2018), so as I understand, one of the limitations of this 
document is that it is only going to be able to provide general 
descriptive guidance in terms of what kinds of tests to run, and what 
types of things to look for, but not prescriptive values and conditions 
to be met.  Do you think that's okay, even though it's probably less 
directly useful than if there were specific values?



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] working group last call on CoDel drafts

[Wesley Eddy]

This message is to start a working group last call on the CoDel and 
FQ-CoDel documents:

https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/
and:
https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/

Please provide any comments you might be saving up on these by the end 
of December.


These both have the intended status designated as "Informational". 
Similar to the questions asked for PIE, we/chairs need to understand if 
there's consensus on:

- Are these specifications are clear and sufficient quality to publish?
- Should the status of the RFCs be "Experimental", "Proposed Standard", 
or "Informational"?







___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Document Action: 'The Benefits of using Explicit Congestion Notification (ECN)' to Informational RFC (draft-ietf-aqm-ecn-benefits-08.txt)

[Wesley Eddy]

On 12/1/2015 5:22 PM, Steve Baillargeon wrote:

Hi
Sorry to come so late with a comment.
Is it too late to add one more benefit to the draft?

I suspect ECN brings potential and significant savings in CPU cycles and memory usage , 
especially on the "server side" terminating a large number of TCP connections.
Has anyone done any analysis to confirm or contradict this assumption?




Hi Steve, thanks for the comment.

I don't think I've seen anyone analyze that before, and would guess at 
the moment that it's too tenuous to try to work into this particular 
document at its advanced stage.


I would recommend continuing discussion or research on this in AQM, 
TSVWG, ICCRG or other appropriate groups at the moment, but not altering 
the draft.  At the ADs, and editors discretion, and if there seems to be 
working group consensus, it might be noted as a potential benefit for 
future exploration, but that's about the only impact I think might be 
appropriate to this particular document at its advanced stage.


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] WGLC for PIE drafts

[Wesley Eddy]

This is the start of a working group last call for the PIE specification:
https://tools.ietf.org/html/draft-ietf-aqm-pie-03

along with the DOCSIS-PIE description as Informational:
https://tools.ietf.org/html/draft-ietf-aqm-docsis-pie-01

Please send any comments on the documents by the end of December. There 
is an open question on the PIE specification of whether it should be 
standards track or not.  I think we've punted on this a bit in the past, 
and need to understand the consensus on now.


Specific questions for the working group that we / chairs need clear 
feedback on:

- Are the documents ready to publish as RFCs?
- Should the PIE specification be Proposed Standard or Experimental?


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] is the codel draft ready for last call?

[Wesley Eddy]

Please go ahead and submit the updated draft so we can start a working 
group last call.



On 10/30/2015 12:25 AM, Andrew Mcgregor wrote:

Hi Dave,

Jana and I did the editorial pass over it, but missed the cutoff 
date.  We plan on submitting a last-call version during the meeting, 
so yes, it will be ready for last call next week.


Andrew

On 22 October 2015 at 02:30, Dave Taht > wrote:


https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/

There were a few comments on the fq_codel draft so far but it was
mostly trivial.

I am not planning on making this ietf (have a trip to washington,
DC to make,
as well as purchasing some needed test gear for the make-wifi-fast
project),
but it would be my hope (for someone) to present some "cake" results
at the next ietf. I would have liked to have gone to japan, but...


Dave Täht
I just lost five years of my life to making wifi better. And, now...
the FCC wants to make my work illegal (!?) for people to install.
https://www.gofundme.com/savewifi

___
aqm mailing list
aqm@ietf.org 
https://www.ietf.org/mailman/listinfo/aqm




--
Andrew McGregor | SRE |andrewm...@google.com 
 | +61 4 1071 2221



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-09.txt

[Wesley Eddy]

Thanks for making this update.

I don't think Roland and Polina who had made last call comments had yet 
had the time to check that the changes in the last revision met what 
they were expecting, so I'd like to give them (and anyone else who has 
comments) a couple of weeks to check this revision out, and assuming 
there are no major issues or objections by around 12/15, will plan to 
end the working group last call, and send the document to the area 
director for publication.




On 11/27/2015 5:50 AM, Kuhn Nicolas wrote:

Dear all,

This updated version integrates:
- modification on the buffer sizes, following some discussion points raised by 
Michael Scharf on the tcpm mailing list [1];
- some nits raised by Greg Skinner.

Kind regards,

Nicolas KUHN

[1] https://www.ietf.org/mail-archive/web/tcpm/current/msg09894.html

-Message d'origine-
De : aqm [mailto:aqm-boun...@ietf.org] De la part de internet-dra...@ietf.org
Envoyé : vendredi 27 novembre 2015 11:44
À : i-d-annou...@ietf.org
Cc : aqm@ietf.org
Objet : [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-09.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Active Queue Management and Packet 
Scheduling Working Group of the IETF.

 Title   : AQM Characterization Guidelines
 Authors : Nicolas Kuhn
   Preethi Natarajan
   Naeem Khademi
   David Ros
Filename: draft-ietf-aqm-eval-guidelines-09.txt
Pages   : 35
Date: 2015-11-27

Abstract:
Unmanaged large buffers in today's networks have given rise to a slew
of performance issues.  These performance issues can be addressed by
some form of Active Queue Management (AQM) mechanism, optionally in
combination with a packet scheduling scheme such as fair queuing.
The IETF Active Queue Management and Packet Scheduling working group
was formed to standardize AQM schemes that are robust, easily
implementable, and successfully deployable in today's networks.  This
document describes various criteria for performing precautionary
characterizations of AQM proposals.  This document also helps in
ascertaining whether any given AQM proposal should be taken up for
standardization by the AQM WG.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-aqm-eval-guidelines-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-eval-guidelines-09


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Yokohama meeting planning

[Wesley Eddy]

On 9/8/2015 9:31 AM, Wesley Eddy wrote:
> This is a quick poll to ask if people think we need to have a
> face-to-face WG meeting in Yokohama.
> 
> If so, please identify the topics that you want face-to-face time
> to discuss, or whether these could be as easily handled in a webex
> or conference call (perhaps as a virtual meeting).
> 


FYI - there were only very limited responses on this, so we took this
to indicate that a meeting in Yokohama is not justified (especially
given the scheduling difficulties recently for the massive number of
working groups).

We'll need to use the mailing list effectively to make progress in
the next couple months on the active documents.  Document editors,
please let us know if you'd like us to setup a webex/telecon or can
facilitate discussion in some other way.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[OPSEC] Fwd: [Idr] flowspec enhancements

[Wesley Eddy]

Since DDoS mitigation may be of interest to folks on the OPSEC list,
I'm sharing this draft about BGP/flowspec enhancements intended to
help with DDoS.

Looking forward to any comments, questions, or criticisms that you
might have:


 Forwarded Message 
Subject: [Idr] flowspec enhancements
Date: Tue, 15 Sep 2015 13:39:29 -0400
From: Wesley Eddy 
Organization: MTI Systems
To: i...@ietf.org
CC: Justin Dailey 

Hello, we've been working on a few enhancements to the BGP flowspec
capabilities that may be of interest:

https://tools.ietf.org/html/draft-eddy-idr-flowspec-exp-00

There are several ideas described in the document that could be
factored out from one another, but the basic idea is to increase
the power of flowspec, mainly for its DDoS mitigation purposes.

Specifically, the suggested enhancements include:
- add packet rate limitations as an action (not just bitrate)
- add support for filtering of tunneled traffic (unencrypted)
- identifying flow specifications for tracking and communication
  between providers
- cryptographically signing flowspecs
- supporting a more surgical re-route to scrubbing centers
- providing feedback about flowspecs to the source

If any of these are interesting to folks, we'll appreciate your
feedback, comments, questions, etc.  Some are more difficult than
others.

I'm assuming IDR is a reasonable list for this, though it also
touches SIDR and OPSEC topics, but will appreciate the chairs'
thoughts on this.  It has been mentioned in the DOTS list, but
is obviously out of scope for DOTS.

-- 
Wes Eddy
MTI Systems

___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr




___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

[aqm] Yokohama meeting planning

[Wesley Eddy]

This is a quick poll to ask if people think we need to have a
face-to-face WG meeting in Yokohama.

If so, please identify the topics that you want face-to-face time
to discuss, or whether these could be as easily handled in a webex
or conference call (perhaps as a virtual meeting).

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] WGLC on draft-ietf-aqm-eval-guidelines

[Wesley Eddy]

On 8/18/2015 6:03 PM, Roland Bless wrote:
> Hi,
> 
> Am 10.08.2015 um 15:43 schrieb Wesley Eddy:
>> As chairs, Richard and I would like to start a 2-week working
>> group last call on the AQM characterization guidelines:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/
>>
>> Please make a review of this, and send comments to the list or
>> chairs.  Any comments that you might have will be useful to us,
>> even if it's just to say that you've read it and have no other
>> comments.
> 
> "Unfortunately", we (Polina and I) did a thorough review,
> which is attached. TL;DR: from our point-of-view
> the I-D needs a major revision.
> 


Many thanks for the detailed review.

I think a majority of the comments could be addressed in an update, if
the authors agree.

There were only a couple of the "major issues" that I thought I should
comment on as a co-chair of the WG:


> 3) the overall number of tests and parameter combinations is really
>   high

Are there particular permutations (or classes of permutations) that you
can suggest to remove?  There's a balancing act between including enough
to satisfy people that want to find edge cases and thoroughly
characterize an algorithm, and the desire for a more easily tractable
suite of tests.


> 4) from the discussed end-to-end metrics only latency/goodput metrics
>   are used in the scenarios and for some of the scenarios these metrics
>   are not suitable to show the desired behavior

It would be easier for the editors to improve this if you could suggest
specific metrics to add to specific scenarios, I think.


> 5) some sections in this document (e.g., 7.3, 10, 13) specify requirements
>   for an AQM standard(/draft) and not requirements for a performance
>   evaluation, so these sections should be moved to
[draft-ietf-aqm-recommendation]

That one is now an RFC (7567), so hopefully they're already reflected
if they were critical requirements.

In any case, I agree with you that requirements themselves should not
be conveyed in this document, but rather it should be just aimed at
characterizing algorithm behavior with regard to the requirements
(for ones that are applicable to verification by testing).

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] WGLC on draft-ietf-aqm-eval-guidelines

[Wesley Eddy]

On 8/18/2015 6:07 PM, Dave Taht wrote:
> On Tue, Aug 18, 2015 at 3:03 PM, Roland Bless  wrote:
>> Hi,
>>
>> Am 10.08.2015 um 15:43 schrieb Wesley Eddy:
>>> As chairs, Richard and I would like to start a 2-week working
>>> group last call on the AQM characterization guidelines:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/
>>>
>>> Please make a review of this, and send comments to the list or
>>> chairs.  Any comments that you might have will be useful to us,
>>> even if it's just to say that you've read it and have no other
>>> comments.
>>
>> "Unfortunately", we (Polina and I) did a thorough review,
>> which is attached. TL;DR: from our point-of-view
>> the I-D needs a major revision.
> 
> I am so tired of this document that I can hardly bear to read it
> again, but I agree with the majority of the comments.
> 
> Sometimes I do wish we could do graphics and charts as the IEEE does.
> 


We can add any type of graphics that are necessary, they will
just only show up in the PDF version of the RFC, with only
references to the PDF version in the TXT copy.  See, for
instance:
https://tools.ietf.org/pdf/rfc6687.pdf

Are there particular figures that need to be added to this AQM
document to strengthen it?

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] WGLC on draft-ietf-aqm-eval-guidelines

[Wesley Eddy]

As chairs, Richard and I would like to start a 2-week working
group last call on the AQM characterization guidelines:

https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/

Please make a review of this, and send comments to the list or
chairs.  Any comments that you might have will be useful to us,
even if it's just to say that you've read it and have no other
comments.

Thanks!

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [Taps] TCP components

[Wesley Eddy]

On 6/19/2015 6:55 PM, Joe Touch wrote:
> It's explicit - see section 3.8 of RFC 793. The issue with that variant
> is that it captures the state of TCP in 1981; it has evolved quite a bit
> since then. Although we do have a 793-bis in the works, the update of
> that section hasn't been tackled yet.

I'm not sure that it will be tackled, but we should discuss that on the
TCPM list :).  Since there are no newer RFCs that alter, deprecate, or
replace that API, I don't think we have a good basis to change it in
793bis.

It's still pretty reasonable in my opinion.

-- 
Wes Eddy
MTI Systems

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits-04.txt

[Wesley Eddy]

On 6/12/2015 8:46 AM, go...@erg.abdn.ac.uk wrote:
> Since we are already in WGLC, the WG Chairs probably will need to decide
> the scope - if this is changed, I expect will anyway require a new WGLC. 
> Hopefully the new ID will help.


Here are my thoughts, with chair hat on.

It's an Informational document (i.e. not Standards Track or BCP).  It
does have some advice about how not to break ECN, but it's not
altering or changing any previous standards or BCPs about how devices,
hosts, or applications behave.

I think it correctly avoids using the 2119 capitalized words (SHOULD,
MUST, etc.).  There are some non-capitalized "must" and "should" words
in section 5 when going through the high-level list of prerequisites
for successful use of ECN, and in my opinion, this is one of the more
useful parts of the document to summarize and bring the advice together.

There's definitely a valid criticism that it isn't particularly
specific about some details in this guidance, but I think that's
probably desirable, as some are still being worked out, and would
ultimately go into Standards Track and BCP documents from TSVWG or
some other working group.

I think as the AQM working group, the level of detail and strength
of recommendations made in -04 are pretty much on the mark for what
we should say.

Certainly people should let us know during this Last Call if they
feel otherwise.  It can be something we explicitly ask the AD to
confirm during their review too.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] review of draft-ietf-aqm-ecn-benefits-04

[Wesley Eddy]

On 5/7/2015 5:39 PM, Dave Taht wrote:
> On Thu, May 7, 2015 at 2:31 PM, Michael Welzl  wrote:
>> Hi,
>>
>>
>>> On 7. mai 2015, at 22.40, Dave Taht  wrote:
>>>
>>> I see that during my absence here most mention of the potential
>>> negative aspects of ecn
>>> have been nuked from this document.
>>
>> Actually I don't think we really removed any - it's just a stylistic change 
>> (title, headlines). So: could you be specific about which one there is in a 
>> (which?) previous version that is missing in this one?
> 
> You are correct. I should have said that few of the negatives I had
> attempted to discuss previously were added to the document.
> 


Hi Dave, I'm trying as a co-chair to figure out if we have consensus
on this document to go forward.  If it's easy to point to, or summarize,
a list of negatives that haven't yet been included, I think that would
make it simpler for the editors to incorporate.  I wasn't able to go
back and track every message, but the things that have been most
discussed do seem to be included currently.  If there are some still
missing, I'd like to make sure they get discussed and incorporated as
needed.

There was the topic of "gaming ECN", which I thought Bob Briscoe's
message on 4/15/2015 came close to putting to rest, and personally,
I'm not sure if or how to reflect this conversation in the draft, but
maybe others have more clear ideas?


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

[Wesley Eddy]

On 5/8/2015 11:42 PM, Simon Barber wrote:
> I have a couple of concerns with the recommendations of this document as
> they stand. Firstly - implementing AQM widely will reduce or even
> possibly completely remove the ability to use delay based congestion
> control in order to provide a low priority or background service. I
> think there should be a recommendation that if you are implementing AQM
> then you should also implement a low priority service using DSCP, e.g.
> CS1. This will enable these low priority applications to continue to
> work in an environment where AQM is increasingly deployed. Unlike DSCPs
> that give higher priority access to the network, a background or low
> priority DSCP is not going to be gamed to get better service!
> 
> Secondly, there is a recommendation that AQM be implemented both within
> classes of service, and across all classes of service. This does not
> make sense. If you are implementing AQM across multiple classes of
> service, then you are making marks or drops while ignoring what class
> the data belongs to. This destroys the very unfairness that you wanted
> to achieve by implementing the classes in the first place.
> 


Hi Simon, thanks for your comments.

These comments appear to be in response to version -04 of the document,
from around 1 year ago.  The document is currently on version -11, has
past working group last call and IESG evaluation, and is in the RFC
Editor's queue.  I mention this, because it isn't clear to me how
applicable your comments are with regard to the current copy.

The current copy can be found at:
https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/

The current revision does mention the impact to delay-based end-host
algorithms as an area for future research.

While I agree that in a lot of cases it seems like logically a good
idea to have a DiffServ configuration like you mention, I don't think
we have seen data on this yet in the working group.  Looking into this
could be part of that mentioned future work, though not something I'd
want to see hacked into this document today, so late in its publication
process.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] PIE (and CoDel) drafts: proposed standard vs informational?

[Wesley Eddy]

On 4/29/2015 12:42 PM, Bob Briscoe wrote:
> Richard, Wes,
> 
> 1) The AQM charter says:
> "Dec 2014 - Submit first algorithm specification to IESG for publication
> as Proposed Standard"
> 


Hi Bob, thanks for raising this, since it probably requires some
clarification and discussion.  I thought we'd outlined this a bit
on the list and through discussion a couple meetings ago, but it
might not have been integrated back into the charter.

I think the intention when chartering was to enable us to put
something on Standards Track, if there is consensus, but not
to limit us to only Standards Track.

It seems apparent that there are drafts which the group has
agreed are worth publishing (the ones we've adopted), and part
of submitting them for publication is deciding on the status
they'll be stamped with.  If the group wants to do Informational
or Experimental and feels those are more appropriate, then
obviously that's what we'll do.

I'm pretty sure our ADs support that, but am happy for them to
jump in and correct it, if not!

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] WGLC for draft-ietf-aqm-ecn-benefits

[Wesley Eddy]

To keep moving forward with the set of documents, we'd like to start
a Working Group Last Call on:
http://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/

Please send any comments you have on this document to the list
by May 8th.  Other than those raised in the thread Mirja has just
opened with her review, I'm not aware of any other open issues.

Thank you to everyone that's been following up on the reviews
pledged at the last meeting!


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [tcpinc] [tcpm] Feedback on EDO?

[Wesley Eddy]

On 3/23/2015 6:22 PM, Joe Touch wrote:
>> > Well, SACK? But, I guess common cases will be a combination of
>> > extensions, not a specific one.
> SACK can use as much space as it is given, AFAICT ;-)


That's right, and there have been multiple studies that even
showed it was useful to be able to carry a larger number of
SACK blocks.

In my opinion, this alone could be worthy motivation, without
even trying to enumerate all the experimental or combinations
of options that might (or might not) find EDO useful.

-- 
Wes Eddy
MTI Systems

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

[aqm] review of PIE -00 draft

[Wesley Eddy]

I reviewed the PIE draft and have some comments:
http://tools.ietf.org/html/draft-ietf-aqm-pie-00

The basic algorithm is very clear and I think it could easily
be implemented by someone else based on this draft alone.  Also,
the background information in the draft is pretty clear,
including the linkage with other documents like the docsis-pie
I-D.

In general, I think the working group should try to quickly
complete reviews and get submit it to the ADs for publication.

Section 3 on the design goals would be good to link back to the
soon-to-be RFC on AQM recommendations from this working group.
As I noted in the similar part of the CoDel draft too, I think
that the AQM recommendations grew out of these design goals
rather than the other way around, but it would be good to tie
the working group items together that are closely related.  Plus
I would guess that the IESG or some other reviewer might ask how
PIE relates to those recommendations previously published.

It might be helpful to encourage specific future work by including
a section near the end on "Future Research".  I certainly had a
number of thoughts in this regard when reading section 5 on the
enhancements.  For instance, there could be other auto-tuning
algorithms, sensitivity of the parameters could be looked at further
(especially with regard to the burst allowance), etc.

Note that the I-D template could in-use is missing some
important things, like an "intended status" header, which will
eventually need to be fixed so it can be submitted for publication
to the ADs.

Minor editorial comment: there's an odd line break or two in section
6, 3rd paragraph, when trying to say "beta = 2.5".

Editorial comment: "time-stamped" should be "timestamps" in section
6 in the 2nd-to-last paragraph on page 12.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] review of fq-codel draft

[Wesley Eddy]

I reviewed the fq-codel draft and have some comments:
https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/

Overall, it's a clear document that someone could definitely
write code from without much difficulty, and I hope we can
quickly finish it in this working group.  I do have a few
comments below that I think would improve it though.

In section 1, the 2nd-to-last paragraph, I had some
confusion on the sentence:
"Exactly how much data a flow has to send to keep its
queue in this state ..."
By my understanding, it would be a matter of how _little_,
not "how much" data the flow has to send to remain in that
state of never having a queue that persists between rounds
of the scheduler.

In section 3, something big is missing here in terms of
explaining the intention to have N queues such that flows
mostly uniquely hash to their own queue.

It would also be worth explaining here what the impact will
be of things like tunnels and people doing things like using
multiple DSCP values within the same 5-tuple (like in the
TSVWG RTCWEB QoS draft).  If everything in a tunnel and
everything on a 5-tuple (regardless of DSCP) hash into the
same flow/queue, then it should be clearly noted.

(I know there's brief mention later in the document about
DiffServ, but IMO it's a big enough architectural issue that
it should be well-understood by the reader and clear up front
in the document)

In section 5.1, it could/should be stressed more strongly that
configuration of a custom filter for classification has a huge
impact on how the system performs, and in this light, it seems
to me like the "standard filter" should be more strongly
recommended, and custom rules noted as not really encouraged
for people that won't actively be measuring and possibly updating
them.

The decapsulation capability described in 5.1 seems like something
that can't generically be assumed in an implementation because
there are N different encapsulations and more on the way.  I think
the paragraph mentioning this should stress that it's a feature of
one implementation, that others could mimic, that it does impact
performance, and that it isn't a panacea for all flavors of tunnel,
especially ones that use encryption.

Section 7.3 should probably reference the LEDBAT RFC directly.

I believe from notes scattered throughout the document that it
would be helpful to have a "Further Research" section near the end
of the document to collect and summarize the productive future
work that the authors would suggest.  For instance, the things
that I can see would be:

- alternate FQ mechanisms like QFQ
- variations of the classification algorithm
- measured interactions with delay-based CC (e.g. LEDBAT)
- sensitivity of parameters (interval, # of queues, etc)
- including other fields in the hash (i.e. "entropy fields") in
  order to deal with tunnels more elegantly (e.g. the way that
  flow label or other things are being used for ECMP).

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] review of CoDel -00 draft

[Wesley Eddy]

I reviewed and have some comments on the CoDel draft:
http://tools.ietf.org/html/draft-ietf-aqm-codel-00

1) I believe it would be a good idea to tie the goals listed in
   section 1 (in the bullet list on page 4) to the AQM guidelines
   from the RFC-to-be of draft-ietf-aqm-recommendation.

   Largely, the CoDel goals were brought into that rather than
   being pulled from it, but it will be good to provide a sentence
   or so that ties the working group documents and material together.

2) In the discussion of sojourn time as a metric (section 3.1) and
   using the minimum time to separate good queue from bad queue,
   it struck me that there is some parallel between this and the
   way that LEDBAT works in using the delta from the minimum as
   indication of queues (and congestion) building.  It may be
   worth noting or expanding on delay-based CC in endpoints and
   in-network.

3) Since the algorithm and pseudocode has been published a few
   places before, it would be good to draw attention to a section
   that notes any changes or differences between what will be
   published in this RFC and any other revisions of the pseudocode
   floating around the net (or clearly note if there aren't any).

In generally, it's very readable and I think it would serve as a
clear basis for implementing the algorithm, so would be happy to
see it go forward quickly through this working group to become an
RFC.


Small / editorial comments:
- The abstract has [TSVBB2011] which doesn't seem to actually
  exist as a reference
- The abstract could really be trimmed to just the 2nd paragraph,
  as the first is just background that's in the Introduction anyways
- The "(covered in another draft)" at the end of section 1 can be
  replaced with a real reference (there's already one later in the
  draft in 4.6)



-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Please review: Benefits and Pitfalls of using ECN

[Wesley Eddy]

On 3/11/2015 4:10 PM, go...@erg.abdn.ac.uk wrote:
> 
> Alas, due to a slight technical mistake by me, we missed the ID deadline.
> So I have posted an interim version here:
> 
> http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.txt
> http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.xml
> 


I've reviewed this copy and have some comments, one larger and
the rest smaller.

Large comment:

I (personally) really do not like using the word "pitfall" in this
document, given that we want people to use ECN, and not scare them
about this list of pitfalls that await them the day they start using
it.

We could call these "operational difficulties that have been
encountered" or "challenges due to misbehaving network devices and
endpoints".

I worry about someone that doesn't have time to carefully read and
consider all the benefits and whether they outweigh the "pitfalls",
and may not fully grok that the pitfalls have known mitigations and
will hopefully go away over time.

We *should* be more clear that there are mitigations and that plenty of
nodes are able to use ECN happily today because it is implemented in
the major OSes and network devices.

For instance, there is no mention of things like ECN blackhole
detection, and measurements of this, such as:
http://conferences.sigcomm.org/imc/2011/docs/p171.pdf

We *definitely* need to stress that bleaching, lying, and cheating
behaviors are non-conformant, in some cases may be from legacy code,
and should be expected to go away over time rather than proliferate,
because these behaviors will cause problems for the growing critical
mass of conforming nodes.

So, in summary, I would really suggest that we go through the document
searching for every instance of "pitfall" and try to be more gentle,
and even change the title just to "The Benefits of Using Explicit
Congestion Notification (ECN)".  There is way more text in the document
about benefits than pitfalls anyways, and I think we could consider the
section discussing pitfalls as just fairly presenting possible
challenges to successfully using ECN.

That's just my opinion ... I'd be curious what others think.


Small comments:
- In section 1, paragraph 3, I suggest changing the text:
  "where the exact combination of AQM/ECN algorithms is generally
   not known by the transport endpoints."
  to:
  "where the exact combination of AQM/ECN algorithms does not need
   to be known by the transport endpoints."

  Since the document is for people that might not be familiar with
  this, it seems worth rewording so they don't think it's somehow
  bad or suboptimal that the endpoints don't know if AQM or ECN is
  supported within the network.

- section 1, paragraph 4, I suggest changing:
  "that would otherwise have been dropped"
  to:
  "that would otherwise have been dropped if the application or
   transport did not support ECN"

  I think this kind of wording will emphasize that they need to
  make sure they're enabling it at the endpoint.

- section 2, paragraph 3 should be changed:
  "Applications that experience congestion in such endpoints"
  to:
  "Applications that experience congestion in such network devices"


Even smaller comments:
- section 1, paragraph 2, "forward" -> "forwards"
- section 1, paragraph 2, "this packet" -> "packets"
- section 1, paragraph 3,
  "The focus of this document is on usage of ECN"
  to:
  "The focus of this document is on usage of ECN by transport and
   application flows"
- section 2, paragraph 2, I think the ECN RFC (3168) could also be cited
  in addition to 2309bis for the recommended behavior for network
  devices

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] review of draft-ietf-aqm-fq-implementation

[Wesley Eddy]

I reviewed the working group document "On Queueing, Marking,
and Dropping" in preparation for the next meeting.

It's due to expire just as the IETF meeting starts.  Folks
haven't been beating it up much in the working group, and yet
we (chairs) know it's been looked at because a critical mass
of people supported it in the past and said it was useful.

So, either it's nearly perfect (and done), or people just
haven't had the bandwidth to send reviews recently.

I personally think it's fairly complete, and could be last-
called ... here are my comments, none of which are major
technical issues, just attempts at clarification or
strengthening.


Comments:
- It will probably be a good idea in the introduction to say
  that in the document, many alternatives are discussed, and
  that this is all just informational to describe what can be
  done and many things that are "reasonable", but the goal isn't
  to flat out say that certain things are right or wrong.  For
  instance section 2.2.3 has discussion of multiple possible
  valid lines of reasoning in how a calendar queue's details look.

- I think most of the discussion is relevant to the IP layer,
  and not really as clearly addressing queues at other layers.
  That's probably fine, but worth being explicit about, maybe
  in the introduction.

- In section 2.1.2, it seems worthwhile to cite Bob Briscoe's
  CCR paper or other publications on flow-rate fairness:
  http://dl.acm.org/citation.cfm?id=1232926

- In section 2.1.3, it seems like it would be worthwhile to
  cite RFC 7141, which has tons of discussion about measuring
  things in bytes versus packets

- In 2.2.1, I'm not clear on the need or purpose behind
  mentioning the methods for creating and destroying queues in
  the list of properties of a queueing algorithm.  It doesn't
  seem to be discussed much (if at all), and IMHO, may not
  really be needed ... More importantly, it might be reasonable
  to mention a management interface to configure the queue (set
  max depth, etc).  These might be "manageable" and not just
  "inspectable" as currently described.

- section 3 covers tail-drop, CoDel, and PIE mark/drop; would
  it make sense to have a brief subsection on RED mark/drop,
  as this is a large "deployed base"?

- I think we can end section 4 (conclusions) more strongly.
  Instead of the current paragraph at the end, saying the
  authors don't think people should mix things up, I think
  we should say something more like:
  "There is value in implementing and coupling the operation
   of both queueing algorithms and queue management algorithms,
   and there is definitely interesting research in this area,
   but specifications, measurements, and comparisons should
   decouple the different algorithms and their contributions to
   system behavior."

Not-so-important-comments:
- section 2.1 has "he duration" instead of "the duration"

- mentioning the arrival rate of TCP acknowledgements at
  the end of section 2.1.1 is probably not necessary, and
  not quite pedantically correct (e.g. if ABC is in use,
  for instance) ... I would just not mention this here.

- I suggest "ring of sub-queues" rather than "ring of queues"
  in section 2.2.2.  It should be explicit that sub-queues
  can be managed in any way themselves e.g. with AQMs (and
  even have further sub-sub-queues nested).

- some references are out of data (e.g. codel draft), but
  the authors probably know this


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [Cerowrt-devel] [Bloat] [aqm] ping loss "considered harmful"

[Wesley Eddy]

On 3/3/2015 12:20 PM, Fred Baker (fred) wrote:
> 
>> On Mar 1, 2015, at 7:57 PM, Dave Taht > > wrote:
>>
>> How can we fix this user perception, short of re-prioritizing ping in
>> sqm-scripts?
> 
> IMHO, ping should go at the same priority as general traffic - the
> default class, DSCP=0. When I send one, I am asking whether a random
> packet can get to a given address and get a response back. I can imagine
> having a command-line parameter to set the DSCP to another value of my
> choosing.
> 


I generally agree, however ...

The DSCP of the response isn't controllable though, and likely the DSCP
that is ultimately received will not be the one that was sent, so it
can't be as simple as echoing back the same one.  Ping doesn't tell you
latency components in the forward or return path (some other protocols
can do this though).

So, setting the DSCP on the outgoing request may not be all that useful,
depending on what the measurement is really for.

-- 
Wes Eddy
MTI Systems
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Bloat] [aqm] ping loss "considered harmful"

[Wesley Eddy]

On 3/3/2015 12:20 PM, Fred Baker (fred) wrote:
> 
>> On Mar 1, 2015, at 7:57 PM, Dave Taht > > wrote:
>>
>> How can we fix this user perception, short of re-prioritizing ping in
>> sqm-scripts?
> 
> IMHO, ping should go at the same priority as general traffic - the
> default class, DSCP=0. When I send one, I am asking whether a random
> packet can get to a given address and get a response back. I can imagine
> having a command-line parameter to set the DSCP to another value of my
> choosing.
> 


I generally agree, however ...

The DSCP of the response isn't controllable though, and likely the DSCP
that is ultimately received will not be the one that was sent, so it
can't be as simple as echoing back the same one.  Ping doesn't tell you
latency components in the forward or return path (some other protocols
can do this though).

So, setting the DSCP on the outgoing request may not be all that useful,
depending on what the measurement is really for.

-- 
Wes Eddy
MTI Systems
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [aqm] [Bloat] ping loss "considered harmful"

[Wesley Eddy]

On 3/3/2015 12:20 PM, Fred Baker (fred) wrote:
> 
>> On Mar 1, 2015, at 7:57 PM, Dave Taht > > wrote:
>>
>> How can we fix this user perception, short of re-prioritizing ping in
>> sqm-scripts?
> 
> IMHO, ping should go at the same priority as general traffic - the
> default class, DSCP=0. When I send one, I am asking whether a random
> packet can get to a given address and get a response back. I can imagine
> having a command-line parameter to set the DSCP to another value of my
> choosing.
> 


I generally agree, however ...

The DSCP of the response isn't controllable though, and likely the DSCP
that is ultimately received will not be the one that was sent, so it
can't be as simple as echoing back the same one.  Ping doesn't tell you
latency components in the forward or return path (some other protocols
can do this though).

So, setting the DSCP on the outgoing request may not be all that useful,
depending on what the measurement is really for.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [Codel] why RED is not considered as a solution to bufferbloat.

[Wesley Eddy]

On 2/24/2015 10:37 AM, sahil grover wrote:
> (i) First of all,i want to know whether RED was implemented or not? 
> if not then what were the reasons(major) ?
> anyone please tell me in simple words here only,because i don't want to
> read any paper like "RED in a different light".
> 
> (ii)Second, as we all know RED controls the  average queue size from
> growing.
> So it also controls delay in a way or  we can say  is a solution to
> bufferbloat problem. Then why it was not considered.
> 


There is an IETF document from the AQM working group which contains
some discussion towards your first question, at least:
https://tools.ietf.org/html/draft-ietf-aqm-recommendation-10
(this should be published as an RFC "soon")

Specifically, the text says:

   With an appropriate set of parameters, RED is an effective algorithm.
   However, dynamically predicting this set of parameters was found to
   be difficult.  As a result, RED has not been enabled by default, and
   its present use in the Internet is limited.  Other AQM algorithms
   have been developed since RC2309 was published, some of which are
   self-tuning within a range of applicability.  Hence, while this memo
   continues to recommend the deployment of AQM, it no longer recommends
   that RED or any other specific algorithm is used as a default;
   instead it provides recommendations on how to select appropriate
   algorithms and that a recommended algorithm is able to automate any
   required tuning for common deployment scenarios.


-- 
Wes Eddy
MTI Systems
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel

Re: [aqm] Pete Resnick's No Objection on draft-ietf-aqm-recommendation-09: (with COMMENT)

[Wesley Eddy]

On 2/19/2015 7:25 AM, Martin Stiemerling wrote:
> Pete,
> 
> Good catch!
> 
> Authors & doc shepherd: Did the author sign anything?
> 
> If not, we need the pre-5378 boiler plate.
> 


No they didn't sign anything.  In fact many of them have been
difficult/impossible to reach, and the author list on 2309 was the
entire end-to-end RG at the time, so it's quite long.

It seems to me that we certainly need to use the pre-5378 boilerplate.
Thanks for catching this, Pete!


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] working group status

[Wesley Eddy]

Hi, to get 2015 started, Richard and I as chairs put together a set of
milestone status notes for the AQM working group items.

Please note, that there are a few relatively short drafts that should
not require much work, but which haven't been very actively discussed
on the list.  Comments on these will be extremely useful in accelerating
them forward.


- WG Milestones:
  - Submit AQM recommendations to IESG for publication, obsoleting
RFC 2309
- http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/
- This has been in IETF Last Call and some notes are being
  discussed from the last call comments

  - Submit AQM algorithm evaluation guidelines to IESG for publication
as Informational
- http://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/
- The editors are updating this based on comments from the last
  (Honolulu) meeting, and after that it may be ready to last call

  - Submit first algorithm specification to IESG for publication as
Proposed Standard
- http://datatracker.ietf.org/doc/draft-ietf-aqm-codel/
- http://datatracker.ietf.org/doc/draft-ietf-aqm-pie/
- These algorithm drafts have been around for some time now, and
  it would be good to get some comments on the present revisions
  posted to the list (following up the Honolulu meeting threads).
  There are some known updates planned for the CoDel draft.

  - Some drafts that we don't have milestones for (but should add):

- Algorithm "companion" documents:
  - http://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/
- adopted after the Honolulu meeting, and now the working
  group draft is available for review

  - http://datatracker.ietf.org/doc/draft-white-aqm-docsis-pie/
- This could be put forward for Informational along with the PIE
  algorithm spec.  If the working group commits to it, it could
  come from the AQM WG, or it could be an ISE track document
  otherwise.  ***We'd like to hear from the AQM working group on
  whether to adopt it for Informational.***

  - http://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/
- Aiming for a Last Call around Dallas meeting timeframe
- This is a short draft; other than section 2 not being complete
  yet, it should be very easy to get finished soon.  Further
  input and reviews would be really helpful on this.

  - http://datatracker.ietf.org/doc/draft-ietf-aqm-fq-implementation/
- This draft is short and was well-received initially as a
  clarification to how AQM relates to FQ techniques.  Some
  references are to older drafts, but otherwise it seems like
  it may be complete enough to last call.  ***Further input and
  reviews would be really helpful on this.***


- Other items:

  - Other Algorithm Drafts:
- (Expired) https://datatracker.ietf.org/doc/draft-lauten-aqm-gsp/


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] Fwd: Gen-art LC review of draft-ietf-aqm-recommendation-08

[Wesley Eddy]

 Original Message 
Subject: Gen-art LC review of draft-ietf-aqm-recommendation-08
Resent-Date: Fri, 19 Dec 2014 14:35:01 -0500
Resent-From: draft-alias-boun...@tools.ietf.org
Resent-To: f...@cisco.com, go...@erg.abdn.ac.uk, mls.i...@gmail.com,
r...@netapp.com, w...@mti-systems.com
Date: Fri, 19 Dec 2014 19:34:39 +
From: Elwyn Davies 
To: General Area Review Team 
CC: draft-ietf-aqm-recommendation@tools.ietf.org,IETF
Discussion 

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-aqm-recommendation-08.txt
Reviewer: Elwyn Davies
Review Date: 2014/12/19
IETF LC End Date: 2014/12/24
IESG Telechat date: (if known) -

Summary:  Almost ready for BCP.

Possibly missing issues:

Buffer bloat:  The suggestions/discussions are pretty much all about
keeping buffer size
sufficiently large to avoid burst dropping.  It seems to me that it
might be good to
mention the possibility that one can over provision queues, and this
needs to be avoided
as well as under provisioning.

Interaction between boxes using different or the same algorithms: Buffer
bloat seems to
be generally about situations where chains of boxes all have too much
buffer.  One thing
that is not currently mentioned is the possibility that if different AQM
schemes are
implemented in various boxes through which a flow passes, then there
could be inappropriate
interaction between the different algorithms.  The old RFC suggested RED
and nothing else so
that one just had one to make sure multiple RED boxes in series didn't
do anything bad.  With
potentially different algorithms in series, one had better be sure that
the mechanisms don't
interact in a bad way when chained together - another research topic, I
think.

Minor issues:
s3, para after end of bullet 3:
> The projected increase in the fraction of total Internet traffic for
> more aggressive flows in classes 2 and 3 could pose a threat to the
> performance of the future Internet.  There is therefore an urgent
> need for measurements of current conditions and for further research
> into the ways of managing such flows.  This raises many difficult
> issues in finding methods with an acceptable overhead cost that can
> identify and isolate unresponsive flows or flows that are less
> responsive than TCP.

Question: Is there actually any published research into how one would
identify
class 2 or class 3 traffic in a router/middle box? If so it would be
worth noting -
the text call for "further research" seems to indicate there is
something out there.

s4.2, next to last para: Is it worth saying also that the randomness
should avoid targeting a single flow within a reasonable period to give
a degree of fairness.

s4.2.1, next to last para:
> An AQM algorithm that supports ECN needs to define the threshold and
> algorithm for ECN-marking.  This threshold MAY differ from that used
> for dropping packets that are not marked as ECN-capable, and SHOULD
> be configurable.
>
Is this suggestion really compatible with recommendation 3 and s4.3 (no
tuning)?

s7:  There is an arguable privacy concern that if schemes are able to
identify class 2 or class 3 flows, then a core device can extract
privacy related info from the identified flows.

Nits/editorial comments:
General: s/e.g./e.g.,/, s/i.e./i.e.,/

s1.2, para 2(?) - top of p4: s/and often necessary/and is often necessary/
s1.2, para 3: s/a > class of technologies that/a class of technologies that/

s2, first bullet 3: s/Large burst of packets/Large bursts of packets/

s2, last para: Probably need to expand POP, IMAP and RDP; maybe provide
refs??

s2.1, last para: s/open a large numbers of short TCP flows/may open a
large number of short duration TCP flows/

s4, last para: s/experience occasional issues that need moderation./can
experience occasional issues that warrant mitigation./

s4.2, para 6, last sentence: s/similarly react/react similarly/

s4.2.1, para 1: s/using AQM to decider when/using AQM to decide when/

s4.7, para 3:
> In 2013,
"At the time of writing" ?

s4.7, para 3:
> the use of Map/Reduce applications in data centers
I think this needs a reference or a brief explanation.






___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] adoption call: algorithm drafts

[Wesley Eddy]

On 9/16/2014 9:58 AM, Dave Taht wrote:
> It didn't seem as though the working group is interested in
> "comprehensive queue management" as I described in my
> last preso.

Actually, I would say that in the near term this is true,
since we need to get the mark/drop AQM algorithm work done,
but in the longer-term it could certainly be of interest.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] adoption call: algorithm drafts

[Wesley Eddy]

On the mailing list, on the summer webex, and during the last
meeting, we've discussed plans and expectations for adopting
algorithm specifications as working group drafts.

For a process description, see page 6 of:
http://www.ietf.org/proceedings/90/slides/slides-90-aqm-0.pdf
(one exception is that our charter says algorithms can be
Proposed Standard, and we must have forgot that when drawing
the chart)

Here is the list of algorithm documents and how we view their
current status (alphabetical order):

- draft-hoeiland-joergensen-aqm-fq-codel : this has cleared
  "Gate-1", and is welcome for continued discussion, but is
  heavily focused on the FQ / scheduling aspect, and relies
  on CoDel as an AQM.  It could become an appendix to the CoDel
  draft, or proceed some other way.  Feedback about how folks
  want to handle this is very welcome.

- draft-lauten-aqm-gsp : this has cleared "Gate-1" and is
  welcome for continued discussion, but we haven't yet seen
  the interest from multiple parties towards progressing it

- draft-nichols-tsvwg-codel : this is ready for the "Gate-2"
  decision about WG adoption.  We have some significant
  concerns about whether editors are available to handle this
  through the working group, however.

- draft-pan-aqm-pie : this is ready for the "Gate-2" decision
  about WG adoption.

- draft-white-aqm-docsis-pie : this could either become an
  appendix to the draft-pan specification or could progress
  in parallel to it as an Informational description of what
  has been done, and shouldn't require much additional work.


We would like feedback right now on adopting:
1 - http://tools.ietf.org/html/draft-pan-aqm-pie-01
and
2 - http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02

towards the charter milestone for submitting algorithm
specifications to the IESG.  Whether they are Proposed Standard
or Experimental can be debated now or later, but we want to
probe if there's critical mass to adopt them first.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] ADOPTED draft-baker-aqm-sfq-implementation

[Wesley Eddy]

Based on mailing list and meeting feedback, we will adopt:
http://datatracker.ietf.org/doc/draft-baker-aqm-sfq-implementation/
as an AQM working group document.

The authors can submit a revision as:
draft-ietf-aqm-fq-implementation

We will add a milestone for this similar to:

Submit discussion of implementation strategies for coupled AQM
mark/drop and fairness/scheduling mechanisms to the IESG for
publication as an Informational RFC.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] ADOPTED draft-welzl-ecn-benefits

[Wesley Eddy]

Based on mailing list and meeting feedback, we will adopt
http://datatracker.ietf.org/doc/draft-welzl-ecn-benefits/
targeted towards an Informational RFC, and ask to have a
milestone added for:

Submit description of ECN application benefits and other
considerations to IESG for publication as an Informational
RFC.

The editors can submit an update as:
draft-ietf-aqm-ecn-benefits-00

There was some feedback received during the adoption call
that should be planned for incorporation.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] ADOPTED draft-kuhn-aqm-eval-guidelines

[Wesley Eddy]

Based on the mailing list adoption call feedback and other
comments received during meetings and telecons, we are
adopting:
http://datatracker.ietf.org/doc/draft-kuhn-aqm-eval-guidelines/
as an AQM WG draft towards the charter milestone for an
informational document on algorithm evaluation guidelines.

The editors can submit an updated as:
draft-ietf-aqm-eval-guidelines-00

We got some comments asking for a more direct way to
contribute text changes (e.g. github), and ask the editors
to consider that or interact with the people that would
like to contribute to find some way to work with them.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] adoption call: draft-welzl-ecn-benefits

[Wesley Eddy]

This draft has been discussed a bit here and in TSVWG:

http://tools.ietf.org/html/draft-welzl-ecn-benefits-01

As I understand, the IAB has also discussed it a bit, and would
be happy if this was something that an IETF working group
published.  I believe the TSVWG chairs also discussed this and
would be fine if the AQM working group adopted it.

That said, there have only been a small number of mail list
comments here about it, and we (unfortunately) didn't devote
much of any meeting time to it in Toronto.

So, *please* let us know your thoughts on this in the next few
weeks.  I believe we would try to complete it relatively quickly
(e.g. 6 months) as an Informational RFC, assuming there is
consensus and AD approval to add the milestone.

I personally would like to see some stronger support for it from
this working group in order to feel good about adopting it, though
I think it is correct and may be "motherhood and apple pie" to
many of us.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] adoption call: draft-kuhn-aqm-eval-guidelines

[Wesley Eddy]

We have a milestone in the charter to produce an Informational RFC
on AQM evaluation guidelines.

We believe there is only one draft that has been targeting this so
far, that folks are reading and commenting on it, and that the
comments recently have been more about tweaking it than major rework.

We'd like to adopt draft-kuhn-aqm-eval-guidelines as a working group
item and develop it into an Informational RFC:

http://tools.ietf.org/html/draft-kuhn-aqm-eval-guidelines-02

Please let use know in the next few weeks if you have any comments,
questions, concerns, etc. about this.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] adoption call: draft-baker-aqm-sfq-implementation

[Wesley Eddy]

Based on feedback we've seen, it looks like there is significant
value in progressing draft-baker-aqm-sfq-implementation as a
working group document.

Assuming there is WG consensus and we have AD-approval, we would
like to add a milestone to develop this towards an Informational
RFC within ~6 months.

Please provide any comments, questions, support, or criticism for
adopting this within the next few weeks.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] adoption call: draft-baker-aqm-sfq-implementation

[Wesley Eddy]

For reference, the draft is at:
http://tools.ietf.org/html/draft-baker-aqm-sfq-implementation-00

On 8/11/2014 10:25 AM, Wesley Eddy wrote:
> Based on feedback we've seen, it looks like there is significant
> value in progressing draft-baker-aqm-sfq-implementation as a
> working group document.
> 
> Assuming there is WG consensus and we have AD-approval, we would
> like to add a milestone to develop this towards an Informational
> RFC within ~6 months.
> 
> Please provide any comments, questions, support, or criticism for
> adopting this within the next few weeks.
> 


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-07.txt

[Wesley Eddy]

On 8/11/2014 9:45 AM, go...@erg.abdn.ac.uk wrote:
> 
>> Responsiveness is important, but I believe it is OK for unresponsive
>> flows that are small in relative terms to only be responsive at very
>> long timescales (even solely at flow set up - self-admission
>> control). This even applies to aggregates of unresponsive flows,
>> because they will tend to be deployed where even the aggregate is
>> small relative to the link capacity.
>> See http://tools.ietf.org/html/draft-ietf-pwe3-congcons-02.pdf
>> (comments to the PWE3 list pls).
> 
> +GF: I don’t see this needed in this draft.
> 


I agree; this BCP is about AQM behavior, and not the right place to
hide recommendations or requirements on flow sources.


> +GF: I’m also considering replacing /congestive collapse/ by /congestion
> collapse/ which seems a more common term, as noted by John L.


I agree with this too.


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] IETF 90 minutes posted

[Wesley Eddy]

Please see the IETF 90 AQM meeting minutes posted at:
http://www.ietf.org/proceedings/90/minutes/minutes-90-aqm

Many thanks to Andrew McGregor for taking these down.

There are a couple of names that may need correcting; please
relay these and any other changes to either this list or to
aqm-cha...@tools.ietf.org.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] proposed process for algorithm RFCs

[Wesley Eddy]

One of the things we will talk about in the meeting today, and
should also discuss on the mailing list, is starting to adopt
algorithms specs as WG drafts towards getting them into RFCs.

We drafted a diagram to show the process we're thinking of as
chairs.  It's on the final slide of:
http://www.ietf.org/proceedings/90/slides/slides-90-aqm-0.pptx

Please share any thoughts, comments, criticisms, etc.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] Obsoleting RFC 2309

[Wesley Eddy]

There has been a bit of discussion last week about
draft-ietf-aqm-recommendation and how to improve the text near
the beginning, that leads to and sets context for the actual
recommendations.

John Leslie noticed that some of the things Bob Briscoe had
mentioned stem from trying to work from RFC 2309 as the starting
point.  We have been planning to Obsolete and replace 2309 with
this document.  John suggested instead to let it live on, and
have this new one only Update it, and has suggested specific
changes that could be edited in, if this were the case.

I think we need to make a conscious on-list decision about this,
and decide to either confirm that Obsoleting 2309 is correct, or
to change course.

Others can amplify or correct these, but I think the points for
each would be:

Obsoleting 2309
- 2309 was an IRTF document from a closed RG, and we now can make
  a stronger statement as an IETF group with a BCP
- 2309 is a bit RED-centric, and we now think that people should
  be looking at things other than RED

Not-Obsoleting 2309 (e.g. Updating 2309)
- 2309 is a snapshot in history of the E2E RG's thinking
- 2309 is mostly oriented towards AQM as a mitigation for congestion
  collapse, whereas now we're more interested in reducing latency

Please share any thoughts you have on this, and what should be done.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] references on global sync & lock-out

[Wesley Eddy]

Per the discussion in the telecon today about references for global
synchronization and lock-out, I think some excellent classic ones are:

Global Synchronization:

Zhang & Clark, "Oscillating Behavior of Network Traffic: A Case Study
Simulation", 1990
http://groups.csail.mit.edu/ana/Publications/Zhang-DDC-Oscillating-Behavior-of-Network-Traffic-1990.pdf

Floyd & Jacobson, "The Synchronization of Periodic Routing Messages", 1994
http://ee.lbl.gov/papers/sync_94.pdf


Lock-Out:

Floyd & Jacobson, "On Traffic Phase Effects in Packet-Switched
Gateways", 1992
http://www.icir.org/floyd/papers/phase.pdf


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] reminder: AQM conference call

[Wesley Eddy]

None of the information below has changed since initially announced,
but this is just a reminder that on Tuesday we'll have a conference
call that everyone is welcome to dial into in order to discuss the
ongoing AQM work and prepare for the Toronto meeting.

Agenda
==

1 - discuss overall WG status quickly
2 - discuss state of the 2309bis / recommendation draft
- if any editors or people with comments are online, this will be
  a chance to discuss any remaining items that haven't converged
  through the mailing list yet
3 - discuss state of evaluation guidelines / scenarios
- if one of the editors is available, we'd like them to share
  plans and status briefly
4 - discuss possibly adopting algorithms, as mentioned on the mailing
list and get some feedback on this
5 - plan agenda for Toronto


Webex and teleconference information



Topic: AQM
Date: Tuesday, June 24, 2014
Time: 1:00 pm, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 644 364 555
Meeting Password: 1234


---
To join the online meeting (Now from mobile devices!)
---
1. Go to
https://ietf.webex.com/ietf/j.php?MTID=ma8f0c666476fa3d8dd02ea205a46c036
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?MTID=mc8130e6e7792ca3024a9d7769782a4ba

---
To join the audio conference only
---
Call-in toll number (US/Canada): 1-650-479-3208

Access code:644 364 555

---
For assistance
---
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You can contact me at:
cmor...@amsl.com
1-510-492-4085

To add this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https://ietf.webex.com/ietf/j.php?MTID=m8c5e445ca347986e1d4d6cd7ee8abb3a

The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in
the meeting, please check whether you have the players installed on your
computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm