Last Modified: 2004-02-09
E-mail Address: email@example.com
To subscribe: firstname.lastname@example.org
In Body: "subscribe sctp-impl
The Transport area receives occasional proposals for the development
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
The tsvwg will serve as the forum for developing these types of
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
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
Request For Comments:
RFC Status Title 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.
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
...handset already in use other is network that is already busy. [need to
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
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
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
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
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
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?
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
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
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.