Subject: [Iccrg] Re: AQM work in the IETF
From: [email-masked] (David Ros)
Date: Tue Nov 27 15:19:21 2012

On 26 nov. 2012, at 03:56, Wesley Eddy wrote:

> As TSV ADs, Martin and I have been wondering lately about
> AQM work.
> 
> At this point, thanks largely to Jim Gettys, we all know
> about large buffers, and we know what bulk-transfer with
> loss-based congestion control can do to interactive traffic
> when large queues exist.
> 
> We know one thing that can be done to help is the use of
> AQMs, but the IETF is currently not doing a whole lot to
> help in this regard.
> 
> There is the CoDel I-D that was discussed in the TSVAREA
> meeting in Vancouver:
> http://tools.ietf.org/html/draft-nichols-tsvwg-codel-00
> But this is an individual submission that Martin and I
> would be happy to sponsor, and not a working group
> activity.
> 
> At the last IETF meeting, we had a request to talk about
> PIE, which we didn't have time for in TSVAREA, but ICCRG
> did:
> http://www.ietf.org/proceedings/85/slides/slides-85-iccrg-2.ppt
> 
> This was really interesting, and we wonder if the
> community is interested in continuing to hear about
> AQMs in this space, and what the IETF should be doing.
> 
> If people have thoughts about this, we'd like to hear
> about them on this list, and/or during the TSVAREA
> meeting in Orlando at the next IETF meeting.  We want
> to know what the level of interest in AQMs is, and
> might make this a focus of the TSVAREA meeting, if a
> lot of people seem to think it's a good idea.

Hi,

Some thoughts from Michael & I, with ICCRG chair hats on. I'm cc'ing the ICCRG list, just in case.

> 
> Particularly, I have wondered:
> - Should we have a working group looking at AQMs?
> - If so, does it make sense to shoot for Standards Track
>  specifications?
> - Would we be able to come up with actual requirements
>  on an AQM so that it's implementable for cheap in
>  hardware and software, and behaves well under load?
> - Would it be valuable to have a test suite for AQMs
>  similar to what ICCRG was doing for high-rate TCP?

An AQM test suite is in the purview of ICCRG, IOHO. And it'd certainly be valuable to have such a test suite.

> - Would it be valuable to have a BCP (or multiple) on
>  configuring "legacy AQM" like RED, or the use of AQM
>  metrics like "sojourn time" rather than variations of
>  the queue length?
> - If any of this is of value, how much belongs in the
>  ICCRG versus TSV working groups?

Metrics-related stuff (as in, e.g., what metric should an arbitrary AQM algorithm base its decisions upon) looks to us as ICCRG material. Other stuff seems more fit to TSV. ICCRG has served as an "intermediate" forum for experimental things that are not ready for a WG yet, so we can take that role again w.r.t. AQMs and TSVWG, just like the RG did for high-speed-TCPs and TCPM -- and, as Michael said, things getting stuck in the ICCRG-to-TCPM path wasn't the fault of the RG, actually. Or, the RG can be the home of Experimental RFCs for AQMs, that would move later to TSVWG when (if) moving to Standards-track.

Our take is, AQMs in general fit in ICCRG, and for some AQM-related things Informational or Experimental RFCs are possible outputs from the RG; in particular, we would very much like to see the new PIE proposal published through ICCRG.

Thanks,

David.

> 
> Thanks for your thoughts :).
> 
> -- 
> Wes Eddy
> MTI Systems

=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

Deadlines really start to press a week or two after they pass. -- John Perry

From: [email-masked] (=?iso-8859-1?Q?P=E5l_Halvorsen?=)
Date: Thu Nov 22 22:23:12 2012
Subject: [Iccrg] [NOSSDAV13]: Deadline extension - 3. December
Message-ID: <[email-masked]>

Due to multiple requests and the Thanksgiving holiday, the NOSSDAV 2013 
paper submission deadline is extended until 3. DECEMBER.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

NOSSDAV 2013:
ACM Workshop on Network and Operating Systems Support 
for Digital Audio and Video

Oslo, Norway, February 26 ? 27, 2013

http://nossdav2013.ndlab.net

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

As in previous years, the workshop seeks papers in all areas of multimedia networking and
systems. Authors are especially encouraged to submit papers with
real-world experimental results and real data sets. Topics of interest
include (but are not restricted to):

- Cloud and peer-to-peer system architectures
- Media streaming, distribution and storage support
- Multimedia communications and system security
- Multi-core and many-core architecture support
- Networked GPUs, graphics and virtual environments
- Networked games / Real-time immersive systems
- Operating system, middleware and network support
- Web 2.0 systems and social networks
- Wireless networks and embedded systems for multimedia applications  

In particular, we are interested in soliciting papers that discuss
system-level support for social media and social networking, papers
that focus on improving performance with multi-core and many-core
processors, as well as papers that focus on multimedia applications on
mobile devices and/or in a cloud computing environment.

Submitted papers must be original and should not be currently under
review for any other publication. Authors of accepted papers will need
to sign an ACM copyright release form and present their paper at
NOSSDAV 2013 in person. The Proceedings of NOSSDAV 2013 will be
published by ACM and distributed at the workshop electronically, and
will also be included in the ACM Digital Library.

* Paper Deadline: 3. December 2012

All paper submissions will be handled electronically in the NOSSDAV
2013 submission web site:
http://submission.ndlab.net/nossdav13/
(also available from http://nossdav2013.ndlab.net)

Best regards,

Laszlo B?sz?rmenyi, Klagenfurt University, Austria
P?l Halvorsen, University of Oslo/Simula, Norway
(Program Co-Chairs)

From: [email-masked] (=?iso-8859-1?Q?P=E5l_Halvorsen?=)
Date: Tue Nov 20 07:25:49 2012
Subject: [Iccrg] [NOSSDAV13]: Paper deadline in one week (26. November)
Message-ID: <[email-masked]>

********* Paper submission deadline in ONE week **********

NOSSDAV 2013:
ACM Workshop on Network and Operating Systems Support 
for Digital Audio and Video

Oslo, Norway, February 26 ? 27, 2013

http://nossdav2013.ndlab.net

NEW:
Authors of selected good papers will be invited to submit an extended version of 
their work and submit it to the ACM Transactions on Multimedia Computing, 
Communications and Applications (ACM TOMCCAP) journal.

NEW: 
Dr. Aljosa Smolic (Disney Research Zurich, Switzerland) will give a keynote 
entiteled "Advanced 3D Video Processing and Coding" at NOSSDAV 2013. 
http://nossdav2013.ndlab.net/program.html

----------------------------------------------------------------------------------------

As in previous years, the workshop seeks papers in all areas of multimedia networking and
systems. Authors are especially encouraged to submit papers with
real-world experimental results and real data sets. Topics of interest
include (but are not restricted to):

- Cloud and peer-to-peer system architectures
- Media streaming, distribution and storage support
- Multimedia communications and system security
- Multi-core and many-core architecture support
- Networked GPUs, graphics and virtual environments
- Networked games / Real-time immersive systems
- Operating system, middleware and network support
- Web 2.0 systems and social networks
- Wireless networks and embedded systems for multimedia applications  

In particular, we are interested in soliciting papers that discuss
system-level support for social media and social networking, papers
that focus on improving performance with multi-core and many-core
processors, as well as papers that focus on multimedia applications on
mobile devices and/or in a cloud computing environment.

Submitted papers must be original and should not be currently under
review for any other publication. Authors of accepted papers will need
to sign an ACM copyright release form and present their paper at
NOSSDAV 2013 in person. The Proceedings of NOSSDAV 2013 will be
published by ACM and distributed at the workshop electronically, and
will also be included in the ACM Digital Library.

* Paper Deadline: 26. November 2012

All paper submissions will be handled electronically in the NOSSDAV
2013 submission web site:
http://submission.ndlab.net/nossdav13/
(also available from http://nossdav2013.ndlab.net)

Best regards,

Program Co-Chairs
P?l Halvorsen, University of Oslo/Simula, Norway
Laszlo B?sz?rmenyi, Klagenfurt University, Austria

From: [email-masked] (Michael Welzl)
Date: Wed Nov 14 09:35:29 2012
Subject: [Iccrg] Draft meeting minutes
Message-ID: <[email-masked]>

Hi all,

The draft meeting minutes from Atlanta are available at:
http://etherpad.tools.ietf.org:9001/p/notes-ietf-85-iccrg?useMonospaceFont=true&showChat=false

Thanks a lot to Andrew McGregor for taking them!

Please take a look and make corrections directly in Etherpad as needed.

Cheers,
Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121114/5d2aeab5/attachment.html
>From [email-masked]  Mon Nov 19 13:43:08 2012
From: [email-masked] ([email-masked])
Date: Mon Nov 19 13:42:58 2012
Subject: [Iccrg] ANT-2013 CFPs: (Due Dec. 8,
 2012) The 4th Int. Conf. on Ambient 
 Systems, Networks and Technologies, Halifax, Nova Scotia, Canada
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

-------------- Call for Papers ----------------------

The 4th International Conference on Ambient Systems, Networks and 
Technologies (ANT-2013)

25-28 June, 2013
Halifax, Nova Scotia, Canada

Conference Website:  http://cs-conferences.acadiau.ca/ant-13/
 
****************************************************************************

IMPORTANT DATES
===============

- Paper Submission:                     December 8, 2012
- Acceptance Notification:             February 8, 2013
- Graduate Symposium Abstract:   March 8, 2013
- Camera-Ready Submission:        March 15, 2013

ANT-2013 accepted papers will be included in the conference proceedings 
published by Elsevier Science in the open-access Procedia Computer 
Science series on-line. Procedia Computer Sciences is hosted on 
www.Elsevier.com and on Elsevier content platform ScienceDirect 
(http://www.sciencedirect.com), and will be freely available worldwide. 
All papers in Procedia will also be indexed by Scopus 
(http://www.scopus.com) and Engineering Village (Ei) 
(http://www.engineeringvillage.com). This includes EI Compendex 
(http://www.ei.org/compendex). The papers will contain linked 
references, XML versions and citable DOI numbers. All accepted papers 
will also be indexed in DBLP (http://dblp.uni-trier.de/). Selected 
papers will be invited for publication, in the special issues of:

- Journal of Ambient Intelligence and Humanized Computing, by Springer
   http://www.springer.com/engineering/journal/12652
- Journal of Computer and System Sciences, by Elsevier
   http://www.journals.elsevier.com/journal-of-computer-and-system-sciences/
- Social Network Analysis and Mining Journal, by Springer
 
http://www.springer.com/computer/database+management+%26+information+retrieval/journal/13278
- The Computer Journal, by Oxford
   http://comjnl.oxfordjournals.org/

ANT 2013 will be held in Halifax Nova Scotia, Canada. Halifax is located 
on the far eastern coast of Canada and is approximately a 6-hour flight 
from London, UK and a 2-hour flight from Toronto, Ontario. Halifax is a 
vibrant and modern city which is home to multiple academic institutions 
and where visitors can enjoy a variety of activities and entertainment 
from whale watching to Jazz festivals to world-class cuisine. Halifax is 
also home to the Maritime Museum of the Atlantic which contains the 
world largest collection of Titanic artifacts. Nova Scotia is a 
picturesque province with many National and Provincial parks, and as 
stated in the Guinness Book of World Records, has the highest tides in 
the world.

ANT-2013 will be held in conjunction with the International Conference 
on Sustainable Energy Information Technology (SEIT, 
http://cs-conferences.acadiau.ca/SEIT-13/).

Conference Tracks:
=================
- Agent Systems, Intelligent Computing and Applications
- Automatic Networks and Communications
- Cloud Computing
- Data Management
- Emerging Networking, Tracking and Sensing Technologies
- Mobile Networks, Protocols and Applications
- Modeling and Simulation in Transportation Sciences
- Multimedia and Social Computing
- Multimodal Interfaces
- Service Oriented Computing for Systems & Applications
- Smart Environments and Applications
- Systems Security and Privacy
- Systems Software Engineering
- Vehicular Networks and Applications
- General Track

COMMITTEES
=========

General Chairs
   Nick Cercone, York University, Canada
   Albert Zomaya, The University of Sydney, Australia

Program Chairs
   Karim Djouani, South African Institute of Technology, South Africa
   Michael Sheng, University of Adelaide, Australia
   Mohamed Younis, University of Maryland Baltimore County, USA

Advisory Committee
   Ali Ghorbani, University of New Brunswick, Canada
   Katia Sycara, Carnegie Mellon University, USA
   Erol Gelenbe, Imperial College, UK
   Vincenzo Loia, University of Salerno, Italy
   Reda Alhajj, University of Calgary, Canada
   Ralf Steinmetz, Technische Universitaet Darmstadt, Germany
   Peter Thomas, Manifesto Research, Australia
   Sajal K. Das, The University of Texas at Arlington, USA
   Timothy K. Shih, Tamkang University, Taiwan

Workshops Chairs
   Ansar-Ul-Haque Yasar, Hasselt University, Belgium
   Weiwei Fang, Beijing Jiaotong University, China

Program vice Chairs
   Reiner Wichert, Fraunhofer-Institut for Computer Graphics IGD, Germany
   Senol Erdogan, Maltepe University, Turkey
   Roberto Di Pietro, Roma Tre University of Rome, Italy
   Eric Pardede, La Trobe University, Australia
   Irena Mlynkova, Charles University, Czech Republic
   Sherali Zeadally, University of the District of Columbia, USA
   Jiang Li, Howard University, USA
   Zakaria Maamar, Zayed University, UAE
   Davy Janssens, Hasselt University, Belgium
   Ansar-Ul-Haque Yasar, Hasselt University, Belgium
   Tom Bellemans, Hasselt University, Belgium
   Keivan Kian-Mehr, University of Western Ontario, Canada
   Mohsen Afsharchi, University of Zanjan, Iran
   Mohyuddin, King Abdullah International Medical Research Center, Saudi 
Arabia
   Walid Chainbi, University of Sousse, Tunis
   Nauman Aslam, Northumbria University, UK
   Bessam Abdulrazak, Sherbrooke University, Canada
   Ridha Khedri, McMaster University, Canada
   Bharat Jayaraman, University at Buffalo (SUNY), USA
   Jayaraj Poroor, Amrita University, India
   Soumaya Cherkaoui, Sherbrooke University, Canada
   Lyes Khoukhi, University of Troy, France
   Nik Bessis, University of Derby, UK
   Navonil Mustafee, Swansea University, UK

International Journals Chairs
   Jing He, Victoria University, Australia
   Jian Yu, Swinburne University, Australia

Local Arrangement Chairs
   Ridha Khedri, McMaster University, Canada
   Janet Light, University of New Brunswick, Canada
   Ramiro Liscano, University of Ontario, Canada
   Bessam Abdulrazak, Sherbrooke University, Canada

Publicity Chairs
   Agustinus Waluyo, Monash University, Australia
   Muhammad Imran, King Saud University, Saudi Arabia
   Wael M El-Medany, University of Bahrain, Bahrain

International Liaison Chairs
   Maytham Safar, Kuwait University, Kuwait
   Markus Aleksy, ABB Corporate Research Center, Germany
   Adnan Al-Anbuky, Auckland University of Technology, New Zealand

Steering Committee
   Elhadi Shakshuki, Acadia University, Canada
   Muhammad Younas, Oxford Brookes University
   Rainer Unland, University of Duisburg-Essen, Germany
   David Taniar, Monash University, Australia
   Zakaria Maamar, Zayed University, UAE
   Hossam Hassanein, Queen's University, Canada
   Takahiro Hara, Osaka University, Japan
   Abdelfettah Belghith, University of Manouba, Tunisia
   Nirwan Ansari, New Jersey Institute of Technology, USA

From: [email-masked] (John Leslie)
Date: Tue Nov 13 14:23:10 2012
Subject: [Iccrg] RE: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <20121113142243.GN78300@verdi>

Ingemar Johansson S <[email-masked]> wrote:
> 
> Must admit that I a bit lost here. 

   We probably need to agree on better terminology.

> The idea is that 
> 1) the sender sets ect0

   My understanding is the sender _always_ sets ect0.

> 2a) a congested router sets ce if it implements low density marking
> 2b) alternatively a router that implements high density marking sets
> packets to ect1 or ce. 

   We'd best agree on "low density" and "high density" or some other names.

   I suggest defining:
- "low density" to mean ECN-marking at a high threshhold with the intent
  that the sender should reduce sending rate by half in response to a
  single mark;
- "high density" to mean ECN-marking packets more often than that,
  intending a lesser reaction to any single ECN mark.

   The intent, IMHO, is that high-density marking will change ect0 to
ect1, while low-density markng will change either to ce.

   Clearly, a pure tail-drop router will drop packets regardless, and
any ECN router will drop packets if it runs out of buffer space.

   The original proposal called for a "high-density" (non-legacy) router
to change ect0 to ect1, or ect1 to ce, at a low threshhold. This seems
reasonable, but not critical -- research might show some other behavior
to be superior. (I don't give a lot of thought to detecting different
marking rates for two routers along the path.)

   From a control-theory viewpoint, exponential growth is bad, while
exponential decay is good. Halving the rate, while rather coarse, is
correct if the appropriate target is zero. Control theory talks of
"critical damping" where there's a continuous "correction" towards
a target value, and the "correction" tends to zero as the target is
approached.

   In congestion-control, we suffer from not knowing the "target".
Neither zero nor infinity is a good target. Research using high-density
ECN marking should help us refine the "target" to more reasonable
values, IMHO.

   From there, we can define reactions which start to resemble critical
damping. We are likely to find, with sufficiently "high-density" marking,
that the ideal response will sometimes be _increasing_ the sending rate,
but increasing more slowly than we have been increasing it.

--
John Leslie <[email-masked]>

From: [email-masked] (Scheffenegger, Richard)
Date: Tue Nov 13 13:46:49 2012
Subject: [Iccrg] RE: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Yes,

ad 2b) an router that implements high density marking changes ECT0 -> ECT1, or ECT1 -> CE

So, a single packet can carry up to two low-density marks simultaneously, for calculating a better estimate of the congestion level at the most congested bottleneck in the path.

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: Ingemar Johansson S [mailto:[email-masked]]
> Sent: Dienstag, 13. November 2012 13:49
> To: Scheffenegger, Richard
> Cc: [email-masked]
> Subject: RE: [tcpm] ECN feedback discussion
> 
> Hi
> 
> Must admit that I a bit lost here.
> The idea is that
> 1) the sender sets ect0
> 2a) a congested router sets ce if it implements low density marking
> 2b) alternatively a router that implements high density marking sets
> packets to ect1 or ce.
> 
> Right or ?
> 
> /Ingemar
> 
> -----Original Message-----
> From: Scheffenegger, Richard [mailto:[email-masked]]
> Sent: den 12 november 2012 11:04
> To: Ingemar Johansson S
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tcpm] ECN feedback discussion
> 
> Alternative to using ect1 by the sender (allowing high density ecn
> marking), what about the sender continuing to use ect0, but high density
> ecn marking by routers changing that from ect0 to ect1 and ect1 to ce (or
> ect0 directl to ce on very high load)?
> 
> 
> Some papers claim that having an counter to allow multiple routers marking
> the same packet enables better signal for cc...
> 
> also, legacy receivers would only react to ce as usual and not fine
> grained...
> 
> Best regards, richard
> 
> Von meinem iPhone gesendet
> 
> Am 12.11.2012 um 09:02 schrieb "Ingemar Johansson S"
> <[email-masked]>:
> 
> > Hi
> >
> > A few comments on an interesting topic.
> >
> > QoS dependent ECN marking:
> > I believe the idea to use different ECN marking strategies depending on
> QoS (or perhaps QCI=QoS class identifier in LTE) has been discussed
> earlier.
> > I am however pretty much in favor of having one strategy regardless of
> QoS, mainly because of the relative simplicity compared to a special ECN
> treatment depending on QCI. This may in the end mean that services with a
> higher QoS will have a higher ECN marking rate  than services with a lower
> QoS but I don't really see a problem with that and long as it is allowed
> by operator policies. Also it blends well with the "weighted farness"
> ideas. In fact ConEx (if it flies) is a good policing framework for this
> in the sense that services with higher QoS can cause a higher congestion
> volume.
> >
> > High density vs Low Density ECN marking:
> > I really like the idea as it can for instance enable a smoother rate
> adaptation for e.g video because of the higher number of congestion
> signals.
> > Had a look into 3GPP TS36.300, no distinction is made between ECT(0) and
> ECT(1) there. This means that additional specification is needed to
> specify that ECT(1) means smomething like "apply high density ECN marking
> if implemented". When 3GPP TS 26.114 was specified it was explicitly
> mentioned that ECT(0) should be used, the idea behind was that at some
> stage there may pop up some interesting use for ECT(1) so it is then best
> to avoid messing with it. Low/High density ECN is a good cantidate.
> >
> > /Ingemar
> > =================================
> > Ingemar Johansson  M.Sc.
> > Senior Researcher
> >
> > Ericsson AB
> > Wireless Access Networks
> > Labratoriegr?nd 11
> > 971 28, Lule?, Sweden
> > Phone +46-1071 43042
> > SMS/MMS +46-73 078 3289
> > [email-masked]
> > www.ericsson.com
> >
> > "However beautiful the strategy,
> > you should occasionally look at the results"
> >        Sir Winston Churchill
> > =================================
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Sat, 10 Nov 2012 16:35:12 +0000
> > From: "Scheffenegger, Richard" <[email-masked]>
> > Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion
> > To: Michael Welzl <[email-masked]>
> > Cc: "[email-masked] list" <[email-masked]>
> > Message-ID: <[email-masked]>
> > Content-Type: text/plain; charset="utf-8"
> >
> > That would be my stance too...
> >
> > Imho, part of why ecn has failed to get traction was/is the complex and
> nondeterministic way in which the end systems and the network in between
> are supposed to run a distributed control loop that should keep congestion
> (standing buffer queues/buffer overflows) at bay.
> >
> > Imho, dctcp has a very good point in keeping the control loop entirely
> in the end systems and have a very simple, straight forward and
> deterministic marking scheme in the network...
> >
> > I think we need first and foremost a signaling scheme that should lend
> itself to the most broad applications.
> >
> > A counter (of some sort, however implemented) would be a huge step
> forward.
> >
> > I'm also wondering, if there is information to be had off the exact
> "pattern" (in the time domain) from CE (or ECT1 too) marks...
> >
> > I.e. Is a sudden jump from no marks to all marks and then a slow drop of
> marking probability - all in one RTT - different from a slow rise in
> markin probabiliy up to 100%, followed by a sudden drop to no marks? With
> the total number of marks in one RTT equal in both cases? Can anyone think
> that such a 2nd order signal might be useful, or does anyone know of
> research into such aspects?
> >
> >
> > Best regards,
> >   Richard
> >
> > Von meinem iPhone gesendet
> >
> > Am 09.11.2012 um 09:20 schrieb "Michael Welzl" <[email-masked]>:
> >
> >> Hi,
> >>
> >> I'd prefer a simpler approach. We haven't seen ECN happen, and trying
> to embed QoS in it isn't exactly going to improve the probability of
> success IMO.
> >>
> >> Cheers,
> >> Michael
> >>
> >>
> >> On Nov 9, 2012, at 7:21 AM, Arjuna Sathiaseelan wrote:
> >>
> >>> I think updating the behaviour of ECN would be a great idea -
> >>>
> >>> We could have different behaviours for different types of
> >>> communication - for e.g.
> >>>
> >>> (1) we could be less aggressive to emergency communications
> >>> (2) We could be more aggressive to scavenger type traffic
> >>> (3) We do the normal ecn behaviour inbetween
> >>>
> >>> So probably we-ve got to map QoS behaviour to ECN I guess..
> >>>
> >>> Arjuna
> >>>
> >>> On 9 November 2012 04:50,  <[email-masked]> wrote:
> >>>> Send Iccrg mailing list submissions to
> >>>>      [email-masked]
> >>>>
> >>>> To subscribe or unsubscribe via the World Wide Web, visit
> >>>>      http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> >>>> or, via email, send a message with subject or body 'help' to
> >>>>      [email-masked]
> >>>>
> >>>> You can reach the person managing the list at
> >>>>      [email-masked]
> >>>>
> >>>> When replying, please edit your Subject line so it is more specific
> >>>> than "Re: Contents of Iccrg digest..."
> >>>>
> >>>>
> >>>> Today's Topics:
> >>>>
> >>>> 1. Re: [tcpm] ECN feedback discussion (Michael Welzl)  2. Re: New
> >>>> co-chair (Eggert, Lars)  3. Re: [tcpm] ECN feedback discussion
> >>>> (Yuchung Cheng)  4. Re: [tcpm] ECN feedback discussion (Michael
> >>>> Welzl)  5. Re: Re: [tcpm] ECN feedback discussion (Mikael
> >>>> Abrahamsson)
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> -
> >>>> --
> >>>>
> >
> > _______________________________________________
> > tcpm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tcpm

From: [email-masked] (Ingemar Johansson S)
Date: Tue Nov 13 12:49:33 2012
Subject: [Iccrg] RE: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi

Must admit that I a bit lost here. 
The idea is that 
1) the sender sets ect0
2a) a congested router sets ce if it implements low density marking
2b) alternatively a router that implements high density marking sets packets to ect1 or ce. 

Right or ?

/Ingemar

-----Original Message-----
From: Scheffenegger, Richard [mailto:[email-masked]] 
Sent: den 12 november 2012 11:04
To: Ingemar Johansson S
Cc: [email-masked]; [email-masked]
Subject: Re: [tcpm] ECN feedback discussion

Alternative to using ect1 by the sender (allowing high density ecn marking), what about the sender continuing to use ect0, but high density ecn marking by routers changing that from ect0 to ect1 and ect1 to ce (or ect0 directl to ce on very high load)?

Some papers claim that having an counter to allow multiple routers marking the same packet enables better signal for cc...

also, legacy receivers would only react to ce as usual and not fine grained...

Best regards, richard

Von meinem iPhone gesendet

Am 12.11.2012 um 09:02 schrieb "Ingemar Johansson S" <[email-masked]>:

> Hi
> 
> A few comments on an interesting topic.
> 
> QoS dependent ECN marking: 
> I believe the idea to use different ECN marking strategies depending on QoS (or perhaps QCI=QoS class identifier in LTE) has been discussed earlier. 
> I am however pretty much in favor of having one strategy regardless of QoS, mainly because of the relative simplicity compared to a special ECN treatment depending on QCI. This may in the end mean that services with a higher QoS will have a higher ECN marking rate  than services with a lower QoS but I don't really see a problem with that and long as it is allowed by operator policies. Also it blends well with the "weighted farness" ideas. In fact ConEx (if it flies) is a good policing framework for this in the sense that services with higher QoS can cause a higher congestion volume.
> 
> High density vs Low Density ECN marking:
> I really like the idea as it can for instance enable a smoother rate adaptation for e.g video because of the higher number of congestion signals.
> Had a look into 3GPP TS36.300, no distinction is made between ECT(0) and ECT(1) there. This means that additional specification is needed to specify that ECT(1) means smomething like "apply high density ECN marking if implemented". When 3GPP TS 26.114 was specified it was explicitly mentioned that ECT(0) should be used, the idea behind was that at some stage there may pop up some interesting use for ECT(1) so it is then best to avoid messing with it. Low/High density ECN is a good cantidate.
> 
> /Ingemar
> =================================
> Ingemar Johansson  M.Sc. 
> Senior Researcher
> 
> Ericsson AB
> Wireless Access Networks
> Labratoriegr?nd 11
> 971 28, Lule?, Sweden
> Phone +46-1071 43042
> SMS/MMS +46-73 078 3289
> [email-masked]
> www.ericsson.com
> 
> "However beautiful the strategy,
> you should occasionally look at the results" 
>        Sir Winston Churchill
> =================================
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sat, 10 Nov 2012 16:35:12 +0000
> From: "Scheffenegger, Richard" <[email-masked]>
> Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion
> To: Michael Welzl <[email-masked]>
> Cc: "[email-masked] list" <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
> 
> That would be my stance too...
> 
> Imho, part of why ecn has failed to get traction was/is the complex and nondeterministic way in which the end systems and the network in between are supposed to run a distributed control loop that should keep congestion (standing buffer queues/buffer overflows) at bay.
> 
> Imho, dctcp has a very good point in keeping the control loop entirely in the end systems and have a very simple, straight forward and deterministic marking scheme in the network...
> 
> I think we need first and foremost a signaling scheme that should lend itself to the most broad applications.
> 
> A counter (of some sort, however implemented) would be a huge step forward.
> 
> I'm also wondering, if there is information to be had off the exact "pattern" (in the time domain) from CE (or ECT1 too) marks...
> 
> I.e. Is a sudden jump from no marks to all marks and then a slow drop of marking probability - all in one RTT - different from a slow rise in markin probabiliy up to 100%, followed by a sudden drop to no marks? With the total number of marks in one RTT equal in both cases? Can anyone think that such a 2nd order signal might be useful, or does anyone know of research into such aspects?
> 
> 
> Best regards,
>   Richard
> 
> Von meinem iPhone gesendet
> 
> Am 09.11.2012 um 09:20 schrieb "Michael Welzl" <[email-masked]>:
> 
>> Hi,
>> 
>> I'd prefer a simpler approach. We haven't seen ECN happen, and trying to embed QoS in it isn't exactly going to improve the probability of success IMO.
>> 
>> Cheers,
>> Michael
>> 
>> 
>> On Nov 9, 2012, at 7:21 AM, Arjuna Sathiaseelan wrote:
>> 
>>> I think updating the behaviour of ECN would be a great idea -
>>> 
>>> We could have different behaviours for different types of 
>>> communication - for e.g.
>>> 
>>> (1) we could be less aggressive to emergency communications
>>> (2) We could be more aggressive to scavenger type traffic
>>> (3) We do the normal ecn behaviour inbetween
>>> 
>>> So probably we-ve got to map QoS behaviour to ECN I guess..
>>> 
>>> Arjuna
>>> 
>>> On 9 November 2012 04:50,  <[email-masked]> wrote:
>>>> Send Iccrg mailing list submissions to
>>>>      [email-masked]
>>>> 
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>      http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>>> or, via email, send a message with subject or body 'help' to
>>>>      [email-masked]
>>>> 
>>>> You can reach the person managing the list at
>>>>      [email-masked]
>>>> 
>>>> When replying, please edit your Subject line so it is more specific 
>>>> than "Re: Contents of Iccrg digest..."
>>>> 
>>>> 
>>>> Today's Topics:
>>>> 
>>>> 1. Re: [tcpm] ECN feedback discussion (Michael Welzl)  2. Re: New 
>>>> co-chair (Eggert, Lars)  3. Re: [tcpm] ECN feedback discussion 
>>>> (Yuchung Cheng)  4. Re: [tcpm] ECN feedback discussion (Michael
>>>> Welzl)  5. Re: Re: [tcpm] ECN feedback discussion (Mikael
>>>> Abrahamsson)
>>>> 
>>>> 
>>>> -------------------------------------------------------------------
>>>> -
>>>> --
>>>> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

From: [email-masked] (Michael Welzl)
Date: Mon Nov 12 22:53:18 2012
Subject: [tcpm] [Iccrg] Re: ECN feedback discussion
In-Reply-To: <20121112224829.GL78300@verdi>
References: <[email-masked]> <[email-masked]> <20121112134825.GJ78300@verdi> <[email-masked]> <20121112224829.GL78300@verdi>
Message-ID: <[email-masked]>

+1

it really belongs here.

On Nov 12, 2012, at 11:48 PM, John Leslie wrote:

> Scheffenegger, Richard <[email-masked]> wrote:
>>
>> "ECN verbose mode: a statistical method for network path congestion
>> estimation", Remi Diana, Emmanuel Lochin, 2010
>>
>> http://arxiv.org/pdf/0910.4455v2.pdf
>
>   I have replied to this in <iccrg> only -- IMHO the thread belongs  
> there.
>
> --
> John Leslie <[email-masked]>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

From: [email-masked] (John Leslie)
Date: Mon Nov 12 22:47:06 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <20121112134825.GJ78300@verdi> <[email-masked]>
Message-ID: <20121112224654.GK78300@verdi>

Scheffenegger, Richard <[email-masked]> wrote:
> 
> I'm back at a decent computer; this is the paper which mentions how the
> highest congestion rate on one of multiple congested routers can be
> determined (needs to know the number of hops though; with L2-to-L3
> mapping of marks, simple TTL assumtions may not be enough).
> 
> "ECN verbose mode: a statistical method for network path congestion estimation", Remi Diana, Emmanuel Lochin, 2010
> 
> http://arxiv.org/pdf/0910.4455v2.pdf

   I think I mostly followed this paper; but deployment of its mechanism
seems iffy, and I'm not sure we could reach consensus on the right
reaction to minor congestion twice along the path.

> I think Emmanuel is listening on one of these groups;

   I'm limiting this reply to <iccrg> -- I doubt there's work for tcpm
yet.

> For the signaling aspect, using ECT1 as the initial signal of a
> high-density marking scheme, and CE for both low-density and when
> two high-density schemes overlap (mark the same packet) would be an
> improvement along the lines mentioned in that paper.

   That doesn't sound sufficient; and the ect0 -> ect1 signal for
low-threshhold seems more deployable.

> However, even the current TCP ECN Nonce feedback wouldn't worki
> properly, as a feedback channel from the receiver to the sender.
> I'm deliberately excluding other protocols for now...

   I suspect all of this will prove more deployable in transport
protocols other than TCP; but I think ECN marking should be strictly
network-layer (without reference to the transport).

> As Matt suggested, if such a scheme were to be standardized, the
> balance between feedback for CE and ECT(1) would generally shift
> more to ECT(1); the codepoint scheme described in
> draft-kuehlewind-tcpm-accurate-ecn could be adapted to that easily...

   Matt is an optimist!

   Actually, there are a number of areas where ect0 -> ect1 -> ce
could be put to good use -- but we need to get some traction in
ICCRG first.

--
John Leslie <[email-masked]>

From: [email-masked] (Scheffenegger, Richard)
Date: Mon Nov 12 14:56:07 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <20121112134825.GJ78300@verdi>
References: <[email-masked]> <[email-masked]> <20121112134825.GJ78300@verdi>
Message-ID: <[email-masked]>

Hi John,

Assuming that the mechanisms of DCTCP get deployed, the threshold could be a small static number of packets in queue (K ~= 0.17*C*d [pps] and [s]); have you had a read of the analysis paper http://www.stanford.edu/~alizade/Site/DCTCP_files/dctcp_analysis-full.pdf
 
If / how the simple dctcp queue marking could be modified with queue delay (PIE, CoDel) instead of queue depth as signal is still open. But these two algorithms currently assume a low density marking paradigm...

Best regards, 

Richard Scheffenegger

> -----Original Message-----
> From: John Leslie [mailto:[email-masked]]
> Sent: Montag, 12. November 2012 14:48
> To: Scheffenegger, Richard
> Cc: Ingemar Johansson S; [email-masked]; [email-masked]
> Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion
> 
> Scheffenegger, Richard <[email-masked]> wrote:
> >
> > Alternative to using ect1 by the sender (allowing high density ecn
> > marking), what about the sender continuing to use ect0, but high
> > density ecn marking by routers changing that from ect0 to ect1 andi
> > ect1 to ce (or ect0 directl to ce on very high load)?
> 
>    A truly interesting idea! Deployable...
> 
>    Of course, we'd need research to determine a good thresshold for
> marking ect0 to ect1.
> 
> --
> John Leslie <[email-masked]>

From: [email-masked] (Scheffenegger, Richard)
Date: Mon Nov 12 14:35:35 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <20121112134825.GJ78300@verdi>
References: <[email-masked]> <[email-masked]> <20121112134825.GJ78300@verdi>
Message-ID: <[email-masked]>

I'm back at a decent computer; this is the paper which mentions how the highest congestion rate on one of multiple congested routers can be determined (needs to know the number of hops though; with L2-to-L3 mapping of marks, simple TTL assumtions may not be enough).

"ECN verbose mode: a statistical method for network path congestion estimation", Remi Diana, Emmanuel Lochin, 2010

http://arxiv.org/pdf/0910.4455v2.pdf

I think Emmanuel is listening on one of these groups;

For the signaling aspect, using ECT1 as the initial signal of a high-density marking scheme, and CE for both low-density and when two high-density schemes overlap (mark the same packet) would be an improvement along the lines mentioned in that paper.

However, even the current TCP ECN Nonce feedback wouldn't work properly, as a feedback channel from the receiver to the sender. I'm deliberately excluding other protocols for now...

As Matt suggested, if such a scheme were to be standardized, the balance between feedback for CE and ECT(1) would generally shift more to ECT(1); the codepoint scheme described in draft-kuehlewind-tcpm-accurate-ecn could be adapted to that easily...

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: John Leslie [mailto:[email-masked]]
> Sent: Montag, 12. November 2012 14:48
> To: Scheffenegger, Richard
> Cc: Ingemar Johansson S; [email-masked]; [email-masked]
> Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion
> 
> Scheffenegger, Richard <[email-masked]> wrote:
> >
> > Alternative to using ect1 by the sender (allowing high density ecn
> > marking), what about the sender continuing to use ect0, but high
> > density ecn marking by routers changing that from ect0 to ect1 andi
> > ect1 to ce (or ect0 directl to ce on very high load)?
> 
>    A truly interesting idea! Deployable...
> 
>    Of course, we'd need research to determine a good thresshold for
> marking ect0 to ect1.
> 
> --
> John Leslie <[email-masked]>

From: [email-masked] (John Leslie)
Date: Mon Nov 12 13:48:43 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <20121112134825.GJ78300@verdi>

Scheffenegger, Richard <[email-masked]> wrote:
> 
> Alternative to using ect1 by the sender (allowing high density ecn
> marking), what about the sender continuing to use ect0, but high
> density ecn marking by routers changing that from ect0 to ect1 andi
> ect1 to ce (or ect0 directl to ce on very high load)?

   A truly interesting idea! Deployable...

   Of course, we'd need research to determine a good thresshold for
marking ect0 to ect1.

--
John Leslie <[email-masked]>

From: [email-masked] (Scheffenegger, Richard)
Date: Mon Nov 12 10:04:54 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Alternative to using ect1 by the sender (allowing high density ecn marking), what about the sender continuing to use ect0, but high density ecn marking by routers changing that from ect0 to ect1 and ect1 to ce (or ect0 directl to ce on very high load)?

Some papers claim that having an counter to allow multiple routers marking the same packet enables better signal for cc...

also, legacy receivers would only react to ce as usual and not fine grained...

Best regards, richard

Von meinem iPhone gesendet

Am 12.11.2012 um 09:02 schrieb "Ingemar Johansson S" <[email-masked]>:

> Hi
> 
> A few comments on an interesting topic.
> 
> QoS dependent ECN marking: 
> I believe the idea to use different ECN marking strategies depending on QoS (or perhaps QCI=QoS class identifier in LTE) has been discussed earlier. 
> I am however pretty much in favor of having one strategy regardless of QoS, mainly because of the relative simplicity compared to a special ECN treatment depending on QCI. This may in the end mean that services with a higher QoS will have a higher ECN marking rate  than services with a lower QoS but I don't really see a problem with that and long as it is allowed by operator policies. Also it blends well with the "weighted farness" ideas. In fact ConEx (if it flies) is a good policing framework for this in the sense that services with higher QoS can cause a higher congestion volume.
> 
> High density vs Low Density ECN marking:
> I really like the idea as it can for instance enable a smoother rate adaptation for e.g video because of the higher number of congestion signals.
> Had a look into 3GPP TS36.300, no distinction is made between ECT(0) and ECT(1) there. This means that additional specification is needed to specify that ECT(1) means smomething like "apply high density ECN marking if implemented". When 3GPP TS 26.114 was specified it was explicitly mentioned that ECT(0) should be used, the idea behind was that at some stage there may pop up some interesting use for ECT(1) so it is then best to avoid messing with it. Low/High density ECN is a good cantidate.
> 
> /Ingemar
> =================================
> Ingemar Johansson  M.Sc. 
> Senior Researcher
> 
> Ericsson AB
> Wireless Access Networks
> Labratoriegr?nd 11
> 971 28, Lule?, Sweden
> Phone +46-1071 43042
> SMS/MMS +46-73 078 3289
> [email-masked]
> www.ericsson.com
> 
> "However beautiful the strategy, 
> you should occasionally look at the results" 
>        Sir Winston Churchill
> =================================
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sat, 10 Nov 2012 16:35:12 +0000
> From: "Scheffenegger, Richard" <[email-masked]>
> Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion
> To: Michael Welzl <[email-masked]>
> Cc: "[email-masked] list" <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
> 
> That would be my stance too...
> 
> Imho, part of why ecn has failed to get traction was/is the complex and nondeterministic way in which the end systems and the network in between are supposed to run a distributed control loop that should keep congestion (standing buffer queues/buffer overflows) at bay.
> 
> Imho, dctcp has a very good point in keeping the control loop entirely in the end systems and have a very simple, straight forward and deterministic marking scheme in the network...
> 
> I think we need first and foremost a signaling scheme that should lend itself to the most broad applications.
> 
> A counter (of some sort, however implemented) would be a huge step forward.
> 
> I'm also wondering, if there is information to be had off the exact "pattern" (in the time domain) from CE (or ECT1 too) marks...
> 
> I.e. Is a sudden jump from no marks to all marks and then a slow drop of marking probability - all in one RTT - different from a slow rise in markin probabiliy up to 100%, followed by a sudden drop to no marks? With the total number of marks in one RTT equal in both cases? Can anyone think that such a 2nd order signal might be useful, or does anyone know of research into such aspects?
> 
> 
> Best regards,
>   Richard
> 
> Von meinem iPhone gesendet
> 
> Am 09.11.2012 um 09:20 schrieb "Michael Welzl" <[email-masked]>:
> 
>> Hi,
>> 
>> I'd prefer a simpler approach. We haven't seen ECN happen, and trying to embed QoS in it isn't exactly going to improve the probability of success IMO.
>> 
>> Cheers,
>> Michael
>> 
>> 
>> On Nov 9, 2012, at 7:21 AM, Arjuna Sathiaseelan wrote:
>> 
>>> I think updating the behaviour of ECN would be a great idea -
>>> 
>>> We could have different behaviours for different types of 
>>> communication - for e.g.
>>> 
>>> (1) we could be less aggressive to emergency communications
>>> (2) We could be more aggressive to scavenger type traffic
>>> (3) We do the normal ecn behaviour inbetween
>>> 
>>> So probably we-ve got to map QoS behaviour to ECN I guess..
>>> 
>>> Arjuna
>>> 
>>> On 9 November 2012 04:50,  <[email-masked]> wrote:
>>>> Send Iccrg mailing list submissions to
>>>>      [email-masked]
>>>> 
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>      http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>>> or, via email, send a message with subject or body 'help' to
>>>>      [email-masked]
>>>> 
>>>> You can reach the person managing the list at
>>>>      [email-masked]
>>>> 
>>>> When replying, please edit your Subject line so it is more specific 
>>>> than "Re: Contents of Iccrg digest..."
>>>> 
>>>> 
>>>> Today's Topics:
>>>> 
>>>> 1. Re: [tcpm] ECN feedback discussion (Michael Welzl)  2. Re: New 
>>>> co-chair (Eggert, Lars)  3. Re: [tcpm] ECN feedback discussion 
>>>> (Yuchung Cheng)  4. Re: [tcpm] ECN feedback discussion (Michael 
>>>> Welzl)  5. Re: Re: [tcpm] ECN feedback discussion (Mikael 
>>>> Abrahamsson)
>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> --
>>>> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

From: [email-masked] (Scheffenegger, Richard)
Date: Sat Nov 10 16:27:38 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

That would be my stance too...

Imho, part of why ecn has failed to get traction was/is the complex and nondeterministic way in which the end systems and the network in between are supposed to run a distributed control loop that should keep congestion (standing buffer queues/buffer overflows) at bay.

Imho, dctcp has a very good point in keeping the control loop entirely in the end systems and have a very simple, straight forward and deterministic marking scheme in the network...

I think we need first and foremost a signaling scheme that should lend itself to the most broad applications.

A counter (of some sort, however implemented) would be a huge step forward.

I'm also wondering, if there is information to be had off the exact "pattern" (in the time domain) from CE (or ECT1 too) marks...

I.e. Is a sudden jump from no marks to all marks and then a slow drop of marking probability - all in one RTT - different from a slow rise in markin probabiliy up to 100%, followed by a sudden drop to no marks? With the total number of marks in one RTT equal in both cases? Can anyone think that such a 2nd order signal might be useful, or does anyone know of research into such aspects?

Best regards,
   Richard

Von meinem iPhone gesendet

Am 09.11.2012 um 09:20 schrieb "Michael Welzl" <[email-masked]>:

> Hi,
> 
> I'd prefer a simpler approach. We haven't seen ECN happen, and trying to embed QoS in it isn't exactly going to improve the probability of success IMO.
> 
> Cheers,
> Michael
> 
> 
> On Nov 9, 2012, at 7:21 AM, Arjuna Sathiaseelan wrote:
> 
>> I think updating the behaviour of ECN would be a great idea -
>> 
>> We could have different behaviours for different types of
>> communication - for e.g.
>> 
>> (1) we could be less aggressive to emergency communications
>> (2) We could be more aggressive to scavenger type traffic
>> (3) We do the normal ecn behaviour inbetween
>> 
>> So probably we-ve got to map QoS behaviour to ECN I guess..
>> 
>> Arjuna
>> 
>> On 9 November 2012 04:50,  <[email-masked]> wrote:
>>> Send Iccrg mailing list submissions to
>>>       [email-masked]
>>> 
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>       http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>> or, via email, send a message with subject or body 'help' to
>>>       [email-masked]
>>> 
>>> You can reach the person managing the list at
>>>       [email-masked]
>>> 
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Iccrg digest..."
>>> 
>>> 
>>> Today's Topics:
>>> 
>>>  1. Re: [tcpm] ECN feedback discussion (Michael Welzl)
>>>  2. Re: New co-chair (Eggert, Lars)
>>>  3. Re: [tcpm] ECN feedback discussion (Yuchung Cheng)
>>>  4. Re: [tcpm] ECN feedback discussion (Michael Welzl)
>>>  5. Re: Re: [tcpm] ECN feedback discussion (Mikael Abrahamsson)
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> 
>>> Message: 1
>>> Date: Thu, 8 Nov 2012 15:11:56 +0100
>>> From: Michael Welzl <[email-masked]>
>>> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
>>> To: [email-masked]
>>> Cc: "tcpm \([email-masked]\)" <[email-masked]>,   "[email-masked]
>>>       list" <[email-masked]>
>>> Message-ID: <[email-masked]>
>>> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
>>>       delsp=yes
>>> 
>>> If your plan is to, in doing so, update RFC3540, I'd love to be a part
>>> of it. If the ECN nonce is used, it's a low hanging fruit to also use
>>> it to sometimes detect spurious loss events:
>>> http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html
>>> 
>>> I have been thinking of writing a draft that updates RFC3540 to
>>> incorporate this for many years now, but never seriously pursued it
>>> because I thought it would be best to wait until Bob Briscoe is done
>>> with all his bit thievery. But he will never stop, will he?  :-)
>>> 
>>> So, if possible, I'd love to be a part of this.
>>> 
>>> Cheers,
>>> Michael
>>> 
>>> 
>>> On Nov 8, 2012, at 3:06 PM, [email-masked] wrote:
>>> 
>>>> Yes - and I plan to write an I-D on this, because I think we could
>>>> perhaps
>>>> move forward with this discussion in parallel with the more accurate
>>>> ECN.
>>>> 
>>>> Gorry
>>>> 
>>>>> ... but the nonce could still be used, somehow - it's just that you
>>>>> risk more queue growth with every ECT(0) packet.
>>>>> 
>>>>> So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s
>>>>> and ECT(1)'s. In doing so, you risk some more queue growth - but this
>>>>> tests the receiver and might be good enough in the long run, as the
>>>>> notion is to stop believing the receiver once the receiver was found
>>>>> to cheat.
>>>>> 
>>>>> Cheers,
>>>>> Michael
>>>>> 
>>>>> 
>>>>> On Nov 8, 2012, at 1:30 PM, [email-masked] wrote:
>>>>> 
>>>>>> I'm also really interested in doing better than current ECN.
>>>>>> 
>>>>>> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the
>>>>>> reaction
>>>>>> is defined in the (still) experimental RFC 3540.
>>>>>> 
>>>>>> The ECN nonce can detect remarking NON-ECT packets to ECT and can
>>>>>> also
>>>>>> detect misbehaving transport receivers hiding CE from the transport
>>>>>> sender. My own opinion is that if we do see more deployment of ECN
>>>>>> (I do
>>>>>> hope so) - we do need this sort of mechanism, not to verify every
>>>>>> segment,
>>>>>> but at least to be able to detect paths/endpoints where the ACK
>>>>>> information is simply invalid.
>>>>>> 
>>>>>> DCCP was mentioned in the thread, RFC 4340, took the view that ECN
>>>>>> nonce
>>>>>> needed to be supported and the ECN Nonce Echo field is encoded in
>>>>>> acknowledgement options.  "Each DCCP sender SHOULD set ECN Nonces on
>>>>>> its
>>>>>> packets and remember which packets had nonces."
>>>>>> 
>>>>>> 
>>>>>> Gorry
>>>>>> 
>>>>>> P.S. Also note, if we do get to plans for new use of ECN this is
>>>>>> likely to
>>>>>> be a TSVWG item - since it effects much more than TCP.
>>>>>> 
>>>>>>> Great idea, I'd love for this semantic shift to happen!
>>>>>>> 
>>>>>>> 
>>>>>>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote:
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> I just wanted to keep a record of these interesting remarks on the
>>>>>>>> list, for further discussion.
>>>>>>>> 
>>>>>>>> We discussed ECN both in TCPM and ICCRG, and this post is to start
>>>>>>>> the discussion on the working group lists.
>>>>>>>> 
>>>>>>>> During the TCPM session, Matt Mathis made an interesting remark on
>>>>>>>> the microphone. To paraphrase (my understanding), current marking
>>>>>>>> schemes (RED, CoDel, PIE,?) assume that ECN marks get treated like
>>>>>>>> loss by the end systems.  Therefore, they employ a ?low density?
>>>>>>>> marking scheme, with marks expected at an (average) rate of around
>>>>>>>> 3% or so at maximum.
>>>>>>>> 
>>>>>>>> Alternative schemes, that start getting deployed at this time,
>>>>>>>> have
>>>>>>>> very simple marking schemes in the network, and give more
>>>>>>>> information to the end systems for processing and reaction
>>>>>>>> there. As
>>>>>>>> a side effect, these newer schemes may run as high as 100% marking
>>>>>>>> for certain periods (longer than a single flows RTT), so they
>>>>>>>> could
>>>>>>>> be classified as ?high density? marking scheme.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent
>>>>>>>> (I know only one stack with partial support), why not re-define
>>>>>>>> ECT(1) to be used by high density marking schemes, keeping ECT(0)
>>>>>>>> for low density schemes (as deployed today). For newer stacks,
>>>>>>>> this
>>>>>>>> would allow an even more fine grained reaction to ECN marking
>>>>>>>> levels?
>>>>>>>> 
>>>>>>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has
>>>>>>>> the same meaning for existing ECN stacks as ECT(0)) would not be
>>>>>>>> addressed, but then again, current ECN is also virtually not
>>>>>>>> deployed, according to recent studies.
>>>>>>>> 
>>>>>>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would
>>>>>>>> also need to have an impact on the future signaling  / feedback
>>>>>>>> scheme used for TCP (DCCP and SCTP would be able to cope already,
>>>>>>>> afaik).
>>>>>>>> 
>>>>>>>> Best regards,
>>>>>>>> 
>>>>>>>> Richard Scheffenegger
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> tcpm mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> tcpm mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 2
>>> Date: Thu, 8 Nov 2012 15:37:20 +0000
>>> From: "Eggert, Lars" <[email-masked]>
>>> Subject: Re: [Iccrg] New co-chair
>>> To: David Ros <[email-masked]>
>>> Cc: iccrg list <[email-masked]>,    Internet Research Steering Group
>>>       <[email-masked]>
>>> Message-ID:
>>>       <[email-masked]>
>>> 
>>> Content-Type: text/plain; charset="us-ascii"
>>> 
>>> Hi David,
>>> 
>>> welcome as new co-chair, and welcome to the IRSG! I have just updated the IRTF's public web site.
>>> 
>>> Murari, thank you very much for your service over the years!
>>> 
>>> Lars
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: smime.p7s
>>> Type: application/pkcs7-signature
>>> Size: 4361 bytes
>>> Desc: not available
>>> Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121108/ba936283/smime-0001.bin
>>> 
>>> ------------------------------
>>> 
>>> Message: 3
>>> Date: Thu, 8 Nov 2012 16:10:38 -0500
>>> From: Yuchung Cheng <[email-masked]>
>>> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
>>> To: "tcpm ([email-masked])" <[email-masked]>,     "[email-masked] list"
>>>       <[email-masked]>
>>> Message-ID:
>>>       <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>> 
>>> Playing devil's advocate: what's the goal of advanced ECN feedback?
>>> what and whose problems are we solving?
>>> 
>>> My worries are that we can design fancier stuff, in the end if it does
>>> not matter for applications, it does not matter. Is today's basic ECN
>>> not being used b/c it's too basic?
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 4
>>> Date: Thu, 8 Nov 2012 17:43:46 -0500
>>> From: Michael Welzl <[email-masked]>
>>> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
>>> To: Yuchung Cheng <[email-masked]>
>>> Cc: "tcpm \([email-masked]\)" <[email-masked]>,   "[email-masked]
>>>       list" <[email-masked]>
>>> Message-ID: <[email-masked]>
>>> Content-Type: text/plain; charset=us-ascii
>>> 
>>> We wanna have less delay, dude!
>>> 
>>> Sent from my iPhone
>>> 
>>> On 8. nov. 2012, at 16:10, Yuchung Cheng <[email-masked]> wrote:
>>> 
>>>> Playing devil's advocate: what's the goal of advanced ECN feedback?
>>>> what and whose problems are we solving?
>>>> 
>>>> My worries are that we can design fancier stuff, in the end if it does
>>>> not matter for applications, it does not matter. Is today's basic ECN
>>>> not being used b/c it's too basic?
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 5
>>> Date: Fri, 9 Nov 2012 05:49:48 +0100 (CET)
>>> From: Mikael Abrahamsson <[email-masked]>
>>> Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion
>>> To: Yuchung Cheng <[email-masked]>
>>> Cc: "tcpm \([email-masked]\)" <[email-masked]>,   "[email-masked]
>>>       list" <[email-masked]>
>>> Message-ID: <[email-masked]>
>>> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>>> 
>>> On Thu, 8 Nov 2012, Yuchung Cheng wrote:
>>> 
>>>> My worries are that we can design fancier stuff, in the end if it does
>>>> not matter for applications, it does not matter. Is today's basic ECN
>>>> not being used b/c it's too basic?
>>> 
>>> I'd imagine ECN isn't used today because nobody knows what it is and why
>>> it's good to use. It's like IPv6, it doesn't really solve anything for the
>>> individual entitiy (ISP|user|equipment vendor), but as a whole, it would
>>> be good if we had it.
>>> 
>>> I would also venture to say that congestion used to happen in the core and
>>> distribution. This is not really the case anymore, now congestion happens
>>> much closer to the edge, which is also the place where there is least
>>> homogenous control and thus harder to coordinate any technology.
>>> 
>>> I have been running with ECN on, on most my machines for years now, just
>>> to make sure it doesn't break anything. When it was first implemented in
>>> the Linux kernel, ECN broke a lot of things. PIX firewalls for instance,
>>> dropped ECN packets. This is not the case anymore as far as I can tell, I
>>> haven't noticed any ECN related problem at all since I re-enabled it, hm,
>>> 3-4 years ago perhaps.
>>> 
>>> To get ECN (and other more advanced tech) into production networks, we
>>> need to be able to explain to users and manufacturers (and ISPs) what good
>>> it does, and how it can make their life metter. From the bufferbloat
>>> discussion, I'd say this is quite hard, since most don't even know how TCP
>>> works in conjunction with large buffers, much less the difference between
>>> different TCP algorithms. So teaching about benefits of ECN is quite
>>> hard.
>>> 
>>> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening (slowly)
>>> because IPv4 ran out. Nothing happened really for 5-10 years because IPv6
>>> didn't really solve any problem people thought they had. ECN is the same
>>> thing. ECN makes the network more efficient, in that it doesn't drop the
>>> packet if there is congestion. But how does that help the individual end
>>> user? That's harder to explain.
>>> 
>>> Sorry for not being able to give any constructive suggestions on how to
>>> solve the problem of lack of ECN support, but if we can get some consensus
>>> about why ECN hasn't been implemented, perhaps that helps us making future
>>> decisions?
>>> 
>>> --
>>> Mikael Abrahamsson    email: [email-masked]
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> _______________________________________________
>>> Iccrg mailing list
>>> [email-masked]
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>> 
>>> 
>>> End of Iccrg Digest, Vol 82, Issue 7
>>> ************************************
>> 
>> 
>> 
>> -- 
>> 
>> Arjuna | http://www.cl.cam.ac.uk/~as2330/
>> 
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>From [email-masked]  Sat Nov 10 16:35:08 2012
From: [email-masked] (Scheffenegger, Richard)
Date: Sat Nov 10 16:27:40 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

No, the sender may react differently to the same network signal based on its notion of quality requirements. I'm not supportive of entangling ECN with QoS and complicating things for network operators

Best regards,
   Richard

Von meinem iPhone gesendet

Am 09.11.2012 um 01:23 schrieb "Arjuna Sathiaseelan" <[email-masked]>:

> I think updating the behaviour of ECN would be a great idea -
> 
> We could have different behaviours for different types of
> communication - for e.g.
> 
> (1) we could be less aggressive to emergency communications
> (2) We could be more aggressive to scavenger type traffic
> (3) We do the normal ecn behaviour inbetween
> 
> So probably we-ve got to map QoS behaviour to ECN I guess..
> 
> Arjuna
> 
> On 9 November 2012 04:50,  <[email-masked]> wrote:
>> Send Iccrg mailing list submissions to
>>        [email-masked]
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>> or, via email, send a message with subject or body 'help' to
>>        [email-masked]
>> 
>> You can reach the person managing the list at
>>        [email-masked]
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Iccrg digest..."
>> 
>> 
>> Today's Topics:
>> 
>>   1. Re: [tcpm] ECN feedback discussion (Michael Welzl)
>>   2. Re: New co-chair (Eggert, Lars)
>>   3. Re: [tcpm] ECN feedback discussion (Yuchung Cheng)
>>   4. Re: [tcpm] ECN feedback discussion (Michael Welzl)
>>   5. Re: Re: [tcpm] ECN feedback discussion (Mikael Abrahamsson)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Thu, 8 Nov 2012 15:11:56 +0100
>> From: Michael Welzl <[email-masked]>
>> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
>> To: [email-masked]
>> Cc: "tcpm \([email-masked]\)" <[email-masked]>,   "[email-masked]
>>        list" <[email-masked]>
>> Message-ID: <[email-masked]>
>> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
>>        delsp=yes
>> 
>> If your plan is to, in doing so, update RFC3540, I'd love to be a part
>> of it. If the ECN nonce is used, it's a low hanging fruit to also use
>> it to sometimes detect spurious loss events:
>> http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html
>> 
>> I have been thinking of writing a draft that updates RFC3540 to
>> incorporate this for many years now, but never seriously pursued it
>> because I thought it would be best to wait until Bob Briscoe is done
>> with all his bit thievery. But he will never stop, will he?  :-)
>> 
>> So, if possible, I'd love to be a part of this.
>> 
>> Cheers,
>> Michael
>> 
>> 
>> On Nov 8, 2012, at 3:06 PM, [email-masked] wrote:
>> 
>>> Yes - and I plan to write an I-D on this, because I think we could
>>> perhaps
>>> move forward with this discussion in parallel with the more accurate
>>> ECN.
>>> 
>>> Gorry
>>> 
>>>> ... but the nonce could still be used, somehow - it's just that you
>>>> risk more queue growth with every ECT(0) packet.
>>>> 
>>>> So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s
>>>> and ECT(1)'s. In doing so, you risk some more queue growth - but this
>>>> tests the receiver and might be good enough in the long run, as the
>>>> notion is to stop believing the receiver once the receiver was found
>>>> to cheat.
>>>> 
>>>> Cheers,
>>>> Michael
>>>> 
>>>> 
>>>> On Nov 8, 2012, at 1:30 PM, [email-masked] wrote:
>>>> 
>>>>> I'm also really interested in doing better than current ECN.
>>>>> 
>>>>> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the
>>>>> reaction
>>>>> is defined in the (still) experimental RFC 3540.
>>>>> 
>>>>> The ECN nonce can detect remarking NON-ECT packets to ECT and can
>>>>> also
>>>>> detect misbehaving transport receivers hiding CE from the transport
>>>>> sender. My own opinion is that if we do see more deployment of ECN
>>>>> (I do
>>>>> hope so) - we do need this sort of mechanism, not to verify every
>>>>> segment,
>>>>> but at least to be able to detect paths/endpoints where the ACK
>>>>> information is simply invalid.
>>>>> 
>>>>> DCCP was mentioned in the thread, RFC 4340, took the view that ECN
>>>>> nonce
>>>>> needed to be supported and the ECN Nonce Echo field is encoded in
>>>>> acknowledgement options.  "Each DCCP sender SHOULD set ECN Nonces on
>>>>> its
>>>>> packets and remember which packets had nonces."
>>>>> 
>>>>> 
>>>>> Gorry
>>>>> 
>>>>> P.S. Also note, if we do get to plans for new use of ECN this is
>>>>> likely to
>>>>> be a TSVWG item - since it effects much more than TCP.
>>>>> 
>>>>>> Great idea, I'd love for this semantic shift to happen!
>>>>>> 
>>>>>> 
>>>>>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I just wanted to keep a record of these interesting remarks on the
>>>>>>> list, for further discussion.
>>>>>>> 
>>>>>>> We discussed ECN both in TCPM and ICCRG, and this post is to start
>>>>>>> the discussion on the working group lists.
>>>>>>> 
>>>>>>> During the TCPM session, Matt Mathis made an interesting remark on
>>>>>>> the microphone. To paraphrase (my understanding), current marking
>>>>>>> schemes (RED, CoDel, PIE,?) assume that ECN marks get treated like
>>>>>>> loss by the end systems.  Therefore, they employ a ?low density?
>>>>>>> marking scheme, with marks expected at an (average) rate of around
>>>>>>> 3% or so at maximum.
>>>>>>> 
>>>>>>> Alternative schemes, that start getting deployed at this time,
>>>>>>> have
>>>>>>> very simple marking schemes in the network, and give more
>>>>>>> information to the end systems for processing and reaction
>>>>>>> there. As
>>>>>>> a side effect, these newer schemes may run as high as 100% marking
>>>>>>> for certain periods (longer than a single flows RTT), so they
>>>>>>> could
>>>>>>> be classified as ?high density? marking scheme.
>>>>>>> 
>>>>>>> 
>>>>>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent
>>>>>>> (I know only one stack with partial support), why not re-define
>>>>>>> ECT(1) to be used by high density marking schemes, keeping ECT(0)
>>>>>>> for low density schemes (as deployed today). For newer stacks,
>>>>>>> this
>>>>>>> would allow an even more fine grained reaction to ECN marking
>>>>>>> levels?
>>>>>>> 
>>>>>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has
>>>>>>> the same meaning for existing ECN stacks as ECT(0)) would not be
>>>>>>> addressed, but then again, current ECN is also virtually not
>>>>>>> deployed, according to recent studies.
>>>>>>> 
>>>>>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would
>>>>>>> also need to have an impact on the future signaling  / feedback
>>>>>>> scheme used for TCP (DCCP and SCTP would be able to cope already,
>>>>>>> afaik).
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> 
>>>>>>> Richard Scheffenegger
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> tcpm mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>> 
>>>>>> _______________________________________________
>>>>>> tcpm mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 2
>> Date: Thu, 8 Nov 2012 15:37:20 +0000
>> From: "Eggert, Lars" <[email-masked]>
>> Subject: Re: [Iccrg] New co-chair
>> To: David Ros <[email-masked]>
>> Cc: iccrg list <[email-masked]>,    Internet Research Steering Group
>>        <[email-masked]>
>> Message-ID:
>>        <[email-masked]>
>> 
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> Hi David,
>> 
>> welcome as new co-chair, and welcome to the IRSG! I have just updated the IRTF's public web site.
>> 
>> Murari, thank you very much for your service over the years!
>> 
>> Lars
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: smime.p7s
>> Type: application/pkcs7-signature
>> Size: 4361 bytes
>> Desc: not available
>> Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121108/ba936283/smime-0001.bin
>> 
>> ------------------------------
>> 
>> Message: 3
>> Date: Thu, 8 Nov 2012 16:10:38 -0500
>> From: Yuchung Cheng <[email-masked]>
>> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
>> To: "tcpm ([email-masked])" <[email-masked]>,     "[email-masked] list"
>>        <[email-masked]>
>> Message-ID:
>>        <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]>
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>> Playing devil's advocate: what's the goal of advanced ECN feedback?
>> what and whose problems are we solving?
>> 
>> My worries are that we can design fancier stuff, in the end if it does
>> not matter for applications, it does not matter. Is today's basic ECN
>> not being used b/c it's too basic?
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 4
>> Date: Thu, 8 Nov 2012 17:43:46 -0500
>> From: Michael Welzl <[email-masked]>
>> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
>> To: Yuchung Cheng <[email-masked]>
>> Cc: "tcpm \([email-masked]\)" <[email-masked]>,   "[email-masked]
>>        list" <[email-masked]>
>> Message-ID: <[email-masked]>
>> Content-Type: text/plain; charset=us-ascii
>> 
>> We wanna have less delay, dude!
>> 
>> Sent from my iPhone
>> 
>> On 8. nov. 2012, at 16:10, Yuchung Cheng <[email-masked]> wrote:
>> 
>>> Playing devil's advocate: what's the goal of advanced ECN feedback?
>>> what and whose problems are we solving?
>>> 
>>> My worries are that we can design fancier stuff, in the end if it does
>>> not matter for applications, it does not matter. Is today's basic ECN
>>> not being used b/c it's too basic?
>>> _______________________________________________
>>> tcpm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 5
>> Date: Fri, 9 Nov 2012 05:49:48 +0100 (CET)
>> From: Mikael Abrahamsson <[email-masked]>
>> Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion
>> To: Yuchung Cheng <[email-masked]>
>> Cc: "tcpm \([email-masked]\)" <[email-masked]>,   "[email-masked]
>>        list" <[email-masked]>
>> Message-ID: <[email-masked]>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>> 
>> On Thu, 8 Nov 2012, Yuchung Cheng wrote:
>> 
>>> My worries are that we can design fancier stuff, in the end if it does
>>> not matter for applications, it does not matter. Is today's basic ECN
>>> not being used b/c it's too basic?
>> 
>> I'd imagine ECN isn't used today because nobody knows what it is and why
>> it's good to use. It's like IPv6, it doesn't really solve anything for the
>> individual entitiy (ISP|user|equipment vendor), but as a whole, it would
>> be good if we had it.
>> 
>> I would also venture to say that congestion used to happen in the core and
>> distribution. This is not really the case anymore, now congestion happens
>> much closer to the edge, which is also the place where there is least
>> homogenous control and thus harder to coordinate any technology.
>> 
>> I have been running with ECN on, on most my machines for years now, just
>> to make sure it doesn't break anything. When it was first implemented in
>> the Linux kernel, ECN broke a lot of things. PIX firewalls for instance,
>> dropped ECN packets. This is not the case anymore as far as I can tell, I
>> haven't noticed any ECN related problem at all since I re-enabled it, hm,
>> 3-4 years ago perhaps.
>> 
>> To get ECN (and other more advanced tech) into production networks, we
>> need to be able to explain to users and manufacturers (and ISPs) what good
>> it does, and how it can make their life metter. From the bufferbloat
>> discussion, I'd say this is quite hard, since most don't even know how TCP
>> works in conjunction with large buffers, much less the difference between
>> different TCP algorithms. So teaching about benefits of ECN is quite
>> hard.
>> 
>> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening (slowly)
>> because IPv4 ran out. Nothing happened really for 5-10 years because IPv6
>> didn't really solve any problem people thought they had. ECN is the same
>> thing. ECN makes the network more efficient, in that it doesn't drop the
>> packet if there is congestion. But how does that help the individual end
>> user? That's harder to explain.
>> 
>> Sorry for not being able to give any constructive suggestions on how to
>> solve the problem of lack of ECN support, but if we can get some consensus
>> about why ECN hasn't been implemented, perhaps that helps us making future
>> decisions?
>> 
>> --
>> Mikael Abrahamsson    email: [email-masked]
>> 
>> 
>> 
>> ------------------------------
>> 
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>> 
>> 
>> End of Iccrg Digest, Vol 82, Issue 7
>> ************************************
> 
> 
> 
> -- 
> 
> Arjuna | http://www.cl.cam.ac.uk/~as2330/
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>From [email-masked]  Mon Nov 12 08:00:17 2012
From: [email-masked] (Ingemar Johansson S)
Date: Mon Nov 12 08:00:56 2012
Subject: [Iccrg] ECN feedback discussion
Message-ID: <[email-masked]>

Hi

A few comments on an interesting topic.
 
QoS dependent ECN marking: 
I believe the idea to use different ECN marking strategies depending on QoS (or perhaps QCI=QoS class identifier in LTE) has been discussed earlier. 
I am however pretty much in favor of having one strategy regardless of QoS, mainly because of the relative simplicity compared to a special ECN treatment depending on QCI. This may in the end mean that services with a higher QoS will have a higher ECN marking rate  than services with a lower QoS but I don't really see a problem with that and long as it is allowed by operator policies. Also it blends well with the "weighted farness" ideas. In fact ConEx (if it flies) is a good policing framework for this in the sense that services with higher QoS can cause a higher congestion volume.

High density vs Low Density ECN marking:
I really like the idea as it can for instance enable a smoother rate adaptation for e.g video because of the higher number of congestion signals.
Had a look into 3GPP TS36.300, no distinction is made between ECT(0) and ECT(1) there. This means that additional specification is needed to specify that ECT(1) means smomething like "apply high density ECN marking if implemented". When 3GPP TS 26.114 was specified it was explicitly mentioned that ECT(0) should be used, the idea behind was that at some stage there may pop up some interesting use for ECT(1) so it is then best to avoid messing with it. Low/High density ECN is a good cantidate.

/Ingemar
=================================
Ingemar Johansson  M.Sc. 
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegr?nd 11
971 28, Lule?, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com

"However beautiful the strategy, 
 you should occasionally look at the results" 
        Sir Winston Churchill
=================================

----------------------------------------------------------------------

Message: 1
Date: Sat, 10 Nov 2012 16:35:12 +0000
From: "Scheffenegger, Richard" <[email-masked]>
Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion
To: Michael Welzl <[email-masked]>
Cc: "[email-masked] list" <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

That would be my stance too...

Imho, part of why ecn has failed to get traction was/is the complex and nondeterministic way in which the end systems and the network in between are supposed to run a distributed control loop that should keep congestion (standing buffer queues/buffer overflows) at bay.

Imho, dctcp has a very good point in keeping the control loop entirely in the end systems and have a very simple, straight forward and deterministic marking scheme in the network...

I think we need first and foremost a signaling scheme that should lend itself to the most broad applications.

A counter (of some sort, however implemented) would be a huge step forward.

I'm also wondering, if there is information to be had off the exact "pattern" (in the time domain) from CE (or ECT1 too) marks...

I.e. Is a sudden jump from no marks to all marks and then a slow drop of marking probability - all in one RTT - different from a slow rise in markin probabiliy up to 100%, followed by a sudden drop to no marks? With the total number of marks in one RTT equal in both cases? Can anyone think that such a 2nd order signal might be useful, or does anyone know of research into such aspects?

Best regards,
   Richard

Von meinem iPhone gesendet

Am 09.11.2012 um 09:20 schrieb "Michael Welzl" <[email-masked]>:

> Hi,
> 
> I'd prefer a simpler approach. We haven't seen ECN happen, and trying to embed QoS in it isn't exactly going to improve the probability of success IMO.
> 
> Cheers,
> Michael
> 
> 
> On Nov 9, 2012, at 7:21 AM, Arjuna Sathiaseelan wrote:
> 
>> I think updating the behaviour of ECN would be a great idea -
>> 
>> We could have different behaviours for different types of 
>> communication - for e.g.
>> 
>> (1) we could be less aggressive to emergency communications
>> (2) We could be more aggressive to scavenger type traffic
>> (3) We do the normal ecn behaviour inbetween
>> 
>> So probably we-ve got to map QoS behaviour to ECN I guess..
>> 
>> Arjuna
>> 
>> On 9 November 2012 04:50,  <[email-masked]> wrote:
>>> Send Iccrg mailing list submissions to
>>>       [email-masked]
>>> 
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>       http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>> or, via email, send a message with subject or body 'help' to
>>>       [email-masked]
>>> 
>>> You can reach the person managing the list at
>>>       [email-masked]
>>> 
>>> When replying, please edit your Subject line so it is more specific 
>>> than "Re: Contents of Iccrg digest..."
>>> 
>>> 
>>> Today's Topics:
>>> 
>>>  1. Re: [tcpm] ECN feedback discussion (Michael Welzl)  2. Re: New 
>>> co-chair (Eggert, Lars)  3. Re: [tcpm] ECN feedback discussion 
>>> (Yuchung Cheng)  4. Re: [tcpm] ECN feedback discussion (Michael 
>>> Welzl)  5. Re: Re: [tcpm] ECN feedback discussion (Mikael 
>>> Abrahamsson)
>>> 
>>> 
>>> --------------------------------------------------------------------
>>> --
>>> 

From: [email-masked] (Emmanuel Lochin)
Date: Fri Nov  9 19:04:43 2012
Subject: [tcpm] [Iccrg] Re: ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]> <[email-masked]> <CAK6E8=[email-masked]> <[email-masked]> <CAEsJsFnpHyCaB=NL4ZbB+u58qO288+S9F+=[email-masked]> <[email-masked]>
Message-ID: <CAEsJsFkm-S9Rhvv5af=[email-masked]>

On 9 November 2012 18:56, Mikael Abrahamsson <[email-masked]> wrote:
> On Fri, 9 Nov 2012, Emmanuel Lochin wrote:
>
>> Ok, ECN might be not used inside the whole network but who cares? All
>> my core devices are ECN compliant so why not using inside my own
>> network?
>
> What core devices are that? When I last looked at platforms such as Cisco
> CRS-1 / ASR9k, Juniper MX/P-series, Huawei 5000, none of them supported ECN.
> This was a few years ago, so I'd be happy to be enlightened about progress!
> The only platform I have encountered so far that does ECN are Cisco
> processor based platforms such as the 7200.

Hi Mikael

Well ... I should precise that I use only GNU/Linux or *BSD. For ECN
marking I use tc on GNU/Linux.

>> We know, following "The power of explicit congestion notification", A.
>> Kuzmanovic, Sigcomm05, that even a partial deployment of ECN brings
>> out benefit for the end-user. My GNU/Linux stack does not react to
>> ECN? Not a problem ... my access network does.
>
>
> What devices are those?

All my routers are Linux or BSD boxes (HP Proliant blades or simple
PC), obvioulsy I need to tune both BSD or Linux kernels to be able to
correctly manage the trafic.

>
>> On my side, I use specific mechanisms conjointly with ECN inherited
>> from the QoS epoch. For instance, I can shape ECN feedbacks to slow
>> down connexions or to give a delay penalty to a specific flow.
>> Basically I use ECN like an "alert".
>
>
> But how many flows do you have that are ECN enabled? What host systems uses
> ECN by default?

All are GNU/Linux boxes except some *BSD. Most of them are used by
students/researchers that access to simulation servers or educational
ressources.
All my network is ECN-enabled. I have also used to enable an ECN path
over a link between Reunion Island university and Paris
VI university in 2004 and paced the traffic following the marking with
a penalty box.

> I have this on my linux boxes:
>
> $ grep -i ecn /etc/sysctl.conf
> net.ipv4.tcp_ecn = 1
> net.ipv6.tcp_ecn = 1
>
> (I believe the ipv6 line is redundant, just put it in there to be future
> proof). I do not believe this is the standard setting? Please correct me if
> I'm wrong.

This is the standard setting. Today kernels enable CUBIC and ECN. But
as far as I know, CUBIC does not react to ECN.

Manu

>
>
> --
> Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Mikael Abrahamsson)
Date: Fri Nov  9 17:49:04 2012
Subject: [tcpm] [Iccrg] Re: ECN feedback discussion
In-Reply-To: <CAEsJsFnpHyCaB=NL4ZbB+u58qO288+S9F+=[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]> <[email-masked]> <CAK6E8=[email-masked]> <[email-masked]> <CAEsJsFnpHyCaB=NL4ZbB+u58qO288+S9F+=[email-masked]>
Message-ID: <[email-masked]>

On Fri, 9 Nov 2012, Emmanuel Lochin wrote:

> Ok, ECN might be not used inside the whole network but who cares? All
> my core devices are ECN compliant so why not using inside my own
> network?

What core devices are that? When I last looked at platforms such as Cisco 
CRS-1 / ASR9k, Juniper MX/P-series, Huawei 5000, none of them supported 
ECN. This was a few years ago, so I'd be happy to be enlightened about 
progress! The only platform I have encountered so far that does ECN are 
Cisco processor based platforms such as the 7200.

> We know, following "The power of explicit congestion notification", A.
> Kuzmanovic, Sigcomm05, that even a partial deployment of ECN brings
> out benefit for the end-user. My GNU/Linux stack does not react to
> ECN? Not a problem ... my access network does.

What devices are those?

> On my side, I use specific mechanisms conjointly with ECN inherited
> from the QoS epoch. For instance, I can shape ECN feedbacks to slow
> down connexions or to give a delay penalty to a specific flow.
> Basically I use ECN like an "alert".

But how many flows do you have that are ECN enabled? What host systems 
uses ECN by default?

I have this on my linux boxes:

$ grep -i ecn /etc/sysctl.conf
net.ipv4.tcp_ecn = 1
net.ipv6.tcp_ecn = 1

(I believe the ipv6 line is redundant, just put it in there to be future 
proof). I do not believe this is the standard setting? Please correct me 
if I'm wrong.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Michael Welzl)
Date: Fri Nov  9 17:01:30 2012
Subject: [tcpm] [Iccrg] Re: ECN feedback discussion
In-Reply-To: <CAEsJsFnpHyCaB=NL4ZbB+u58qO288+S9F+=[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]> <[email-masked]> <CAK6E8=[email-masked]> <[email-masked]> <CAEsJsFnpHyCaB=NL4ZbB+u58qO288+S9F+=[email-masked]>
Message-ID: <[email-masked]>

Hi,

Yes I meant TCP. Sorry if my message got across as meaning "ECN is  
useless". This is certainly not what I was trying to say: my point is,  
we're perhaps facing a chicken-egg problem where operators won't have  
much incentive to support ECN as they probably don't see many ECN- 
capable packets in their path.

I'm all for changing that!

 From anecdotal evidence (including yours, based on the email below!)  
as well as the IMC'11 paper:
Measuring the State of ECN Readiness in Servers, Clients, and Routers
http://rbeverly.net/research/papers/ecn-imc11.pdf

it seems to me that turning on ECN support in general won't cause you  
harm (although it's apparently common to have it disabled somewhere  
along the path). I think this was perhaps different in the past.

Cheers,
Michael

On Nov 9, 2012, at 5:54 PM, Emmanuel Lochin wrote:

> Sorry but "none" means TCP? Because I use ECN (I take my network
> engineer hat). And I am not the only one ... at least all my
> sys/network admin colleagues are using it too. I use it to take QoS
> decisions and to collect statistics on my network (the rationale of
> using a counter comes from this observation).
>
> Ok, ECN might be not used inside the whole network but who cares? All
> my core devices are ECN compliant so why not using inside my own
> network?
> We know, following "The power of explicit congestion notification", A.
> Kuzmanovic, Sigcomm05, that even a partial deployment of ECN brings
> out benefit for the end-user. My GNU/Linux stack does not react to
> ECN? Not a problem ... my access network does.
>
> On my side, I use specific mechanisms conjointly with ECN inherited
> from the QoS epoch. For instance, I can shape ECN feedbacks to slow
> down connexions or to give a delay penalty to a specific flow.
> Basically I use ECN like an "alert".
>
> The problem is that we do not propose the right tools to operate with
> ECN. ECN* was an attempt, Re-ECN is also a good example of a practical
> usage of ECN.
>
> Emmanuel
>
>
>
>
>
> On 9 November 2012 16:11, Michael Welzl <[email-masked]> wrote:
>>
>> On Nov 9, 2012, at 4:06 PM, Yuchung Cheng wrote:
>>
>>> On Thu, Nov 8, 2012 at 11:49 PM, Mikael Abrahamsson <[email-masked] 
>>> >
>>> wrote:
>>>>
>>>> On Thu, 8 Nov 2012, Yuchung Cheng wrote:
>>>>
>>>>> My worries are that we can design fancier stuff, in the end if  
>>>>> it does
>>>>> not
>>>>> matter for applications, it does not matter. Is today's basic  
>>>>> ECN not
>>>>> being
>>>>> used b/c it's too basic?
>>>>
>>>>
>>>>
>>>> I'd imagine ECN isn't used today because nobody knows what it is  
>>>> and why
>>>> it's good to use. It's like IPv6, it doesn't really solve  
>>>> anything for
>>>> the
>>>> individual entitiy (ISP|user|equipment vendor), but as a whole,  
>>>> it would
>>>> be
>>>> good if we had it.
>>>>
>>>> I would also venture to say that congestion used to happen in the  
>>>> core
>>>> and
>>>> distribution. This is not really the case anymore, now congestion  
>>>> happens
>>>> much closer to the edge, which is also the place where there is  
>>>> least
>>>> homogenous control and thus harder to coordinate any technology.
>>>>
>>>> I have been running with ECN on, on most my machines for years  
>>>> now, just
>>>> to
>>>> make sure it doesn't break anything. When it was first  
>>>> implemented in the
>>>> Linux kernel, ECN broke a lot of things. PIX firewalls for  
>>>> instance,
>>>> dropped
>>>> ECN packets. This is not the case anymore as far as I can tell, I  
>>>> haven't
>>>> noticed any ECN related problem at all since I re-enabled it, hm,  
>>>> 3-4
>>>> years
>>>> ago perhaps.
>>>>
>>>> To get ECN (and other more advanced tech) into production  
>>>> networks, we
>>>> need
>>>> to be able to explain to users and manufacturers (and ISPs) what  
>>>> good it
>>>> does, and how it can make their life metter. From the bufferbloat
>>>> discussion, I'd say this is quite hard, since most don't even  
>>>> know how
>>>> TCP
>>>> works in conjunction with large buffers, much less the difference  
>>>> between
>>>> different TCP algorithms. So teaching about benefits of ECN is  
>>>> quite
>>>> hard.
>>>>
>>>> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening  
>>>> (slowly)
>>>> because IPv4 ran out. Nothing happened really for 5-10 years  
>>>> because IPv6
>>>> didn't really solve any problem people thought they had. ECN is  
>>>> the same
>>>> thing. ECN makes the network more efficient, in that it doesn't  
>>>> drop the
>>>> packet if there is congestion. But how does that help the  
>>>> individual end
>>>> user? That's harder to explain.
>>>>
>>>> Sorry for not being able to give any constructive suggestions on  
>>>> how to
>>>> solve the problem of lack of ECN support, but if we can get some
>>>> consensus
>>>> about why ECN hasn't been implemented, perhaps that helps us making
>>>> future
>>>> decisions?
>>>
>>> +1
>>>
>>> ECN has many good things but it's not used. If we are going to  
>>> develop
>>> a "useful" ECN+ maybe we should ask why the operators don't use ECN.
>>> And I know many ops guy that know extremely well about TCP so maybe
>>> they have valid reasons.
>>
>>
>> Chicken-egg, I suppose: why support something that noone uses?
>>
>> Cheers,
>> Michael
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm

From: [email-masked] (Emmanuel Lochin)
Date: Fri Nov  9 16:47:05 2012
Subject: [tcpm] [Iccrg] Re: ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]> <[email-masked]> <CAK6E8=[email-masked]> <[email-masked]>
Message-ID: <CAEsJsFnpHyCaB=NL4ZbB+u58qO288+S9F+=[email-masked]>

Sorry but "none" means TCP? Because I use ECN (I take my network
engineer hat). And I am not the only one ... at least all my
sys/network admin colleagues are using it too. I use it to take QoS
decisions and to collect statistics on my network (the rationale of
using a counter comes from this observation).

Ok, ECN might be not used inside the whole network but who cares? All
my core devices are ECN compliant so why not using inside my own
network?
We know, following "The power of explicit congestion notification", A.
Kuzmanovic, Sigcomm05, that even a partial deployment of ECN brings
out benefit for the end-user. My GNU/Linux stack does not react to
ECN? Not a problem ... my access network does.

On my side, I use specific mechanisms conjointly with ECN inherited
from the QoS epoch. For instance, I can shape ECN feedbacks to slow
down connexions or to give a delay penalty to a specific flow.
Basically I use ECN like an "alert".

The problem is that we do not propose the right tools to operate with
ECN. ECN* was an attempt, Re-ECN is also a good example of a practical
usage of ECN.

Emmanuel

On 9 November 2012 16:11, Michael Welzl <[email-masked]> wrote:
>
> On Nov 9, 2012, at 4:06 PM, Yuchung Cheng wrote:
>
>> On Thu, Nov 8, 2012 at 11:49 PM, Mikael Abrahamsson <[email-masked]>
>> wrote:
>>>
>>> On Thu, 8 Nov 2012, Yuchung Cheng wrote:
>>>
>>>> My worries are that we can design fancier stuff, in the end if it does
>>>> not
>>>> matter for applications, it does not matter. Is today's basic ECN not
>>>> being
>>>> used b/c it's too basic?
>>>
>>>
>>>
>>> I'd imagine ECN isn't used today because nobody knows what it is and why
>>> it's good to use. It's like IPv6, it doesn't really solve anything for
>>> the
>>> individual entitiy (ISP|user|equipment vendor), but as a whole, it would
>>> be
>>> good if we had it.
>>>
>>> I would also venture to say that congestion used to happen in the core
>>> and
>>> distribution. This is not really the case anymore, now congestion happens
>>> much closer to the edge, which is also the place where there is least
>>> homogenous control and thus harder to coordinate any technology.
>>>
>>> I have been running with ECN on, on most my machines for years now, just
>>> to
>>> make sure it doesn't break anything. When it was first implemented in the
>>> Linux kernel, ECN broke a lot of things. PIX firewalls for instance,
>>> dropped
>>> ECN packets. This is not the case anymore as far as I can tell, I haven't
>>> noticed any ECN related problem at all since I re-enabled it, hm, 3-4
>>> years
>>> ago perhaps.
>>>
>>> To get ECN (and other more advanced tech) into production networks, we
>>> need
>>> to be able to explain to users and manufacturers (and ISPs) what good it
>>> does, and how it can make their life metter. From the bufferbloat
>>> discussion, I'd say this is quite hard, since most don't even know how
>>> TCP
>>> works in conjunction with large buffers, much less the difference between
>>> different TCP algorithms. So teaching about benefits of ECN is quite
>>> hard.
>>>
>>> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening (slowly)
>>> because IPv4 ran out. Nothing happened really for 5-10 years because IPv6
>>> didn't really solve any problem people thought they had. ECN is the same
>>> thing. ECN makes the network more efficient, in that it doesn't drop the
>>> packet if there is congestion. But how does that help the individual end
>>> user? That's harder to explain.
>>>
>>> Sorry for not being able to give any constructive suggestions on how to
>>> solve the problem of lack of ECN support, but if we can get some
>>> consensus
>>> about why ECN hasn't been implemented, perhaps that helps us making
>>> future
>>> decisions?
>>
>> +1
>>
>> ECN has many good things but it's not used. If we are going to develop
>> a "useful" ECN+ maybe we should ask why the operators don't use ECN.
>> And I know many ops guy that know extremely well about TCP so maybe
>> they have valid reasons.
>
>
> Chicken-egg, I suppose: why support something that noone uses?
>
> Cheers,
> Michael
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

From: [email-masked] (Michael Welzl)
Date: Fri Nov  9 15:04:31 2012
Subject: [tcpm] [Iccrg] Re: ECN feedback discussion
In-Reply-To: <CAK6E8=[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]> <[email-masked]> <CAK6E8=[email-masked]>
Message-ID: <[email-masked]>

On Nov 9, 2012, at 4:06 PM, Yuchung Cheng wrote:

> On Thu, Nov 8, 2012 at 11:49 PM, Mikael Abrahamsson  
> <[email-masked]> wrote:
>> On Thu, 8 Nov 2012, Yuchung Cheng wrote:
>>
>>> My worries are that we can design fancier stuff, in the end if it  
>>> does not
>>> matter for applications, it does not matter. Is today's basic ECN  
>>> not being
>>> used b/c it's too basic?
>>
>>
>> I'd imagine ECN isn't used today because nobody knows what it is  
>> and why
>> it's good to use. It's like IPv6, it doesn't really solve anything  
>> for the
>> individual entitiy (ISP|user|equipment vendor), but as a whole, it  
>> would be
>> good if we had it.
>>
>> I would also venture to say that congestion used to happen in the  
>> core and
>> distribution. This is not really the case anymore, now congestion  
>> happens
>> much closer to the edge, which is also the place where there is least
>> homogenous control and thus harder to coordinate any technology.
>>
>> I have been running with ECN on, on most my machines for years now,  
>> just to
>> make sure it doesn't break anything. When it was first implemented  
>> in the
>> Linux kernel, ECN broke a lot of things. PIX firewalls for  
>> instance, dropped
>> ECN packets. This is not the case anymore as far as I can tell, I  
>> haven't
>> noticed any ECN related problem at all since I re-enabled it, hm,  
>> 3-4 years
>> ago perhaps.
>>
>> To get ECN (and other more advanced tech) into production networks,  
>> we need
>> to be able to explain to users and manufacturers (and ISPs) what  
>> good it
>> does, and how it can make their life metter. From the bufferbloat
>> discussion, I'd say this is quite hard, since most don't even know  
>> how TCP
>> works in conjunction with large buffers, much less the difference  
>> between
>> different TCP algorithms. So teaching about benefits of ECN is  
>> quite hard.
>>
>> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening  
>> (slowly)
>> because IPv4 ran out. Nothing happened really for 5-10 years  
>> because IPv6
>> didn't really solve any problem people thought they had. ECN is the  
>> same
>> thing. ECN makes the network more efficient, in that it doesn't  
>> drop the
>> packet if there is congestion. But how does that help the  
>> individual end
>> user? That's harder to explain.
>>
>> Sorry for not being able to give any constructive suggestions on  
>> how to
>> solve the problem of lack of ECN support, but if we can get some  
>> consensus
>> about why ECN hasn't been implemented, perhaps that helps us making  
>> future
>> decisions?
> +1
>
> ECN has many good things but it's not used. If we are going to develop
> a "useful" ECN+ maybe we should ask why the operators don't use ECN.
> And I know many ops guy that know extremely well about TCP so maybe
> they have valid reasons.

Chicken-egg, I suppose: why support something that noone uses?

Cheers,
Michael

From: [email-masked] (Yuchung Cheng)
Date: Fri Nov  9 14:59:22 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]> <[email-masked]>
Message-ID: <CAK6E8=[email-masked]>

On Thu, Nov 8, 2012 at 11:49 PM, Mikael Abrahamsson <[email-masked]> wrote:
> On Thu, 8 Nov 2012, Yuchung Cheng wrote:
>
>> My worries are that we can design fancier stuff, in the end if it does not
>> matter for applications, it does not matter. Is today's basic ECN not being
>> used b/c it's too basic?
>
>
> I'd imagine ECN isn't used today because nobody knows what it is and why
> it's good to use. It's like IPv6, it doesn't really solve anything for the
> individual entitiy (ISP|user|equipment vendor), but as a whole, it would be
> good if we had it.
>
> I would also venture to say that congestion used to happen in the core and
> distribution. This is not really the case anymore, now congestion happens
> much closer to the edge, which is also the place where there is least
> homogenous control and thus harder to coordinate any technology.
>
> I have been running with ECN on, on most my machines for years now, just to
> make sure it doesn't break anything. When it was first implemented in the
> Linux kernel, ECN broke a lot of things. PIX firewalls for instance, dropped
> ECN packets. This is not the case anymore as far as I can tell, I haven't
> noticed any ECN related problem at all since I re-enabled it, hm, 3-4 years
> ago perhaps.
>
> To get ECN (and other more advanced tech) into production networks, we need
> to be able to explain to users and manufacturers (and ISPs) what good it
> does, and how it can make their life metter. From the bufferbloat
> discussion, I'd say this is quite hard, since most don't even know how TCP
> works in conjunction with large buffers, much less the difference between
> different TCP algorithms. So teaching about benefits of ECN is quite hard.
>
> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening (slowly)
> because IPv4 ran out. Nothing happened really for 5-10 years because IPv6
> didn't really solve any problem people thought they had. ECN is the same
> thing. ECN makes the network more efficient, in that it doesn't drop the
> packet if there is congestion. But how does that help the individual end
> user? That's harder to explain.
>
> Sorry for not being able to give any constructive suggestions on how to
> solve the problem of lack of ECN support, but if we can get some consensus
> about why ECN hasn't been implemented, perhaps that helps us making future
> decisions?
+1

ECN has many good things but it's not used. If we are going to develop
a "useful" ECN+ maybe we should ask why the operators don't use ECN.
And I know many ops guy that know extremely well about TCP so maybe
they have valid reasons.

Thanks.

>
> --
> Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Emmanuel Lochin)
Date: Fri Nov  9 10:20:06 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <CAEsJsF=[email-masked]>

Hi all,

I wish to come back on the discussion concerning a "more accurate ECN
feedback".
I utterly support the following draft
draft-kuehlewind-tcpm-accurate-ecn-option and the idea that this binary
signal is not enough to clearly take an optimal decision concerning the
sending rate.

Two years ago, we drove a study to illustrate that the use of a simple ECN
counter might open the door to several schemes and methods allowing to
better assess the level of congestion and thus, react to losses in a
consistent way. See : Diana, R?mi and Lochin, Emmanuel *ECN verbose mode: a
statistical method for network path congestion estimation.* (2011) Computer
Networks, vol. 55 (n? 10). pp. 2380-2391. ISSN 1389-1286 available here :
http://oatao.univ-toulouse.fr/4779/

Enhancing ECN feedback would greatly help us to collect statistical
information in order to optimize the TCP reaction to this signal.

Emmanuel

On 9 November 2012 09:32, Scharf, Michael (Michael) <
[email-masked]> wrote:

> > I have been thinking of writing a draft that updates RFC3540
> > to incorporate this for many years now, but never seriously
> > pursued it because I thought it would be best to wait until
> > Bob Briscoe is done with all his bit thievery. But he will
> > never stop, will he?  :-)
>
> While I really enjoy the technical ideas in this discussion, I am somehow
> concerned about the tone here... I think the community must really
> understand that *burglary* is not at all an appropriate approach for
> getting the beloved bits in the TCP header. Instead, quite obviously, the
> right thing to do is bribery of the TCPM chairs ;)
>
> Michael
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121109/d709a4c3/attachment.html
>From [email-masked]  Fri Nov  9 14:17:17 2012
From: [email-masked] (Michael Welzl)
Date: Fri Nov  9 14:10:31 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I'd prefer a simpler approach. We haven't seen ECN happen, and trying  
to embed QoS in it isn't exactly going to improve the probability of  
success IMO.

Cheers,
Michael

On Nov 9, 2012, at 7:21 AM, Arjuna Sathiaseelan wrote:

> I think updating the behaviour of ECN would be a great idea -
>
> We could have different behaviours for different types of
> communication - for e.g.
>
> (1) we could be less aggressive to emergency communications
> (2) We could be more aggressive to scavenger type traffic
> (3) We do the normal ecn behaviour inbetween
>
> So probably we-ve got to map QoS behaviour to ECN I guess..
>
> Arjuna
>
> On 9 November 2012 04:50,  <[email-masked]> wrote:
>> Send Iccrg mailing list submissions to
>>        [email-masked]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>> or, via email, send a message with subject or body 'help' to
>>        [email-masked]
>>
>> You can reach the person managing the list at
>>        [email-masked]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Iccrg digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: [tcpm] ECN feedback discussion (Michael Welzl)
>>   2. Re: New co-chair (Eggert, Lars)
>>   3. Re: [tcpm] ECN feedback discussion (Yuchung Cheng)
>>   4. Re: [tcpm] ECN feedback discussion (Michael Welzl)
>>   5. Re: Re: [tcpm] ECN feedback discussion (Mikael Abrahamsson)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 8 Nov 2012 15:11:56 +0100
>> From: Michael Welzl <[email-masked]>
>> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
>> To: [email-masked]
>> Cc: "tcpm \([email-masked]\)" <[email-masked]>,   "[email-masked]
>>        list" <[email-masked]>
>> Message-ID: <[email-masked]>
>> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
>>        delsp=yes
>>
>> If your plan is to, in doing so, update RFC3540, I'd love to be a  
>> part
>> of it. If the ECN nonce is used, it's a low hanging fruit to also use
>> it to sometimes detect spurious loss events:
>> http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html
>>
>> I have been thinking of writing a draft that updates RFC3540 to
>> incorporate this for many years now, but never seriously pursued it
>> because I thought it would be best to wait until Bob Briscoe is done
>> with all his bit thievery. But he will never stop, will he?  :-)
>>
>> So, if possible, I'd love to be a part of this.
>>
>> Cheers,
>> Michael
>>
>>
>> On Nov 8, 2012, at 3:06 PM, [email-masked] wrote:
>>
>>> Yes - and I plan to write an I-D on this, because I think we could
>>> perhaps
>>> move forward with this discussion in parallel with the more accurate
>>> ECN.
>>>
>>> Gorry
>>>
>>>> ... but the nonce could still be used, somehow - it's just that you
>>>> risk more queue growth with every ECT(0) packet.
>>>>
>>>> So you could mostly use ECT(1)'s, but occasionally, use both  
>>>> ECT(0)'s
>>>> and ECT(1)'s. In doing so, you risk some more queue growth - but  
>>>> this
>>>> tests the receiver and might be good enough in the long run, as the
>>>> notion is to stop believing the receiver once the receiver was  
>>>> found
>>>> to cheat.
>>>>
>>>> Cheers,
>>>> Michael
>>>>
>>>>
>>>> On Nov 8, 2012, at 1:30 PM, [email-masked] wrote:
>>>>
>>>>> I'm also really interested in doing better than current ECN.
>>>>>
>>>>> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the
>>>>> reaction
>>>>> is defined in the (still) experimental RFC 3540.
>>>>>
>>>>> The ECN nonce can detect remarking NON-ECT packets to ECT and can
>>>>> also
>>>>> detect misbehaving transport receivers hiding CE from the  
>>>>> transport
>>>>> sender. My own opinion is that if we do see more deployment of ECN
>>>>> (I do
>>>>> hope so) - we do need this sort of mechanism, not to verify every
>>>>> segment,
>>>>> but at least to be able to detect paths/endpoints where the ACK
>>>>> information is simply invalid.
>>>>>
>>>>> DCCP was mentioned in the thread, RFC 4340, took the view that ECN
>>>>> nonce
>>>>> needed to be supported and the ECN Nonce Echo field is encoded in
>>>>> acknowledgement options.  "Each DCCP sender SHOULD set ECN  
>>>>> Nonces on
>>>>> its
>>>>> packets and remember which packets had nonces."
>>>>>
>>>>>
>>>>> Gorry
>>>>>
>>>>> P.S. Also note, if we do get to plans for new use of ECN this is
>>>>> likely to
>>>>> be a TSVWG item - since it effects much more than TCP.
>>>>>
>>>>>> Great idea, I'd love for this semantic shift to happen!
>>>>>>
>>>>>>
>>>>>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I just wanted to keep a record of these interesting remarks on  
>>>>>>> the
>>>>>>> list, for further discussion.
>>>>>>>
>>>>>>> We discussed ECN both in TCPM and ICCRG, and this post is to  
>>>>>>> start
>>>>>>> the discussion on the working group lists.
>>>>>>>
>>>>>>> During the TCPM session, Matt Mathis made an interesting  
>>>>>>> remark on
>>>>>>> the microphone. To paraphrase (my understanding), current  
>>>>>>> marking
>>>>>>> schemes (RED, CoDel, PIE,?) assume that ECN marks get treated  
>>>>>>> like
>>>>>>> loss by the end systems.  Therefore, they employ a ?low density?
>>>>>>> marking scheme, with marks expected at an (average) rate of  
>>>>>>> around
>>>>>>> 3% or so at maximum.
>>>>>>>
>>>>>>> Alternative schemes, that start getting deployed at this time,
>>>>>>> have
>>>>>>> very simple marking schemes in the network, and give more
>>>>>>> information to the end systems for processing and reaction
>>>>>>> there. As
>>>>>>> a side effect, these newer schemes may run as high as 100%  
>>>>>>> marking
>>>>>>> for certain periods (longer than a single flows RTT), so they
>>>>>>> could
>>>>>>> be classified as ?high density? marking scheme.
>>>>>>>
>>>>>>>
>>>>>>> Later on, Bob noted, that since ECN Nonce is virtually  
>>>>>>> nonexistent
>>>>>>> (I know only one stack with partial support), why not re-define
>>>>>>> ECT(1) to be used by high density marking schemes, keeping  
>>>>>>> ECT(0)
>>>>>>> for low density schemes (as deployed today). For newer stacks,
>>>>>>> this
>>>>>>> would allow an even more fine grained reaction to ECN marking
>>>>>>> levels?
>>>>>>>
>>>>>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1)  
>>>>>>> has
>>>>>>> the same meaning for existing ECN stacks as ECT(0)) would not be
>>>>>>> addressed, but then again, current ECN is also virtually not
>>>>>>> deployed, according to recent studies.
>>>>>>>
>>>>>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1)  
>>>>>>> would
>>>>>>> also need to have an impact on the future signaling  / feedback
>>>>>>> scheme used for TCP (DCCP and SCTP would be able to cope  
>>>>>>> already,
>>>>>>> afaik).
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Richard Scheffenegger
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> tcpm mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>>
>>>>>> _______________________________________________
>>>>>> tcpm mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 8 Nov 2012 15:37:20 +0000
>> From: "Eggert, Lars" <[email-masked]>
>> Subject: Re: [Iccrg] New co-chair
>> To: David Ros <[email-masked]>
>> Cc: iccrg list <[email-masked]>,    Internet Research Steering  
>> Group
>>        <[email-masked]>
>> Message-ID:
>>        <[email-masked] 
>> >
>>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi David,
>>
>> welcome as new co-chair, and welcome to the IRSG! I have just  
>> updated the IRTF's public web site.
>>
>> Murari, thank you very much for your service over the years!
>>
>> Lars
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: smime.p7s
>> Type: application/pkcs7-signature
>> Size: 4361 bytes
>> Desc: not available
>> Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121108/ba936283/smime-0001.bin
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 8 Nov 2012 16:10:38 -0500
>> From: Yuchung Cheng <[email-masked]>
>> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
>> To: "tcpm ([email-masked])" <[email-masked]>,     "[email-masked]  
>> list"
>>        <[email-masked]>
>> Message-ID:
>>        <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked] 
>> >
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Playing devil's advocate: what's the goal of advanced ECN feedback?
>> what and whose problems are we solving?
>>
>> My worries are that we can design fancier stuff, in the end if it  
>> does
>> not matter for applications, it does not matter. Is today's basic ECN
>> not being used b/c it's too basic?
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 8 Nov 2012 17:43:46 -0500
>> From: Michael Welzl <[email-masked]>
>> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
>> To: Yuchung Cheng <[email-masked]>
>> Cc: "tcpm \([email-masked]\)" <[email-masked]>,   "[email-masked]
>>        list" <[email-masked]>
>> Message-ID: <[email-masked]>
>> Content-Type: text/plain; charset=us-ascii
>>
>> We wanna have less delay, dude!
>>
>> Sent from my iPhone
>>
>> On 8. nov. 2012, at 16:10, Yuchung Cheng <[email-masked]> wrote:
>>
>>> Playing devil's advocate: what's the goal of advanced ECN feedback?
>>> what and whose problems are we solving?
>>>
>>> My worries are that we can design fancier stuff, in the end if it  
>>> does
>>> not matter for applications, it does not matter. Is today's basic  
>>> ECN
>>> not being used b/c it's too basic?
>>> _______________________________________________
>>> tcpm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Fri, 9 Nov 2012 05:49:48 +0100 (CET)
>> From: Mikael Abrahamsson <[email-masked]>
>> Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion
>> To: Yuchung Cheng <[email-masked]>
>> Cc: "tcpm \([email-masked]\)" <[email-masked]>,   "[email-masked]
>>        list" <[email-masked]>
>> Message-ID: <[email-masked]>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>>
>> On Thu, 8 Nov 2012, Yuchung Cheng wrote:
>>
>>> My worries are that we can design fancier stuff, in the end if it  
>>> does
>>> not matter for applications, it does not matter. Is today's basic  
>>> ECN
>>> not being used b/c it's too basic?
>>
>> I'd imagine ECN isn't used today because nobody knows what it is  
>> and why
>> it's good to use. It's like IPv6, it doesn't really solve anything  
>> for the
>> individual entitiy (ISP|user|equipment vendor), but as a whole, it  
>> would
>> be good if we had it.
>>
>> I would also venture to say that congestion used to happen in the  
>> core and
>> distribution. This is not really the case anymore, now congestion  
>> happens
>> much closer to the edge, which is also the place where there is least
>> homogenous control and thus harder to coordinate any technology.
>>
>> I have been running with ECN on, on most my machines for years now,  
>> just
>> to make sure it doesn't break anything. When it was first  
>> implemented in
>> the Linux kernel, ECN broke a lot of things. PIX firewalls for  
>> instance,
>> dropped ECN packets. This is not the case anymore as far as I can  
>> tell, I
>> haven't noticed any ECN related problem at all since I re-enabled  
>> it, hm,
>> 3-4 years ago perhaps.
>>
>> To get ECN (and other more advanced tech) into production networks,  
>> we
>> need to be able to explain to users and manufacturers (and ISPs)  
>> what good
>> it does, and how it can make their life metter. From the bufferbloat
>> discussion, I'd say this is quite hard, since most don't even know  
>> how TCP
>> works in conjunction with large buffers, much less the difference  
>> between
>> different TCP algorithms. So teaching about benefits of ECN is quite
>> hard.
>>
>> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening  
>> (slowly)
>> because IPv4 ran out. Nothing happened really for 5-10 years  
>> because IPv6
>> didn't really solve any problem people thought they had. ECN is the  
>> same
>> thing. ECN makes the network more efficient, in that it doesn't  
>> drop the
>> packet if there is congestion. But how does that help the  
>> individual end
>> user? That's harder to explain.
>>
>> Sorry for not being able to give any constructive suggestions on  
>> how to
>> solve the problem of lack of ECN support, but if we can get some  
>> consensus
>> about why ECN hasn't been implemented, perhaps that helps us making  
>> future
>> decisions?
>>
>> --
>> Mikael Abrahamsson    email: [email-masked]
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>>
>> End of Iccrg Digest, Vol 82, Issue 7
>> ************************************
>
>
>
> -- 
>
> Arjuna | http://www.cl.cam.ac.uk/~as2330/
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Scharf, Michael (Michael))
Date: Fri Nov  9 08:26:16 2012
Subject: [Iccrg] RE: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I have been thinking of writing a draft that updates RFC3540 
> to incorporate this for many years now, but never seriously 
> pursued it because I thought it would be best to wait until 
> Bob Briscoe is done with all his bit thievery. But he will 
> never stop, will he?  :-)

While I really enjoy the technical ideas in this discussion, I am somehow concerned about the tone here... I think the community must really understand that *burglary* is not at all an appropriate approach for getting the beloved bits in the TCP header. Instead, quite obviously, the right thing to do is bribery of the TCPM chairs ;)

Michael

From: [email-masked] (Arjuna Sathiaseelan)
Date: Fri Nov  9 06:14:14 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
Message-ID: <[email-masked]>

I think updating the behaviour of ECN would be a great idea -

We could have different behaviours for different types of
communication - for e.g.

(1) we could be less aggressive to emergency communications
(2) We could be more aggressive to scavenger type traffic
(3) We do the normal ecn behaviour inbetween

So probably we-ve got to map QoS behaviour to ECN I guess..

Arjuna

On 9 November 2012 04:50,  <[email-masked]> wrote:
> Send Iccrg mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Iccrg digest..."
>
>
> Today's Topics:
>
>    1. Re: [tcpm] ECN feedback discussion (Michael Welzl)
>    2. Re: New co-chair (Eggert, Lars)
>    3. Re: [tcpm] ECN feedback discussion (Yuchung Cheng)
>    4. Re: [tcpm] ECN feedback discussion (Michael Welzl)
>    5. Re: Re: [tcpm] ECN feedback discussion (Mikael Abrahamsson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 8 Nov 2012 15:11:56 +0100
> From: Michael Welzl <[email-masked]>
> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
> To: [email-masked]
> Cc: "tcpm \([email-masked]\)" <[email-masked]>,   "[email-masked]
>         list" <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
>         delsp=yes
>
> If your plan is to, in doing so, update RFC3540, I'd love to be a part
> of it. If the ECN nonce is used, it's a low hanging fruit to also use
> it to sometimes detect spurious loss events:
> http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html
>
> I have been thinking of writing a draft that updates RFC3540 to
> incorporate this for many years now, but never seriously pursued it
> because I thought it would be best to wait until Bob Briscoe is done
> with all his bit thievery. But he will never stop, will he?  :-)
>
> So, if possible, I'd love to be a part of this.
>
> Cheers,
> Michael
>
>
> On Nov 8, 2012, at 3:06 PM, [email-masked] wrote:
>
>> Yes - and I plan to write an I-D on this, because I think we could
>> perhaps
>> move forward with this discussion in parallel with the more accurate
>> ECN.
>>
>> Gorry
>>
>>> ... but the nonce could still be used, somehow - it's just that you
>>> risk more queue growth with every ECT(0) packet.
>>>
>>> So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s
>>> and ECT(1)'s. In doing so, you risk some more queue growth - but this
>>> tests the receiver and might be good enough in the long run, as the
>>> notion is to stop believing the receiver once the receiver was found
>>> to cheat.
>>>
>>> Cheers,
>>> Michael
>>>
>>>
>>> On Nov 8, 2012, at 1:30 PM, [email-masked] wrote:
>>>
>>>> I'm also really interested in doing better than current ECN.
>>>>
>>>> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the
>>>> reaction
>>>> is defined in the (still) experimental RFC 3540.
>>>>
>>>> The ECN nonce can detect remarking NON-ECT packets to ECT and can
>>>> also
>>>> detect misbehaving transport receivers hiding CE from the transport
>>>> sender. My own opinion is that if we do see more deployment of ECN
>>>> (I do
>>>> hope so) - we do need this sort of mechanism, not to verify every
>>>> segment,
>>>> but at least to be able to detect paths/endpoints where the ACK
>>>> information is simply invalid.
>>>>
>>>> DCCP was mentioned in the thread, RFC 4340, took the view that ECN
>>>> nonce
>>>> needed to be supported and the ECN Nonce Echo field is encoded in
>>>> acknowledgement options.  "Each DCCP sender SHOULD set ECN Nonces on
>>>> its
>>>> packets and remember which packets had nonces."
>>>>
>>>>
>>>> Gorry
>>>>
>>>> P.S. Also note, if we do get to plans for new use of ECN this is
>>>> likely to
>>>> be a TSVWG item - since it effects much more than TCP.
>>>>
>>>>> Great idea, I'd love for this semantic shift to happen!
>>>>>
>>>>>
>>>>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I just wanted to keep a record of these interesting remarks on the
>>>>>> list, for further discussion.
>>>>>>
>>>>>> We discussed ECN both in TCPM and ICCRG, and this post is to start
>>>>>> the discussion on the working group lists.
>>>>>>
>>>>>> During the TCPM session, Matt Mathis made an interesting remark on
>>>>>> the microphone. To paraphrase (my understanding), current marking
>>>>>> schemes (RED, CoDel, PIE,?) assume that ECN marks get treated like
>>>>>> loss by the end systems.  Therefore, they employ a ?low density?
>>>>>> marking scheme, with marks expected at an (average) rate of around
>>>>>> 3% or so at maximum.
>>>>>>
>>>>>> Alternative schemes, that start getting deployed at this time,
>>>>>> have
>>>>>> very simple marking schemes in the network, and give more
>>>>>> information to the end systems for processing and reaction
>>>>>> there. As
>>>>>> a side effect, these newer schemes may run as high as 100% marking
>>>>>> for certain periods (longer than a single flows RTT), so they
>>>>>> could
>>>>>> be classified as ?high density? marking scheme.
>>>>>>
>>>>>>
>>>>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent
>>>>>> (I know only one stack with partial support), why not re-define
>>>>>> ECT(1) to be used by high density marking schemes, keeping ECT(0)
>>>>>> for low density schemes (as deployed today). For newer stacks,
>>>>>> this
>>>>>> would allow an even more fine grained reaction to ECN marking
>>>>>> levels?
>>>>>>
>>>>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has
>>>>>> the same meaning for existing ECN stacks as ECT(0)) would not be
>>>>>> addressed, but then again, current ECN is also virtually not
>>>>>> deployed, according to recent studies.
>>>>>>
>>>>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would
>>>>>> also need to have an impact on the future signaling  / feedback
>>>>>> scheme used for TCP (DCCP and SCTP would be able to cope already,
>>>>>> afaik).
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Richard Scheffenegger
>>>>>>
>>>>>> _______________________________________________
>>>>>> tcpm mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 8 Nov 2012 15:37:20 +0000
> From: "Eggert, Lars" <[email-masked]>
> Subject: Re: [Iccrg] New co-chair
> To: David Ros <[email-masked]>
> Cc: iccrg list <[email-masked]>,    Internet Research Steering Group
>         <[email-masked]>
> Message-ID:
>         <[email-masked]>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi David,
>
> welcome as new co-chair, and welcome to the IRSG! I have just updated the IRTF's public web site.
>
> Murari, thank you very much for your service over the years!
>
> Lars
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 4361 bytes
> Desc: not available
> Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121108/ba936283/smime-0001.bin
>
> ------------------------------
>
> Message: 3
> Date: Thu, 8 Nov 2012 16:10:38 -0500
> From: Yuchung Cheng <[email-masked]>
> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
> To: "tcpm ([email-masked])" <[email-masked]>,     "[email-masked] list"
>         <[email-masked]>
> Message-ID:
>         <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Playing devil's advocate: what's the goal of advanced ECN feedback?
> what and whose problems are we solving?
>
> My worries are that we can design fancier stuff, in the end if it does
> not matter for applications, it does not matter. Is today's basic ECN
> not being used b/c it's too basic?
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 8 Nov 2012 17:43:46 -0500
> From: Michael Welzl <[email-masked]>
> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
> To: Yuchung Cheng <[email-masked]>
> Cc: "tcpm \([email-masked]\)" <[email-masked]>,   "[email-masked]
>         list" <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> We wanna have less delay, dude!
>
> Sent from my iPhone
>
> On 8. nov. 2012, at 16:10, Yuchung Cheng <[email-masked]> wrote:
>
>> Playing devil's advocate: what's the goal of advanced ECN feedback?
>> what and whose problems are we solving?
>>
>> My worries are that we can design fancier stuff, in the end if it does
>> not matter for applications, it does not matter. Is today's basic ECN
>> not being used b/c it's too basic?
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 9 Nov 2012 05:49:48 +0100 (CET)
> From: Mikael Abrahamsson <[email-masked]>
> Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion
> To: Yuchung Cheng <[email-masked]>
> Cc: "tcpm \([email-masked]\)" <[email-masked]>,   "[email-masked]
>         list" <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Thu, 8 Nov 2012, Yuchung Cheng wrote:
>
>> My worries are that we can design fancier stuff, in the end if it does
>> not matter for applications, it does not matter. Is today's basic ECN
>> not being used b/c it's too basic?
>
> I'd imagine ECN isn't used today because nobody knows what it is and why
> it's good to use. It's like IPv6, it doesn't really solve anything for the
> individual entitiy (ISP|user|equipment vendor), but as a whole, it would
> be good if we had it.
>
> I would also venture to say that congestion used to happen in the core and
> distribution. This is not really the case anymore, now congestion happens
> much closer to the edge, which is also the place where there is least
> homogenous control and thus harder to coordinate any technology.
>
> I have been running with ECN on, on most my machines for years now, just
> to make sure it doesn't break anything. When it was first implemented in
> the Linux kernel, ECN broke a lot of things. PIX firewalls for instance,
> dropped ECN packets. This is not the case anymore as far as I can tell, I
> haven't noticed any ECN related problem at all since I re-enabled it, hm,
> 3-4 years ago perhaps.
>
> To get ECN (and other more advanced tech) into production networks, we
> need to be able to explain to users and manufacturers (and ISPs) what good
> it does, and how it can make their life metter. From the bufferbloat
> discussion, I'd say this is quite hard, since most don't even know how TCP
> works in conjunction with large buffers, much less the difference between
> different TCP algorithms. So teaching about benefits of ECN is quite
> hard.
>
> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening (slowly)
> because IPv4 ran out. Nothing happened really for 5-10 years because IPv6
> didn't really solve any problem people thought they had. ECN is the same
> thing. ECN makes the network more efficient, in that it doesn't drop the
> packet if there is congestion. But how does that help the individual end
> user? That's harder to explain.
>
> Sorry for not being able to give any constructive suggestions on how to
> solve the problem of lack of ECN support, but if we can get some consensus
> about why ECN hasn't been implemented, perhaps that helps us making future
> decisions?
>
> --
> Mikael Abrahamsson    email: [email-masked]
>
>
>
> ------------------------------
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
> End of Iccrg Digest, Vol 82, Issue 7
> ************************************

-- 

Arjuna | http://www.cl.cam.ac.uk/~as2330/

From: [email-masked] (Mikael Abrahamsson)
Date: Fri Nov  9 04:42:27 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]>
Message-ID: <[email-masked]>

On Thu, 8 Nov 2012, Yuchung Cheng wrote:

> My worries are that we can design fancier stuff, in the end if it does 
> not matter for applications, it does not matter. Is today's basic ECN 
> not being used b/c it's too basic?

I'd imagine ECN isn't used today because nobody knows what it is and why 
it's good to use. It's like IPv6, it doesn't really solve anything for the 
individual entitiy (ISP|user|equipment vendor), but as a whole, it would 
be good if we had it.

I would also venture to say that congestion used to happen in the core and 
distribution. This is not really the case anymore, now congestion happens 
much closer to the edge, which is also the place where there is least 
homogenous control and thus harder to coordinate any technology.

I have been running with ECN on, on most my machines for years now, just 
to make sure it doesn't break anything. When it was first implemented in 
the Linux kernel, ECN broke a lot of things. PIX firewalls for instance, 
dropped ECN packets. This is not the case anymore as far as I can tell, I 
haven't noticed any ECN related problem at all since I re-enabled it, hm, 
3-4 years ago perhaps.

To get ECN (and other more advanced tech) into production networks, we 
need to be able to explain to users and manufacturers (and ISPs) what good 
it does, and how it can make their life metter. From the bufferbloat 
discussion, I'd say this is quite hard, since most don't even know how TCP 
works in conjunction with large buffers, much less the difference between 
different TCP algorithms. So teaching about benefits of ECN is quite 
hard.

ECN is a good idea. IPv6 is a good idea. IPv6 is now happening (slowly) 
because IPv4 ran out. Nothing happened really for 5-10 years because IPv6 
didn't really solve any problem people thought they had. ECN is the same 
thing. ECN makes the network more efficient, in that it doesn't drop the 
packet if there is congestion. But how does that help the individual end 
user? That's harder to explain.

Sorry for not being able to give any constructive suggestions on how to 
solve the problem of lack of ECN support, but if we can get some consensus 
about why ECN hasn't been implemented, perhaps that helps us making future 
decisions?

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Michael Welzl)
Date: Thu Nov  8 22:36:26 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]>
Message-ID: <[email-masked]>

We wanna have less delay, dude!

Sent from my iPhone

On 8. nov. 2012, at 16:10, Yuchung Cheng <[email-masked]> wrote:

> Playing devil's advocate: what's the goal of advanced ECN feedback?
> what and whose problems are we solving?
> 
> My worries are that we can design fancier stuff, in the end if it does
> not matter for applications, it does not matter. Is today's basic ECN
> not being used b/c it's too basic?
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

From: [email-masked] (Eggert, Lars)
Date: Thu Nov  8 15:31:09 2012
Subject: [Iccrg] New co-chair
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi David,

welcome as new co-chair, and welcome to the IRSG! I have just updated the IRTF's public web site.

Murari, thank you very much for your service over the years!

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4361 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121108/ba936283/smime.bin
>From [email-masked]  Thu Nov  8 21:10:38 2012
From: [email-masked] (Yuchung Cheng)
Date: Thu Nov  8 21:03:40 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=[email-masked]>

Playing devil's advocate: what's the goal of advanced ECN feedback?
what and whose problems are we solving?

My worries are that we can design fancier stuff, in the end if it does
not matter for applications, it does not matter. Is today's basic ECN
not being used b/c it's too basic?

From: [email-masked] (Michael Welzl)
Date: Thu Nov  8 14:04:38 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

If your plan is to, in doing so, update RFC3540, I'd love to be a part  
of it. If the ECN nonce is used, it's a low hanging fruit to also use  
it to sometimes detect spurious loss events:
http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html

I have been thinking of writing a draft that updates RFC3540 to  
incorporate this for many years now, but never seriously pursued it  
because I thought it would be best to wait until Bob Briscoe is done  
with all his bit thievery. But he will never stop, will he?  :-)

So, if possible, I'd love to be a part of this.

Cheers,
Michael

On Nov 8, 2012, at 3:06 PM, [email-masked] wrote:

> Yes - and I plan to write an I-D on this, because I think we could  
> perhaps
> move forward with this discussion in parallel with the more accurate  
> ECN.
>
> Gorry
>
>> ... but the nonce could still be used, somehow - it's just that you
>> risk more queue growth with every ECT(0) packet.
>>
>> So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s
>> and ECT(1)'s. In doing so, you risk some more queue growth - but this
>> tests the receiver and might be good enough in the long run, as the
>> notion is to stop believing the receiver once the receiver was found
>> to cheat.
>>
>> Cheers,
>> Michael
>>
>>
>> On Nov 8, 2012, at 1:30 PM, [email-masked] wrote:
>>
>>> I'm also really interested in doing better than current ECN.
>>>
>>> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the
>>> reaction
>>> is defined in the (still) experimental RFC 3540.
>>>
>>> The ECN nonce can detect remarking NON-ECT packets to ECT and can  
>>> also
>>> detect misbehaving transport receivers hiding CE from the transport
>>> sender. My own opinion is that if we do see more deployment of ECN
>>> (I do
>>> hope so) - we do need this sort of mechanism, not to verify every
>>> segment,
>>> but at least to be able to detect paths/endpoints where the ACK
>>> information is simply invalid.
>>>
>>> DCCP was mentioned in the thread, RFC 4340, took the view that ECN
>>> nonce
>>> needed to be supported and the ECN Nonce Echo field is encoded in
>>> acknowledgement options.  "Each DCCP sender SHOULD set ECN Nonces on
>>> its
>>> packets and remember which packets had nonces."
>>>
>>>
>>> Gorry
>>>
>>> P.S. Also note, if we do get to plans for new use of ECN this is
>>> likely to
>>> be a TSVWG item - since it effects much more than TCP.
>>>
>>>> Great idea, I'd love for this semantic shift to happen!
>>>>
>>>>
>>>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I just wanted to keep a record of these interesting remarks on the
>>>>> list, for further discussion.
>>>>>
>>>>> We discussed ECN both in TCPM and ICCRG, and this post is to start
>>>>> the discussion on the working group lists.
>>>>>
>>>>> During the TCPM session, Matt Mathis made an interesting remark on
>>>>> the microphone. To paraphrase (my understanding), current marking
>>>>> schemes (RED, CoDel, PIE,?) assume that ECN marks get treated like
>>>>> loss by the end systems.  Therefore, they employ a ?low density?
>>>>> marking scheme, with marks expected at an (average) rate of around
>>>>> 3% or so at maximum.
>>>>>
>>>>> Alternative schemes, that start getting deployed at this time,  
>>>>> have
>>>>> very simple marking schemes in the network, and give more
>>>>> information to the end systems for processing and reaction  
>>>>> there. As
>>>>> a side effect, these newer schemes may run as high as 100% marking
>>>>> for certain periods (longer than a single flows RTT), so they  
>>>>> could
>>>>> be classified as ?high density? marking scheme.
>>>>>
>>>>>
>>>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent
>>>>> (I know only one stack with partial support), why not re-define
>>>>> ECT(1) to be used by high density marking schemes, keeping ECT(0)
>>>>> for low density schemes (as deployed today). For newer stacks,  
>>>>> this
>>>>> would allow an even more fine grained reaction to ECN marking
>>>>> levels?
>>>>>
>>>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has
>>>>> the same meaning for existing ECN stacks as ECT(0)) would not be
>>>>> addressed, but then again, current ECN is also virtually not
>>>>> deployed, according to recent studies.
>>>>>
>>>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would
>>>>> also need to have an impact on the future signaling  / feedback
>>>>> scheme used for TCP (DCCP and SCTP would be able to cope already,
>>>>> afaik).
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Richard Scheffenegger
>>>>>
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>
>>>
>>
>
>

From: [email-masked] (Michael Welzl)
Date: Thu Nov  8 13:58:29 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Nov 8, 2012, at 2:50 PM, Steve Bauer wrote:

>> To have a better basis for such a decision, it could be useful to  
>> look at some data from the backbone, or from popular servers, on  
>> how many packets arrive with ECT0 or ECT1 set.
>
> In our IMC 2011 paper,
>
> Measuring the State of ECN Readiness in Servers, Clients, and Routers
> http://rbeverly.net/research/papers/ecn-imc11.pdf
>
> We reported that "Across all of our data sets, we see no instances of
> ECN nonce support. Manual inspection of arriving packets with ECT1 set
> reveals that these ?ows always set ECT1, even when ECN is not
> negotiated by TCP."

I have read this paper, and also had it open while I wrote my previous  
email  :-)   but I managed to miss that statement.

> So any packets with ECT1 set are evidence of something broken along  
> the path.

Well... up to now, it is. I don't see how what you describe would  
limit us to not have a sender set ECT1?
It would break the nonce interpretation though. Tricky. But should we  
design for such equipment faults? A quick look at your paper doesn't  
reveal how often you saw that; maybe I'm missing it again...

Another thought: in my previous email, addressing Richard, I wrote:
"Yes this leads to unexpected behavior for current ECN-capable end  
systems, but given that nobody (except for you!  :-)))   )   uses ECN,  
maybe we can just update that behavior and not worry about this  
problem much?"

- this made me think: Richard would certainly not run an old kernel.
=> given that ECN is probably not on by default in any system, isn't  
it fair to assume that folks who'd turn it on would run an up-to-date  
system?

Sure, lots of assumptions, but we're talking of blowing life into a  
dead corpse here! You can't do that without doing ugly stuff, such as  
having a zombie bite it...

Cheers,
Michael

From: [email-masked] (Steve Bauer)
Date: Thu Nov  8 13:45:40 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> To have a better basis for such a decision, it could be useful to look at some data from the backbone, or from popular servers, on how many packets arrive with ECT0 or ECT1 set.

In our IMC 2011 paper,

Measuring the State of ECN Readiness in Servers, Clients, and Routers
http://rbeverly.net/research/papers/ecn-imc11.pdf

We reported that "Across all of our data sets, we see no instances of
ECN nonce support. Manual inspection of arriving packets with ECT1 set
reveals that these ?ows always set ECT1, even when ECN is not
negotiated by TCP."

So any packets with ECT1 set are evidence of something broken along the path.

Steven Bauer
MIT

From: [email-masked] (Michael Welzl)
Date: Thu Nov  8 13:15:06 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>,  <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ah,

Sorry, I had misunderstood Bob's proposal. My interpretation was:
ECT1 tells routers to apply a high density marking scheme.

Yes this leads to unexpected behavior for current ECN-capable end  
systems, but given that nobody (except for you!  :-)))   )   uses ECN,  
maybe we can just update that behavior and not worry about this  
problem much?

To have a better basis for such a decision, it could be useful to look  
at some data from the backbone, or from popular servers, on how many  
packets arrive with ECT0 or ECT1 set. We should agree to not worry  
about it if the value is below a certain percentage   :-)

Cheers,
Michael

On Nov 8, 2012, at 2:08 PM, Scheffenegger, Richard wrote:

> Hi Michael,
>
> If both ect1 and ce signify some kind of congestion, having the  
> sender "probe" ect1 is a noisy business (in the sense that there is  
> no guarantee that the ect1 from the sender makes it all the way to  
> the receiver. Hypothetically, the first part of the path might "eat"  
> ect1
> And the 2nd half expirience congestion...
>
> (probing would mask true marks always. A mechanism to  
> probabilistically test this is still possible)
>
> Rgds
>    Richard
>
> Von meinem iPhone gesendet
>
> Am 08.11.2012 um 07:59 schrieb "Michael Welzl" <[email-masked]>:
>
>> ... but the nonce could still be used, somehow - it's just that you  
>> risk more queue growth with every ECT(0) packet.
>>
>> So you could mostly use ECT(1)'s, but occasionally, use both  
>> ECT(0)'s and ECT(1)'s. In doing so, you risk some more queue growth  
>> - but this tests the receiver and might be good enough in the long  
>> run, as the notion is to stop believing the receiver once the  
>> receiver was found to cheat.
>>
>> Cheers,
>> Michael
>>
>>
>> On Nov 8, 2012, at 1:30 PM, [email-masked] wrote:
>>
>>> I'm also really interested in doing better than current ECN.
>>>
>>> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the  
>>> reaction
>>> is defined in the (still) experimental RFC 3540.
>>>
>>> The ECN nonce can detect remarking NON-ECT packets to ECT and can  
>>> also
>>> detect misbehaving transport receivers hiding CE from the transport
>>> sender. My own opinion is that if we do see more deployment of ECN  
>>> (I do
>>> hope so) - we do need this sort of mechanism, not to verify every  
>>> segment,
>>> but at least to be able to detect paths/endpoints where the ACK
>>> information is simply invalid.
>>>
>>> DCCP was mentioned in the thread, RFC 4340, took the view that ECN  
>>> nonce
>>> needed to be supported and the ECN Nonce Echo field is encoded in
>>> acknowledgement options.  "Each DCCP sender SHOULD set ECN Nonces  
>>> on its
>>> packets and remember which packets had nonces."
>>>
>>>
>>> Gorry
>>>
>>> P.S. Also note, if we do get to plans for new use of ECN this is  
>>> likely to
>>> be a TSVWG item - since it effects much more than TCP.
>>>
>>>> Great idea, I'd love for this semantic shift to happen!
>>>>
>>>>
>>>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I just wanted to keep a record of these interesting remarks on the
>>>>> list, for further discussion.
>>>>>
>>>>> We discussed ECN both in TCPM and ICCRG, and this post is to start
>>>>> the discussion on the working group lists.
>>>>>
>>>>> During the TCPM session, Matt Mathis made an interesting remark on
>>>>> the microphone. To paraphrase (my understanding), current marking
>>>>> schemes (RED, CoDel, PIE,?) assume that ECN marks get treated like
>>>>> loss by the end systems.  Therefore, they employ a ?low density?
>>>>> marking scheme, with marks expected at an (average) rate of around
>>>>> 3% or so at maximum.
>>>>>
>>>>> Alternative schemes, that start getting deployed at this time,  
>>>>> have
>>>>> very simple marking schemes in the network, and give more
>>>>> information to the end systems for processing and reaction  
>>>>> there. As
>>>>> a side effect, these newer schemes may run as high as 100% marking
>>>>> for certain periods (longer than a single flows RTT), so they  
>>>>> could
>>>>> be classified as ?high density? marking scheme.
>>>>>
>>>>>
>>>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent
>>>>> (I know only one stack with partial support), why not re-define
>>>>> ECT(1) to be used by high density marking schemes, keeping ECT(0)
>>>>> for low density schemes (as deployed today). For newer stacks,  
>>>>> this
>>>>> would allow an even more fine grained reaction to ECN marking  
>>>>> levels?
>>>>>
>>>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has
>>>>> the same meaning for existing ECN stacks as ECT(0)) would not be
>>>>> addressed, but then again, current ECN is also virtually not
>>>>> deployed, according to recent studies.
>>>>>
>>>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would
>>>>> also need to have an impact on the future signaling  / feedback
>>>>> scheme used for TCP (DCCP and SCTP would be able to cope already,
>>>>> afaik).
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Richard Scheffenegger
>>>>>
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>
>>>
>>

From: [email-masked] (Scheffenegger, Richard)
Date: Thu Nov  8 13:00:55 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>,  <[email-masked]>
Message-ID: <[email-masked]>

Hi Michael,

If both ect1 and ce signify some kind of congestion, having the sender "probe" ect1 is a noisy business (in the sense that there is no guarantee that the ect1 from the sender makes it all the way to the receiver. Hypothetically, the first part of the path might "eat" ect1 
And the 2nd half expirience congestion...

(probing would mask true marks always. A mechanism to probabilistically test this is still possible)

Rgds
    Richard

Von meinem iPhone gesendet

Am 08.11.2012 um 07:59 schrieb "Michael Welzl" <[email-masked]>:

> ... but the nonce could still be used, somehow - it's just that you risk more queue growth with every ECT(0) packet.
> 
> So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s and ECT(1)'s. In doing so, you risk some more queue growth - but this tests the receiver and might be good enough in the long run, as the notion is to stop believing the receiver once the receiver was found to cheat.
> 
> Cheers,
> Michael
> 
> 
> On Nov 8, 2012, at 1:30 PM, [email-masked] wrote:
> 
>> I'm also really interested in doing better than current ECN.
>> 
>> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the reaction
>> is defined in the (still) experimental RFC 3540.
>> 
>> The ECN nonce can detect remarking NON-ECT packets to ECT and can also
>> detect misbehaving transport receivers hiding CE from the transport
>> sender. My own opinion is that if we do see more deployment of ECN (I do
>> hope so) - we do need this sort of mechanism, not to verify every segment,
>> but at least to be able to detect paths/endpoints where the ACK
>> information is simply invalid.
>> 
>> DCCP was mentioned in the thread, RFC 4340, took the view that ECN nonce
>> needed to be supported and the ECN Nonce Echo field is encoded in
>> acknowledgement options.  "Each DCCP sender SHOULD set ECN Nonces on its
>> packets and remember which packets had nonces."
>> 
>> 
>> Gorry
>> 
>> P.S. Also note, if we do get to plans for new use of ECN this is likely to
>> be a TSVWG item - since it effects much more than TCP.
>> 
>>> Great idea, I'd love for this semantic shift to happen!
>>> 
>>> 
>>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I just wanted to keep a record of these interesting remarks on the
>>>> list, for further discussion.
>>>> 
>>>> We discussed ECN both in TCPM and ICCRG, and this post is to start
>>>> the discussion on the working group lists.
>>>> 
>>>> During the TCPM session, Matt Mathis made an interesting remark on
>>>> the microphone. To paraphrase (my understanding), current marking
>>>> schemes (RED, CoDel, PIE,?) assume that ECN marks get treated like
>>>> loss by the end systems.  Therefore, they employ a ?low density?
>>>> marking scheme, with marks expected at an (average) rate of around
>>>> 3% or so at maximum.
>>>> 
>>>> Alternative schemes, that start getting deployed at this time, have
>>>> very simple marking schemes in the network, and give more
>>>> information to the end systems for processing and reaction there. As
>>>> a side effect, these newer schemes may run as high as 100% marking
>>>> for certain periods (longer than a single flows RTT), so they could
>>>> be classified as ?high density? marking scheme.
>>>> 
>>>> 
>>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent
>>>> (I know only one stack with partial support), why not re-define
>>>> ECT(1) to be used by high density marking schemes, keeping ECT(0)
>>>> for low density schemes (as deployed today). For newer stacks, this
>>>> would allow an even more fine grained reaction to ECN marking levels?
>>>> 
>>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has
>>>> the same meaning for existing ECN stacks as ECT(0)) would not be
>>>> addressed, but then again, current ECN is also virtually not
>>>> deployed, according to recent studies.
>>>> 
>>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would
>>>> also need to have an impact on the future signaling  / feedback
>>>> scheme used for TCP (DCCP and SCTP would be able to cope already,
>>>> afaik).
>>>> 
>>>> Best regards,
>>>> 
>>>> Richard Scheffenegger
>>>> 
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>> 
>>> _______________________________________________
>>> tcpm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>> 
>> 
>> 
> 

From: [email-masked] (Michael Welzl)
Date: Thu Nov  8 12:52:00 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

... but the nonce could still be used, somehow - it's just that you  
risk more queue growth with every ECT(0) packet.

So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s  
and ECT(1)'s. In doing so, you risk some more queue growth - but this  
tests the receiver and might be good enough in the long run, as the  
notion is to stop believing the receiver once the receiver was found  
to cheat.

Cheers,
Michael

On Nov 8, 2012, at 1:30 PM, [email-masked] wrote:

> I'm also really interested in doing better than current ECN.
>
> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the  
> reaction
> is defined in the (still) experimental RFC 3540.
>
> The ECN nonce can detect remarking NON-ECT packets to ECT and can also
> detect misbehaving transport receivers hiding CE from the transport
> sender. My own opinion is that if we do see more deployment of ECN  
> (I do
> hope so) - we do need this sort of mechanism, not to verify every  
> segment,
> but at least to be able to detect paths/endpoints where the ACK
> information is simply invalid.
>
> DCCP was mentioned in the thread, RFC 4340, took the view that ECN  
> nonce
> needed to be supported and the ECN Nonce Echo field is encoded in
> acknowledgement options.  "Each DCCP sender SHOULD set ECN Nonces on  
> its
> packets and remember which packets had nonces."
>
>
> Gorry
>
> P.S. Also note, if we do get to plans for new use of ECN this is  
> likely to
> be a TSVWG item - since it effects much more than TCP.
>
>> Great idea, I'd love for this semantic shift to happen!
>>
>>
>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote:
>>
>>> Hi,
>>>
>>> I just wanted to keep a record of these interesting remarks on the
>>> list, for further discussion.
>>>
>>> We discussed ECN both in TCPM and ICCRG, and this post is to start
>>> the discussion on the working group lists.
>>>
>>> During the TCPM session, Matt Mathis made an interesting remark on
>>> the microphone. To paraphrase (my understanding), current marking
>>> schemes (RED, CoDel, PIE,?) assume that ECN marks get treated like
>>> loss by the end systems.  Therefore, they employ a ?low density?
>>> marking scheme, with marks expected at an (average) rate of around
>>> 3% or so at maximum.
>>>
>>> Alternative schemes, that start getting deployed at this time, have
>>> very simple marking schemes in the network, and give more
>>> information to the end systems for processing and reaction there. As
>>> a side effect, these newer schemes may run as high as 100% marking
>>> for certain periods (longer than a single flows RTT), so they could
>>> be classified as ?high density? marking scheme.
>>>
>>>
>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent
>>> (I know only one stack with partial support), why not re-define
>>> ECT(1) to be used by high density marking schemes, keeping ECT(0)
>>> for low density schemes (as deployed today). For newer stacks, this
>>> would allow an even more fine grained reaction to ECN marking  
>>> levels?
>>>
>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has
>>> the same meaning for existing ECN stacks as ECT(0)) would not be
>>> addressed, but then again, current ECN is also virtually not
>>> deployed, according to recent studies.
>>>
>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would
>>> also need to have an impact on the future signaling  / feedback
>>> scheme used for TCP (DCCP and SCTP would be able to cope already,
>>> afaik).
>>>
>>> Best regards,
>>>
>>> Richard Scheffenegger
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>
>

From: [email-masked] (John Leslie)
Date: Wed Nov  7 17:54:41 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <20121107175918.GC78300@verdi>

Scheffenegger, Richard <[email-masked]> wrote:
> 
> During the TCPM session, Matt Mathis made an interesting remark on the
> microphone. To paraphrase (my understanding), current marking schemes
> (RED, CoDel, PIE,...) assume that ECN marks get treated like loss by
> the end systems. Therefore, they employ a "low density" marking scheme,
> with marks expected at an (average) rate of around 3% or so at maximum.

   Actually, 3% loss is pretty bad, and 3% ECN-marking would be very much
worth avoiding. Nonetheless, "low-density" can rise that high without
seriously damaging the transport.

> Alternative schemes, that start getting deployed at this time, have
> very simple marking schemes in the network, and give more information
> to the end systems for processing and reaction there. As a side effect,
> these newer schemes may run as high as 100% marking for certain periods
> (longer than a single flows RTT), so they could be classified as
> "high density" marking scheme.

   DCTCP fits this model. Alas, I don't think we all understand it...

> Later on, Bob noted, that since ECN Nonce is virtually nonexistent
> (I know only one stack with partial support), why not re-define ECT(1)
> to be used by high density marking schemes, keeping ECT(0) for low
> density schemes (as deployed today).

   This would have been a much better initial design!

> For newer stacks, this would allow an even more fine grained reaction
> to ECN marking levels...

   With 100% deployment, yes...

> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has the
> same meaning for existing ECN stacks as ECT(0)) would not be addressed,

   It might be possible to define a protocol for sender and receiver to
agree to treat ECT(1) this way; but I'm not optimistic about adoption.
It should be workable for research, though...

> but then again, current ECN is also virtually not deployed, according
> to recent studies.

   There's quite a bit of "deployed but disabled" AFAICT.

> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would
> also need to have an impact on the future signaling  / feedback scheme
> used for TCP (DCCP and SCTP would be able to cope already, afaik).

   I believe SCTP could, with near-trivial changes, get both ends to
agree on this difference for ECT(1). I'm not familiar enough with DCCP
to say for sure, but at first blush it appears there are enough
reserved bits to adapt. (It looks non-trivial, though.)

   Looking ahead, I doubt that two flavors of ECN will be sufficient
for all needs. Getting beyond one flavor is _very_ much worth doing;
but I think we need a final target of at least eight flavors.

--
John Leslie <[email-masked]>

From: [email-masked] (Scheffenegger, Richard)
Date: Wed Nov  7 13:03:19 2012
Subject: [Iccrg] ECN feedback discussion
Message-ID: <[email-masked]>

Hi,

I just wanted to keep a record of these interesting remarks on the list, for further discussion.

We discussed ECN both in TCPM and ICCRG, and this post is to start the discussion on the working group lists.

During the TCPM session, Matt Mathis made an interesting remark on the microphone. To paraphrase (my understanding), current marking schemes (RED, CoDel, PIE,...) assume that ECN marks get treated like loss by the end systems.  Therefore, they employ a "low density" marking scheme, with marks expected at an (average) rate of around 3% or so at maximum.

Alternative schemes, that start getting deployed at this time, have very simple marking schemes in the network, and give more information to the end systems for processing and reaction there. As a side effect, these newer schemes may run as high as 100% marking for certain periods (longer than a single flows RTT), so they could be classified as "high density" marking scheme.

Later on, Bob noted, that since ECN Nonce is virtually nonexistent (I know only one stack with partial support), why not re-define ECT(1) to be used by high density marking schemes, keeping ECT(0) for low density schemes (as deployed today). For newer stacks, this would allow an even more fine grained reaction to ECN marking levels...

However, ECN security aspects (Nonce) and legacy uses (ECT(1) has the same meaning for existing ECN stacks as ECT(0)) would not be addressed, but then again, current ECN is also virtually not deployed, according to recent studies.

Of course, such a shift in the semantics of ECT(0) vs ECT(1) would also need to have an impact on the future signaling  / feedback scheme used for TCP (DCCP and SCTP would be able to cope already, afaik).

Best regards,

Richard Scheffenegger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121107/9ed600c2/attachment.html
>From [email-masked]  Wed Nov  7 13:14:06 2012
From: [email-masked] (Michael Welzl)
Date: Wed Nov  7 13:06:52 2012
Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Great idea, I'd love for this semantic shift to happen!

On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote:

> Hi,
>
> I just wanted to keep a record of these interesting remarks on the  
> list, for further discussion.
>
> We discussed ECN both in TCPM and ICCRG, and this post is to start  
> the discussion on the working group lists.
>
> During the TCPM session, Matt Mathis made an interesting remark on  
> the microphone. To paraphrase (my understanding), current marking  
> schemes (RED, CoDel, PIE,?) assume that ECN marks get treated like  
> loss by the end systems.  Therefore, they employ a ?low density?  
> marking scheme, with marks expected at an (average) rate of around  
> 3% or so at maximum.
>
> Alternative schemes, that start getting deployed at this time, have  
> very simple marking schemes in the network, and give more  
> information to the end systems for processing and reaction there. As  
> a side effect, these newer schemes may run as high as 100% marking  
> for certain periods (longer than a single flows RTT), so they could  
> be classified as ?high density? marking scheme.
>
>
> Later on, Bob noted, that since ECN Nonce is virtually nonexistent  
> (I know only one stack with partial support), why not re-define  
> ECT(1) to be used by high density marking schemes, keeping ECT(0)  
> for low density schemes (as deployed today). For newer stacks, this  
> would allow an even more fine grained reaction to ECN marking levels?
>
> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has  
> the same meaning for existing ECN stacks as ECT(0)) would not be  
> addressed, but then again, current ECN is also virtually not  
> deployed, according to recent studies.
>
> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would  
> also need to have an impact on the future signaling  / feedback  
> scheme used for TCP (DCCP and SCTP would be able to cope already,  
> afaik).
>
> Best regards,
>
> Richard Scheffenegger
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

From: [email-masked] (Ali C. Begen (abegen))
Date: Tue Nov  6 23:02:07 2012
Subject: [Iccrg] slides for the iccrg session
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Sorry, going over the tools-style agenda and links were missing there.

Thanks.

-----Original Message-----
From: Michael Welzl <[email-masked]>
Date: Tuesday, November 6, 2012 7:05 PM
To: "Ali C. Begen" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Iccrg] slides for the iccrg session

>They were already posted before the meeting, to the normal IETF
>meeting materials page, as always...
>https://datatracker.ietf.org/meeting/85/materials.html#wg-iccrg
>
>Cheers,
>Michael
>
>
>On Nov 6, 2012, at 11:59 PM, Ali C. Begen (abegen) wrote:
>
>> Will they be posted on the web?
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

From: [email-masked] (Michael Welzl)
Date: Tue Nov  6 22:58:31 2012
Subject: [Iccrg] slides for the iccrg session
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

They were already posted before the meeting, to the normal IETF  
meeting materials page, as always...
https://datatracker.ietf.org/meeting/85/materials.html#wg-iccrg

Cheers,
Michael

On Nov 6, 2012, at 11:59 PM, Ali C. Begen (abegen) wrote:

> Will they be posted on the web?
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Eggert, Lars)
Date: Tue Nov  6 20:47:44 2012
Subject: [Iccrg] On using up-to-date TCP code in simulations
In-Reply-To: <[email-masked]>
References: <5841_135[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Lawrence Stewart is AFAIK working on getting FreeBSD-CURRENT supported on NSC. I agree that Linux 3.x would be good as well.

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4361 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121106/fdaf7a66/smime.bin
>From [email-masked]  Tue Nov  6 22:59:45 2012
From: [email-masked] (Ali C. Begen (abegen))
Date: Tue Nov  6 22:52:42 2012
Subject: [Iccrg] slides for the iccrg session
Message-ID: <[email-masked]>

Will they be posted on the web?

From: [email-masked] (Pasi Sarolahti)
Date: Tue Nov  6 19:52:04 2012
Subject: [Iccrg] On using up-to-date TCP code in simulations
In-Reply-To: <5841_135[email-masked]>
References: <5841_135[email-masked]>
Message-ID: <[email-masked]>

On Nov 6, 2012, at 2:45 PM, Michael Welzl wrote:

> According to:
> http://www.nsnam.org/docs/release/3.12/models/html/tcp.html
> ns-3 uses the Network Simulation Cradle: http://www.wand.net.nz/~stj2/nsc/status.html
> and this page says FreeBSD version 5.3 and Linux 2.6.10 are supported.

I have been playing with Linux 2.6.26 in ns-3 simulation cradle and that worked pretty well, although there is upper bound of 50 NSC nodes per simulation. 2.6.26 was the latest version available at the time for NSC (at least year ago when I did this).

It would indeed be nice to have a more recent version supported with NSC.

- Pasi

From: [email-masked] (Michael Welzl)
Date: Tue Nov  6 19:38:00 2012
Subject: [Iccrg] On using up-to-date TCP code in simulations
Message-ID: <[email-masked]>

Hi,

A stupid question. Is there a simple way to run an up-to-date TCP  
implementation in simulations?
I know that Linux-TCP ( http://netlab.caltech.edu/projects/ns2tcplinux/ns2linux/index.html 
  ) has been used a lot in ns-2, but this page talks about  
2.6something, and so does this: http://nsnam.isi.edu/nsnam/index.php/Contributed_Code 
  - it says that the code models TCP 2.6.16.3

According to:
http://www.nsnam.org/docs/release/3.12/models/html/tcp.html
ns-3 uses the Network Simulation Cradle: http://www.wand.net.nz/~stj2/nsc/status.html
and this page says FreeBSD version 5.3 and Linux 2.6.10 are supported.

All of that sounds hopelessly outdated?!  So maybe I'm missing  
something... I hope I am! My question is just, is there a simple way  
to get an up-to-date kernel implementation (Linux or FreeBSD) running  
in a simulator?

Thanks a lot to anyone who can help out!

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Tue Nov  6 13:53:35 2012
Subject: [Iccrg] draft-fairhurst-tcpm-newcwv-03
Message-ID: <[email-masked]>

Hi,

(ICCRG chair hat off)

In his presentation yesterday, Gorry said that he'd like to get more  
comments. I have also read this draft, and had the overall impression  
that it has significantly improved since the first version. In  
particular, I like the way the non-validated phase is used.

Given the trade-off between:
1) systems that collapse cwnd (do they exist? :-) )
2) systems that simply maintain cwnd
3) old cwv which noone uses because it doesn't perform well enough

...this proposal strikes me as quite a reasonable trade-off. In other  
words: I'd prefer seeing this deployed and used over the current state  
of things.

Cheers,
Michael

From: [email-masked] (Ingemar Johansson S)
Date: Tue Nov  6 11:55:57 2012
Subject: [Iccrg] Re: Why don't we stop treating ECN and loss similarly
In-Reply-To: <20121031143533.GC68232@verdi>
References: <[email-masked]> <20121031143533.GC68232@verdi>
Message-ID: <[email-masked]>

Hi

The actual ECN marking algos in LTE are likely to be proprietary, this is quite similar to the actual packet/user scheduling which is also proprietary.

/Ingemar

-----Original Message-----
From: John Leslie [mailto:[email-masked]] 
Sent: den 31 oktober 2012 15:36
To: Ingemar Johansson S
Cc: [email-masked]
Subject: Re: [Iccrg] Re: Why don't we stop treating ECN and loss similarly

Ingemar Johansson S <[email-masked]> wrote:
> 
>... It is doable and sometime beneficial to treat ECN and implicit  
>signals of congestion (delay, packet loss) differently. We explored  
>the possibilities in  
>http://www.tschofenig.priv.at/cc-workshop/irtf_iab-ccirtcpaper4.pdf

... demonstrating that early ECN marking, signaling a condition where no packet drop is expected yet, enables a smooth adaptation of sending rate.

> The trick we did was to include the channel conditions into the ECN 
> decision meaning that the cost per transmitted bit is included,

   Alas, the paper itself didn't make the ECN-marking algorithm clear.
(And I'm afraid "cost per transmitted bit" isn't entirely clear either.)

> this and the combination of only a limited decrease of the bitrate
> (~20%) gives a dramatically improved performance compared to delay 
> based rate adaptation.

   As one would expect, but it's always good to have data to back it up.

> ECN with cost per transmitted bit only makes sense with wireless 
> access as it is only then the cost may differ between the terminals.

   Indeed, gathering similar data for all-ethernet networks would be useful. IMHO, it's good to consider a path "congested" long before packet drop is inevitable. To some degree, as soon as you have two packets ready to send, there is _some_ congestion which might be worth notifying.

   In an ideal world, we could pass on explicit notification of time- in-queue -- and I believe there is valuable research in exploring different possible reactions to such a signal.

   Clearly, there is value in ECN feedback if the response to ECN is allowed to be proportionate to the actual congestion signal instead of "the same as packet loss". In a Research Group, we can explore that.

>...
> A tough question is .. How is the end user made aware of the  
>differentiated ECN and drop behavior?.

   The right way is to _ask_ for it.

   Alas, IPv6 doesn't do much better than IPv4 at enabling this. The mere existence of ECN-enabled proves nothing about what level of ECN-marking is desired. For the big-I internet, something hidden in a destination option is useless; but we could use that for research...

--
John Leslie <[email-masked]>

From: [email-masked] (=?iso-8859-1?Q?P=E5l_Halvorsen?=)
Date: Thu Nov  1 13:49:47 2012
Subject: [Iccrg] NOSSDAV 2013: less than a month until paper deadline (26. November)
Message-ID: <[email-masked]>

NOSSDAV 2013 - Call for Papers: less than a month until paper deadline (26. November)

NOSSDAV 2013:
ACM Workshop on Network and Operating Systems Support 
for Digital Audio and Video

Oslo, Norway, February 26 ? 27, 2013

http://nossdav2013.ndlab.net

NEW:
Authors of selected good papers will be invited to submit an extended version of 
their work and submit it to the ACM Transactions on Multimedia Computing, 
Communications and Applications (ACM TOMCCAP) journal.

NEW: 
Dr. Aljosa Smolic (Disney Research Zurich, Switzerland) will give a keynote 
entiteled "Advanced 3D Video Processing and Coding" at NOSSDAV 2013. 
http://nossdav2013.ndlab.net/program.html

----------------------------------------------------------------------------------------

As in previous years, NOSSDAV will continue to focus on both established 
and emerging research topics, high-risk high-return ideas and proposals, and 
future research directions in multimedia networking and systems, in a 
single-track format that encourages active participation and discussions among
academic and industry researchers and practitioners.

The workshop seeks papers in all areas of multimedia networking and
systems. Authors are especially encouraged to submit papers with
real-world experimental results and real data sets. Topics of interest
include (but are not restricted to):

- Cloud and peer-to-peer system architectures
- Media streaming, distribution and storage support
- Multimedia communications and system security
- Multi-core and many-core architecture support
- Networked GPUs, graphics and virtual environments
- Networked games / Real-time immersive systems
- Operating system, middleware and network support
- Web 2.0 systems and social networks
- Wireless networks and embedded systems for multimedia applications  

In particular, we are interested in soliciting papers that discuss
system-level support for social media and social networking, papers
that focus on improving performance with multi-core and many-core
processors, as well as papers that focus on multimedia applications on
mobile devices and/or in a cloud computing environment.

Submitted papers must be original and should not be currently under
review for any other publication. Authors of accepted papers will need
to sign an ACM copyright release form and present their paper at
NOSSDAV 2013 in person. The Proceedings of NOSSDAV 2013 will be
published by ACM and distributed at the workshop electronically, and
will also be included in the ACM Digital Library.

* Paper Deadline: 26. November 2012

All paper submissions will be handled electronically in the NOSSDAV
2013 submission web site:
http://submission.ndlab.net/nossdav13/
(also available from http://nossdav2013.ndlab.net)

Best regards,

Program Co-Chairs
P?l Halvorsen, University of Oslo/Simula, Norway
Laszlo B?sz?rmenyi, Klagenfurt University, Austria