[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

[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 <w...@mti-systems.com> 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: [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] 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) 
<roland.bl...@kit.edu <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: [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] 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

[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 

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

[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] 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

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] 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] 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

[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

[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

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

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 <w...@mti-systems.com> 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

[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

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

[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 <w...@mti-systems.com>
Organization: MTI Systems
To: i...@ietf.org
CC: Justin Dailey <jus...@mti-systems.com>

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:07 PM, Dave Taht wrote:
 On Tue, Aug 18, 2015 at 3:03 PM, Roland Bless roland.bl...@kit.edu 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

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

[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 mich...@ifi.uio.no wrote:
 Hi,


 On 7. mai 2015, at 22.40, Dave Taht dave.t...@gmail.com 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

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 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: [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 dave.t...@gmail.com
 mailto:dave.t...@gmail.com 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: [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 davie...@scss.tcd.ie
To: General Area Review Team gen-...@ietf.org
CC: draft-ietf-aqm-recommendation@tools.ietf.org,IETF
Discussion i...@ietf.org

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

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

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

[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

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

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

[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] 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] 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

Re: [aqm] AQM conference call - June 24

[Wesley Eddy]

Here are webex and teleconference information for this meeting:


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

Re: [aqm] last call results on draft-ietf-aqm-recommendation

[Wesley Eddy]

On 5/15/2014 5:09 AM, Bob Briscoe wrote:
 Wes,
 
 I assume you also want comments on the new version. Is there a deadline
 for comments?


Absolutely, yes.  There's no deadline at the moment, but it would
be good to get any out sooner rather than later, especially if they're
likely to need more discussion or are asking for major changes.


 I prepared comments on the previous version, but didn't get the time to
 type them up. So I want to try to remedy this with the new version (that
 I haven't read yet).


The diffs aren't huge, so many of your comments on the previous
revision might still be valid.


-- 
Wes Eddy
MTI Systems

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

[aqm] last call results on draft-ietf-aqm-recommendation

[Wesley Eddy]

Hello AQMers, the WG last call on the 2309bis / AQM
recommendation draft has turned up a couple of reviews that
said the document isn't quite ready.  I think some of the
comments could be resolved relatively easily with an update,
though others might take some discussion to converge on what
really is needed to say or not say in this document.

There haven't been any responses to these yet that I've seen,
nor a solid set of positive comments.  So, we're not going to
advance this quite yet.

We do want to make progress between now and the next meeting.

We thought that perhaps a webex / teleconference side meeting
would give people a chance to talk about next steps and help
to advance this.

If you're interested in participating in this, please respond
to this poll on some possible times:

http://doodle.com/ng3y444te6mbendx

Assuming there's a critical mass of responses, we'll try to
pick a time that's least inconvenient, though guaranteed to
be terrible for some.

Thanks for your feedback on this, and help towards finishing
the document.

-- 
Wes Eddy
MTI Systems

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

[aqm] publishing algorithms

[Wesley Eddy]

Hello AQMers.  As chairs, Richard and I had been planning to let
the evaluation guidelines converge and then use those to guide
adoption of algorithm documents.

However, we now think there may be value in not waiting so long,
and getting some algorithm documents moving along more quickly.

We hope you can provide some feedback on the plan below:

1) Starting soon, we may look to adopt a small number of algorithm
   drafts for Experimental, with the goal that by doing so, it will
   increase the number of eyeballs and independent reviews of them, and
   enhance the quality, since people may be implementing to the drafts
   in order to test using the evaluation guidelines.  Each algorithm
   *must* clearly identify which types of use cases / scenarios it is
   targeted for.

2) Adoption of an algorithm spec as a working group draft will require
   working group consensus that the algorithm looks attractive to
   experiment with for the stated scenarios, and multiple parties will
   plan to be looking at it, testing, analyzing, providing feedback,
   etc.

3) The evaluation guidelines / scenarios drafts being worked on
   separately will guide the later selection of one or more Experimental
   algorithms to become Proposed Standards with applicability
   statements for the scenarios they have been evaluated in.

We're interested to know if the working group thinks this sounds like
a good idea, bad idea, or any other thoughts.

-- 
Wes Eddy
MTI Systems

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

Re: [aqm] publishing algorithms

[Wesley Eddy]

n 4/1/2014 12:34 PM, Fred Baker (fred) wrote:
 Makes sense to me. I do have one question. Per charter, in December 
 we are supposed to Submit first algorithm specification to IESG for 
 publication as Proposed Standard”. Would this be a change of 
 direction for the charter?


Yes, it would be a shift in plans, and we'd have to make up some new
milestone targets.  That's why we're looking for feedback before doing
it, because it only makes sense to do if the people actually doing the
work will go along with it :).


 Note that I’m not pushing a given algorithm, nor am I convinced that 
 there should be exactly one. In protocol design, we are worried about
 interoperability, and everyone has to implement the protocol the same
 way. In AQM, the different algorithms, and the ones we think of next,
 have to produce a specific drop or mark rate under a specified
 circumstance (which might be about queue depth, latency in queue, or
 rate through a queue), and the end systems need to respond to that
 predictably. The means by which the mark or drop rate is established
 is semi-irrelevant if the rate itself is maintained. So I’m not
 exactly sure what the terms “Experimental” or “Proposed Standard”
 mean in the context and using the definitions in RFC 2026. It would
 be nice if we had a status that said “recommended for consideration
 for operational use”, and we could put that status on several that
 meet our requirements, whatever we decide those are.


I think (well, I hope) that pretty much everyone agrees on this.

My personal thought is that the Experimental ones may have some warts or
unknowns, and that should be okay with us, as long as they seem to be
promising and there is wide interest in using them and finding out more
about how they work or how they can be tweaked further, but a baseline
is needed/desirable for multiple people to work from.

The Standards Track algorithm(s) should have substantially less warts or
unknowns about them, and people should be able to put them in their code
and products with strong confidence that:

  1) they're implementing from an unambiguous specification
  2) it will perform with well-understood results

For instance, a hypothetical Algorithm X may have been beat to death by
one set of folks for some particular use case like a home gateway cable
router. They speculate that it will do well for some other scenarios
too, and there are other people interested in implementing and trying it
out over a longer term, but nobody is fully sure that it's absolutely
the best algorithm, and maybe there are some downsides like a bit of
minor tuning or a hidden variable that has to be tweaked for other
scenarios. That sounds like a good candidate for Experimental to me.
Maybe people will go play with it, and either learn good things and fix
it up for Standards Track, or learn bad things and drop it or make it
Historic.


-- 
Wes Eddy
MTI Systems

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

Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))

[Wesley Eddy]

On 1/14/2014 4:57 PM, l.w...@surrey.ac.uk wrote:
 I don't think sayng 'oh, that error source is no longer a problem' disproves
 Stone's overall point about undetected errors, though the
 examples he uses from the technology of the day are necessarily
 dated. Dismissing the overall  point because the examples use obsolete
 technology is throwing the baby out with the bathwater; a host-to-host
 error check catches things that intermediate checks cannot.
 
 Measuring error rates across end-to-end  Internet traffic is something that 
 has
 not received much attention , as error detection is not
 instrumented well - hence citing Stone's published work,  in the absence
 of awareness of anything newer (and as high profile/immediately recognisable
 as sigcomm) in the area.
 


+1 ... the message in the paper is applicable to layered systems
and internetworks in general.  Changes in the link technology
since then don't invalidate it, especially since we know that
the technology not only changes rapidly, but also is always
growing in diverse directions, such that there things almost
universally true today may be turned on their heads tomorrow.

Designs for stacking layers need to follow solid general
principles in order to be robust to changes (above and below).

-- 
Wes Eddy
MTI Systems
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[aqm] WG status

[Wesley Eddy]

Hi, as we've entered 2014 and have charter milestones that we're
working towards, Richard and I thought it would be good to start
periodically sending a status report to the WG mailing list so
that we can all keep up with what's going on, and focus our efforts
together on the things that need work.

Towards that goal, here is a snapshot of where we think the AQM
working group is at today, and what the next steps are that people
can contribute to:


- WG Milestones:
  - Submit AQM recommendations to IESG for publication, obsoleting RFC
2309 (Goal: January 2014)
- draft-ietf-aqm-recommendation is accepted towards this milestone
- http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/
- the draft needs to be updated per comments received, including
feedback on the recommendations from the Vancouver meeting
- if the authors are comfortable, a WGLC might be made on the next
revision
- we would like to hear from other authors of RFC 2309 on this
document, if anyone has contacts to them.

  - Submit AQM algorithm evaluation guidelines to IESG for publication
as Informational (Goal: July 2014)
- We need an editor team to step forward and begin work on this;
there was initial work presented in Vancouver, but no draft available or
adopted by the working group yet.
- It will be difficult to make this milestone, and will push other
milestones back, if this work isn't accelerated.
- Please express interest to the chairs or on-list

  - Submit first algorithm specification to IESG for publication as
Proposed Standard (Goal: December 2014)
- Since any Proposed Standard algorithm should be in line with the
recommendations and be passable versus the evaluation guidelines, this
milestone is hard to start on without significant progress on the
previous two.
- Currently the only algorithm spec with a complete and active
individual-submission draft is PIE

- Other items:
  - draft-pan-aqm-pie is under active work as a proposed algorithm:
http://tools.ietf.org/id/draft-pan-aqm-pie-00.txt
  - CoDel draft is expired; Dave Taht or others may revive it and/or
describe pairing with FQ/SFQ algorithms:
http://tools.ietf.org/id/draft-nichols-tsvwg-codel-01.txt
  - Other algorithm specifications are welcome!
- Though, we are not planning on adopting algorithms until
recommendations and evaluation guidelines are mostly stable


-- 
Wes Eddy
MTI Systems
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] [Bloat] [iccrg] AQM deployment status?

[Wesley Eddy]

On 10/14/2013 1:07 PM, Curtis Villamizar wrote:
 So my first question to the AQM WG is what is the scope of AQM WG
 work in terms of where in the network this WG wants to focus?  If the
 answer to that question is everywhere, then we have to be aware that
 conditions in core and conditions in home or enterprise are very
 different.  If the focus is on home, soho, and small business, then
 the charter should say so (I don't think it is).


The charter says:

  It is expected that some classes of algorithms will focus on software
  implementations, while others on existing or new hardware
  deployments, and algorithms may be specific to distinct scenarios.


I would say anywhere that AQM algorithms can have a positive impact
is in scope, and that it's understood and accepted that particular
algorithms or tuning rules may not be ideal across different
environments (or may not be easily implemented in different kinds of
platforms).  There was at least some talk of applicability
statements for things that wind up being recommended by the working
group.

In my opinion, the home broadband router is one well-known case that
may hold a lot of the initial attention in the working group, because
the barriers to implementing/testing/deploying new algorithms for this
case are less than for many others.  We definitely did not want to
limit the charter to this scenario though, and it is intentionally
open to others.

I hope this clears it up!


-- 
Wes Eddy
MTI Systems
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] working group kickoff

[Wesley Eddy]

Congratulations, as you may have seen, the AQM working group was
approved by the IESG!

Richard and I wanted to remind people that the charter is fairly
aggressive in schedule.

We previously had seen strong consensus in the BoF meeting and
on the AQM and TSVAREA mailing lists for making a working group
document of draft-baker-aqm-recommendation.  Richard and I plan
to have the editors submit the next revision of that as a WG item,
but please scream if there is a problem with this.

There is a meeting request in for Vancouver where we hope to spend
the time talking about 2309bis, and any big issues with it, and
about algorithm evaluation (Naeem Khademi et al).  Currently, those
are our agenda priorities, based on the upcoming charter milestones,
but please let Richard and I know if you have other needs for
meeting time.

-- 
Wes Eddy
MTI Systems
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: TCPMUX (RFC 1078) status

[Wesley Eddy]

On 8/15/2013 4:18 PM, Joe Touch wrote:
 
 
 On 8/10/2013 12:29 PM, Wesley Eddy wrote:
 On 8/10/2013 1:43 AM, Martin Sustrik wrote:
 Hi all,

 Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used?
 Is it the case that there are inetd daemons in TCPMUX mode running
 everywhere, or can it be rather considered a dead protocol?

 Specifically, if I implement a new TCPMUX daemon how likely I am to
 clash with an existing TCPMUX daemon listening on port 1?



 It's in the FreeBSD inetd, among others, but to to my
 knowledge, nobody actually turns it on.  There are
 probably security issues.
 
 There are semantics issues to; see draft-touch-tcp-portnames-00 for
 information (this is being revised for resubmission shortly, FWIW).
 


I totally agree.  In fact, in the update to the TCP roadmap [1], we
added TCPMUX to the section on Historic and Undeployed Extensions,
though it definitely bears further discussion than is currently in
the roadmap.  I think we should add a reference to your portnames doc
to explain why this should be Historic plus check a bit more to see if
the code that's out there is really being used or whether it's just
hanging out like a vestigal limb in the various inetd packages.

If it's fair to ask Martin ... I'm kind of curious why you might want
to be using it or think it sounds useful?  I think a lot of admins
would be concerned that it could be used to get around port-based
firewall rules, etc.

[1] http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-00

-- 
Wes Eddy
MTI Systems

Re: TCPMUX (RFC 1078) status

[Wesley Eddy]

On 8/10/2013 1:43 AM, Martin Sustrik wrote:
 Hi all,
 
 Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used?
 Is it the case that there are inetd daemons in TCPMUX mode running
 everywhere, or can it be rather considered a dead protocol?
 
 Specifically, if I implement a new TCPMUX daemon how likely I am to
 clash with an existing TCPMUX daemon listening on port 1?
 


It's in the FreeBSD inetd, among others, but to to my
knowledge, nobody actually turns it on.  There are
probably security issues.

-- 
Wes Eddy
MTI Systems

[Int-area] forming an IETF AQM working group

[Wesley Eddy]

We are trying to start a working group in the IETF to focus
on Active Queue Management (AQM) and packet scheduling or
fair queuing algorithms.

There is a mailing list setup at:
https://www.ietf.org/mailman/listinfo/aqm

Anyone interested is free and welcomed to join the discussion.
We especially want to have people with different perspectives
participating, including hardware and software developers for
different types of systems, network operators, academics, etc.

There will also be a Birds of a Feather (BoF) meeting at the
IETF meeting in Berlin (http://www.ietf.org/meeting/87) later
this month, which we wanted to make people aware of.  The
goal of the meeting is to form a working group following the
meeting.

A draft charter that is being discussed can be found here:
http://www.ietf.org/mail-archive/web/aqm/current/msg00165.html

-- 
Wes Eddy
MTI Systems
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: Draft agenda for the IETF-87 TSV Area meeting uploaded

[Wesley Eddy]

On 7/6/2013 5:52 PM, l.w...@surrey.ac.uk wrote:
 
 IETF transport focuses on maintaining its existing standards; that's 
 my point. It's not really set up for experimental work not directly 
 related to those standards.
 


I'm not really sure how TSV could be setup any better to do this type
of work.  It could be a matter of opinion how directly related the
experimental work is.  For instance, CONEX is built on ECN, MPTCP is
built on TCP, and RMCAT is building on RTP ... but all are such
significant developments that they can't be classed as simply
maintenance.  In Berlin, TSV has 2 BoFs planned in Berlin which are
not jst maintenance of existing standards (TCMTF and AQM). Clearly,
there are also important existing protocols (TCP, SCTP, etc) that a lot
of TSV energy goes into maintaining, but that's certainly not all that
we do.

The community focuses on what it chooses to, by individuals (and
companies sponsoring them) investing time and energy into the WGs and
drafts that they have shared interests in.  For some experimental
things, that can be difficult because it requires a critical mass, and
people have to be willing to work together at whatever pace the group
adapts.  Larger groups will have slower paces.

The hope is that we wind up with better specs, less flaws, and stronger
interop between multiple codebases as a result of working together, and
create a better Internet.  Those are not the priority for every protocol
development effort, and a lot of people have good reasons for doing
things on their own.  This does not signal a problem with the IETF.

-- 
Wes Eddy
MTI Systems

new AQM list

[Wesley Eddy]

Following on the TSVAREA meeting today, we started a new non-WG
mailing list called AQM for Active Queue Management topics:

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

This is intended to be the place to discuss drafts, and proposing
a BoF or WG charter for AQM work, along with anything else related
to sizing and managing buffers that may be relevant.

If the folks who are interested could join there, and gradually
shift the conversations to it, off of TSVWG (who have other fish
to fry), that would be excellent.

Thanks for your feedback today!

-- 
Wes Eddy
MTI Systems

Re: congestion control? - (was Re: Appointment of a Transport Area Director)

[Wesley Eddy]

On 3/5/2013 10:40 AM, Spencer Dawkins wrote:
 On 3/5/2013 8:15 AM, Brian E Carpenter wrote:
 On 05/03/2013 11:55, Dearlove, Christopher (UK) wrote:
 I've no idea about the example quoted, but I can see some of their
 motivation.

 TCP's assumptions (really simplified) that loss of packet =
 congestion = backoff
 aren't necessarily so in a wireless network, where packets can be
 lost without
 congestion. This means that TCP into, out of, or across, a MANET
 using TCP can be
 bad. It then tends to happen that the MANET people don't fully
 understand TCP,
 and the TCP people don't fully understand MANETs.

 The effects you mention were definitely discussed in PILC.
 http://www.ietf.org/wg/concluded/pilc.html
 Maybe the PILC documents need revision?

  Brian
 
 TRIGTRAN tried to nail this down in more detail after PILC concluded (I
 co-chaired both PILC and the TRGTRAN BOFs). This quote from the IETF 56
 minutes pretty much captured where that ended up:
 
 quote
 Spencer summarized a private conversation with Mark Allman as, Gee,
 maybe TCP does pretty well often times on its own.  You may be able to
 find cases where you could do better with notifications, but by the time
 you make sure the response to a notification doesn't have undesirable
 side effects in other cases, TCP doesn't look so bad
 /quote
 
 If we had to have all the TCP responding-to-loss mechanisms in an
 implementation anyway, and we could tell a sender to slow down, but not
 to speed up, it wasn't clear that additional mechanisms would buy you much.
 
 References are at
 http://www.ietf.org/proceedings/55/239.htm and
 http://www.ietf.org/proceedings/56/251.htm
 
 The high order bit on this may have been that TRIGTRAN wasn't IETF-ready
 and should have gone off to visit IRTF-land, but in the early 2000s, I
 (at least) had no idea how to make that happen.
 


Later on, there was also a proposed TERNLI BoF and mailing list,
and bar BoF that resulted in:
http://tools.ietf.org/id/draft-sarolahti-tsvwg-crosslayer-01.txt
But didn't go any farther, that I'm aware of.  Section 6 actually
puts into context TRIGTRAN and other attempts to do something in
this space.  There's quite a bit of history just in the IETF.

RFC 4907 (IAB's Architectural Implications of Link Indications)
is also a good snapshot of the thinking at that time.

-- 
Wes Eddy
MTI Systems

Re: congestion control? - (was Re: Appointment of a Transport Area Director)

[Wesley Eddy]

On 3/5/2013 3:01 PM, Cameron Byrne wrote:
 
 In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop
 the packet, by design.  It will just delay the packet as it gets
 resent through various checkpoints and goes through various rounds of
 FEC.  The result is delay, TCP penalties that assume delay is loss,
 ... the end result is that every 3GPP network in the world (guessing)
 has proxies in place to manipulate TCP so that when you go to
 speedtest.net your $serviceprovider looks good.  Is this good
 cross-layer optimization, no... but this is how it is.
 
 So, fundamentals of CC and TCP have resulted in commercial need for
 middleboxes in the core of the fastest growing part of the internet.
 This is sometimes known as tcp optmization or WAN acceleration,
 both murky terms.
 


There may be some things the IETF can do to improve this.  It's not
clear yet, but some of the relevant vendors are participating in a
non-WG mailing list, focused on one aspect of the situation (TCP
option numbers), but recently more ambitious work was suggested:
http://www.ietf.org/mail-archive/web/middisc/current/msg00121.html

People who are interested in this, should *definitely* self-organize
a bit and think about a BoF, in my opinion.

-- 
Wes Eddy
MTI Systems

Re: Appointment of a Transport Area Director

[Wesley Eddy]

On 3/4/2013 3:07 AM, Eggert, Lars wrote:
 There are qualified people in the industry, and that's where most of
 the past ADs have come from. In the last few years, it's been
 increasingly harder to get them to step forward, because their
 employers are reluctant to let them spend the time. I actually think
 that this is because employers realize that these skills are
 important and rare to find, and so you want these guys to work on
 internal things and not donate them to the IETF.


When the TSV ADs asked the directorate about this topic, one of
the things we heard is that transport features don't strongly
associate with product lines or features.  So there may also be
a case where management doesn't identify with the value in TSV,
and maybe companies aren't internally developing people as much
for TSV expertise as for other topics.

Also, sponsoring an AD does not seem to be generally feasible for
small companies or services-based companies (compared to product-
based companies) without some outside support, since otherwise
the hours spent ADing are overhead.  This further limits the pool.

-- 
Wes Eddy
MTI Systems

Re: [Cerowrt-devel] [Bloat] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

[Wesley Eddy]

On 2/28/2013 2:55 PM, Matt Mathis wrote:
 Two of the tests in my model based metrics draft (for IPPM) are for
 AQM (like) tests.   One we have pretty good theory for (preventing
 standing queues in congestion avoidance) and the other we don't
 (exiting from slowstart at a reasonable window).
 
 See: draft-mathis-ippm-model-based-metrics-01.txt
 
 My intent is that these tests will become part of a future IPPM
 standard on what a network must do in order to support modern
 applications at specific performance levels. Although the draft
 will not specify AQM algorithms at all, it will forbid some non-AQM
 behaviors such as unreasonable standing queues.   To the extent that
 it gets traction as a standard, it will strongly encourage deployment,
 even if we are not totally convinced that our current AQM algorithms
 are 100% correct.


I like the idea.


 However, It is not clear that we need to standardize AQM - It strikes
 me as one area where we can permit pretty much unfettered diversity in
 the operational Internet as long as it meets a pretty low  it seems
 to work bar.


Fully agreed!  Publishing specs is only useful to get some
known-good algorithm(s) that folks can safely implement
without thinking too hard, and also to burn off any possible
ambiguities in the descriptions of the algorithms, catch any
corner cases, etc.


 For this reason it is important to deploy your favorite algorithm(s)
 ASAP, because they are all infinitely better than none, and future
 improvements will be relatively minor by comparison.
 


Agreed, with the caveat that not *all* conceivable algorithms
are good :).  One of the things I think might be useful rather
than (or in addition to) specifying algorithms, is specifying
test setups or metrics that allow any algorithm to be checked
for sanity, as a black box.

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

Re: [Cerowrt-devel] [Bloat] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

[Wesley Eddy]

On 2/28/2013 10:53 AM, Dave Taht wrote:
 
 For those that don't attend ietf meetings in person, there is usually
 live audio and jabber chat hooked up into the presentations.
 
 See y'all there, next month, in one form or another.
 


In the TSVAREA meeting, we've also set aside some time to talk
about AQM and whether there's interest and energy to do some
more specific work on AQM algs in the IETF (e.g. like CoDel and
PIE):

https://datatracker.ietf.org/meeting/86/agenda/tsvarea

I'm working with Martin on some slides to seed the discussion,
but we hope that it's mostly the community that we hear from,
following up in the higher-bandwidth face-to-face time from
the thread we had on the tsv-a...@ietf.org mailing list a few
months ago.


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

Re: [Bloat] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

[Wesley Eddy]

On 2/28/2013 10:53 AM, Dave Taht wrote:
 
 For those that don't attend ietf meetings in person, there is usually
 live audio and jabber chat hooked up into the presentations.
 
 See y'all there, next month, in one form or another.
 


In the TSVAREA meeting, we've also set aside some time to talk
about AQM and whether there's interest and energy to do some
more specific work on AQM algs in the IETF (e.g. like CoDel and
PIE):

https://datatracker.ietf.org/meeting/86/agenda/tsvarea

I'm working with Martin on some slides to seed the discussion,
but we hope that it's mostly the community that we hear from,
following up in the higher-bandwidth face-to-face time from
the thread we had on the tsv-a...@ietf.org mailing list a few
months ago.


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

Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc

[Wesley Eddy]

On 12/20/2012 12:21 PM, Brandon Williams wrote:
 Dear all,
 
 A new version of this draft has been submitted that attempts to lay out
 a more clear argument for the use of both TCP and IP options, with
 references to other efforts in the same arena.
 
 Comments are welcome.

(note, I've cross-posted to INTAREA and TCPM, since similar
announcements went to each list)

Hi Brandon, *many* thanks for writing this; it does help me (at least)
to understand what you're doing with this option.

As I now understand it, instead of a tunneling approach that would
normally be applied for building overlay networks, this approach
pushes and pops IP addresses from the protocol options fields.

Can you discuss why normal tunneling protocols aren't used to build
the overlay?

Since those are easily and widely available, I wonder why they aren't
used and why something more elaborate, fragile, and not as compatible
with the Internet architecture is really needed or felt to be a good
idea?  I understand that it basically *works* ... but just am not
seeing how it makes sense?

-- 
Wes Eddy
MTI Systems

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc

[Wesley Eddy]

On 12/20/2012 3:49 PM, Brandon Williams wrote:
 Hi Wes,
 
 Thanks for your comments.
 
 It looks like I might have managed to make the use of the proposed
 option less clear, instead of more clear. Or maybe I'm misunderstanding
 the point that you're making.
 
 The mechanics of our system are tunnel-based, as with most overlay
 architectures that I've looked at. The tunneling starts at an overlay
 ingress machine close to one of the endpoints (i.e. the client or
 server) and ends at an overlay egress machine close to the other
 endpoint. Since the ingress and egress are on the public internet, the
 overlay does not extend all the way onto the endpoints' LANs. This means
 that standard internet routing cannot be used to drive the connections
 into the overlay. Instead, NAT is used on both sides of the overlay,
 which results in the server having no way to reliably identify the client.
 
 The proposed options are not intended to be used as part of the
 mechanics of the overlay. The overlay is fully functional without the
 options. Instead, the options are intended to provide the client's
 connection identifying information to the server for use in
 load-balancing, diagnostics, etc.
 

Ah, so are there additional devices beyond what's shown in your Figure
1?  I ask because if the overlay ingress and egress are simple tunnel
endpoints, then the endpoint addresses would be totally visible to one
another.

Your figure 1 is:

  ++
  ||
  |  INTERNET  |
  ||
   +---+  |  ++|
   |  HOST_1   |-| OVRLY_IN_1 |---+|
   +---+  |  ++   ||
  |   ||
   +---+  |  ++ +---+  |  ++
   |  HOST_2   |-| OVRLY_IN_2 |-| OVRLY_OUT |-| SERVER |
   +---+  |  ++ +---+  |  ++
  |   ||
   +---+  |  ++   ||
   |  HOST_3   |-| OVRLY_IN_3 |---+|
   +---+  |  ++|
  ||
  ++

 Figure 1

If there were tunnels between the OVRLY_IN and OVERLY_OUT boxes,
then the inner IP headers would have the HOST_X and SERVER
addresses, and the outer ones in the tunnel would have the
overlay headers.  Since the inner packets would be delivered
ultimately after egressing the tunnels, the HOST_X addresses
are totally visible to the server, and vice versa.

Your document shows instead:

   -

 ip hdr contains:   ip hdr contains:
   SENDER - src = sender   -- OVERLAY -- src = overlay2  -- RECEIVER
 dst = overlay1 dst = receiver

   -

So, this is not really showing tunnels to me ... this is rewriting
(NAT) of the destination address.

Or am I misunderstanding?

-- 
Wes Eddy
MTI Systems
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[dccp] closing DCCP WG

[Wesley Eddy]

Hello, as you may have noticed, the RFC on UDP encapsulation of
DCCP is now published, and there is nothing left to be done on
the DCCP WG milestones list.

I am going to ask for the Working Group to be closed.  The
necessary specifications have all been completed and are stable,
and not much other activity on extensions, new CCIDs, etc seems
to be going on, which would justify keeping the group chartered.

Thanks to everyone who participated over the years to reach this
state!

After discussion with Pasi, we think it may be a good idea to
leave the mailing list open for a year or so, in case there are
any questions from people implementing and using DCCP.  After
then, we'll reassess whether leaving the mailing list available
is having any value.

Any new proposals for DCCP maintenance or extension should go
to TSVWG (ts...@ietf.org).

-- 
Wes Eddy
MTI Systems

Re: [Bloat] [Codel] RFC: Realtime Response Under Load (rrul) test specification

[Wesley Eddy]

On 11/6/2012 8:56 AM, Dave Taht wrote:
 On Tue, Nov 6, 2012 at 2:42 PM, Henrique de Moraes Holschuh
 h...@hmh.eng.br wrote:
 On Tue, 06 Nov 2012, Dave Taht wrote:
 I have been working on developing a specification for testing networks
 more effectively for various side effects of bufferbloat, notably
 gaming and voip performance, and especially web performance as
 well as a few other things that concerned me, such as IPv6 behavior,
 and the effects of packet classification.

 When it is reasonably complete, it would be nice to have it as an
 informational or better yet, standards-track IETF RFC.

 IETF RFC non-experimental status allows us to require RRUL testing prior to
 service acceptance, and even add it as one of the SLA metrics on public
 tenders, which goes a long way into pushing anything into more widespread
 usage.
 
 It was my intent to write this as a real, standards track rfc, and
 also submit it as a prospective test to the ITU and other testing
 bodies such as nist, undewriter labratories, consumer reports, and so
 on.
 
 However I:
 
 A) got intimidated by the prospect of dealing with the rfc editor
 
 B) Have some sticky problems with two aspects of the test methodology
 (and that's just what I know about) which I am prototyping around.
 Running the prototype tests on various real networks has had very
 interesting results... (I do hope others try the prototype tests,
 too, on their networks)
 
 C) thought it would be clearer to write the shortest document possible
 on this go-round.
 D) Am not particularly fond of the rrule name. (suggestions?)
 
 I now plan (after feedback) to produce and submit this as a standards
 track RFC in the march timeframe.
 
 It would give me great joy to have this test series included in
 various SLA metrics, in the long run.
 


Hi Dave, in my role as IETF TSV AD, I would be happy to help
you get this into the IETF.  Please note that you can't get
a Standards Track RFC published without a working group
adopting it or an AD sponsoring it.

This topic would be of interest for the IPPM and BMWG working
groups, and I know it is of interest to me as a TSV AD, so we
should be able to find a way to bring it in.

In fact, the timing is good, as FCC folks are at the IETF this
week talking about their vision for broadband test and
measurement architecture, and these tests may relate nicely
to that proposed work.

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

IETF 85 TSVAREA planning

[Wesley Eddy]

It's already time to start planning for IETF 85 in Atlanta.
https://www.ietf.org/meeting/85/index.html

We've requested a timeslot for a TSVAREA open meeting.  If
there are things you'd like to talk about or suggest, please
let Martin and I know, as soon as possible, so that we can
organize this and plan appropriately.

-- 
Wes Eddy
MTI Systems

Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02

[Wesley Eddy]

On 8/8/2012 11:30 AM, Dan Wing wrote:
 Today's Internet users, which are not sharing addresses with other users,
 are sending an uniquely-identifyable identifier to every Internet server
 they use:  their unique IP address.  

Users don't have IP addresses.  Machines do.  Which are
we trying to identify again?  I think the distinction
is important since the relation between users and devices
can be one-to-many, or many-to-one, and certainly isn't
one-to-one, even if we went back in time when the
relation between end-host machines and addresses might
have been closer to one-to-one.

I also don't think user and subscriber are synonyms for
many purposes, though some of the reveal-analysis seems to
be more oriented towards identifying the access network
subscriber.  That subscriber generally may have quite
a few users and machines behind them.

-- 
Wes Eddy
MTI Systems
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02

[Wesley Eddy]

On 7/27/2012 2:03 PM, Dan Wing wrote:
 -Original Message-
 From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On
 Behalf Of Wesley Eddy
 Sent: Thursday, July 26, 2012 11:34 AM
 To: sarik...@ieee.org
 Cc: Internet Area; Behcet Sarikaya
 Subject: Re: [Int-area] Completion of working group last call for
 draft-ietf-intarea-nat-reveal-analysis-02

 On 7/26/2012 1:08 PM, Behcet Sarikaya wrote:
 On Thu, Jul 26, 2012 at 3:25 AM,  mohamed.boucad...@orange.com
 wrote:
 Dear Suresh, all,

 After reading received comments, the major point we need to discuss
 is whether the WG wants to remove Section 3.3 or maintain it. I'm
 waiting for a feedback from the WG for the direction to take. I will
 implement any change requested by the WG.


 Section 3.3 seems to give preference to one specific solution, as
 such
 it is against the whole spirit of this document.

 I suggest removing it.



 +1

 In fact, I suggest that the draft should clearly say that it's
 doubtful whether a solution actually *needs* to be identified and
 recommended, especially ones that are implemented awkwardly in other
 layers.
 
 I can't make technical sense of which of the 8 approaches are awkward, in
 your analysis.  I have my own analysis, but the document does not do an
 evaluation on awkwardness.  
 
 
 The underlying problem was identified in Section 13.1 Abuse Logging and
 Penalty Boxes of RFC6269, Issues with IP Address Sharing,
 http://tools.ietf.org/html/rfc6269#section-13.1.  That was an INTAREA
 document.  
 
 Hence, that is why the analysis document is also an INTAREA document.
 
 
 My view is the penalty box problem described in Section 13.1 of RFC6269 is
 real.  My view is the penalty box problem will continue to grow so long as
 there are IPv4-accessible servers and so long as there are IPv6 clients
 (NAT64) or IPv4 clients accessing those IPv4 servers.  There appear to be
 different views on the size and trajectory of the problem (getting worse
 versus getting better).  Perhaps discussing those views would be beneficial.
 


Hi Dan - The problem is real because there are bits of
deployed code built on an assumption that was good maybe
12 years ago, that IP addresses could be tied to users or
machines.  Since this is totally broken now, the solution
is to get rid of them and use the proper identifiers for
whatever it is that these system are trying to do.  Building
kludges in other layers to supplement the IP address is
not the answer.

Since the analysis in the document already indicates that
each of the 8 solutions has non-starter properties to them,
I consider that to make them pretty awkward.  Recommending
any of them is like saying this is the best tasting crap
we could find.

-- 
Wes Eddy
MTI Systems
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: IETF84/Vancouver planning

[Wesley Eddy]

TSVAREA is currently on the agenda for Monday 7/30, in the 1540-1710
timeslot.  The current agenda (still subject to some change) is:


* Agenda bashing

* Bufferbloat Topics:

  * Controlled Delay -- Van Jacobson (35 minutes)
http://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel/
http://queue.acm.org/detail.cfm?id=2209336

  * Harnessing the power of ECN -- Murari Sridharan (20 minutes)

  * LEDBAT and Real-Time Media -- Randell Jesup (15 minutes)

* Other Topics:

  * Self-forming P2P -- Johan Pouwelse (15 minutes)
https://datatracker.ietf.org/doc/draft-pouwelse-censorfree-scenarios/



-- 
Wes Eddy
MTI Systems

Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02

[Wesley Eddy]

I read the document and came to rather different conclusions (see
below):

On 7/9/2012 4:41 PM, Tina TSOU wrote:
 I reviewed this draft and I found it very detailed about the various
 ways of including a HOST ID. Considering the number of users that share
 the same IPv4 address, there is an increasing importance of the HOST ID.
 Though it is discussed in the introduction about the various
 implications of not having HOST IDs, in my opinion, there should be a
 little more explanation of the problems faced if there is no HOST ID
 included. Moreover, the main concern is security issue. It is very
 difficult to identify a particular user, when there are a number of
 users with different private IP addresses sharing the same public address.


I agree with you that if the document is pursued, it should include
more discussion of what the problems are with not having a host ID;
the current text seems like handwaving to me.  I don't personally
think it is very well motivated, and from my standpoint there is
absolutely no reason to pursue a solution.  It would be enough to
simply have the analysis documented as to why all of the considered
approaches COMPLETELY STINK.

But aside from that, I disagree with you on purpose of whatever is
being attempted here.  The document is about identifying hosts, and
you mention users.  These are not the same thing.  Which do you want
to identify?  In my opinion, anything related to users (and not hosts)
should be completely out of scope.

Further, I think the problem has to perhaps be refined to
disambiguating between different hosts using the same IP address
versus trying to semi-uniquely identify the hosts.  The problems
described are due to aliasing, and unique identification is a
rather strong means of de-aliasing.


 The TCP option is another good way to include the HOST ID in case of TCP
 and UDP communications. 


Surely there's a typo there, since it does not work at all in the
case of UDP.

I disagree with the overall recommendation of the document, since
it presumes that a solution is required, among other flaws with it.

Additionally, it is not particularly clear how this can work for
multiple layers of sharing (e.g. CGN), though draft-abdo seems to
think that CGN is a single layer of sharing.

-- 
Wes Eddy
MTI Systems
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

IETF-83/Paris TSVAREA planning

[Wesley Eddy]

Hello, as we plan for a potential TSVAREA meeting in Paris at
IETF-83 (http://www.ietf.org/meeting/83/index.html), please
let David and myself know of any topics you would like to
discuss in a TSVAREA meeting, so that we can plan for the time
appropriately.

Thanks!

-- 
Wes Eddy
MTI Systems

TSVAREA in Taipei

[Wesley Eddy]

Hi, David and I haven't requested a TSVAREA meeting yet in Taipei.
The cut-off for requests is on Monday.  I don't think we've seen
any proposed presentation topics, and would need to know those in
order to request an appropriate meeting time.

At the moment, I'm not planning to request a TSVAREA meeting time,
so if there are topics you'd like to discuss, please let us know
swiftly so that we can request a timeslot.  Otherwise, I assume
we'll plan to send an area status update to the mailing list, rather
than present it in-person.

Thanks in advance for any feedback on this.

--
Wes Eddy
MTI Systems

Re: Limitations in RFC Errata mechanism

[Wesley Eddy]

On 8/30/2011 11:19 AM, Mykyta Yevstifeyev wrote:

Hello all,

I've observed several problems with submission mechanism for RFC Errata.
Here they are:

First, we have only two types of errata - Technical or Editorial. In
presence of
http://www.ietf.org/iesg/statement/rfc-metadata-errata.html, IESG
Statement on IESG Processing of RFC Errata concerning RFC Metadata, I
think the third type is necessary - Metadata.




I agree with this part of the proposal, at least.


--
Wes Eddy
MTI Systems
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: notes from discussion of KARP design guidelines

[Wesley Eddy]

On 7/13/2011 1:31 PM, Joel M. Halpern wrote:

Replacing a widely used term (on the wire) with term that folks will
not understand does not seem to me personally to be a benefit.


I think Joe's point is that it's widely used as a concept, but what
it means specifically in this document is not clear.  A sentence to
clarify up-front what the definition is in this document might be
enough.



In terms of this document, I do not see a problem with the usage as it
is. This is not a protocol document. The use of the current term in this
context seems helpful rather than harmful.


It might be reasonable to add a sentence that says, In this document,
'on the wire' refers to (A) the routing protocol data itself, as well
as (B) the way in which routing protocol data is exchanged using
underlying protocols, including the headers and other meta-data used by
those underlying protocols, or something like that?

To me, that's a lot more useful than saying this term is commonly
used without defining in what sense(s) you mean it in the present
document.

I think it's important because the protections possible are
potentially a lot different, and if you want people to think
about only one or both, it should be made explicit.

On a lighter note, I once generated a lot of confusion using this
term with people working on satellite networks, who were wondering
what wires I could possibly be talking about since all of our links
were microwave.  I guess if KARP covered MANET protocols we'd have
to protect them on the wireless.

--
Wes Eddy
MTI Systems
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: notes from discussion of KARP design guidelines

[Wesley Eddy]

On 7/13/2011 2:34 PM, Joel M. Halpern wrote:

As I said in my earlier note proposing responses to Joe, we would be
happy to some text in the front clarifying the usage. Quoting from my
earlier email:

This text would note that it is a widely used term in IETF documents,
including many RFCs. It would also state for clarity that in this
document it is used to refer to the message sent from one routing
process to another.

Apparently, this does not address Joe's concern.



message sent from one routing process to another doesn't seem to be
right to me either since it sounds like the first definition that
covers routing protocol data only, and not underlying protocols, so I
wouldn't expect that proposal to address Joe's concern.

--
Wes Eddy
MTI Systems
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf