From exim@www1.ietf.org Fri Apr 2 16:45:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03445 for ; Fri, 2 Apr 2004 16:45:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WTf-0002uZ-Tw for tsvwg-archive@odin.ietf.org; Fri, 02 Apr 2004 16:45:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LjRAb011192 for tsvwg-archive@odin.ietf.org; Fri, 2 Apr 2004 16:45:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WTP-0002jH-Pg; Fri, 02 Apr 2004 16:45:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Uud-0006uW-9M for tsvwg@optimus.ietf.org; Fri, 02 Apr 2004 15:05:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25523 for ; Fri, 2 Apr 2004 15:05:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Uua-0006hJ-00 for tsvwg@ietf.org; Fri, 02 Apr 2004 15:05:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UtZ-0006a4-00 for tsvwg@ietf.org; Fri, 02 Apr 2004 15:04:07 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9UtG-0006Td-00 for tsvwg@ietf.org; Fri, 02 Apr 2004 15:03:46 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9UtG-00021l-Th for tsvwg@ietf.org; Fri, 02 Apr 2004 20:03:46 +0000 To: tsvwg@ietf.org Reply-To: mankin@psg.com Date: Fri, 02 Apr 2004 12:03:46 -0800 From: Allison Mankin Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Tsvwg] IETF 59 minutes - amendable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , 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. ======================================================= babiarz@nortelnetworks.com 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 tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Apr 2 18:05:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11250 for ; Fri, 2 Apr 2004 18:05:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xhb-0005xv-97 for tsvwg-archive@odin.ietf.org; Fri, 02 Apr 2004 18:04:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32N3jW0022724 for tsvwg-archive@odin.ietf.org; Fri, 2 Apr 2004 18:03:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xd6-0002z7-Ix; Fri, 02 Apr 2004 17:59:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xc5-0002ta-MA for tsvwg@optimus.ietf.org; Fri, 02 Apr 2004 17:58:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10864 for ; Fri, 2 Apr 2004 17:58:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Xc3-0005UL-00 for tsvwg@ietf.org; Fri, 02 Apr 2004 17:58:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Xb4-0005Mo-00 for tsvwg@ietf.org; Fri, 02 Apr 2004 17:57:12 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Xa4-000582-00 for tsvwg@ietf.org; Fri, 02 Apr 2004 17:56:08 -0500 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i32MtaJ00665; Fri, 2 Apr 2004 14:55:36 -0800 (PST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQ4CL6HW; Fri, 2 Apr 2004 14:55:36 -0800 Received: from tweedy.nortelnetworks.com (tweedy.engeast.baynetworks.com [192.32.135.156]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D826JNZY; Fri, 2 Apr 2004 17:55:33 -0500 Message-Id: <6.0.3.0.0.20040402174202.03727790@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 02 Apr 2004 17:55:00 -0500 To: mankin@psg.com From: Kwok Ho Chan Subject: Re: [Tsvwg] IETF 59 minutes - amendable Cc: tsvwg@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , 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. 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. > > >======================================================= >babiarz@nortelnetworks.com > >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 >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sat Apr 3 00:05:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23731 for ; Sat, 3 Apr 2004 00:05:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9dLG-0000no-88 for tsvwg-archive@odin.ietf.org; Sat, 03 Apr 2004 00:05:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3355ErE003060 for tsvwg-archive@odin.ietf.org; Sat, 3 Apr 2004 00:05:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9dL3-0000eW-4U; Sat, 03 Apr 2004 00:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9dKX-0000X4-GZ for tsvwg@optimus.ietf.org; Sat, 03 Apr 2004 00:04:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23646 for ; Sat, 3 Apr 2004 00:04:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9dKU-0005xH-00 for tsvwg@ietf.org; Sat, 03 Apr 2004 00:04:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9dJc-0005ql-00 for tsvwg@ietf.org; Sat, 03 Apr 2004 00:03:34 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1B9dJD-0005kB-00 for tsvwg@ietf.org; Sat, 03 Apr 2004 00:03:07 -0500 Received: from isi.edu (lsanca1-ar42-4-61-186-000.lsanca1.dsl-verizon.net [4.61.186.0]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3352VN06219; Fri, 2 Apr 2004 21:02:31 -0800 (PST) Message-ID: <406E4565.4020007@isi.edu> Date: Fri, 02 Apr 2004 21:02:29 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kwok Ho Chan CC: mankin@psg.com, tsvwg@ietf.org Subject: Re: [Tsvwg] IETF 59 minutes - amendable References: <6.0.3.0.0.20040402174202.03727790@zbl6c002.corpeast.baynetworks.com> In-Reply-To: <6.0.3.0.0.20040402174202.03727790@zbl6c002.corpeast.baynetworks.com> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig44D10F976632DAB0F34995B6" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44D10F976632DAB0F34995B6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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. >> >> >> ======================================================= >> babiarz@nortelnetworks.com >> >> 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 >> tsvwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/tsvwg > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --------------enig44D10F976632DAB0F34995B6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAbkVrE5f5cImnZrsRAhNpAJsGX72fGOr8MUas1oHSbDbgjvv7+ACg/kNO iP3p8I1Rh8L6hIA7G4vRvYw= =AlWA -----END PGP SIGNATURE----- --------------enig44D10F976632DAB0F34995B6-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sat Apr 3 16:38:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06438 for ; Sat, 3 Apr 2004 16:38:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9sqH-0007IZ-1U for tsvwg-archive@odin.ietf.org; Sat, 03 Apr 2004 16:38:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33LcHpa028056 for tsvwg-archive@odin.ietf.org; Sat, 3 Apr 2004 16:38:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9sq1-0007HK-LO; Sat, 03 Apr 2004 16:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9spA-0006gU-6q for tsvwg@optimus.ietf.org; Sat, 03 Apr 2004 16:37:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06364 for ; Sat, 3 Apr 2004 16:37:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9sp8-0000my-00 for tsvwg@ietf.org; Sat, 03 Apr 2004 16:37:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9soG-0000fl-00 for tsvwg@ietf.org; Sat, 03 Apr 2004 16:36:14 -0500 Received: from ns.arraycomm.com ([199.74.167.5] helo=bastion.arraycomm.com) by ietf-mx with esmtp (Exim 4.12) id 1B9snf-0000YN-00 for tsvwg@ietf.org; Sat, 03 Apr 2004 16:35:35 -0500 Received: from lester.arraycomm.com (lester.arraycomm.com [172.16.0.17]) by bastion.arraycomm.com (Postfix) with ESMTP id 314435E272; Sat, 3 Apr 2004 13:35:35 -0800 (PST) Received: from ARRAYCOMM.COM (vclient-16.e.arraycomm.com [192.168.10.16]) by lester.arraycomm.com (8.12.9/8.12.9) with ESMTP id i33LZQKF005649 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 3 Apr 2004 13:35:27 -0800 (PST) Message-Id: <200404032135.i33LZQKF005649@lester.arraycomm.com> From: Branislav Meandzija To: Joe Touch , Kwok Ho Chan Cc: mankin@psg.com, tsvwg@ietf.org Subject: RE: [Tsvwg] IETF 59 minutes - amendable Date: Sat, 3 Apr 2004 13:35:19 -0800 X-Mailer: CorporateTime Outlook Connector 3.3 40513 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) X-Filter-Version: 1.14 (lester) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I wouldn't mind reviewing this. I've read the first couple of drafts and h= ave 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 red= uce the number of classes to 4. Branislav > -----Original Message----- > From: tsvwg-admin@ietf.org [mailto:tsvwg-admin@ietf.org]On = > Behalf Of Joe > Touch > Sent: Friday, April 02, 2004 9:02 PM > To: Kwok Ho Chan > Cc: mankin@psg.com; tsvwg@ietf.org > 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 =3D 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. > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> 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. > >> > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >> babiarz@nortelnetworks.com > >> > >> 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. > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> tsvwg time over, mr. faber up for the TCPM Working Group!!! > >> > >> ------- End of Forwarded Message > >> > >> > >> _______________________________________________ > >> tsvwg mailing list > >> tsvwg@ietf.org > >> https://www1.ietf.org/mailman/listinfo/tsvwg > > = > > = > > = > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sat Apr 3 16:47:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06703 for ; Sat, 3 Apr 2004 16:47:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9syl-00010w-6g for tsvwg-archive@odin.ietf.org; Sat, 03 Apr 2004 16:47:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33Ll3VZ003876 for tsvwg-archive@odin.ietf.org; Sat, 3 Apr 2004 16:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9syj-0000zR-N6; Sat, 03 Apr 2004 16:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9sxw-0000ph-NK for tsvwg@optimus.ietf.org; Sat, 03 Apr 2004 16:46:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06676 for ; Sat, 3 Apr 2004 16:46:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9sxu-0001p5-00 for tsvwg@ietf.org; Sat, 03 Apr 2004 16:46:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9swv-0001hr-00 for tsvwg@ietf.org; Sat, 03 Apr 2004 16:45:10 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9swK-0001b4-00 for tsvwg@ietf.org; Sat, 03 Apr 2004 16:44:32 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9swJ-000FW7-Nh; Sat, 03 Apr 2004 21:44:31 +0000 To: Kwok Ho Chan cc: mankin@psg.com, tsvwg@ietf.org Reply-To: mankin@psg.com Subject: Re: [Tsvwg] IETF 59 minutes - amendable In-reply-to: Your message of Fri, 02 Apr 2004 17:55:00 -0500. <6.0.3.0.0.20040402174202.03727790@zbl6c002.corpeast.baynetworks.com> Date: Sat, 03 Apr 2004 13:44:31 -0800 From: Allison Mankin Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi, The meeting consensus was that we would have three published reviews of the text, followed by discussion in the mailing list. There was not consensus in the meeting to take the work on as a working group task, let alone to take the particular draft. The purpose of the reviews (reviewers note) is to stimulate discussion as well as pick up on specifics in the draft. One more note about work becoming working group items - it is a three-stage process: 1. the working group expresses strong interest in the area/topic and willingness to use cycles working on it and reviewing it. 2. the IESG and IAB review the area/topic in a re-charter review and agree it's within the charter goals. There may be a period of request for comments by the IETF and broad community too. 3. a particular draft is strongly accepted by the working group as the basis for the work to be done on the topic. Allison _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Apr 5 10:16:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02647 for ; Mon, 5 Apr 2004 10:16:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUtS-0003KF-ME for tsvwg-archive@odin.ietf.org; Mon, 05 Apr 2004 10:16:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35EG6pg012783 for tsvwg-archive@odin.ietf.org; Mon, 5 Apr 2004 10:16:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUtM-0003IQ-Uh; Mon, 05 Apr 2004 10:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUtJ-0003HG-Gi for tsvwg@optimus.ietf.org; Mon, 05 Apr 2004 10:15:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02584 for ; Mon, 5 Apr 2004 10:15:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUtH-00036T-00 for tsvwg@ietf.org; Mon, 05 Apr 2004 10:15:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUsN-0002yP-00 for tsvwg@ietf.org; Mon, 05 Apr 2004 10:15:00 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BAUrX-0002n9-00 for tsvwg@ietf.org; Mon, 05 Apr 2004 10:14:07 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i35EDSB27169; Mon, 5 Apr 2004 10:13:29 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1F3QF6P0; Mon, 5 Apr 2004 10:13:28 -0400 Received: from tweedy.nortelnetworks.com (tweedy.engeast.baynetworks.com [192.32.135.156]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D826J3RD; Mon, 5 Apr 2004 10:13:27 -0400 Message-Id: <6.0.3.0.0.20040405100724.0272f4e8@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 05 Apr 2004 10:12:53 -0400 To: mankin@psg.com From: Kwok Ho Chan Subject: Re: [Tsvwg] IETF 59 minutes - amendable Cc: "Kwok-Ho Chan" , mankin@psg.com, tsvwg@ietf.org In-Reply-To: <200404032144.i33LiXp23617@zrtps06u.us.nortel.com> References: <200404032144.i33LiXp23617@zrtps06u.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Allison: Thank you very much for the guidance. And thank you for correcting my mis-interpretation of the result. We are taking the steps (working on the draft) to get there. -- Kwok -- At 05:44 PM 4/3/2004, Allison Mankin wrote: >Hi, > >The meeting consensus was that we would have three published >reviews of the text, followed by discussion in the mailing list. >There was not consensus in the meeting to take the work on as >a working group task, let alone to take the particular draft. > >The purpose of the reviews (reviewers note) is to stimulate >discussion as well as pick up on specifics in the draft. > >One more note about work becoming working group items - it is a >three-stage process: > >1. the working group expresses strong interest in the area/topic and > willingness to use cycles working on it and reviewing it. > >2. the IESG and IAB review the area/topic in a re-charter review > and agree it's within the charter goals. There may be a > period of request for comments by the IETF and broad community > too. > >3. a particular draft is strongly accepted by the working group as > the basis for the work to be done on the topic. > >Allison _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Apr 7 07:10:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08810 for ; Wed, 7 Apr 2004 07:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAwW-0000vS-An for tsvwg-archive@odin.ietf.org; Wed, 07 Apr 2004 07:10:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37BA4SJ003523 for tsvwg-archive@odin.ietf.org; Wed, 7 Apr 2004 07:10:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAwS-0000rw-Vr; Wed, 07 Apr 2004 07:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAvX-0000Sb-AO for tsvwg@optimus.ietf.org; Wed, 07 Apr 2004 07:09:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08467 for ; Wed, 7 Apr 2004 07:09:00 -0400 (EDT) From: mbakke@cisco.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBAvT-0004Iq-00 for tsvwg@ietf.org; Wed, 07 Apr 2004 07:08:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB9gz-0003gP-00 for tsvwg@ietf.org; Wed, 07 Apr 2004 05:49:58 -0400 Received: from [61.171.215.38] (helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BB8c0-00037i-00 for tsvwg@ietf.org; Wed, 07 Apr 2004 04:40:45 -0400 To: tsvwg@ietf.org Date: Wed, 7 Apr 2004 16:47:03 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_0000446A.0000191A" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.7 required=5.0 tests=MICROSOFT_EXECUTABLE, MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Subject: [Tsvwg] Re: Hi Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0009_0000446A.0000191A Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Here is the file. ------=_NextPart_000_0009_0000446A.0000191A Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: your_file.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0009_0000446A.0000191A-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Apr 15 15:18:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15042 for ; Thu, 15 Apr 2004 15:18:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BECGR-0004bW-QQ for tsvwg-archive@odin.ietf.org; Thu, 15 Apr 2004 15:11:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FJB7LW017651 for tsvwg-archive@odin.ietf.org; Thu, 15 Apr 2004 15:11:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BECDS-0002pt-5s; Thu, 15 Apr 2004 15:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEC9U-0008FS-IC for tsvwg@optimus.ietf.org; Thu, 15 Apr 2004 15:03:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13404 for ; Thu, 15 Apr 2004 15:03:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEC9R-00021T-00 for tsvwg@ietf.org; Thu, 15 Apr 2004 15:03:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEC8Y-0001w8-00 for tsvwg@ietf.org; Thu, 15 Apr 2004 15:02:58 -0400 Received: from seahorse.shentel.net ([204.111.11.44]) by ietf-mx with esmtp (Exim 4.12) id 1BEC7a-0001qr-00 for tsvwg@ietf.org; Thu, 15 Apr 2004 15:01:58 -0400 Received: from Steve (ha24s363.d.shentel.net [204.111.29.107]) by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id i3FJ1M423490 for ; Thu, 15 Apr 2004 15:01:22 -0400 From: "Steve Silverman" To: "TSVWG" Date: Thu, 15 Apr 2004 15:02:00 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] draft-silverman-tsvwg-mlefphb-00.txt is available Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I didn't see anything on the list so here is an announcement that the MLEF draft has been submitted to the TSVWG group. Moving the topic here was the result of a discussion with Jon Peterson after the last TSVWG meeting. For those of you who haven't been following this topic, MLEF allows the division of Expedited Forwarding traffic into multiple priority classes so that higher priority classes are less affected by congestion. This function is intended for certain specific networks that can't simply provision more bandwidth. It is not intended as a replacement for congestion management via some sort of call admission or call manager but complements this option. MLEF operates at the packet level, not the call level using various Diffserv codepoints to distinguish among the various classes. Steve Silverman steves@shentel.net _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Apr 21 00:50:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23527 for ; Wed, 21 Apr 2004 00:50:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9Uc-0007CX-Qf for tsvwg-archive@odin.ietf.org; Wed, 21 Apr 2004 00:37:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L4boLu027648 for tsvwg-archive@odin.ietf.org; Wed, 21 Apr 2004 00:37:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9N6-0004Cu-OK; Wed, 21 Apr 2004 00:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9Kc-0002ki-K9 for tsvwg@optimus.ietf.org; Wed, 21 Apr 2004 00:27:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22490 for ; Wed, 21 Apr 2004 00:27:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG9KZ-0007jj-UG for tsvwg@ietf.org; Wed, 21 Apr 2004 00:27:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG9Jb-0007dK-00 for tsvwg@ietf.org; Wed, 21 Apr 2004 00:26:28 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx with esmtp (Exim 4.12) id 1BG9Il-0007Vp-00 for tsvwg@ietf.org; Wed, 21 Apr 2004 00:25:35 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i3L4LduN005319 for ; Tue, 20 Apr 2004 21:21:39 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i3L4PW9G014818 for ; Tue, 20 Apr 2004 23:25:33 -0500 Received: from motorola.com (pcwks377.ap.mot.com [10.232.1.141]) by zin05exm02.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JFG6VGMA; Wed, 21 Apr 2004 09:55:31 +0530 Message-ID: <4085F7C1.C9CC52B@motorola.com> Date: Wed, 21 Apr 2004 09:55:37 +0530 From: Reji Varghese Organization: Motorola India, Bangalore - 560 042 X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] TCP flaw threatens Net data transmissions Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit http://news.com.com/2100-1002-5195909.html?tag=nefd.hed Regards Reji Varghese _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Apr 21 01:27:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25722 for ; Wed, 21 Apr 2004 01:27:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGADG-00013U-4i for tsvwg-archive@odin.ietf.org; Wed, 21 Apr 2004 01:23:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L5NwVe004028 for tsvwg-archive@odin.ietf.org; Wed, 21 Apr 2004 01:23:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGA5b-0005xJ-QY; Wed, 21 Apr 2004 01:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGA0L-00041m-TN for tsvwg@optimus.ietf.org; Wed, 21 Apr 2004 01:10:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24314 for ; Wed, 21 Apr 2004 01:10:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGA0I-00040o-Ua for tsvwg@ietf.org; Wed, 21 Apr 2004 01:10:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG9zN-0003vw-00 for tsvwg@ietf.org; Wed, 21 Apr 2004 01:09:38 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BG9z6-0003qW-00 for tsvwg@ietf.org; Wed, 21 Apr 2004 01:09:20 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 20 Apr 2004 21:19:17 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3L58n8k001296; Tue, 20 Apr 2004 22:08:49 -0700 (PDT) Received: from irp-view8.cisco.com (irp-view8.cisco.com [171.70.65.145]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASH02474; Tue, 20 Apr 2004 22:08:01 -0700 (PDT) Date: Tue, 20 Apr 2004 22:08:48 -0700 (PDT) From: Mitesh Dalal To: Reji Varghese cc: tsvwg@ietf.org Subject: Re: [Tsvwg] TCP flaw threatens Net data transmissions In-Reply-To: <4085F7C1.C9CC52B@motorola.com> Message-ID: References: <4085F7C1.C9CC52B@motorola.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , a draft is already out and is being discussed in tcpm. Mitesh On Wed, 21 Apr 2004, Reji Varghese wrote: > http://news.com.com/2100-1002-5195909.html?tag=nefd.hed > > Regards > Reji Varghese > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Apr 21 22:01:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09895 for ; Wed, 21 Apr 2004 22:01:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGTRg-000476-BC for tsvwg-archive@odin.ietf.org; Wed, 21 Apr 2004 21:56:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M1u8ab015782 for tsvwg-archive@odin.ietf.org; Wed, 21 Apr 2004 21:56:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGTKn-0000wE-2o; Wed, 21 Apr 2004 21:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGTGL-0007oA-Uh for tsvwg@optimus.ietf.org; Wed, 21 Apr 2004 21:44:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09232 for ; Wed, 21 Apr 2004 21:44:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGTGJ-0003Vu-3o for tsvwg@ietf.org; Wed, 21 Apr 2004 21:44:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGTFV-0003Ks-00 for tsvwg@ietf.org; Wed, 21 Apr 2004 21:43:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGTEv-00039C-00 for tsvwg@ietf.org; Wed, 21 Apr 2004 21:42:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGTE7-00062H-Dd for tsvwg@ietf.org; Wed, 21 Apr 2004 21:42:07 -0400 Received: (from nobody@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M1g7xv023203 for tsvwg@ietf.org; Wed, 21 Apr 2004 21:42:07 -0400 Date: Wed, 21 Apr 2004 21:42:07 -0400 Message-Id: <200404220142.i3M1g7xv023203@www1.ietf.org> X-Authentication-Warning: www1.ietf.org: nobody set sender to iesg-secretary@ietf.org using -f From: Support Online To: tsvwg@ietf.org Reply-To: iesg-secretary@ietf.org X-Loop: WREQ 2 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Tsvwg] [iesg-secretary #28656] Mail Delivery (failure ietf-secretariat@ietf.org) (Autoreply) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Your request of the subject Mail Delivery (failure ietf-secretariat@ietf.org) has been received. If you have further email on this subject, please retain the subject: line (including the tracking number [ietf-action #xxx]) so that when you respond to ietf-action@ietf.org, the email goes in the same tracking ticket. Thank you. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sun Apr 25 17:10:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17784 for ; Sun, 25 Apr 2004 17:10:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHqrL-0002RF-Kl for tsvwg-archive@odin.ietf.org; Sun, 25 Apr 2004 17:08:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3PL8JCR009342 for tsvwg-archive@odin.ietf.org; Sun, 25 Apr 2004 17:08:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHqp7-0001J6-8M; Sun, 25 Apr 2004 17:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhTk-0002Rg-DF for tsvwg@optimus.ietf.org; Thu, 22 Apr 2004 12:55:12 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10031 for ; Thu, 22 Apr 2004 12:55:08 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BGhMc-0008G6-PY; Thu, 22 Apr 2004 12:47:50 -0400 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 22 Apr 2004 12:47:50 -0400 Subject: [Tsvwg] Last Call: 'The Eifel Response Algorithm for TCP' to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Transport Area Working Group WG to consider the following document: - 'The Eifel Response Algorithm for TCP ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-05-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-05.txt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Apr 26 14:35:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08807 for ; Mon, 26 Apr 2004 14:35:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAsD-0005Um-VR for tsvwg-archive@odin.ietf.org; Mon, 26 Apr 2004 14:30:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QIUX0K021101 for tsvwg-archive@odin.ietf.org; Mon, 26 Apr 2004 14:30:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAi5-0002Ca-Gm; Mon, 26 Apr 2004 14:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAWV-0006xz-Ai for tsvwg@optimus.ietf.org; Mon, 26 Apr 2004 14:08:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06323 for ; Mon, 26 Apr 2004 14:08:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAWS-0002bd-UD for tsvwg@ietf.org; Mon, 26 Apr 2004 14:08:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAVc-0002Z0-00 for tsvwg@ietf.org; Mon, 26 Apr 2004 14:07:13 -0400 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1BIAV6-0002Vd-00; Mon, 26 Apr 2004 14:06:40 -0400 Received: from [192.168.1.15] (pD9FF1FEA.dip.t-dialin.net [217.255.31.234]) by ilsa.franken.de (Postfix) with ESMTP id 333CC24631; Mon, 26 Apr 2004 20:06:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: quoted-printable Message-Id: <6C19FB58-97AC-11D8-AAF0-000A95DC192A@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed To: "'lksctp-developers@lists.sourceforge.net'" , sigtran@ietf.org, tsvwg@ietf.org From: Michael Tuexen Date: Mon, 26 Apr 2004 20:06:21 +0200 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] (no subject) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear all, the 7th SCTP interop will be held at University of Applied Sciences,=20 M=FCnster, from July 25th to July 30th 2004. You can now register and find more information at http://sctp.fh-muenster.de If you have any further questions please do not hesitate to contact me=20= via tuexen@fh-muenster.de Happy SCTPing Michael _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Apr 26 15:31:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13624 for ; Mon, 26 Apr 2004 15:31:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBhd-0007mo-5R for tsvwg-archive@odin.ietf.org; Mon, 26 Apr 2004 15:23:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QJNfER029905 for tsvwg-archive@odin.ietf.org; Mon, 26 Apr 2004 15:23:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBaH-0005v0-Iz; Mon, 26 Apr 2004 15:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBNh-0007RL-AT for tsvwg@optimus.ietf.org; Mon, 26 Apr 2004 15:03:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10734 for ; Mon, 26 Apr 2004 15:03:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBNe-0007cl-C7 for tsvwg@ietf.org; Mon, 26 Apr 2004 15:03:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBMi-0007a4-00 for tsvwg@ietf.org; Mon, 26 Apr 2004 15:02:04 -0400 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1BIBLp-0007Vz-00; Mon, 26 Apr 2004 15:01:09 -0400 Received: from [192.168.1.15] (pD9FF1FEA.dip.t-dialin.net [217.255.31.234]) by ilsa.franken.de (Postfix) with ESMTP id E097E245CE; Mon, 26 Apr 2004 21:00:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: quoted-printable Message-Id: <0F5E2801-97B4-11D8-AAF0-000A95DC192A@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed To: sigtran@ietf.org, tsvwg@ietf.org From: Michael Tuexen Date: Mon, 26 Apr 2004 21:01:01 +0200 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] Registration for 7th SCTP interop is now open Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear all, the 7th SCTP interop will be held at University of Applied Sciences,=20 M=FCnster, from July 25th to July 30th 2004. You can now register and find more information at http://sctp.fh-muenster.de If you have any further questions please do not hesitate to contact me=20= via tuexen@fh-muenster.de Happy SCTPing Michael PS.: Sorry for sending it twice, I forgot the subject line... _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Apr 26 19:23:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03128 for ; Mon, 26 Apr 2004 19:23:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIFQD-0004GN-DN for tsvwg-archive@odin.ietf.org; Mon, 26 Apr 2004 19:21:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QNLv5j016382 for tsvwg-archive@odin.ietf.org; Mon, 26 Apr 2004 19:21:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIFLR-0003XE-Vu; Mon, 26 Apr 2004 19:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIFK5-0003Jj-Rk for tsvwg@optimus.ietf.org; Mon, 26 Apr 2004 19:15:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02613 for ; Mon, 26 Apr 2004 19:15:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIFK4-0006Xb-A6 for tsvwg@ietf.org; Mon, 26 Apr 2004 19:15:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIFJE-0006Rp-00 for tsvwg@ietf.org; Mon, 26 Apr 2004 19:14:45 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BIFIg-0006L6-00; Mon, 26 Apr 2004 19:14:10 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3QNDXN12738; Mon, 26 Apr 2004 16:13:33 -0700 (PDT) Message-Id: <200404262313.i3QNDXN12738@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, tsvwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 26 Apr 2004 16:13:33 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-9.1 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Subject: [Tsvwg] RFC 3782 on The NewReno Modification to TCP's Fast Recovery Algorithm Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3782 Title: The NewReno Modification to TCP's Fast Recovery Algorithm Author(s): S. Floyd, T. Henderson, A. Gurtov Status: Standards Track Date: April 2004 Mailbox: floyd@acm.org, thomas.r.henderson@boeing.com, andrei.gurtov@teliasonera.com Pages: 19 Characters: 49603 Obsoletes: 2582 I-D Tag: draft-ietf-tsvwg-newreno-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3782.txt The purpose of this document is to advance NewReno TCP's Fast Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status. The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewReno TCP. This document is a product of the Transport Area Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040426161134.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3782 --OtherAccess Content-Type: Message/External-body; name="rfc3782.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040426161134.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Apr 28 08:16:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10765 for ; Wed, 28 Apr 2004 08:16:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIntc-0006vX-89 for tsvwg-archive@odin.ietf.org; Wed, 28 Apr 2004 08:10:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCAa4b026624 for tsvwg-archive@odin.ietf.org; Wed, 28 Apr 2004 08:10:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInNt-0008Kg-WF; Wed, 28 Apr 2004 07:37:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BImYb-00031K-Cy for tsvwg@optimus.ietf.org; Wed, 28 Apr 2004 06:44:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05279 for ; Wed, 28 Apr 2004 06:44:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BImYV-00054j-9b for tsvwg@ietf.org; Wed, 28 Apr 2004 06:44:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BImXc-0004p0-00 for tsvwg@ietf.org; Wed, 28 Apr 2004 06:43:49 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1BImWd-0004J2-00 for tsvwg@ietf.org; Wed, 28 Apr 2004 06:42:47 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3SAgKYm437308 for ; Wed, 28 Apr 2004 06:42:20 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3SAgJfA337480 for ; Wed, 28 Apr 2004 04:42:20 -0600 To: tsvwg@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Kristine Adamson Date: Wed, 28 Apr 2004 04:42:07 -0600 X-MIMETrack: S/MIME Sign by Notes Client on Kristine Adamson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 04/28/2004 06:42:09 AM, Serialize by Notes Client on Kristine Adamson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 04/28/2004 06:42:09 AM, Serialize complete at 04/28/2004 06:42:09 AM, S/MIME Sign failed at 04/28/2004 06:42:09 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 04/28/2004 04:42:19, Serialize complete at 04/28/2004 04:42:19 Content-Type: multipart/alternative; boundary="=_alternative 003ACA7885256E84_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [Tsvwg] TCP-ESTATS-MIB: tcpEStatsDataIpTos Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 003ACA7885256E84_= Content-Type: text/plain; charset="US-ASCII" Hello, I had raised this question earlier about the tcpEStatsDataIpTos object in the TCP-ESTATS-MIB: >- tcpEStatsDataIpTos: Haven't IPv4 TOS and IPv6 traffic class been superceded by DSCP? Since TOS seems to belong to >IPv4, wouldn't it be better to use a different name for this object, one that applied to both IPv4 and IPv6? and I was asked for a reference to a DSCP standards document. But, instead of using DSCP, it might be better to use a policy MIB object. This would be consistent with the inetCidrRoutePolicy MIB object in the new, version-neutral, IP-FORWARD-MIB. The current version of this MIB module is in IETF internet draft: draft-ietf-ipv6-rfc2096-update-07.txt In the existing IP-FORWARD-MIB, there is an ipCidrRouteTos MIB object. At one point, as the version-neutral IP-FORWARD-MIB was being created, there was an inetCidrRouteDscp MIB object but this was later changed to the policy MIB object. I don't remember now what the reasons were for the change. The IP-FORWARD-MIB changes were done as part of the ipv6 working group. Kristine Adamson IBM z/OS Communications Server: TCP/IP Development Internet e-mail:adamson@us.ibm.com --=_alternative 003ACA7885256E84_= Content-Type: text/html; charset="US-ASCII"
Hello,
   I had raised this question earlier about the tcpEStatsDataIpTos object in the TCP-ESTATS-MIB:

>- tcpEStatsDataIpTos: Haven't IPv4 TOS and IPv6 traffic class been superceded by DSCP?  Since TOS seems to belong to >IPv4, wouldn't it be better to use a different name for this object, one that applied to both IPv4 and IPv6?

and I was asked for a reference to a DSCP standards document.  But, instead of using DSCP, it might be better to use a policy MIB object.  This would be consistent with the inetCidrRoutePolicy MIB object in the new, version-neutral, IP-FORWARD-MIB.  The current version of this MIB module is in IETF internet draft:  draft-ietf-ipv6-rfc2096-update-07.txt

In the existing IP-FORWARD-MIB, there is an ipCidrRouteTos MIB object.  At one point, as the version-neutral IP-FORWARD-MIB was being created, there was an inetCidrRouteDscp MIB object but this was later changed to the policy MIB object.  I don't remember now what the reasons were for the change.  The IP-FORWARD-MIB changes were done as part of the ipv6 working group.
       
Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Internet e-mail:adamson@us.ibm.com
 --=_alternative 003ACA7885256E84_=-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg