[Tsvwg] Draft Paris meeting notes and a request...

We need to submit revisions next week, so please send your fixes in.

In Paris, as you'll see from these notes, I put up a volunteer/
nomination notice for a third tsvwg chair to help Jon and me keep the working
group moving.  The list hasn't heard this notice yet, oops, and our list
is fairly short, so we'd like to get a few more folks on it before
we do our interviewing and figure out who to pick.  Please let us
know if you are interested or think someone else would do a good job.

Here are the draft notes, with much thanks (as usual) to Matt Z.

-----------

TSVWG - Transport Working Group - IETF 63

Meeting Notes, taken by Matt Zekauskas, brilliantly as always.

Lights edits thereof by Allison Mankin, co-chair, co-AD.

This meeting was singly chaired by Allison.  Jon was absent
in order to serve as the AD for the voipeer BOF.  The Transport
Area overflowed its scheduling boundaries beyond repair this meeting.

0. Agenda Bashing and Status Update
===
Several documents that are scheduled for WGLC:

 draft-ietf-tsvwg-sctpimpguide0-14.txt
 draft-ietf-tsvwg-diffserv-service-classes-01.txt (multiple revs before wg)
 draft-ietf-tsvwg-mlpp-that-works-02.txt

The goal is to get these documents on the end August and first of September
IESG agendas, and out the door.

The working group should determine which other documents are ready.

Allison then turned to tsvwg structure.  Allison and Jon are considering
adding a tsvwg co-chair, to help track documents, and move them along.
They are looking for people that are active participants; if you are
interested, please tell the chairs.  They will do some interviewing.
This is relevant to the absence of Jon in this meeting -- there is
too much work and the area generates too many conflicts for
participants.  

In addition:
Allison and Jon have been thinking of restructuring the area for 
some time -- both for area or topic focus and for
logistical breathing room.  This split would entail taking an
area with the topic of something like Real Time Applications
and Operations (with groups like IPTEL, SIP...) out separate
from Transport.  There would be many details to discuss.
We can have some discussion of the split on the list if 
you like, as this develops.

=====================

1. Francois Lefaucheur
===
draft-tsvwg-rsvp-dste-00.txt (first version as a wg doc)

Francois started by reviewing the status of the document, which
discusses the aggregation of RSVP reservations over MPLS TE tunnels
(see slides).

He noted the changes, which responded to comments here, as well
as the responses from the MPLS WG due to a message asking for comments
there.

Francois said that the authors were not aware of any remaining
outstanding issues, and feel the document is done.  Should the
document go to WGLC?

Allison asked where the MPLS discussion occurred.  It was on the MPLS list.
She also verified that this has no MPLS extensions.  Francois said the
principal concern was with possible overlap with LSP-HEIR.  With the
most recent changes, there is no overlap and the two documents are
consistent.

Bob Braden said that he  recently looked at RFCs and drafts about RSVP
and tunneling.  It seemed that they were all solving the same problem,
and it wasn't clear which ones should be implemented.  His conclusion
was that the modularity is all wrong... the documents were taking little
bits and slices of the problem... but it was really all the same problem.
Another way would be to update earlier documents, rather than writing
a new document with a different slice.   He asked what others thought.

Francois kind of agreed with Bob's analysis,  but he wasn't shure
he would come to the same conclusion.  If we were to start over, maybe
we would end up with a more generic and modulare framework; perhaps
it is too late.  First there was RSVP over IP, then aggregation in
3175, now LSP tunnels.  The set of potential new documents is small,
there are not too many situations left; Francois thought that this
line of modification was basically over.

Bob thought that perhaps we'll just replace RSVP with NSIS. [[say something
about a snide comment?  drop this?  put a smiley?]]

Bruce Davie said that as a co-author,  they did try to position this
draft with respect to the other drafts.  Rather than viewing this as a
"pigs ear", there was a set of design decisions when first tunnel
draft was done, 3175 did more, and this is a delta to 3175.  He didn't
think the situation was as bad as Bob fears.

Allison noted that people inherently use tunnels for non-coordinated
purposes, that's the nature of tunnels.  And many people have tried to
make "clean tunnel" theory.  Tunnels by design are clean on the inside,
but an outside logic for them, the idea that they should be related
to other types of tunnels is not clear - they're just meant to arrange
for their own inside user's benefit.  But one of the first comments given
to Francois was to clarify the relation to the past RSVP* tunnel work,
and that's in there.  

Allison said that she is willing to have a WGLC,  but the WG needs to
have written reviews from the people that call themselves the "RSVP team".
Any objections?  No one voiced objections.

Allson called for a hum: People supporting wglc at this time?
   There was moderate support
Allison declares enough support to go ahead.  The requirement will
be a least a couple of RSVP reviewers (from the RSVP team) to
write during WGLC.

=====================

2. More Francois...
===
Generic aggregate RSVP reservations
draft-lefaucheur-rsvp-ipsec-01.txt

Francois next discussed for the second time an RSVP extension
which combines two features of RSVP: aggregation into IPSec 
and aggregation into Diffserv regions (see his slides to get
the picture).

The open items mainly carry over from last time: clarifying text about
what is responsible for managing the security association and what is
responsible for mapping traffic onto the security associations; and
moving the discussion of handling dynamic SPI/Security association
updates out of the security considerations section.

The authors would like more feedback, and wish to have the document
accepted as a working group document.

James Polk asked if IEPREP changes its charter as proposed would this
document be better homed there.

Allison stated that she did not think this document is directly 
pertinent to IEPREP -- it's not strongly tied to emergency service.
It has a role, but she did not see IEPREP as the proper home.

Allison's biggest concern is that we don't have a strong security group that
can look at aggregating identities in SPI.  She did not think RSVP extension
was a concern, and was not worried about doing the document here.  It fits
with the nested VPN work.  She did feel that we 
need to ask someone in IPsec as to whether extending the RSVP IPsec story,
brning multiple identities and users, has any security problems.
Some other WG has to go through the security issues; she will ask
the security ADs about that.

James said that he didn't read the draft but felt the problem was a
good one to solve.

Someone asked what's intent for nested VPN document? 
[That one is draft-baker-vpn-signaled-preemption, it needs to
recover from expiration].

author: the last time it was discussed, Fred tried to get it into
last call.  We have gotten feedback on the mailing list; the document
is now at -03.

Allison asked if the changes on it could be summarized to the list, and then
request last call on the list.  We'll discuss it over on the mailing list.

author: When we discussed, nested VPN was with Fred and James'  bandwidth
reduction draft.

[draft-ietf-tsvwg-bw-reduction - expired currently]

James stated that he will have a new revision of the bandwidth reduction
draft within 5 days.

Allison said that we have to discuss these drafts and go through the
issues, and we can do that on the mailing list.  Get the changes to the
list so we can discuss them.

James stated that he thought the nested VPN draft was agreed to become
a working group document at last meeting.

Allison said we also need a commitment from room to review.  She asked
for a hum of interest:  hum if you will give effort and interest to this work.
Allison declared the result  "low but not absent".
=====================

3.  Kwok-ho Chan  
===
Kwok said he didn't make slides on the diffserv service class draft.
They have received no comments; only spelling and grammatical cleanup
has been done.  They are essentially into WGLC, as mentioned.

Aggregation of DiffServ Service Classes
draft-chan-tsvwg-diffserv-class-aggr-02.txt

He then went on to talk about the aggregation of DiffServ service classes
draft (see slides).  He mentioned the changes in the draft, which included
using the EXP field of MPLS to send the aggregates, so DSCP doesn't
change.

James Polk asked about EXP being used to preserve DSCP.  EXP only has
3 bits versus the six of DSCP -- is there a mapping?  Kwok-ho responded
yes.

James then asked about preserving DSCP from one domain to the next - how
do you make the policy decision that domain B must follow given domain
A actions?  Kwok-ho responded that they were thinking this would be like
service classes, and certain DSCP values would be recommended.

However, the end user is one that requested service from network.  They
want traffic treated certain way.  Say Alice in Atlanta uses DSCP 3,
and Bob uses DSCP 5.  Don't you need to map them?

Kwok said they want to avoid having a mapping function.  James thought
you couldn't complete avoid this.

Brian Carpenter stated that mapping DSCP at administrative boundaries
is part of the DiffServ architecture, you can't switch it off.
It might be desirable that operators agree on a one-to-one mapping.

Kwok agreed that a mapping function could be there.

He then went back to his presentation, and showed a mapping of EXP bits.
In his view the next steps are to get comments on the list, and make
the document a working group document.  He thinks it could be in WGLC
within two IETF meetings.

Allison stated that she did not see consensus around this draft yet;
the working group needs to work on the structure of the idea.
=====================

4. Josef Babiarez
===
RT-ECN
draft-babiarz-tsvwg-rtecn-04.txt

Josef Babiarez discussed the RT-ECN draft.  He began with associated
drafts and a justification for new ECN semantics (see slides).
He then discussed the updates, principally:
* updated draft to meet requirements in floyd ECN draft
* handle both ECN and non-ECN using same DSCP
* addressed who rt flows reach when encountering 3168 router

James Polk asked if Josef would expand on that.  Josef said that 
when an alternate ECN mechanism encounters an RFC3168 router that
is in congestion it should back off.

James said that he read the draft last time, and this wasn't clear
to him, nor is it clear what has changed to help.  Josef said they
now have a mechanism to test for non-conformance, and use that
mechanism to test for router that is marking ECN bits as per 3168.

David Black said that it was not clear to him that the mechanism
works as advertised; James said that that was his concern as well.
David said the reciever can figure out what's going wrong, but 
where is feedback to the sender?  Josef said through application
contro, for example SIP signalling.  The ECN marking is sent to the
end point, the end station gives this to application control,
and the application control preempts the session.

David said that in other words it is "not your problem"; the draft
must contain an explicit MUST to implementers to do this.

Colin Perkins said that in the AVT WG, there was pushback on
application mechanisms.   They don't think they work.

James gave an example: suppose Alice & Bob are have an RTP real time flow.
It can take multiple paths.  In the limit, every packet could take
different paths.  These paths can have multiple different routers.
The receiver gets an ECN notification from one of them.  The server
will tell Alice what to do.  What can Alice do?  She can't reroute
traffic...

Josef said that wasn't quite true; when a flow contains congestion,
the application controller has a flow association, and it terminates
the session.  The issue is that the end point can terminate the session.

James said that he didn't think it will necessarily have the desired effect.
If the end point can't determine which intermediate routers the flow
uses, it doesn't know that if the flow stops, that it would help
reduce congestion.

Magnus Westerlund stated that if a receiver gets one or two marked packets
the response is usually to slow down, not terminate the flow.
Josef said that could be a valid response.

Magnus thought the use case seems to be admission control if get probe packet;
Josef said to read the draft.

Colin said that during establishment of new flows, he doesn't see how you
can count absence of marked packets as an indication that you are allowed
to admit a flow.  Josef said that if traffic at time of session setup is
below 20%, then packets won't be marked; Colin said that only makes sense
if packets all follow same path and if congestion is stationary, neither
is true.

David echoed that there is still an opportunity to get in trouble if
the path changes at wrong moment.  Josef said that if the path
changes, and there is now congestion, the flow will be preempted.

Another participant [xxx] stated that his understanding from AVT is that
these packets which you are going to send may have different characteristics
than packets that consitute main flow.  Therefore, they may follow a different
path than main flow. Josef said they were using IP/UDP and he didn't see a
differnece.

David stated that all you need is a filter that puts RTP elsewhere.  Then
you are guaranteed to have the path switch.

Fred Baker said it depended on how probing was done; suppose the 
probe was an RTP packet?  However, there was another possibility;
if a different DSCP was used.  The topology might depend on the DSCP.

Routes change over time, things fail and restore.

Colin said it would only work if RTP packets were sent, and there
was strong pushback from AVT to not use RTP for this.

Allison thought there was an RTP NOP; Colin said there was a NOP
draft under discussion.  Wouldn't that be a possible manner of probing?
Colin stated that he has no problem with marking RTP traffic, but
this use would warp the architecture.

Fred thought another way forward might be to look at the implication
of probe traffic on other traffic.  You have admitted traffic you
would like to maintain.  The concern he has is that additional
(probe) traffic might preturb the already admitted traffic and hurt
service for a different time.

Josef said that's why they wanted to use a very lightweight RTP flow.
A no-op or something similar.

Magnus thought this might cause a preemption.  Josef said to look
at the draft - that's why there are two levels.  One as an early
indication of congestion, to stop permitting new traffic.
There is a level between stop admitting and preemption.

Another concern is that the threshold would depend on the type
of traffic carried;  however this draft assumes you own a DSCP,
and don't expect other types of traffic in service classes.

Colin asked if there were going to be different code points for
voice, video, tcp? 

Allison said that we seem to have gotten past fine points and worked
up to big points, which seems to be the way the IETF does things.
It's important that this discussion goes on but we are out of time;
maybe the intersted parties could linger afterwards to discuss the
issues, and also discuss them on the list.

Allison asked David Black to shepherd the discussion; would like
closure at "tree level" than "document level".  David said
that he would, and in his view the "tree level" is that
the assumptions made by this draft don't match AVT and MMUSIC concepts.
Allison said it's an important problem, and we need to work
on it.  [xxx: the first is, is it this draft?]
(Editorial comment by Allison:  no, the first is still, the
concepts...)
=====================

5. Sally Floyd 
===
draft-floyd-ecn-alternates-01.txt

Sally Floyd quickly discussed the ECN alternates draft --
what you need to consider if you want to specify a new ECN
behavior.  She would like this to be not just her draft,
but an official WG document, so she can get out of the
business of consulting on ECN.  She discussed the problem:
how do routers know what to do; how do you deal with incremental
deployment problems; can the new version co-exist with the
old; and how you can evaluate alternate ECN semantics
(see the slides for details).   There has been one
round of feedback and revisions were minor.

Bob Briscoe said that he agreed with everything in the draft.
He thought that Sally said that the ECN nonce is not a standard part of
the default semantics, but informational.  Sally replied that
3162 includes code points for ECN nonce, but doesn't include all details.

Bob said that he is sensitive to this, because he is intending to
write an alternative that uses codepoints for a different nonce.

Allison said that the intent is to bring nonce to proposed standard;
she thinks we need it.  If you have a solution that improves upon it,
this is valuable to know.  Please contribute, but soon.

The nonce was put out as an Experimental (as Sally said the bits
were in the Standard), just as ECN was first Experimental and then
went to Proposed Standard.  There is a window of discussion about
its effectiveness.  Bob mentioned his SIGCOMM paper on use of the
nonce bits.  We encouraged his draft.  (Editorial since this
link was not provided at the time:
http://www.acm.org/sigs/sigcomm/sigcomm2005/paper-BriJac.pdf).

Sally said that the ecn alternates document was needed;
there are alternate proposals that she hears about and
this would save her work responding to them; she didn't think it
would cause a flood of documents, or imply in any way that documents
should or should not be approved.

Allison asked if we should take a hum. 
Him to see if people would like to adopt it for guidance to world.
"Hum if you think we could adopt as a working group document"
 <loud>
Hum if oppose
 <none>
Allison declares consensus to adopt as a working group document.

Sally asked if the document should be informational; Allison thought it
would be fine.

Aaron Falk asked about the document status; he thought the document
feels like a BCP instead of informational.  Allison thought it could
be.  It could be replaced as we learn and evolve.  Sally said that it
could, but she hoped it would not need to be replaced.  Allison
thought Gorry gave good a good test: if you would want to keep the
same number for new advice.  Notetaker's report: it was not clear 
we came to closure, think BCP was the general feeling]
=====================

6. More Sally...
===
draft-ietf-tsvwg-quickstart-00.txt

Sally then discussed the QuickStart draft (see slides for details).
In summary: why not send data all at once if have super underutilized path.
It's an "anti-congestion control" mechanism.  All promised changes
have been made.

Open issues:
* retransmitting SYN packets.
  Is there any implementation that would react badly if TCP sender
  retransmitts SYN packet with different ISN?
* there are four free bits: use QuickStart nonce?
  Sally would like to have a QuickStart nonce, the co-authors are neutral.
  It's a way to get around the receiver lying.

Randall Stewart noted that if he was going to scam QuickStart as a
receiver, he would just always reduce the amount by 10 Kbits, so the
sender wouldn't look at the nonce.  Sally noted that if the sender
was very conservative, or had reason to be suspicious, it would only use
QuickStart if the original request was approved.

Matt Mathis asked about handling the case where the request was
reduced twice.  Sally said that the nonce doesn't give any protection
once the rate is reduced.  Matt said that the random value might not
need to change [xxx?].  Sally said they gave it a lot of thought
but couldn't come up with any easy answer.

?3: if have few extra bits, if router indicates requested rate was way lower...
get "that's really a small bit for this network".
don't think we came up with that one, none seems as pressing.

Sally said that Joe Touch offered to help improve the section on tunnels.
The remaining items are a revision for tunnels, to decide about using
a nonce, and any other feedback the group would provide.  Please send
feedback.

Sally asked if there was a group of people that wanted to brainstorm
with her on the draft... send email.  Allison noted that there are a
lot of "bright noncers" in the group; Bob Briscoe and Gorry Fairhurst
offered to be among the quick start nonce think tank to resolve this.
=====================

7. Mark Handley
===
Internet Congestion Control Research Group (ICCRG)

Mark Handley gave a brief presentation forshadowing his plenary
talk tomorrow on a proposed research group in the IRTF:
The Internet Congestion Control Research Group.

There is a lot of work going on in improving congestion control:
to better utilize "long fat networks", for realtime, for wireless
and recovering from non-congestive packet loss.  There are problems
being faced by research networks today.  However, there is no
desparate need, and we have the opportunity to "do it right".

How do you get all right people together to decide on really good
ideas and map them into the real world?  The IETF is not good at
long-term discussion, and there doesn't appear to be another good
venue.  So, why not the IRTF?

See
<http://nrg.cs.ucl.ac.uk/mjh/iccrg>
<http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg>

Tell Aaron Falk (IRTF chair) if you think it is a good or bad idea.
=====================

8. Doug Leith
===
draft-leith-tcp-htcp-00.txt

Doug discussed his H-TCP draft.  Mark's talk was a good introduction.
Doug gave motivation and background (see slides for details).
He thought it was time to re-open discussion on congestion control
algorithrms; there are two RFCs out there in this space that
have gone through and seem to have stalled. [Editor: I think this
refers to the deployment situation of RFC 3649 but I'm not sure...]

Doug's guiding principle is to make the smallest changes to make
things work again.  He thought that was vital.

H-TCP adjusts the increase rate as a function of the time of last
backoff; and it is symmetric.  The authors have been working on
H-TCP for a while; there was an implementation at the Stanford
Linear Accelerator Center (SLAC) in 2004 and the Hamilton Institute
in 2005. The initial internet-draft is out there for comments.  Please read
it and comment.

Allison said that TCPM asked that discussion on this draft happen here.
She asked for a hum if there was interest in thorough reading and
commenting:
 <moderate hum>
Allison declared that there was interest, so the authors should return.
[Notetaker comments: presumably after starting discussion on the ML :);
Editor replies: yes, you are right!].
=====================

9. Bob Briscoe
===

Bob Briscoe reported on two drafts that execute an idea that goes
back to the INTSERV days: providing a controlled load service,
using distributed measurement-based admission control.
See the slides for detail.

The two drafts:
* a use case:  draft-briscoe-tsvwg-cl-architecture-00.txt
* a PHB: draft-briscoe-twvwg-cl-phb-00.txt

This idea relates to RT-ECN, and RMD (in NSIS).  The idea started
in theory, and then moved to engineering.  IETF protocols and
functions [RSVP, DSCP, ECN] are used to implement the idea, but
it breaks the original architectures.

The environment is one where congestion events are rare, and you want
to deal with them, but you'd like a cheap mechanism, and not have
to deal with them all the time.

The solution builds on IntServ over DiffServ.  RSVP is used in the
examples, but NSIS could be used in the future.
Start with a non-controlled-load base, and overlay with IntServ
over the edges.  The egress nodes identify aggregates; identifiers
are not carried in the traffic.  There is microflow signalling
across the network, but nodes in the middle ignore it.  Impementation
of this idea may encourage ECN.

Bob walked through some examples, which without loss of generality,
assume some flows are already present in the network.

The controlled load service is end-to-end, and Bob believes it is
more robust than IntServ, since there is no flow signalling or state
in core or border region.  They've been working on it at BT since 2000.

Allison asked if it was aimed at commercial networks; Bob replied
that BT is working on it for its own network.

To move forward two things are needed:
 - agreement on PHB (either new or an addition to an existing one)
   Would need to consider if this is a working group draft eventually.
 - extension for RSVP for opaque ECN fraction object

Fred Baker had a couple of questions and a comment.

Question1: Does this only apply where the law of large numbers applies?
Bob said yes; Fred said that the places where I find myself most worrying
are places where the law of large numbers doesn't apply.  You should make
it really clear in the draft that this is an assumption.

Question2: you want to have somewhere in the RSVP message the rate of ECN
you are seeing in at least some of scenarios we are looking at... domain
seeing ECN will also see loss.  Is there value in having the loss rate too?
Bob commented that loss is hard to measure in the middle of the network,
and if you have loss you'll also get high ECN markings.

Comment: On numbers carried forward and opaque ECN: we have numbers like
that in adspec, maybe we should extend adspec?

Sally commented about loss and ECN.  3168 strongly advises routers not
to use ECN when marking rate is high, but drop packets instead --  as a way
to not cheat about ECN.  Keep that in mind.

Fred said that as one of the people that makes the routers that would like
to implement ECN, that's really hard.  

The discussion got to a level of detail about ECN that was very interesting
and the notetaker lost details.
Allison had to cut off discussion as we were out of time for this topic.
If the area is split, maybe there will be more breathing room for more of
this detail (where implementation/deployment meet ECN, diffserv and intserv).

The notetaker points out that there is an audio record for anyone who needs
to bring this back.

The Chair reports that there was the group discuss chartering of these
documents as yet; there was too much to do just understanding the basic
goals and framework.
=====================

10. Mark Watson
===
draft-watson-tsvwg-fec-sf-00

Mark Watson discussed a draft based on work done in 3GPP: a generic
framework for FEC for media flows.  The folks at 3GPP felt that
it was an idea that had broad applicability so they brought it to
the IETF to see if it could be used more broadly.

Mark stated the objectives (see slides for detail): extend the
RMT FEC building block to streaming media, provide FEC without
any assumption about FEC codec, and avoid the proliferation of
FEC codes.  The proposal is for an FEC streaming layer above
UDP that provides protection for a "bundle" of UDP flows.

Mark went on to describe the idea in more depth.  Two things
this note taker thought were worth putting here:  FEC considers
symbols to be received or lost.  If two packets form one symbl,
losing either packets makes the symbol unintelligable and you lose.
The scheme provides "close to backwards compatability": if you
understand the framework, you can read the underlying data packets
even if you don't understand the particular FEC coding.

Mark had a number of questions for TSVWG:

* When bringing this work to the IETF, they thought of AVT, but
the work is not specific to RTP.  They thought of RMT, but the
work is not specific to multicast, although that is a use case.
Hence this presentation in the more general group: do we need
this kind of generic approach to streaming?  In 3GPP, they
evaluated 2733 and ULP, but decided they were not appropriate.

* Is this the right approach?

* The relationship with ULP work (in AVT) -- probably different applicability.

* venue for further work?  AVT, RMT or TSVWG?

Matt Mathis asked how strongly this work was tied to UDP, and not a
more general IP mechanism?  The answer was not very strongly tied.

Stefan, co-author said that UDP was used for practical reasons; it was easy
to build on top of UDP.  It could be built on a lower layer, but then there
are other issues.

Allison thought that you could provide this on DCCP or DTLS.

Magnus thought the main requirement was for use in multicast environment.  

Allison asked if others could imagine use cases, and the value this would
provide; or imagine implications in other transports.  She has had private
discussions with Mark, and it seems that TSVWG is more relevent than
a specific group.  Is there enough energy here or is it big enough that
it is too big for here?

Since we were now late for the coffee break, she said to think about this
question, and she or Mark W.  would re-ask it on the mailing list.

With that, the meeting was brought to a close.

-- 30 --

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg