[Tsvwg] IETF 59 minutes - amendable

[Allison Mankin <[e-mail]>]

Here are the TSVWG notes/minutes - thank you to Matt Zekauskas for
very kind scribing. 

Corrections to chairs - we are allowed to send some small amendments
after proceedings go online.

And we have some work to do, these remind us,

Allison

------- 


The Transport Working Group (TSVWG) Meeting had a two hour slot at
IETF 59.  Matt Zekauskas took excellent notes (thank you).  
Allison Mankin and Jon Peterson chaired TSVWG.
This was the birth of the TCP Maintenance and Minor
Extensions Working Group (TCPM )and our slot was shared with TCPM,
which used the second hour and which has separate minutes.

The meeting was SRO, hard to find seats.

First was agenda-bashing.  We had planned an introductory discussion 
of a new effort, a draft that attempts to do a datagram version of
TLS.  This would be beneficial for applications that require an
unreliable service, but still desire the services provided by TLS.
The work is by Nagendra Modadugu and Eric Rescorla.

The impact of the formation of the split of TCPM from TSVWG is more
room in TSVWG for discussions of drafts - more time between the two
working groups.  The TCPM working group is chaired by Mark Allman
and Ted Faber, Ted to run the miniature, birthday TCPM meeting following
TSVWG in the slot.

The TSVWG charter deliverables were updated following the split and
the proposed new ones were presented for discussion (having also  been 
given some review by the IESG).  They included (by clerical accident)
a 2009 deadline for variable rate TFRC; this was not intended to mean
that Sally Floyd has a super-laidback task :)

The charter more or less retained tasks already in play, notably kept
some TCP work that was already in WGLC call or beyond rather than moving
it to TCPM.  We asked for comments and review. 

New work is to be considered.  Some new discussions are under way and
were on the podium during the session.

- --------------
fred baker
mlef w/o capacity admission does not satisfy MLPP requirements

draft-baker-tsvwg-mlef-concerns-01.txt

military network policy being proposed in civilian networks, and 
impl in Internet.

multi-level preemption & precidence.
  imagine sarin gas in subway station.  want fire, police, ambulance...
 person coordinating needs to talk, but lots of folks already on phone.

imagine ATC for F-18's across med and run out of gas.  need to get through to i
talian airstrip, and 
they are on phone... opes.

make services available on internet that would alow this.
US comm services for civil networks...
  preempt telephone, voip, might apply to video.
 --
important characteristics
  ...handset already in use
  other is network that is already busy.  [need to gain capacity]
 --
DISA Assured Service [DISA = US Defense Info Systems Agency]
  have a set of drafts.
  talk about MLEF, specifically talking about one of these drafts
  builds on RFC 3246 EF PHB.
    assigns different code points to different packets based on precidence.
    drops in preferential pattern.
  no call admission!
  service description for assured service doesn't require call admission. 
  but as a vendor
random military in random countries (and thier systems integrators) - the specs
 that they are 
reading saying the only thing they have to do is drop traffic.  can we talk?

issue for EF as well.  need a way to negate a call or don't do right now.

steve silverman: some kind of call management or admin control is 
complementary to MLEF.
  MLEF is l3 vs 
session control
when you say not required... it might be on piece of the puzzle
 --
what's defined already?  h323

dale: can't sell product to customers, if they can't figure out how to be able 
to make people not 
place a call.  doesn't have to work, only has to get salesmen in door.  so they
 have concept of 
gatekeeper.  when # gets to high: stop.  configure on basis of calls to another
 gatekeeper or...

don't want to overrun any single link in network.
it's a heuristic.  could be described as hack.
what is done in SIP proxy as well.
  counts calls, or instances of bw units, and when 0, say "stop".

ok... if 20% of bw.  but, if want as much utilization of links as can get, and 
willing to take down 
important calls for more important calls, need something better.

rfc 3312 describes something more specific.
- --
pix of problem.

control problems divorced from data paths.  so can be completely different
place.
harvard prof in japan, interact as if local.  that's an extreme example, 
but it's an example.

concern: dropping random packets from session going by in absence of capacity(
(not just call) 
admission... very inadequate.
inadequate to protect lower priority cals...  can affect all low prio calls.
vs just one would be 
enough.  (dropping more than a few % is not good).  are improved codecs, that
move line.  but don't fix

dropping calls based on MLEF induced loss... don't know how to do it.
  how make distributed system drop one call.  can drop none, or all...

think approach is inadquate.

baker/pold proposal for mlpp, different draft.  imagine that we use RFCs 
already defined.  *So proposal is to architect from IETF standards
already well understood*

network bandwidth admission: use existing specs.  use control plane signaling, 
then diffserv in 
data plane.  do that as needed.
 --
walk through draft quickly...

don't need rsvp everywhere.  need at end points.  
and at bottleneck link endpoints.

pstn interfaces become endpoints to IP system.
 --
diffserv in data plane.  had dinner with DISA folks, want to use 
multiple code 
points.
concern about measurement-based, and voice activity detection to approximate...
 want to be able to 
improve quality of call.  statsistical based?
  but fundimentally want bw for call in first place
 --
aaa: use them.
 --
one interesting thing: VPNs in our context.
  nw composed of tunnels.  (or type 1 encription association)

  can bring individ reservations to tunnel end points, and then
   size tunnel for aggregate
 --
RFC3175 - RSVP aggregation.  suggest that use it.

what want:  guidance and comments from IETF.  if missing something need to know
 it.  and the 
assured service folks need to know whot

henning schulzrinne: didn't mention NSIS efforts.  not close to baked?

because not baked.  don't care what signalling proto is, just want it to work.

Alan O'Neil: extend scope a bit.  in wireless networks, as hopping, need to do 
admin control mulitiple types.

yeah, something that works in MANET networks.  in RSVP (built into spec) whenr
route changes, need 
to fire that path message down and the RESV back and ensure that have capacity.
  and if don't 
that's a place for preemption to happen.

allison mankin: little concerned about preemption arch.  not sure that really h
ave 
thatt in our protocols, 
as opposed to local implementation-specific usage.

have posted internet drafts in SIP

allison: yes, but not something that you've adopted.  and not necessarily
somehing going to adopt. 
not something have taken on.

ok.  part of debate.  btw, at this point, there is a fair amount of VOIP
happening (not all 
military) and people would like to see this capability.  
passing laws to this effect.

q: as author of two SIP internet drafts calling for preemption that have both
gone through WGLC, 
curious about what you mean about "not something taken on".

allison: don't believe this actually describes accomplishing
all that is needed to preempt and priority media resource
usage - it gives capabilities for describing and requesting
preemption at signaling level.

henning: differnet from resource prio... 3rd party tells 
low prio call tear down call.  this 
is more like aaa yank existing call expeditiously.

allison: not created that kind of my structure.

jon peterson: two evils:
1. random amounts drop until people all hang up
2. individual calls sniped in a more organized fashion.

prefer (2), not that both just evils.  I agree with most of stuff on screen.

q: (SIP guy) but if domain chooses to do sniping randomly should support that.

henning: right thing is not to worry about SIP level release,
voice+text, just because no bw for voice doesn't mean lose text.
or maybe just quiet whole time

so maybe reason not to do in SIP level.

rsvp level indications... and end systems can decide for self.  or switch.

fred: if policy of network, fine.  if policy is of cmdr in chief, you don't get
 to make that call.

 --
jon: disposition that there is some interest, and discussion on mailing list.  
clearly other views. 
the message is probably right one that's expressed here

a: usage of existing specs, and esp. rsvp arch is very appropriate here.
happy to hear it.

=============
kwok

draft-baker-diffserv-basic-classes-02.txt

basic guidelines for config of diffserv usage classes.

discussr basic points, can read for details.  guideline on how to configure qos
 me
chanism, so service 
differentiation offered by network.

apps use dscp to indicate req'd service class needed to support packet/traffic 
treatment.
service classes are e2e. different grom PHB.
 so need to make sure marks at end of tunnels are right.

think existing 4 phb's are sufficient.  class selector, AF, EF

 --
classes
  simplify to a few classes
 --
packet cube graph based on customer input
see IP phone
    SKYPE (ip phone)
    HTTP
    FILE SHARING

can see different.
 --
so it's all good.  easier to deploy

Suggestion to make this a BCP.

customers asking for this kiind of guideline

make this a TSVWG item, in form of BCP?.


allison: show of hands, how many reviewed?
  about 2.

  Allison found it an important kind of document.  There were
  divergent views by the diffserv WG about whether to do something like
  this.  It's probably true that we reached a point where this it is
  important to do something like this.  But not without getting a lot of
  review and comments and discussion, paying attention to the specifics.
  It's a concern that noone read it.  We need expression of willingness to
  look at it and discuss it.

Allan O'Neil: independent vendor view: absolutely req'd.

Kwok: by making WG item, get more inputs.  welcome different view.

a: hum about interest in working on this.  
hum if interested in doing further work
and will put energy into working on it.

1/4 size hum.

allison: pretty good, go to discussion on ML.  Must have three
people raise hands to review (who were involved in DS).

dlb (david l black), allan o'neil (AO)

allison: for third we'll draft one.


=======================================================
[e-mail]

congestion notification for real-time traffic

how do flow control and admission control for real time apps/flows.
copying concept for TCP, ECN.  use the same bits in IP header used for tcp.
6&7 of DS field in IP packet.
 --
this does not impact existing ecn stuff.

meter real-time flows using something similar to policer...
   when rate hits level, mark one of ECN bits.  note congestion.

meters/markers can be deployed selectively

does requre real-time flows to be separated (different treatment).
response is req of application.
  slow down, stop sending packets, stop admitting.
- --
use for admin control... deny setup for new calls. and rate control.

henning: concern that this ieven more of a kludge than fred's gatekeeper model.
  don't know if 
markings will be on same path as new call admitting.  cong from one call ... de
pends on path.

yes, to use this mechanism, need to send probe packet or call packet on same 
path as new stream. 
to discover at time when would admint.

sally floyd: comment - ECN is not just for TCP traffic.  is stand
  DCCP using, RT flows for UDP will use it.  the default semantics for
  ECN are default semantics, router doesn't check for TCP.  the plan is that th
ere should be able 
to be alternate semantics, signalled by DSCP, but not by protocol field.

  I'm fine with that.  in my draft, am suggesting that that's what would happen
 in implementation.. 
would have different traffic types.

fred: pepole already complain that charge for equip... how complicated do we wa
nt to make this...

already have meters in routers

ECN isn't managed by a meter, it's managed further dwn way.

how handle MPEG4?  500 channels of TV.  all showing large green field of fav sp
ort.  15 min, 80 kb. 
15 min boundary, adverts show up, all simultaneously jump to 800 kb.  admitted 
based on 80kb, how do that
that?

don't mix mpeg 4 and voice in same policy.

fred: yet another thing for video.  please make something work for all?

suggesting one for different classes

henning: same problem.  voice conference.  participants silent, on line... 
meas-based admin control 
not a new topic.  hasn't gotten traction for a variety of reasons.  delays, 
sttisical
papers deal with it.  unless make restrictive assumptions, run into problems.  
don't get gty. 
"mostly feels good", work in some fraction, but..

doing admission control on aggregate levels.  not single flow.  can engineer
for supression etc, of 
single flow.
can't engineer for average.  those techniques already used today.
don't need to be that precise.

q: to tie together fred & henning.  going to make two hacks to make something w
ork.  don't want 
meter in router to set policy for which calls going to drop.  green field situa
tion.... warn way 
over bw, renegotiation, bw drops... get into see-saw behavior.  need app-level 
gatekeeper model to 
do this.

that's what suggesting.  nw provides an indicator.  doesn't have to be spontati
ons

propose: wg look at it to see if useful mechanism.  request as be wg item for d
iscussion & 
evolution.

jon: given concerns raised here, can profit for a bit more of discussion and co
nsensus before hum. 
bring to list and resolve concerns.

==================================================================
==================================================================
==================================================================
==================================================================
==================================================================
==================================================================
tsvwg time over, mr. faber up for the TCPM Working Group!!!

------- End of Forwarded Message


_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg