RE: [Tsvwg] IETF 59 minutes - amendable

[Branislav Meandzija <[e-mail]>]

I wouldn't mind reviewing this. I've read the first couple of  drafts and have been trying to encourage use the recommendations in IEEE 802.20 (mobile broadband wireless access). The one major comment we got in .20 was to reduce the number of classes to 4.

Branislav

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On 
> Behalf Of Joe
> Touch
> Sent: Friday, April 02, 2004 9:02 PM
> To: Kwok Ho Chan
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Tsvwg] IETF 59 minutes - amendable
> 
> 
> 
> 
> Kwok Ho Chan wrote:
> 
> > Allison:
> > Can we add the result and action items of the 
> > draft-baker-diffserv-basic-classes-02.txt
> > presentation to the WG minutes?
> > 
> > I believe that the chairs have indicated 
> > draft-baker-diffserv-basic-classes-xx.txt will
> > become a TSVWG WG work item.
> 
> So far, there have been only two of the desired three reviewers 
> requested for this doc. It would be useful to see some "rough 
> consensus" 
> from the community before acting on the request of the chairs or ADs. 
> The review below is intended to precede such a decision, at 
> least as far 
> as I could tell at the meeting.
> 
> Joe
> 
> > With Action Items:
> > 1. The co-authors is to publish an updated version, 
> > draft-baker-diffserv-basic-classes-03.txt,
> >     for the official reviewers to review.  (We are in the 
> process of 
> > doing this).
> > 2. Reviewers to provide comments.
> > 3. Next version based on review comments is to be named 
> > draft-tsvwg-xxx-00.txt.
> > 
> > Please verify and add to the official published minutes if possible.
> > 
> > And thank you very much for taking the minutes, Matt.
> > 
> > Thanks!
> > -- Kwok --
> > 
> > 
> > At 03:03 PM 4/2/2004, Allison Mankin wrote:
> > 
> >> 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
> > 
> > 
> > 
> > _______________________________________________
> > tsvwg mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> 


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