2.7.17 Transport Area Working Group (tsvwg)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-09

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: tsvwg@ietf.org
To Subscribe: tsvwg-request@ietf.org
In Body: subscribe email_address
Archive: ftp://ftp.ietf.org/ietf-mail-archive/tsvwg/
Description of Working Group:
NOTE: special mailing list for questions related to implementing and using SCTP.

E-mail Address: sctp-impl@external.cisco.com To subscribe: mailer@cisco.com In Body: "subscribe sctp-impl "

The Transport area receives occasional proposals for the development and publication of RFCs dealing with Transport topics, but for which the required work does not rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and a single BOF would not provide the time to ensure a mature proposal. The tsvwg will serve as the forum for developing these types of proposals.

The tsvwg mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion.

The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose.

Goals and Milestones:
Done  Updates to RFC 793 to resolve conflict between diffserv and TCP interpretation of IP Precedence submitted for publication as Proposed Standard
Done  Addition to RFC 2018 to use TCP SACK for detecting unnecessary retransmissions submitted for publication as Proposed Standard
Done  Submit I-D on TCP Congestion Window Validation to IESG for consideration as a Proposed Standard
Done  Submit I-D on Computing TCP's Retransmission Timer to IESG for consideration as a Proposed Standard.
Done  submit revised ID for ECN to IESG for consideration as a proposed standard
May 01  submit ID on TCP framing by a shim to IESG for consideration as a proposed standard
Done  submit ID on UDP-lite to IESG for consideration as a proposed standard
Done  TCP-Friendly Rate Control (TFRC) unicast congestion control algorithm submitted to IESG for consideration as a proposed standard
Done  submit ID for adding and deleting addresses from an existing associations in SCTP to IESG for consideration as a proposed standard
Jun 01  submit ID on flow control for individual streams in SCTP to IESG for consideration as a proposed standard
Jun 01  submit ID for SCTP unreliable transport mode to IESG for consideration as a proposed standard
Jun 01  submit ID for SCTP API for consideration as an informational RFC
Jul 01  ECN Nonce procedure submitted to IESG for consideration as
Dec 01  TCP-Friendly Variable Rate Control unicast congestion control submitted to IESG for consideration as a proposed standard
  • - draft-ietf-tsvwg-tcp-nonce-04.txt
  • - draft-ietf-tsvwg-addip-sctp-08.txt
  • - draft-ietf-tsvwg-sctpsocket-07.txt
  • - draft-ietf-tsvwg-sctpimpguide-10.txt
  • - draft-ietf-tsvwg-udp-lite-02.txt
  • - draft-ietf-tsvwg-tcp-mib-extension-04.txt
  • - draft-ietf-tsvwg-tcp-eifel-response-04.txt
  • - draft-ietf-tsvwg-prsctp-03.txt
  • - draft-ietf-tsvwg-newreno-02.txt
  • - draft-ietf-tsvwg-dsack-use-02.txt
  • - draft-ietf-tsvwg-slowstart-00.txt
  • - draft-ietf-tsvwg-tcp-frto-01.txt
  • Request For Comments:
    RFC2861 E TCP Congestion Window Validation
    RFC2883 PS An Extension to the Selective Acknowledgement (SACK) Option for TCP
    RFC2988 PS Computing TCP's Retransmission Timer
    RFC3042 PS Enhancing TCP's Loss Recovery Using Limited Transmit
    RFC3168 PS The Addition of Explicit Congestion Notification (ECN) to IP
    RFC3309 PS Stream Control Transmission Protocol (SCTP) Checksum Change
    RFC3390 PS Increasing TCP's Initial Window
    RFC3436 PS Transport Layer Security over Stream Control Transmission Protocol
    RFC3448 PS TCP Friendly Rate Control (TFRC):Protocol Specification
    RFC3517 PS A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP
    RFC3522 E The Eifel Detection Algorithm for TCP
    RFC3649 E HighSpeed TCP for Large Congestion Windows

    Current Meeting Report

    The Transport Working Group (TSVWG)
    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. It was the birth of the TCP Maintenance and Minor 
    Extensions Working Group (TCPM).  The 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 
    has a very easy 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
    military network policy being proposed in civilian networks, and impl in 
    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 
    imagine ATC for F-18's across med and run out of gas.  need to get 
    through to italian 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 
    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 
        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 
    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 
    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 have 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 
    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 
    q: (SIP guy) but if domain chooses to do sniping randomly should support 
    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 
    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.
    basic guidelines for config of diffserv usage classes.
    discussr basic points, can read for details.  guideline on how to 
    configure qos mechanism, 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
      simplify to a few classes
    packet cube graph based on customer input see IP phone
        SKYPE (ip phone)
    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.
    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 
    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 ... depends 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 there 
    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 want 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 
    sport.  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 
    q: to tie together fred & henning.  going to make two hacks to make 
    something work.  don't want meter in router to set policy for which calls 
    going to drop.  green field situation.... 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 
    propose: wg look at it to see if useful mechanism.  request as be wg item 
    for discussion & evolution.
    jon: given concerns raised here, can profit for a bit more of 
    discussion and consensus before hum.  bring to list and resolve 
    tsvwg time over, mr. faber up for the TCPM Working Group!!! 


    MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements
    Congestion Notification Process for Real-Time Traffic
    Configuration Guidelines for Diffserv Service Classes
    F-RTO Update