philip.eardley | 1 Nov 11:36 2005

Drafts on "Admission Control over DiffServ using Pre-Congestion Notification"

We've submitted a couple of drafts, which we'd very much appreciate your comments and feedback on, and which we will -  tsvwg agenda permitting - discuss in Vancouver. They’re about “Admission Control over DiffServ using Pre-Congestion Notification”:

-         a framework (architecture & use case)

-         RSVP extensions necessary for the framework.

 

Here are their abstracts & links to them

 A Framework for Admission Control over DiffServ using Pre-Congestion Notificationhttp://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-01.txt

Abstract

This document describes a framework to achieve an end-to-end Controlled Load (CL) service without the scalability problems of previous approaches. Flow admission control and if necessary flow pre-emption preserve the CL service to admitted flows. But interior routers within a large DiffServ-based region of the Internet do not require flow state or signalling. They only have to give early warning of their own congestion by bulk packet marking using a new pre-congestion notification behaviour. Gateways around the edges of the region convert measurements of this packet granularity marking into admission control and pre-emption functions at flow granularity.

 

 

RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification

http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-ecn-00.txt

Abstract

This document specifies the extensions to RSVP for support of the Controlled Load (CL) service over a Diffserv cloud using Pre-Congestion Notification as defined in [CL-ARCH].

 

Best wishes,

 

Joe Babiarz

Bob Briscoe

Kwok Chan

Anna Charny

Philip Eardley

Francois Le Faucheur

Dave Songhurst

 

BT Group plc
Registered office:
81 Newgate Street London EC1A 7AJ
Registered in
England and Wales no. 4190816   This electronic message contains information from BT Group plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the BT Group plc E-mail system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.

 

_______________________________________________
tsvwg mailing list
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
Allison Mankin | 2 Nov 14:55 2005

diffserv control plane discussion - please participate

Hi, TWVWG folks,

The OPS area has hosted a half hour discussion on diffserv
control plane in their opsarea meeting.  They did consult 
the TSV ADs, and we have talked about how this is strongly
a topic in our area, with work already going on in NSIS
and with related activity in TSVWG.  Though it says "proposed
working group", this is far from a done deal or a deal in
that area.  The meeting has been intentionally scheduled
not to have TSV conflicts.  We expect to put in a talk about
the ongoing diffserv control plane work (more on that not from
me).  Please participate in the meeting and shape the ongoing
and future IETF work on this topic.

Allison

Draft Agenda (v1) for the Operations & Management Open Area Meeting IETF64

When:   1740-1950, MONDAY, November 7, 2005
Where:  Salon 2/3

A. Administrative stuff
[snip]

   (David Kessens, Bert Wijnen)

B. Proposed working groups

   - AAA Maintenance
     (John Loughney, speaker not yet confirmed)

   - Diffserv Control Plane Elements (DCPEL)
     (Kathleen Nichols, Scott Bradner)

     mailing list: dcpel <at> ietf.org

     archive: https://www1.ietf.org/mailman/listinfo/dcpel

[snip]   

Also in that slot:

Salon 1	  APP  calsify Calendaring and Scheduling Standards Simplification WG
Salon C	  INT  mipshop MIPv6 Signaling and Handoff Optimization WG
Oak   INT ntp  Network Time Protocol WG
Salon 2/3 OPS  opsarea Operations and Management Open Area
Salon F	  RTG  rpsec   Routing Protocols Security Requirements WG - CANCELLED
Cypress	  SEC  smime   S/MIME Mail Security WG

 - RPSEC is cancelled, I'm told
Mark Watson | 3 Nov 02:22 2005

Fecframe BOF next week

All,

 

There will be a BOF session on Wednesday afternoon next week on the topic of FEC over transport protocols. The objective is to consider starting work on a framework for generalized FEC protection of IP flows over unreliable transport (possibly based on the framework presented in draft-watson-tsgwg-fec-sf-00 which I presented at TSVWG and AVT at IETF63.)

 

The BOF description and agenda are available at: http://www3.ietf.org/proceedings/05nov/agenda/fecframe.txt

 

As many of you will be aware, there is increasing interest in applying FEC to media streams in a variety of environments, but a notable lack of IETF protocols to support that in a way which is independent of the actual FEC code used. This would would aim to address that in a way which is as far of possible generic with respect to transport and application protocols as well.

 

Regards,

 

Mark Watson

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Joe Touch | 3 Nov 18:57 2005
Picon

Re: Fecframe BOF next week


Mark Watson wrote:
> All,
> 
> There will be a BOF session on Wednesday afternoon next week on the
> topic of FEC over transport protocols. The objective is to consider
> starting work on a framework for generalized FEC protection of IP flows
> over unreliable transport (possibly based on the framework presented in
> draft-watson-tsgwg-fec-sf-00 which I presented at TSVWG and AVT at IETF63.)

This is a little confusing; in the IETF, transport happens over IP, not
the other way around. And the term flows applies to IPv6, but not as
well to IPv4.

Do you mean FEC of unreliable transport flows over IP? (that seems what
the BOF is talking about)?

> The BOF description and agenda are available at:
> http://www3.ietf.org/proceedings/05nov/agenda/fecframe.txt
> 
>  
> 
> As many of you will be aware, there is increasing interest in applying
> FEC to media streams in a variety of environments, but a notable lack of
> IETF protocols to support that in a way which is independent of the
> actual FEC code used. This would would aim to address that in a way
> which is as far of possible generic with respect to transport and
> application protocols as well.
> 
>  
> 
> Regards,
> 
>  
> 
> Mark Watson
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> tsvwg mailing list
> tsvwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg
Mark Watson | 3 Nov 19:10 2005

RE: [Tsvwg] Fecframe BOF next week

Joe,

Yes - thank you for the clarification. I mean FEC protection of
unreliable transport flows over IP (v4 or v6).

Also, btw, there is a mailing list for this BOF: fecframe <at> ietf.org,
https://www1.ietf.org/mailman/listinfo/fecframe which I should also have
advertised in the mail below.

Regards,

Mark

-----Original Message-----
From: Joe Touch [mailto:touch <at> ISI.EDU] 
Sent: Thursday, November 03, 2005 9:57 AM
To: Mark Watson
Cc: rmt <at> ietf.org; avt <at> ietf.org; mmusic <at> ietf.org; tsvwg <at> ietf.org
Subject: Re: [Tsvwg] Fecframe BOF next week

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Watson wrote:
> All,
> 
> There will be a BOF session on Wednesday afternoon next week on the
> topic of FEC over transport protocols. The objective is to consider
> starting work on a framework for generalized FEC protection of IP
flows
> over unreliable transport (possibly based on the framework presented
in
> draft-watson-tsgwg-fec-sf-00 which I presented at TSVWG and AVT at
IETF63.)

This is a little confusing; in the IETF, transport happens over IP, not
the other way around. And the term flows applies to IPv6, but not as
well to IPv4.

Do you mean FEC of unreliable transport flows over IP? (that seems what
the BOF is talking about)?

> The BOF description and agenda are available at:
> http://www3.ietf.org/proceedings/05nov/agenda/fecframe.txt
> 
>  
> 
> As many of you will be aware, there is increasing interest in applying
> FEC to media streams in a variety of environments, but a notable lack
of
> IETF protocols to support that in a way which is independent of the
> actual FEC code used. This would would aim to address that in a way
> which is as far of possible generic with respect to transport and
> application protocols as well.
> 
>  
> 
> Regards,
> 
>  
> 
> Mark Watson
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> tsvwg mailing list
> tsvwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDak9vE5f5cImnZrsRAhOLAJ9SOr2+z8EJdUGRa6O3tFpiUOhdegCg/qfz
LoVKyPZvX2g+VKIfHWJW52Q=
=YFfm
-----END PGP SIGNATURE-----
Caitlin Bestler | 3 Nov 19:34 2005

RE: Fecframe BOF next week


Mark Watson said:
> Joe,
>
> Yes - thank you for the clarification. I mean FEC protection of
> unreliable transport flows over IP (v4 or v6).
>
> Also, btw, there is a mailing list for this BOF:
> fecframe <at> ietf.org,
> https://www1.ietf.org/mailman/listinfo/fecframe which I should
> also have
> advertised in the mail below.
>
> Regards,
>

Actually I think that Error Correction vs. Error Detection
and Reliable vs. Unreliable are distinct issues.

With Error Deteciton alone a packet either is valid or it
is not. With error correction, a packet can be valid *after*
correction or it can still be invalid.

Reliable vs. Unreliable deals with how the transport
responds to missing packets (potentially because they
were deemed invalid).

I will agree, however, that the *applicability* of
Error Correction heavily favors unreliable or partially
reliable transports.
Kwok-Ho Chan | 3 Nov 20:19 2005

Status Update on ECN for Real Time Traffic drafts

Update to TSVWG on the status and differences of the submitted drafts 
on ECN Field
for Real Time traffic topic:

We have been working together on the front of using the ECN Field for 
Real Time traffic.
We have submitted the following drafts:

1. 
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-01.txt
     Provides a Framework for the usage of ECN Field for Real Time 
traffic in an Edge-to-Edge scenario.

2. http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-ecn-00.txt
     Provides an Extension to RSVP for use as signaling in the 
Edge-to-Edge scenario.

3. http://www.ietf.org/internet-drafts/draft-babiarz-tsvwg-rtecn-05.txt
     Provides incremental addition of Framework on the usage of ECN Field for
     Real Time traffic in an End-to-End scenario.

Please notice that both the Edge-to-Edge (cl-architecture) and 
End-to-End (rtecn) Framework,
and http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-00.txt
contains information on how marking of the ECN field is done for Real 
Time traffic.
But these are still work in progress and not finalized.
We are working toward a common Marking method that can be used for 
both Edge-to-Edge and
End-to-End scenarios.

We welcome all comments on these drafts and the topic in general.
We will be in Vancouver IETF if face to face discussion is preferred.

Thanks!

Philip Eardley
Bob Briscoe
Francois Le Faucheur
Anna Charny
Joe Babiarz
Kwok Ho Chan
Sally Floyd | 4 Nov 00:42 2005

several items for the tsvwg agenda

I have three items that I would like to put on the tsvwg agenda for next
week:

* Quick-Start, draft-ietf-tsvwg-quickstart-01.txt:  
  From our email on 10/13, we have revised this draft, and would 
  like to discuss it briefly.  Our hope is that it is (finally) ready 
  for WG Last Call.

* Adding ECN Capability to TCP's SYN/ACK Packets,
  draft-kuzmanovic-ecn-syn-00.txt:
  From our email on 10/03, we would like to present this briefly, and to
  ask that it be added as a tsvwg item.

* Specifying Alternate Semantics for the ECN Field,
  draft-floyd-ecn-alternates-02.txt:
  From our email on 8/18, we have modified this in response to feedback
  at the last IETF, and think it is now ready for WG Last Call.
  We are waiting for the OK to submit this as draft-ietf-tsvwg-*
  as an official WG item.  It just needs two minutes, I think.

- Sally
http://www.icir.org/floyd/
Matt Mathis | 4 Nov 01:21 2005
Picon

TCP-ESTATS-MIB agenda item

Can I have a 5 minute agenda slot to show a slide or two on my
plans to get closure on the TCP extended statistics MIB?

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by people who think they know
"The Truth" and use force to apply it to others.
James M. Polk | 4 Nov 03:25 2005
Picon

draft-ietf-tsvwg-diffserv-service-classes-01 starting WGLC

TSVWG

The chairs have started a WGLC on the following ID:

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-service-classes-01.txt 

This document is being put forth as an Informational document.

Because of the nature of this document, it has the potential to affect 
other efforts outside this WG's influence and/or review, therefore comments 
will be solicited from other WGs on this document. Each WG will be 
contacted by me. So -  if you see one or more of those requests for comment 
and are otherwise confused, you'll know why.

This WGLC will end on November 18th.

Allison
Jon
James
	IETF TSVWG co-chairs

Gmane