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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: statement regarding keepalives

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

Re: [aqm] Status of the GSP AQM?

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

[aqm] WG status

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

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

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

Re: [Bloat] Fixing bufferbloat in 2017

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

Re: [aqm] status of codel WGLC

: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 m

Re: [aqm] status of codel WGLC

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

[aqm] status of codel WGLC

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,

Re: [aqm] Berlin meeting

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

[aqm] working group status and rechartering vs. closing

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

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

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

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

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

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

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

Re: [aqm] AQM plans

] 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

[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

Re: [aqm] status of PIE drafts WGLC

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

Re: [aqm] status of PIE drafts WGLC

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

Re: [aqm] Experimental vs informational vs standards track

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,

Re: [aqm] Experimental vs informational vs standards track

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

Re: [aqm] Experimental vs informational vs standards track

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

Re: [aqm] Experimental vs informational vs standards track

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: ""&qu

[aqm] status of WGLC on fq-codel

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:

[aqm] status of codel WGLC

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:

Re: [aqm] status of PIE drafts WGLC

nformative): 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'v

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

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 eval

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

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,

[aqm] status of PIE drafts WGLC

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

[aqm] working group last call on CoDel drafts

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.

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

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

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

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

[OPSEC] Fwd: [Idr] flowspec enhancements

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 inte

[aqm] Yokohama meeting planning

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

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

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

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

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

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

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

Re: [Taps] TCP components

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.

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

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

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

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

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

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

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

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

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

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

[aqm] review of CoDel -00 draft

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.

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

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

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

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

[aqm] working group status

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

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

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,

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

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

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

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

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

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

[aqm] IETF 90 minutes posted

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] Obsoleting RFC 2309

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

[aqm] reminder: AQM conference call

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

Re: [aqm] AQM conference call - June 24

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

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

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

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

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

[aqm] publishing algorithms

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

Re: [aqm] publishing algorithms

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

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

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

[aqm] WG status

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

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

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

[aqm] working group kickoff

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

Re: TCPMUX (RFC 1078) status

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

Re: TCPMUX (RFC 1078) status

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

[Int-area] forming an IETF AQM working group

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

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

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

new AQM list

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

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

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 =

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

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

Re: Appointment of a Transport Area Director

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

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

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).

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

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

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

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

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

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

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

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

[dccp] closing DCCP WG

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

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

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,

IETF 85 TSVAREA planning

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

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

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

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

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

Re: IETF84/Vancouver planning

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/

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

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

IETF-83/Paris TSVAREA planning

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

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

Re: Limitations in RFC Errata mechanism

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

Re: notes from discussion of KARP design guidelines

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

Re: notes from discussion of KARP design guidelines

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

  1   2   >