Formal IESG Teleconference WebEx and Dial-in Information: 14 July 2022

2022-07-07 Thread IESG Secretary 
All members of the community are welcome to attend formal IESG telechats
as observers. Observers are not invited to participate in the
discussion.

The next formal IESG telechat will be held on Thursday, July 14,  
2022 at 07:00 US/Canada Pacific (14:00 UTC). The meeting is scheduled 
for two hours (07:00-09:00 US/Canada Pacific). Webex and Dial-in information 
is at the bottom of this message.

The agenda for the upcoming telechat can be found at


A calendar of upcoming public telechats can be downloaded or subscribed
to at:
https://calendar.google.com/calendar/ical/ietf.org_egdabaf39ch5v8a13dt39mvee4%40group.calendar.google.com/public/basic.ics


Topic: IESG Formal Telechat
Date: July 14, 2022
Time: 07:00 US/Canada Pacific 
09:00 US/Canada Central
10:00 US/Canada Eastern
14:00 UTC
15:00 United Kingdom
16:00 Germany, France, Belgium, Sweden
17:00 Finland, Kenya
22:00 Beijing, China
  
---
JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=m38beb3706c7e5a24dd749a50d7e87dfd
Meeting number: 642 944 708
Meeting password: 1234


JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 642 944 708

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Protocol Action: 'Application-Specific Attributes Advertisement with BGP Link-State' to Proposed Standard (draft-ietf-idr-bgp-ls-app-specific-attr-15.txt)

2022-07-07 Thread The IESG 
The IESG has approved the following document:
- 'Application-Specific Attributes Advertisement with BGP Link-State'
  (draft-ietf-idr-bgp-ls-app-specific-attr-15.txt) as Proposed Standard

This document is the product of the Inter-Domain Routing Working Group.

The IESG contact persons are Alvaro Retana, Andrew Alston and John Scudder.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-app-specific-attr/





Technical Summary

   New extensions have been defined for link-state routing protocols
   that enable distribution of application-specific link attributes for
   existing as well as newer applications such as Segment Routing.  This
   document defines extensions to BGP-LS to enable the advertisement of
   these application-specific attributes as a part of the topology
   information from the network.

Working Group Summary

   Nothing worth noting.  The working group provided the 
   expected level of support for BGP-LS drafts. 

Document Quality

   Existing implementations: 
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-app-specific-attr%20implementations
 

Personnel
   
   Document Shepherd: Keyur Patel
   Responsible Area Director: Alvaro Retana

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Volunteer list update

2022-07-07 Thread NomCom Chair 2022 
The list I posted yesterday DID NOT include anyone who volunteered by checking 
the box on their IETF 114 registration. Apologies for the confusion; that part 
of the system isn't automated yet.

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Last Call: (DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S)) to Experimental RFC

2022-07-07 Thread The IESG 


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'DualQ Coupled AQMs for Low
Latency, Low Loss and Scalable Throughput
   (L4S)'
   as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2022-07-21. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This specification defines a framework for coupling the Active Queue
   Management (AQM) algorithms in two queues intended for flows with
   different responses to congestion.  This provides a way for the
   Internet to transition from the scaling problems of standard TCP
   Reno-friendly ('Classic') congestion controls to the family of
   'Scalable' congestion controls.  These are designed for consistently
   very Low queuing Latency, very Low congestion Loss and Scaling of
   per-flow throughput (L4S) by using Explicit Congestion Notification
   (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
   could only be deployed where a clean-slate environment could be
   arranged, such as in private data centres.  The coupling acts like a
   semi-permeable membrane: isolating the sub-millisecond average
   queuing delay and zero congestion loss of L4S from Classic latency
   and loss; but pooling the capacity between any combination of
   Scalable and Classic flows with roughly equivalent throughput per
   flow.  The DualQ achieves this indirectly, without having to inspect
   transport layer flow identifiers and without compromising the
   performance of the Classic traffic, relative to a single queue.  The
   DualQ design has low complexity and requires no configuration for the
   public Internet.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/


The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2952/
   https://datatracker.ietf.org/ipr/3561/
   https://datatracker.ietf.org/ipr/3562/
   https://datatracker.ietf.org/ipr/2679/






___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Last Call: (Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (L4S)) to Experimental RFC

2022-07-07 Thread The IESG 


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'Explicit Congestion
Notification (ECN) Protocol for Very Low Queuing
   Delay (L4S)'
   as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2022-07-21. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This specification defines the protocol to be used for a new network
   service called low latency, low loss and scalable throughput (L4S).
   L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
   layer that is similar to the original (or 'Classic') ECN approach,
   except as specified within.  L4S uses 'scalable' congestion control,
   which induces much more frequent control signals from the network and
   it responds to them with much more fine-grained adjustments, so that
   very low (typically sub-millisecond on average) and consistently low
   queuing delay becomes possible for L4S traffic without compromising
   link utilization.  Thus even capacity-seeking (TCP-like) traffic can
   have high bandwidth and very low delay at the same time, even during
   periods of high traffic load.

   The L4S identifier defined in this document distinguishes L4S from
   'Classic' (e.g. TCP-Reno-friendly) traffic.  It gives an incremental
   migration path so that suitably modified network bottlenecks can
   distinguish and isolate existing traffic that still follows the
   Classic behaviour, to prevent it degrading the low queuing delay and
   low loss of L4S traffic.  This specification defines the rules that
   L4S transports and network elements need to follow with the intention
   that L4S flows neither harm each other's performance nor that of
   Classic traffic.  Examples of new active queue management (AQM)
   marking algorithms and examples of new transports (whether TCP-like
   or real-time) are specified separately.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/



No IPR declarations have been submitted directly on this I-D.





___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Last Call: (Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture) to Informational RFC

2022-07-07 Thread The IESG 


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'Low Latency, Low Loss,
Scalable Throughput (L4S) Internet Service:
   Architecture'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2022-07-21. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document describes the L4S architecture, which enables Internet
   applications to achieve Low queuing Latency, Low Loss, and Scalable
   throughput (L4S).  The insight on which L4S is based is that the root
   cause of queuing delay is in the congestion controllers of senders,
   not in the queue itself.  With the L4S architecture all Internet
   applications could (but do not have to) transition away from
   congestion control algorithms that cause substantial queuing delay,
   to a new class of congestion controls that induce very little
   queuing, aided by explicit congestion signalling from the network.
   This new class of congestion controls can provide low latency for
   capacity-seeking flows, so applications can achieve both high
   bandwidth and low latency.

   The architecture primarily concerns incremental deployment.  It
   defines mechanisms that allow the new class of L4S congestion
   controls to coexist with 'Classic' congestion controls in a shared
   network.  These mechanisms aim to ensure that the latency and
   throughput performance using an L4S-compliant congestion controller
   is usually much better (and rarely worse) than performance would have
   been using a 'Classic' congestion controller, and that competing
   flows continuing to use 'Classic' controllers are typically not
   impacted by the presence of L4S.  These characteristics are important
   to encourage adoption of L4S congestion control algorithms and L4S
   compliant network elements.

   The L4S architecture consists of three components: network support to
   isolate L4S traffic from classic traffic; protocol features that
   allow network elements to identify L4S traffic; and host support for
   L4S congestion controls.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/



No IPR declarations have been submitted directly on this I-D.





___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce