From ckdwibedy@yahoo.com Fri Jun 1 07:26:30 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9D411E8085 for ; Fri, 1 Jun 2012 07:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVuA1bE-Mmxt for ; Fri, 1 Jun 2012 07:26:28 -0700 (PDT) Received: from nm19.bullet.mail.sp2.yahoo.com (nm19.bullet.mail.sp2.yahoo.com [98.139.91.89]) by ietfa.amsl.com (Postfix) with SMTP id 94D9D11E80EA for ; Fri, 1 Jun 2012 07:26:28 -0700 (PDT) Received: from [98.139.91.66] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 01 Jun 2012 14:26:28 -0000 Received: from [98.139.91.28] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 01 Jun 2012 14:26:28 -0000 Received: from [127.0.0.1] by omp1028.mail.sp2.yahoo.com with NNFMP; 01 Jun 2012 14:26:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 475266.82948.bm@omp1028.mail.sp2.yahoo.com Received: (qmail 15928 invoked by uid 60001); 1 Jun 2012 14:26:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1338560787; bh=QaXVdmtm4TRp0Jj79/l4LWUUPMclbGHS4hm9F9Z6V3I=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IUjcTkO9ovK0Uoy3Lv+91CjySyC0COnXYxSP9sSglTbI+52+mcjp9dcnwm7TBNdQrLPCUzniYc+ehisM+3/QI98kZnpGWar7Vf7kditGKWyIwGZeRieXXuWdd7zrcWvSRjIlLfyL7Rt9m9AihVZT6ElIrGL54n0df7ja1Z00Xc8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DnByIWYl/CdEtJZW0hxBqgvlgZJi5I/PBv6uelezP3xOM0cB/8HKoWKvPTaCJV10IjBC9wc9eVey1qx4EBjzQS6290DFKgM94uttC65U3TSxHWxeJRHA2cpVM07tEAlThiIrxy0T8d/4P7hYfVE4RQE8hMZdvdQGpz0KrVxL520=; X-YMail-OSG: BUSS7TwVM1ng2twMxypSCNIKzwgWBw7ptwoHEUm7w9hHswm _vb1rTecFrVekn_MZ9EuNmeOb6eAPHDxAPXrK8ctdu3jOf_43tDC_f.Ekbu7 xF8JC8Kp7Z6U1OQ5A32wKjtR8I.krhCbYtN7xwR28R7G.mEcgLsO9G5s_VXZ 9gWDGdjYVeIQ4zzir_k4eRywBWTvMh.Ne3c0MqGoM70wAUT8yoGslJaN4HfK ucBiRRztxAhvMnLKwyCuF4HZs19cYBkA.K9J.GxUEE7psa.xA7SeB4EGRbMS fEJPb9U0vu8W3W.G9aVAgYoKLZ4h5npNJsGb.JfzmBhJXoUPMpVwiN.PM_x5 wuKOiO6CuYfrmgAQoHTfmzdE6jbCidZgxA_TzQR9RBw8cxt1LpGLe6pezYNM C8e3uovR4rShQ1l6dTjKC7G..nqlTtxD0RqwhzhVwxC.wSN6Iaj6Rs7U96NK NdFZ2FOXZ.YRcKvTfov1jtWE- Received: from [111.93.163.178] by web130104.mail.mud.yahoo.com via HTTP; Fri, 01 Jun 2012 07:26:27 PDT X-Mailer: YahooMailWebService/0.8.118.349524 References: <4FBE562E.6000909@gmail.com> <1338463399.19395.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338467385.57530.YahooMailNeo@web130105.mail.mud.yahoo.com> <1338489317.38384.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338492008.97916.YahooMailNeo@web130103.mail.mud.yahoo.com> Message-ID: <1338560787.8033.YahooMailNeo@web130104.mail.mud.yahoo.com> Date: Fri, 1 Jun 2012 07:26:27 -0700 (PDT) From: Chinmaya Dwibedy To: Randy Stewart In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="641185687-1756681586-1338560787=:8033" Cc: "tsvwg@ietf.org" Subject: [tsvwg] Source IP address of the HEARTBEAT_ACK in multi-homing setup X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Chinmaya Dwibedy List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 14:26:30 -0000 --641185687-1756681586-1338560787=:8033 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=0AWe have a SCTP multi-homing setup with host and peer having two netwo= rk interfaces with IP addresses belong to two different subnets.=0A=C2=A0Ho= st=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IP eth5 (192.168.16.125 =E2=80=93 pr= imary IP),=0A=C2=A0 IP eth6 (192.168.17.125 =E2=80=93 secondary IP): Multi-= Homed endpoint=0A=C2=A0Peer-end IP eth5 (192.168.16.129 =E2=80=93 primary I= P),=0A=C2=A0The network interfaces of host and peer are connected with cros= sover cable.=0AWe have received one issue saying that, Host (SCTP endpoint)= should use the source IP (i.e., 192.168.17.125 =E2=80=93 secondary IP) on = which it received the Heart_beat_req on while sending back the response (He= art_beat_ack)=E2=80=9D. =0AHere goes my analysis. Can anyone please validat= e and feel free to correct me if I am wrong? Thanks in advance for your res= ponse.=0AAs per section 3.3.6 of rfc-2960/rfc-4960, a HEARTBEAT ACK is alwa= ys sent to the source IP address of the IP datagram containing the HEARTBEA= T chunk to which this ACK is responding. It says nothing about whether the = source of the response has to be the same as the destination of HEART_BEAT_= REQ. The RFC/standard does not mandate to keep the source IP address of the= HEARTBEAT_ACK has to be the same as the destination IP address of HEART_BE= AT_REQ. I think in this case, it is quite expected behavior in compliance w= ith rfc-2960/rfc-4960. It would be wrong to say that, it is an issue in RHE= L4 (kernel version: 2.6.9-55.ELsmp). =0AEven if there are two paths, SCTP d= oes not have any way to determine whether two paths share links and routers= when traversing the network. The paths used by the IP=C2=A0=C2=A0 packets = across the network might be different depending on the destination IP addre= ss.=C2=A0 If a message fails to reach its destination, SCTP may retransmit = the message using a different destination IP address. If somewhere along th= e path a link or/and router fails then SCTP can detect the failure of the p= ath via a heartbeat message. These actions done by SCTP are independent of = the actions performed by the lower layers for failure detection and restora= tion. Under the assumption that every IP address will have a different, sep= arate path towards the remote endpoint, (this is the responsibility of the = routing protocols or of manual static configuration), if the transport to o= ne of the IP addresses (=3D 1 particular path) fails then the traffic can m= igrate to the other remaining IP address (=3D other paths) within the SCTP association.=0A=C2=A0=0ARegards,=0AChinmayaD --641185687-1756681586-1338560787=:8033 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,
We have a SCTP multi-homing setup with host and peer having two network in= terfaces with IP addresses belong to two different subnets.
 Host       IP eth5 (192.168.16.= 125 =E2=80=93 primary IP),
  IP eth6 (192.168.17.125 = =E2=80=93 secondary IP): Multi-Homed endpoint
 Peer-end IP eth5 (192.168.1= 6.129 =E2=80=93 primary IP),
 The network interfaces of h= ost and peer are connected with crossover cable.
We have received one issue saying that, Host (SCTP endpoint) should use th= e source IP (i.e., 192.168.17.125 =E2=80=93 secondary IP) on which it recei= ved the Heart_beat_req on while sending back the response (Heart_beat_ack)= =E2=80=9D.
Here goes my analysis. Can anyone please validate and feel free to correct= me if I am wrong? Thanks in advance for your response.
As per section 3.3.6 of rfc-2960/rfc-4960, a HEARTBEAT ACK is= always sent to the source IP address of the IP datagram containing the HEA= RTBEAT chunk to which this ACK is responding. It says nothing about whether= the source of the response has to be the same as the destination of HEART_= BEAT_REQ. The RFC/standard does not mandate to keep the source IP address o= f the HEARTBEAT_ACK has to be the same as the destination IP address of HEA= RT_BEAT_REQ. I think in this case, it is quite expected behavior in complia= nce with rfc-2960/rfc-4960. It would be wrong to say that, it is an issue i= n RHEL4 (kernel version: 2.6.9-55.ELsmp).
Even if there are two paths, SCTP does not have any way to determine wheth= er two paths share links and routers when traversing the network. The paths= used by the IP   packets across the network might be different d= epending on the destination IP address.  If a message fails to reach i= ts destination, SCTP may retransmit the message using a different destinati= on IP address. If somewhere along the path a link or/and router fails then = SCTP can detect the failure of the path via a heartbeat message. These acti= ons done by SCTP are independent of the actions performed by the lower laye= rs for failure detection and restoration. Under the assumption that every I= P address will have a different, separate path towards the remote endpoint,= (this is the responsibility of the routing protocols or of manual static configuration), if the transport to one of the IP addresses (=3D 1 particu= lar path) fails then the traffic can migrate to the other remaining IP addr= ess (=3D other paths) within the SCTP association.
 
Regards,
ChinmayaD
--641185687-1756681586-1338560787=:8033-- From Michael.Tuexen@lurchi.franken.de Fri Jun 1 07:42:59 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5F011E8106 for ; Fri, 1 Jun 2012 07:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrznbxLta+XJ for ; Fri, 1 Jun 2012 07:42:58 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC1F11E8174 for ; Fri, 1 Jun 2012 07:42:58 -0700 (PDT) Received: from [192.168.1.103] (p508F91D2.dip.t-dialin.net [80.143.145.210]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DFDFD1C0C0BD8; Fri, 1 Jun 2012 16:42:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Michael Tuexen In-Reply-To: <1338560787.8033.YahooMailNeo@web130104.mail.mud.yahoo.com> Date: Fri, 1 Jun 2012 16:42:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FBE562E.6000909@gmail.com> <1338463399.19395.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338467385.57530.YahooMailNeo@web130105.mail.mud.yahoo.com> <1338489317.38384.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338492008.97916.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338560787.8033.YahooMailNeo@web130104.mail.mud.yahoo.com> To: Chinmaya Dwibedy X-Mailer: Apple Mail (2.1278) Cc: "tsvwg@ietf.org" , Randy Stewart Subject: Re: [tsvwg] Source IP address of the HEARTBEAT_ACK in multi-homing setup X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 14:42:59 -0000 On Jun 1, 2012, at 4:26 PM, Chinmaya Dwibedy wrote: > Hi, > We have a SCTP multi-homing setup with host and peer having two = network interfaces with IP addresses belong to two different subnets. > Host IP eth5 (192.168.16.125 =96 primary IP), > IP eth6 (192.168.17.125 =96 secondary IP): Multi-Homed endpoint > Peer-end IP eth5 (192.168.16.129 =96 primary IP), > The network interfaces of host and peer are connected with crossover = cable. > We have received one issue saying that, Host (SCTP endpoint) should = use the source IP (i.e., 192.168.17.125 =96 secondary IP) on which it = received the Heart_beat_req on while sending back the response = (Heart_beat_ack)=94. > Here goes my analysis. Can anyone please validate and feel free to = correct me if I am wrong? Thanks in advance for your response. > As per section 3.3.6 of rfc-2960/rfc-4960, a HEARTBEAT ACK is always = sent to the source IP address of the IP datagram containing the = HEARTBEAT chunk to which this ACK is responding. It says nothing about = whether the source of the response has to be the same as the destination = of HEART_BEAT_REQ. The RFC/standard does not mandate to keep the source = IP address of the HEARTBEAT_ACK has to be the same as the destination IP = address of HEART_BEAT_REQ. I think in this case, it is quite expected=20 > behavior in compliance with rfc-2960/rfc-4960. It would be wrong to = say that, it is an issue in RHEL4 (kernel version: 2.6.9-55.ELsmp). RFC 4960 does require you to use any specific source address. The only = constraint is, that you use one of the addresses known by the peer (which means listed = in the INIT or INIT-ACK or the source address of the INIT or INIT-ACK). Best regards Michael > Even if there are two paths, SCTP does not have any way to determine = whether two paths share links and routers when traversing the network. = The paths used by the IP packets across the network might be different = depending on the destination IP address. If a message fails to reach = its destination, SCTP may retransmit the message using a different = destination IP address. If somewhere along the path a link or/and router = fails then SCTP can detect the failure of the path via a heartbeat = message. These actions done by SCTP are independent of the actions = performed by the lower layers for failure detection and restoration. = Under the assumption that every IP address will have a different, = separate path towards the remote endpoint, (this is the responsibility = of the routing protocols or of manual static configuration), if the = transport to one of the IP addresses (=3D 1 particular path) fails then = the traffic can migrate to the other remaining IP address (=3D other = paths) within the SCTP association. > =20 > Regards, > ChinmayaD From touch@isi.edu Mon Jun 4 17:09:46 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C116221F8741; Mon, 4 Jun 2012 17:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.579 X-Spam-Level: X-Spam-Status: No, score=-104.579 tagged_above=-999 required=5 tests=[AWL=2.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfsorEqvDAqE; Mon, 4 Jun 2012 17:09:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B27F021F873C; Mon, 4 Jun 2012 17:09:45 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5508ltq006727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Jun 2012 17:08:47 -0700 (PDT) Message-ID: <4FCD4E0F.2080100@isi.edu> Date: Mon, 04 Jun 2012 17:08:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: internet-drafts@ietf.org References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> In-Reply-To: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org, i-d-announce@ietf.org Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 00:09:46 -0000 Hi, all, I've resubmitted this as a WG doc. The major changes were to include full references for previous placeholders and a few minor notes. It would be useful to get feedback on whether there are any areas that should be addressed that are not listed before diving into the two key issues I hope we can discuss as part of this doc: - whether to deprecate the distinction between system and user ports (or to do nothing at this time) - whether to make stronger recommendations on the use of security on port services (i.e., whether security "should" be supported for new services, or to make no specific recommendation at this time) Any gap material notes would be most useful now, though. Joe On 5/31/2012 11:34 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. > > Title : Recommendations for Transport Port Uses > Author(s) : Joe Touch > Filename : draft-ietf-tsvwg-port-use-00.txt > Pages : 11 > Date : 2012-05-30 > > This document provides recommendations to application and service > designers on how to use the transport protocol port number space to > help in its preservation. **NOTE THAT THIS CURRENT VERSION IS > LARGELY AN OUTLINE OF ISSUES**. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ > From randall@lakerest.net Tue Jun 5 07:50:49 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CC321F872E for ; Tue, 5 Jun 2012 07:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7LcFm6WU4st for ; Tue, 5 Jun 2012 07:50:49 -0700 (PDT) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0165021F872D for ; Tue, 5 Jun 2012 07:50:48 -0700 (PDT) Received: from [10.1.1.141] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id q55EnVgd012080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Jun 2012 10:49:32 -0400 (EDT) (envelope-from randall@lakerest.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Randy Stewart In-Reply-To: Date: Tue, 5 Jun 2012 10:10:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4634330F-FA48-488F-8F6A-27A52072034C@lakerest.net> References: <4FBE562E.6000909@gmail.com> <1338463399.19395.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338467385.57530.YahooMailNeo@web130105.mail.mud.yahoo.com> <1338489317.38384.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338492008.97916.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338560787.8033.YahooMailNeo@web130104.mail.mud.yahoo.com> To: Michael Tuexen X-Mailer: Apple Mail (2.1278) Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Source IP address of the HEARTBEAT_ACK in multi-homing setup X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 14:50:50 -0000 On Jun 1, 2012, at 10:42 AM, Michael Tuexen wrote: > On Jun 1, 2012, at 4:26 PM, Chinmaya Dwibedy wrote: >=20 >> Hi, >> We have a SCTP multi-homing setup with host and peer having two = network interfaces with IP addresses belong to two different subnets. >> Host IP eth5 (192.168.16.125 =96 primary IP), >> IP eth6 (192.168.17.125 =96 secondary IP): Multi-Homed endpoint >> Peer-end IP eth5 (192.168.16.129 =96 primary IP), >> The network interfaces of host and peer are connected with crossover = cable. >> We have received one issue saying that, Host (SCTP endpoint) should = use the source IP (i.e., 192.168.17.125 =96 secondary IP) on which it = received the Heart_beat_req on while sending back the response = (Heart_beat_ack)=94. >> Here goes my analysis. Can anyone please validate and feel free to = correct me if I am wrong? Thanks in advance for your response. >> As per section 3.3.6 of rfc-2960/rfc-4960, a HEARTBEAT ACK is always = sent to the source IP address of the IP datagram containing the = HEARTBEAT chunk to which this ACK is responding. It says nothing about = whether the source of the response has to be the same as the destination = of HEART_BEAT_REQ. The RFC/standard does not mandate to keep the source = IP address of the HEARTBEAT_ACK has to be the same as the destination IP = address of HEART_BEAT_REQ. I think in this case, it is quite expected=20 >> behavior in compliance with rfc-2960/rfc-4960. It would be wrong to = say that, it is an issue in RHEL4 (kernel version: 2.6.9-55.ELsmp). > RFC 4960 does require you to use any specific source address. The only = constraint is, > that you use one of the addresses known by the peer (which means = listed in the INIT or > INIT-ACK or the source address of the INIT or INIT-ACK). The HB section also says that you *SHOULD* use the source address the = packet was received on. There is a known bug in the linux implementation that has been since = fixed where it would incorrectly reply from a different address=85 SHOULD in general means you really really really should do this unless = you have some other purposeful reason not to. A bug is not a purposeful reason IMO. So yes, = you are allowed to respond with any valid source. But when responding with a HB you SHOULD = use the src address. Which basically means you *should* unless you have a specific reason (for = example you are a user land stack and you cannot control the src address). Not responding due = to a bug, is not being conformant to the RFC IMO=85 ;-) In fact in general, if I remember correctly you SHOULD respond whenever = possible with the source address that sent you the packet. There are times when thats = not possible (A sack for example acking a packet that came in from two different = source addresses, or a situation where you suspect the reverse path is broke), but in = general that SHOULD also applies here as well.=20 R >=20 > Best regards > Michael >> Even if there are two paths, SCTP does not have any way to determine = whether two paths share links and routers when traversing the network. = The paths used by the IP packets across the network might be different = depending on the destination IP address. If a message fails to reach = its destination, SCTP may retransmit the message using a different = destination IP address. If somewhere along the path a link or/and router = fails then SCTP can detect the failure of the path via a heartbeat = message. These actions done by SCTP are independent of the actions = performed by the lower layers for failure detection and restoration. = Under the assumption that every IP address will have a different, = separate path towards the remote endpoint, (this is the responsibility = of the routing protocols or of manual static configuration), if the = transport to one of the IP addresses (=3D 1 particular path) fails then = the traffic can migrate to the other remaining IP address (=3D other = paths) within the SCTP association. >>=20 >> Regards, >> ChinmayaD >=20 >=20 ----- Randall Stewart randall@lakerest.net From jsaldana@unizar.es Wed Jun 6 00:20:43 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C5711E80D1 for ; Wed, 6 Jun 2012 00:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.172 X-Spam-Level: X-Spam-Status: No, score=-5.172 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IexMH9akRetH for ; Wed, 6 Jun 2012 00:20:41 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5342511E80A1 for ; Wed, 6 Jun 2012 00:20:39 -0700 (PDT) Received: from jsaldanapc (n33d97.cs.unibo.it [130.136.33.97]) (authenticated bits=0) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q567KYnN020201 for ; Wed, 6 Jun 2012 09:20:35 +0200 From: "Jose Saldana" To: Date: Wed, 6 Jun 2012 09:20:35 +0200 Message-ID: <000901cd43b4$ddf1ad70$99d50850$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01CD43C5.A17B67D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1DtLy0SvxRKELjSjG0G//ktipRhw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tsvwg] draft-saldana-tsvwg-tcmtf in the World IPv6 Launch day: 70% bandwidth saving X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 07:20:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01CD43C5.A17B67D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01CD43C5.A17B67D0" ------=_NextPart_001_000B_01CD43C5.A17B67D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Today we are in the World IPv6 Launch day: http://www.worldipv6launch.org/ So I would like to share with the group some results I have deployed with TCMTF, using IPv6. As everyone knows, the header of IPv6 is twice as big as the one of IPv4. This can be seen as a problem for real-time services using small packets, since the overhead is increased. Thus, header compressing mechanisms are expected to become more and more interesting. One of the three layers of TCMTF is header compression, and the savings achieved with IPv6 are bigger than the ones obtained with IPv4. I attach a graph of the bandwidth savings obtained when multiplexing and compressing client-to-server flows of World of Warcraft, the most popular MMORPG in the World. Up to 70 percent of the bandwidth can be saved, while adding a small delay. Best regards, Jose De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de Jose Saldana Enviado el: martes, 29 de mayo de 2012 12:19 Para: tsvwg@ietf.org Asunto: [tsvwg] draft-saldana-tsvwg-tcmtf for World of Warcraft: 60% bandwidth saving Hi all, Our research group has just got accepted a paper for a conference next July. It presents the tests of TCMTF (the "tunnels draft") for the traffic of World of Warcraft (an online game with 10 million players). This game uses TCP/IP, and client-to-server headers can be compressed from 40 to 8.72 bytes average, so this traffic can get a 60% reduction. The cause of these good results is that the game also generates a high number of TCP ACK packets without payload (56%). For them, the saving is very high: the compression is applied to headers, and these packets are "only header". Two other MMORPG games are also analyzed, and the savings are 40% and 45%. The saving is lower for server-to-client traffic (8.5%, 22%, 20%). The number of packets per second can also be reduced: if the traffic of 100 players is multiplexed, pps can be reduced from 900 to 12. We have also used a MOS estimator (based on delay and jitter) in order to grant that subjective quality is not harmed. I attach two (small) PDF graphs showing the savings. Since it has not already been published, I have put the paper in my web page, just in case somebody wants to have a look: http://diec.unizar.es/~jsaldana/personal/sergei_SPECTS_2012_in_proc.pdf Best regards, Jose Saldana ------=_NextPart_001_000B_01CD43C5.A17B67D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Today we = are in the World IPv6 Launch day: http://www.worldipv6launch.org/<= /a>

 

So I would = like to share with the group some results I have deployed with TCMTF, = using IPv6. As everyone knows, the header of IPv6 is twice as big as the = one of IPv4. This can be seen as a problem for real-time services using = small packets, since the overhead is increased. Thus, header compressing = mechanisms are expected to become more and more interesting. One of the = three layers of TCMTF is header compression, and the savings achieved = with IPv6 are bigger than the ones obtained with IPv4. I attach a graph = of the bandwidth savings obtained when multiplexing and compressing = client-to-server flows of World of Warcraft, the most popular = MMORPG in the World. Up to 70 percent of the bandwidth can be saved, = while adding a small delay.

 

Best = regards,

 

Jose

 

 

Hi = all,

 

Our research group has just got = accepted a paper for a conference next July. It presents the tests of = TCMTF (the “tunnels draft”) for the traffic of World of = Warcraft (an online game with 10 million players). This game uses = TCP/IP, and client-to-server headers can be compressed from 40 to 8.72 = bytes average, so this traffic can get a 60% reduction. The cause of = these good results is that the game also generates a high number of TCP = ACK packets without payload (56%). For them, the saving is very high: = the compression is applied to headers, and these packets are “only = header”. Two other MMORPG games are also analyzed, and the savings = are 40% and 45%. The saving is lower for server-to-client traffic (8.5%, = 22%, 20%).

 

The number of packets per second can also be reduced: if = the traffic of 100 players is multiplexed,  pps can be reduced from = 900 to 12.

 

We have also used a MOS estimator (based on delay and = jitter) in order to grant that subjective quality is not = harmed.

 

I attach two (small) PDF graphs showing the = savings.

 

Since it has not already been published, I have put the = paper in my web page, just in case somebody wants to have a look: =

 

http://diec.unizar.es/~jsaldana/personal/sergei_SPECTS_2012_in_pr= oc.pdf

 

 

Best regards,

 

Jose Saldana

------=_NextPart_001_000B_01CD43C5.A17B67D0-- ------=_NextPart_000_000A_01CD43C5.A17B67D0 Content-Type: application/pdf; name="TCMTF_World_of_Warcraft_Bandwidth_IPv6.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="TCMTF_World_of_Warcraft_Bandwidth_IPv6.pdf" JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlcy1FUykgL1N0cnVjdFRyZWVSb290IDEyIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDEvS2lkc1sgNCAwIFJdID4+ DQplbmRvYmoNCjMgMCBvYmoNCjw8L0F1dGhvcih1c3VhcmlvKSAvQ3JlYXRpb25EYXRlKEQ6MjAx MjA2MDUyMDA5MjkrMDInMDAnKSAvTW9kRGF0ZShEOjIwMTIwNjA1MjAwOTI5KzAyJzAwJykgL1By b2R1Y2VyKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABFAHgAYwBlAGwArgAgADIAMAAxADApIC9D cmVhdG9yKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABFAHgAYwBlAGwArgAgADIAMAAxADApID4+ DQplbmRvYmoNCjQgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwv Rm9udDw8L0YxIDYgMCBSL0YyIDggMCBSL0YzIDEwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0lt YWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDg0MS44IDU5NS4yXSAvQ29udGVu dHMgNSAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+ L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDA+Pg0KZW5kb2JqDQo1IDAgb2JqDQo8PC9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDI0MjY+Pg0Kc3RyZWFtDQp4nLVa3W/kRBJ/j5T/oV9OmkEXb39Ut9sS 4mEXDoFA4s457QPcw+oI2T0lOVgQiP+eqv6s9njsmYwD2iRTXV3+dX38quyxePWd+PTTV9+++epz IT/7TLz+/I1Q4v76ysoOhNOd1aI3ujNOQO8758XHu+urnz65vlJ66HotlDbd4FDToL5BQV6XtPoH /bbaii+vr9Du/0TZ1pNcPF5f9dZ0qggeimGtHBmuGknANJxpbSRB1TByaG0kAdOwrrWRBFUDpG5t JAHTgKG1kQRMY7ATG1GAGiN6iLyz6M+RuXGi+Di9SLSJQksYDrSSIGCLGiUSbWiqRo1EGxqmUSLR hqZq1Ei0oWEaJRJtaKpGjUQbGqZRItGGhmmUSBzx2sS3OTuL12a1skDhr4hn8LTENJKgaGjnO8Nt ZEHRMKbvLLeRBUUDpOs8U0if63rvOglcIQmKhgXbaW4iC4qGU9A5biMLqoY3nec2sqBotE5kXi0a 6NVfmhTVRD4QCrLXnYdQBm8/EU/oqE65SCx6EMhSA+DP3hjxr0gyXxeSgUhc1f0AfQpj8jbYcKnq bbCWsBfngg3i6kywPmVUchXYgWBWV5EAPPNMFeTqR0E+9j/pIEbhEax0dBBQ4uN9TU+DeOIRDO71 +UyMWzQeLX52ndZM4T0SceBhe9RdG11mrB62qrM+5DMWJ1AF+k56VhMA6KVYklh64JhGBLyVqTFG mdzt0uF0rzrnQtRNSYPIEkP8CF3PlhOgDcyMMcMgpocN5QwS1cGWYg+L2HFTPmKxQF5OQC40Mcas xiYOTlGUiRKU7BSEPHcl70nDAoU5CGJGFI0EZiNTYy0tHDekjjxFB6ylVmrPdjIVYzhk1ciYNrE0 1uJGQz1EYvT0F7k+EkYpf9v1PgoU/VU1EqaNTI2RYKiHoaXBRy7u6S/GOEkDU1UmTlL0V9VIoDYy NUaSQxJnlnwfCKKhQdKoljySkZsBtY2pMRAtmjG0ObQbF9jBBiZ7SMso1LE9QcyRvJrQXGrjeT2t ByuIqomltdczTU0qShbW1JCJYwPKTQ10Kq/c1LDteeBNTSWaLOVgkomSipBMlKbGez2du3ghdrTA PaylkXuosdE5DMYq9jRHTjADwhFhhAw/wh3DsbMvbRoT8fvQnRDlgc3F9TExNTUzLLSZ3QvLY+LX 2IVg5jyL62MkQx1i089de2F5TLTlQsvp3dzuhfUxEkzMAzN37YXlMRFBajRzu5fWx1SyPrfHme0L 62OqNB0yVM55fWn9eSVphzCYaUpOg0PUQUmiMN92xJI03qUpMpckusTwqR7wqppVpGm6E+poz8sR +7xvyhFMO30DKg5NRWLiNDOmQ2/EwQ9PAQMfMilRFbDpz2DNKc+mvSrIQ+WcU55pr06PZpBxsEkT n8HDxVkmDXhV0M6K522skyF6M3aaPNJJnxpLmuHK53YUPGsfm/00VjMb3DRxHh/VimAy8J2zj015 ONU7zUczokHHJ7EimAx15+1kM1wAWAeviI/NWUUwmdjO2cfmM+RWy2cqqi7gI1QRTKaxszay2QvL yjQDEwKHZj4qgsmodd5ONlkRoQEfh7C/W8+nnyKYDFLn7cxzE9J+O/Ogr5opp3zmk9JZu55HxEA3 sKYn4nG6P+RhKk4+GRnMUctv942DNPgkGiai5oORlIlFc1oqxWlY+TTlZBouj4UyDeMVFX/mAUaR IuNhi5HGUwz00xkbeTjSpHaBqx4LTepep4zIgqqRthSNn454aBPjY2VWbTsVfRyJFadP6TjTZoW8 oSgE/rzYylhI1ziZ7qgi6RpHLPlQP5blrJ/WA5ALbYyZjKmzyPR8LnAU9aLI/VlQNeKOohAo/mIr Y2FpGpLjI5PM0hISiyUB00jEXjQCG29gZywkLvtEP5nEiQk5qTOFsCGvx8ZwmY2xcnvp1pnbtUrN JAuYRtxSNGLPuNzOWHlfp1kl0z42d3C8D1SFtCErxHZyqZWx9gOkXK9jg4j9wKj0CCILmEbcUjRi o7nczlhbBrFncF9qGTiFKGAtpK6nDUUhtqFLrSAU8cW3b4Rg34qpV9+8e7oXu7unm3+P+/QV2S8r X5DFzvX69vrq1T+UwKzAXnKLGJWQ+L8SWD2QHpHjTHD7SF8C3advgsQNFrbEbihu//v9Tv5t/x9x +/X11Re3oYEc4NMvgc8PqIn4sCP4YRGfWgVoXhCgVtgdFvHpVXzwkvgsDiJqEaBZBWhfEKCR2G7t IkBYBeheEiDOlThiLQG0qwD7lwSIsyb0iwDdKkD/ggBp8B6WSaZfBTi8JMBB0f4lgH4VoJLbIHQt REUNvEfrunOzQVaUnIEH1wBu1EimANF52F/XAepVgBt1kglA7cLrBOsAzSrAjTrJBCA9vcNJZB0g rALcqJVMAQ5DJ0/JQbsKcKNWMgEIdHcNJwB0qwA3aiUTgNbQw9B1fP0qvo06yQSfo6cPwwkA/SrA jTrJFGDvOmVPADisAtyok0wA9ngDZs1JPL2GUMtngNKsvYXOFf/DohA3SjSSnm5YgV6AmsNp3RBw vh5bmC8MRocnWy2e73dizVXq2a464DhNL1fgDu0Ocfy8t7u7jx/2N3b3f/zzR/wn8N8Pu8df92b3 w/5SVx3w2UB3iEfArDpFP88p9ACyaZyg6ebQ0u37NKUxP9497W8MuuJG7/7Y3yjYffgRffHbe7HX eje++32v7O5D0LknHfF8H5lDbBQudM0RbG/32mCg8KpvL4rM9KpggB7DHrnq38Wbhw93T5Qkv217 2UFScRy57M3G13L0hPrItca7j5j2GFqzo78GPHMI/VffhXC7TaHYITxHOgJltQoMf5uYnu3T64/G xHcce3rgr4yksx68MBzecl3bMZ70IqDDxo8bNIRf9PSJ3tgogof0au3M+3cOHD3v1ehBp+JOSdej nfFLgawBhjSCwLQa79uDoVcJ0gaGWxtHHlxp2Kz7W5zv+kBI9pAPqaNC4OOfH979ufeYmr+uJYdN 0E557yXHkB7sOh7DKMgxnHvhhBxHryur/CqAxElhLudyaBbUZ13sNroTzh5WNAEceNjK4l17inf7 A+8ef4UheVd5TZiqd5Mge3fu7YGUhcrbzrFEVnRslrbl81I5nGyk0T+W+X7bsCiaksxBWPSZYRkO wnL0C80cFRiozbKoREGOytx3idmB4HJAQ1ar8opX+lzX04aiMBOki23Ohck8Z9BeChNYnPNn+Gk1 TH8BfLysqQ0KZW5kc3RyZWFtDQplbmRvYmoNCjYgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBl L1RydWVUeXBlL05hbWUvRjEvQmFzZUZvbnQvQXJpYWwvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5n L0ZvbnREZXNjcmlwdG9yIDcgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjEvV2lkdGhzIDc1 IDAgUj4+DQplbmRvYmoNCjcgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUv QXJpYWwvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgOTA1L0Rlc2NlbnQgLTIxMC9DYXBI ZWlnaHQgNzI4L0F2Z1dpZHRoIDQ0MS9NYXhXaWR0aCAyNjY1L0ZvbnRXZWlnaHQgNDAwL1hIZWln aHQgMjUwL0xlYWRpbmcgMzMvU3RlbVYgNDQvRm9udEJCb3hbIC02NjUgLTIxMCAyMDAwIDcyOF0g Pj4NCmVuZG9iag0KOCAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9G Mi9CYXNlRm9udC9BcmlhbCxCb2xkL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3Jp cHRvciA5IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTE5L1dpZHRocyA3NiAwIFI+Pg0KZW5k b2JqDQo5IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FyaWFsLEJvbGQv RmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgOTA1L0Rlc2NlbnQgLTIxMC9DYXBIZWlnaHQg NzI4L0F2Z1dpZHRoIDQ3OS9NYXhXaWR0aCAyNjI4L0ZvbnRXZWlnaHQgNzAwL1hIZWlnaHQgMjUw L0xlYWRpbmcgMzMvU3RlbVYgNDcvRm9udEJCb3hbIC02MjggLTIxMCAyMDAwIDcyOF0gPj4NCmVu ZG9iag0KMTAgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjMvQmFz ZUZvbnQvQXJpYWwsQm9sZEl0YWxpYy9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2Ny aXB0b3IgMTEgMCBSL0ZpcnN0Q2hhciA4Ny9MYXN0Q2hhciAxMTEvV2lkdGhzIDc3IDAgUj4+DQpl bmRvYmoNCjExIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FyaWFsLEJv bGRJdGFsaWMvRmxhZ3MgMzIvSXRhbGljQW5nbGUgLTEyL0FzY2VudCA5MDUvRGVzY2VudCAtMjEw L0NhcEhlaWdodCA3MjgvQXZnV2lkdGggNDc5L01heFdpZHRoIDE5NTAvRm9udFdlaWdodCA3MDAv WEhlaWdodCAyNTAvTGVhZGluZyAzMy9TdGVtViA0Ny9Gb250QkJveFsgLTU2MCAtMjEwIDEzOTAg NzI4XSA+Pg0KZW5kb2JqDQoyMCAwIG9iag0KPDwvVHlwZS9PYmpTdG0vTiA2Mi9GaXJzdCA0NzUv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5Njc+Pg0Kc3RyZWFtDQp4nKVX22rcMBB9L/Qf5g+s u2QohdILLSFhyQb6EPrgJGqydLMOjgPt3/fInuylXalBhWV9m5kzOjoajWQgQUqRlaQkSaFIGZLO kNJ4YUk5Ut6TsqRVIPx0C3tPxkjSgqyAWUvWGnwnJx1pSc550oY8PmhNPgjSjoJRpC2FVpMO1FoE 9MATjozA1aXIJKUSBEMpgyIgSIU4BgmpFnaapDaBjCNpJOwsrg52gaRF1gbxrHfICQMAhkE8h2wt 4nk7DVEGYQi5yuBgh3itDGQRr0WSSEkJjMJinKKFHYYNALItCBKBXCIKfoBUGngOlGngOVBggOfg b4CXyLMYBEyVAx6GphxAwIryKU6bKBXk4R9APW5V8IkvUAmmcKvaEMiDKZHIAZtpYhK5GkaYFW0w ExKEGvAkYWdhLDEHQWDQoD1gHG/eNIvkLOi8WTbLh27TXPx6iM1yHJ6ux4/reN8sbslM309IvH37 +tXkAh3MLou/7E8uSX6jrdvWZYtyEX+OV/3PY44YKWyOeUNqBUBVDWiygLYEqKsBXRbQlwBNNWDI ArYlQFsLiBWfAdRF0bhqwKxodFE0vhowKxpdFE2oBsyKRhdF01YDZkWji6KRohbRZFVjyqWmutaY rGxMUTayutiYrG5MUTeyutqYrHBMUTiyutyYrHJMWTnV9cZmlWPLyqkuODarHFtWTnXFsVnl2LJy qkuOzSrHlpVTXXNsVjkv2uaqK486WkFcUTuquga4rHZe3IUpvcvSFLOsXsXO/n+WdpdlUTGqeh26 fyvmn1n6rY8XxSyrV5KX/59lu8uyWGF09Srw2QojHXu/v+uG8XiVSRZ8JuBOnftn7mq51+QOkPsy 7pa4h+HOgrd73oN5Y+TdircQrutcbLkCcllKB7F0cWK+zJZutpxXSzpzTZfZwc0O8+yn89V00Vk2 nuvtxMbjXYzHKfFzgJ2fYr+v/fDjqu9/HN+SDrz2LC6GGM/7fmzO+3U87R7SgS7FW3RD3Exf09Fu Ussl55iy3349w8yfxF8kOfQnxNr0Y2zO0t/Hzc3u4Vkky3g9Np9jdxOH+T75PN9/2axXm7i861KG 6cW7DSJ046rf8PMwrr53uJmetoP+0F8/3SOn6c3M3iKp6rS7Hvq95z12p+cPq27d3+69WK5XN3HP dsaB2e3Q3TefVrdPQ+Sxnj3dP16CEdnu2N2Jdp7w+RzIpzM+M/FJhs8X3PVzL84dMret3Etyg8dd F7dC3J9w08A7OW+vvOf9KVp1IFp7INpwIFp5IFpewq9f/QYvfpW2DQplbmRzdHJlYW0NCmVuZG9i ag0KNzUgMCBvYmoNClsgMjc4IDAgMCAwIDAgODg5IDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDU1 NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1 NiAwIDAgMCA1NTYgMCAwIDAgMCAwIDAgMjIyIDAgMCAwIDU1NiAwIDMzMyA1MDAgMCAwIDAgMCAw IDUwMF0gDQplbmRvYmoNCjc2IDAgb2JqDQpbIDI3OCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAw IDI3OCAzMzMgMCAwIDAgMCAwIDAgMCAwIDU1NiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNzIyIDcy MiAwIDAgMCAwIDAgMjc4IDAgMCAwIDAgMCAwIDY2NyAwIDAgNjY3IDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgNTU2IDAgMCA2MTEgNTU2IDAgNjExIDYxMSAyNzggMCAwIDI3OCA4ODkgNjExIDYx MSA2MTEgMCAzODkgNTU2IDMzMyAwIDU1NiA3NzhdIA0KZW5kb2JqDQo3NyAwIG9iag0KWyA5NDQg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYxMV0gDQplbmRv YmoNCjc4IDAgb2JqDQo8PC9UeXBlL1hSZWYvU2l6ZSA3OC9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIv SW5mbyAzIDAgUi9JRFs8RjY4M0RFN0U2QjdERUM0N0E4QjMxMEI2M0M5MTdBRTA+PEY2ODNERTdF NkI3REVDNDdBOEIzMTBCNjNDOTE3QUUwPl0gL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTgx Pj4NCnN0cmVhbQ0KeJw10ccNAlEMRdE/5DxkhpxzzrkSltQBZSBRCM1QChIaPr7ghY8s+a2eUnps 29A7ptSXCzwE4y44bkLoBC8h/BQiV8E8C1FTf+t4Uu1gDwfYwgbW8Ascv/H3/3KAAS5wggfc4AMv BMAPIQhCBMIQBRPiEIMkJCANKbAgAznIQgHyUIIiVKAMNahCA+rQgia0oQM96EIfhjCAEUxgDFOY wwwWsIKlLiDVkxrTeSFjKfUBdHAWVw0KZW5kc3RyZWFtDQplbmRvYmoNCnhyZWYNCjAgNzkNCjAw MDAwMDAwMTIgNjU1MzUgZg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAwMDAwMTI1IDAwMDAwIG4N CjAwMDAwMDAxODEgMDAwMDAgbg0KMDAwMDAwMDQwOSAwMDAwMCBuDQowMDAwMDAwNjYyIDAwMDAw IG4NCjAwMDAwMDMxNjMgMDAwMDAgbg0KMDAwMDAwMzMyMiAwMDAwMCBuDQowMDAwMDAzNTQ2IDAw MDAwIG4NCjAwMDAwMDM3MTAgMDAwMDAgbg0KMDAwMDAwMzkzOSAwMDAwMCBuDQowMDAwMDA0MTEx IDAwMDAwIG4NCjAwMDAwMDAwMTMgNjU1MzUgZg0KMDAwMDAwMDAxNCA2NTUzNSBmDQowMDAwMDAw MDE1IDY1NTM1IGYNCjAwMDAwMDAwMTYgNjU1MzUgZg0KMDAwMDAwMDAxNyA2NTUzNSBmDQowMDAw MDAwMDE4IDY1NTM1IGYNCjAwMDAwMDAwMTkgNjU1MzUgZg0KMDAwMDAwMDAyMCA2NTUzNSBmDQow MDAwMDAwMDIxIDY1NTM1IGYNCjAwMDAwMDAwMjIgNjU1MzUgZg0KMDAwMDAwMDAyMyA2NTUzNSBm DQowMDAwMDAwMDI0IDY1NTM1IGYNCjAwMDAwMDAwMjUgNjU1MzUgZg0KMDAwMDAwMDAyNiA2NTUz NSBmDQowMDAwMDAwMDI3IDY1NTM1IGYNCjAwMDAwMDAwMjggNjU1MzUgZg0KMDAwMDAwMDAyOSA2 NTUzNSBmDQowMDAwMDAwMDMwIDY1NTM1IGYNCjAwMDAwMDAwMzEgNjU1MzUgZg0KMDAwMDAwMDAz MiA2NTUzNSBmDQowMDAwMDAwMDMzIDY1NTM1IGYNCjAwMDAwMDAwMzQgNjU1MzUgZg0KMDAwMDAw MDAzNSA2NTUzNSBmDQowMDAwMDAwMDM2IDY1NTM1IGYNCjAwMDAwMDAwMzcgNjU1MzUgZg0KMDAw MDAwMDAzOCA2NTUzNSBmDQowMDAwMDAwMDM5IDY1NTM1IGYNCjAwMDAwMDAwNDAgNjU1MzUgZg0K MDAwMDAwMDA0MSA2NTUzNSBmDQowMDAwMDAwMDQyIDY1NTM1IGYNCjAwMDAwMDAwNDMgNjU1MzUg Zg0KMDAwMDAwMDA0NCA2NTUzNSBmDQowMDAwMDAwMDQ1IDY1NTM1IGYNCjAwMDAwMDAwNDYgNjU1 MzUgZg0KMDAwMDAwMDA0NyA2NTUzNSBmDQowMDAwMDAwMDQ4IDY1NTM1IGYNCjAwMDAwMDAwNDkg NjU1MzUgZg0KMDAwMDAwMDA1MCA2NTUzNSBmDQowMDAwMDAwMDUxIDY1NTM1IGYNCjAwMDAwMDAw NTIgNjU1MzUgZg0KMDAwMDAwMDA1MyA2NTUzNSBmDQowMDAwMDAwMDU0IDY1NTM1IGYNCjAwMDAw MDAwNTUgNjU1MzUgZg0KMDAwMDAwMDA1NiA2NTUzNSBmDQowMDAwMDAwMDU3IDY1NTM1IGYNCjAw MDAwMDAwNTggNjU1MzUgZg0KMDAwMDAwMDA1OSA2NTUzNSBmDQowMDAwMDAwMDYwIDY1NTM1IGYN CjAwMDAwMDAwNjEgNjU1MzUgZg0KMDAwMDAwMDA2MiA2NTUzNSBmDQowMDAwMDAwMDYzIDY1NTM1 IGYNCjAwMDAwMDAwNjQgNjU1MzUgZg0KMDAwMDAwMDA2NSA2NTUzNSBmDQowMDAwMDAwMDY2IDY1 NTM1IGYNCjAwMDAwMDAwNjcgNjU1MzUgZg0KMDAwMDAwMDA2OCA2NTUzNSBmDQowMDAwMDAwMDY5 IDY1NTM1IGYNCjAwMDAwMDAwNzAgNjU1MzUgZg0KMDAwMDAwMDA3MSA2NTUzNSBmDQowMDAwMDAw MDcyIDY1NTM1IGYNCjAwMDAwMDAwNzMgNjU1MzUgZg0KMDAwMDAwMDA3NCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDU0MTggMDAwMDAgbg0KMDAwMDAwNTY1OSAwMDAwMCBuDQow MDAwMDA1OTEyIDAwMDAwIG4NCjAwMDAwMDU5ODkgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSA3 OS9Sb290IDEgMCBSL0luZm8gMyAwIFIvSURbPEY2ODNERTdFNkI3REVDNDdBOEIzMTBCNjNDOTE3 QUUwPjxGNjgzREU3RTZCN0RFQzQ3QThCMzEwQjYzQzkxN0FFMD5dID4+DQpzdGFydHhyZWYNCjYz NzANCiUlRU9GDQp4cmVmDQowIDANCnRyYWlsZXINCjw8L1NpemUgNzkvUm9vdCAxIDAgUi9JbmZv IDMgMCBSL0lEWzxGNjgzREU3RTZCN0RFQzQ3QThCMzEwQjYzQzkxN0FFMD48RjY4M0RFN0U2QjdE RUM0N0E4QjMxMEI2M0M5MTdBRTA+XSAvUHJldiA2MzcwL1hSZWZTdG0gNTk4OT4+DQpzdGFydHhy ZWYNCjgxMDUNCiUlRU9G ------=_NextPart_000_000A_01CD43C5.A17B67D0-- From lear@cisco.com Wed Jun 6 02:27:25 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3537321F868A; Wed, 6 Jun 2012 02:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.53 X-Spam-Level: X-Spam-Status: No, score=-110.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ5QM0TGHvP6; Wed, 6 Jun 2012 02:27:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A161721F858E; Wed, 6 Jun 2012 02:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=7591; q=dns/txt; s=iport; t=1338974843; x=1340184443; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ZF4sQJhbnX9S5wByBTpE9Z34i9WZ6Uy3vu+YMzdFpCE=; b=j65UT51RsYn93djaBJtUNBLpDqGt0SxNANLjZk9xqfjN6lHr5d7mNrPC 1qPJ1CwGb//qew6J7BG2+qiSaE/hh8kHMktOOScT5NEt9V+zOtAiQUUx2 cjuPRGX5oW2WcbCgZx8YGvJ0yiuUFmD0hPyjucTt/1U7cfBozaP+C81cM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACUiz0+Q/khM/2dsb2JhbABFDoVArmKBB4IYAQEBBBIBEFUBEAkCGAkWCwICCQMCAQIBRQYNAQUCAQEFGYdpC5ckjRaSZYsUhQeBEgOVHI4SgWaCJzs X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208,217";a="139198384" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 06 Jun 2012 09:27:14 +0000 Received: from dhcp-10-55-81-197.cisco.com (dhcp-10-55-81-197.cisco.com [10.55.81.197]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q569RDCK020222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 09:27:14 GMT Message-ID: <4FCF2271.6090705@cisco.com> Date: Wed, 06 Jun 2012 11:27:13 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Joe Touch References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> In-Reply-To: <4FCD4E0F.2080100@isi.edu> X-Enigmail-Version: 1.4.1 Content-Type: multipart/alternative; boundary="------------050206090500040305030108" Cc: tsvwg@ietf.org, "saag@ietf.org" Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 09:27:25 -0000 This is a multi-part message in MIME format. --------------050206090500040305030108 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Joe, I support the development of this draft, and would be willing to provide you with both content and editorial assistance. I would ask that (at least) one additional important question be considered by this group and the security area: * Is a request for a static port assignment in order to accommodate firewalls still an appropriate reason? I ask this question because there have been applications for as many as six ports for related or very similar services that could all be dynamically discovered from one. Some come back and say that they are concerned that firewalls will prevent the service from functioning properly. What is the IETF's point of view on this? Eliot On 6/5/12 2:08 AM, Joe Touch wrote: > Hi, all, > > I've resubmitted this as a WG doc. The major changes were to include > full references for previous placeholders and a few minor notes. > > It would be useful to get feedback on whether there are any areas that > should be addressed that are not listed before diving into the two key > issues I hope we can discuss as part of this doc: > > - whether to deprecate the distinction between system and > user ports (or to do nothing at this time) > > - whether to make stronger recommendations on the use of > security on port services (i.e., whether security "should" > be supported for new services, or to make no specific > recommendation at this time) > > Any gap material notes would be most useful now, though. > > Joe > > On 5/31/2012 11:34 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Transport Area Working >> Group Working Group of the IETF. >> >> Title : Recommendations for Transport Port Uses >> Author(s) : Joe Touch >> Filename : draft-ietf-tsvwg-port-use-00.txt >> Pages : 11 >> Date : 2012-05-30 >> >> This document provides recommendations to application and service >> designers on how to use the transport protocol port number space to >> help in its preservation. **NOTE THAT THIS CURRENT VERSION IS >> LARGELY AN OUTLINE OF ISSUES**. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ >> > > --------------050206090500040305030108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Joe,

I support the development of this draft, and would be willing to provide you with both content and editorial assistance.  I would ask that (at least) one additional important question be considered by this group and the security area:
  • Is a request for a static port assignment in order to accommodate firewalls still an appropriate reason?

I ask this question because there have been applications for as many as six ports for related or very similar services that could all be dynamically discovered from one.  Some come back and say that they are concerned that firewalls will prevent the service from functioning properly.  What is the IETF's point of view on this?

Eliot

On 6/5/12 2:08 AM, Joe Touch wrote:
Hi, all,

I've resubmitted this as a WG doc. The major changes were to include full references for previous placeholders and a few minor notes.

It would be useful to get feedback on whether there are any areas that should be addressed that are not listed before diving into the two key issues I hope we can discuss as part of this doc:

    - whether to deprecate the distinction between system and
    user ports (or to do nothing at this time)

    - whether to make stronger recommendations on the use of
    security on port services (i.e., whether security "should"
    be supported for new services, or to make no specific
    recommendation at this time)

Any gap material notes would be most useful now, though.

Joe

On 5/31/2012 11:34 PM, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF.

    Title           : Recommendations for Transport Port Uses
    Author(s)       : Joe Touch
    Filename        : draft-ietf-tsvwg-port-use-00.txt
    Pages           : 11
    Date            : 2012-05-30

    This document provides recommendations to application and service
    designers on how to use the transport protocol port number space to
    help in its preservation. **NOTE THAT THIS CURRENT VERSION IS
    LARGELY AN OUTLINE OF ISSUES**.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/



--------------050206090500040305030108-- From touch@isi.edu Wed Jun 6 13:27:17 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B1C21F8505; Wed, 6 Jun 2012 13:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.68 X-Spam-Level: X-Spam-Status: No, score=-102.68 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pWDLdL0+g6A; Wed, 6 Jun 2012 13:27:16 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7566A21F84CF; Wed, 6 Jun 2012 13:27:11 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q56KQsRS018230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Jun 2012 13:26:54 -0700 (PDT) Message-ID: <4FCFBD0E.1070603@isi.edu> Date: Wed, 06 Jun 2012 13:26:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eliot Lear References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <4FCF2271.6090705@cisco.com> In-Reply-To: <4FCF2271.6090705@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org, "saag@ietf.org" Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 20:27:17 -0000 On 6/6/2012 2:27 AM, Eliot Lear wrote: > Joe, > > I support the development of this draft, and would be willing to provide > you with both content and editorial assistance. I would ask that (at > least) one additional important question be considered by this group and > the security area: > > * Is a request for a static port assignment in order to accommodate > firewalls still an appropriate reason? Good point - I think that this is still inevitable for one assignment. FWIW, I don't see a reason for 6 of anything - separate connections to a single port can often suffice in such cases, and firewall management for more than one port is complex (what happens when only a subset of the ports are open? how do you know, and how do you recover?). Joe > > I ask this question because there have been applications for as many as > six ports for related or very similar services that could all be > dynamically discovered from one. Some come back and say that they are > concerned that firewalls will prevent the service from functioning > properly. What is the IETF's point of view on this? > > Eliot > > On 6/5/12 2:08 AM, Joe Touch wrote: >> Hi, all, >> >> I've resubmitted this as a WG doc. The major changes were to include >> full references for previous placeholders and a few minor notes. >> >> It would be useful to get feedback on whether there are any areas that >> should be addressed that are not listed before diving into the two key >> issues I hope we can discuss as part of this doc: >> >> - whether to deprecate the distinction between system and >> user ports (or to do nothing at this time) >> >> - whether to make stronger recommendations on the use of >> security on port services (i.e., whether security "should" >> be supported for new services, or to make no specific >> recommendation at this time) >> >> Any gap material notes would be most useful now, though. >> >> Joe >> >> On 5/31/2012 11:34 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Transport Area Working >>> Group Working Group of the IETF. >>> >>> Title : Recommendations for Transport Port Uses >>> Author(s) : Joe Touch >>> Filename : draft-ietf-tsvwg-port-use-00.txt >>> Pages : 11 >>> Date : 2012-05-30 >>> >>> This document provides recommendations to application and service >>> designers on how to use the transport protocol port number space to >>> help in its preservation. **NOTE THAT THIS CURRENT VERSION IS >>> LARGELY AN OUTLINE OF ISSUES**. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt >>> >>> The IETF datatracker page for this Internet-Draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ >>> >> >> From ckdwibedy@yahoo.com Thu Jun 7 11:24:58 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3082311E80ED for ; Thu, 7 Jun 2012 11:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyFB06iyNgUT for ; Thu, 7 Jun 2012 11:24:57 -0700 (PDT) Received: from nm21-vm0.bullet.mail.ac4.yahoo.com (nm21-vm0.bullet.mail.ac4.yahoo.com [98.139.53.216]) by ietfa.amsl.com (Postfix) with SMTP id ABFDD21F8658 for ; Thu, 7 Jun 2012 11:24:54 -0700 (PDT) Received: from [98.139.52.191] by nm21.bullet.mail.ac4.yahoo.com with NNFMP; 07 Jun 2012 18:24:51 -0000 Received: from [98.139.52.145] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 07 Jun 2012 18:24:51 -0000 Received: from [127.0.0.1] by omp1028.mail.ac4.yahoo.com with NNFMP; 07 Jun 2012 18:24:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 630352.24783.bm@omp1028.mail.ac4.yahoo.com Received: (qmail 89583 invoked by uid 60001); 7 Jun 2012 18:24:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1339093489; bh=FhMLorrEL6vYnRLnj3VPbRPE/cJKudlaiOs+6/cgeY8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sMoo/J14dpRxM6qJxdc5gewmKoSiL8VDtpPapIkVlRSTOgKyoP0BPHzrULgEcoA+5eNSKIzaNRtnRvZH1aaBfgaYGoQtyA6in4yd7QdPa4A6+/oBXsDef3nbF1QcjePZqzBDrQAQ7A/xn4QkxP+jRAweDxcbsTjwDd6EMb6RSeA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xfEmtUoF0Zvf79VkCObz0TU3Yu8pp62Awb0OZ5+xuJWRM9DnCFbpvQ5Y5LcDHEAX2BvrvxCFSfSL2C9sx9j3QnF9VAlGEbPg7uD7HCLDArnnKK2KvstLmiH8jzMFNPlQXL9RKUmvDp9ya+odPpQVbtphUwwKxILrSab9vjlp1SY=; X-YMail-OSG: VPR48BAVM1m_gJq4cqnYCqxcoYBjJOm.Rvugcn5SNSAvbjJ 5H9uGmY3ypaW2yXPR3FTcIOz9Gh6iPxiVByHwPwwtBhftXuB8fxhxU2uKIn6 AOZYkEYDSi3EtKsYm783Bu9qyFgRhLIZEzTMO7hDkAONRo0ttq4d_VN98ZDg ywrfNheu.OzDazxZDsAVz8FNLj.o6TKRYYnASd44da6lEI9pYsiX4pkNSp6E fvNi7YWumL8TqqVBBquWky3W_We38O70UxXJdBKxSq61On1z2LrBsAl81CZM .UF9M9CS5MYRFHND9I9iRxDARIvrwzeQQKuDb05GQTWdJhcbdtivp5uqoDZn SKwDoH9wbf3BmvTszI0MOPPuvIp7beV2_PlhN0S_zyBE.wwqw.H8cdGN.2wi itKnF69RTPsj04Cq1kmR5U8hIiLE6NlZ_VhDB7I8_tVndeCZ2FwbKIGBb9Iv yPObUtML_3jTJC5IYDJx7z62b Received: from [117.197.253.92] by web130106.mail.mud.yahoo.com via HTTP; Thu, 07 Jun 2012 11:24:49 PDT X-Mailer: YahooMailWebService/0.8.118.349524 References: <4FBE562E.6000909@gmail.com> <1338463399.19395.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338467385.57530.YahooMailNeo@web130105.mail.mud.yahoo.com> <1338489317.38384.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338492008.97916.YahooMailNeo@web130103.mail.mud.yahoo.com> Message-ID: <1339093489.85309.YahooMailNeo@web130106.mail.mud.yahoo.com> Date: Thu, 7 Jun 2012 11:24:49 -0700 (PDT) From: Chinmaya Dwibedy To: Randy Stewart In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1528062040-1910670411-1339093489=:85309" Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] =?utf-8?q?When_SCTP_server_is_restarted=2C_DATA_chunks_st?= =?utf-8?q?art_to_get_dropped_or_lost_after_sometime_at_SCTP_client?= =?utf-8?b?4oCZcyBlbmQu?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Chinmaya Dwibedy List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 18:24:58 -0000 --1528062040-1910670411-1339093489=:85309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mr. Randy Stewart,=0AThanks a lot for your valuable suggestion. We turne= d off Partial Reliability and set the 0 ms timetolive in sctp_sendmsg () AP= I. Thereafter there was no loss in DATA chunks, upon restarting the peer (i= .e., SCTP server). =0ABut when the peer (i.e., SCTP server) gets restarted,= =0A1)=C2=A0=C2=A0=C2=A0=C2=A0 All the SCTP clients receive INIT messages (w= ith same address to the association) from SCTP server. The INIT ACK is bein= g sent with the new InitTag and Verification Tag set to the InitTag receive= d in INIT for each association. =C2=A0The four-way handshake gets completed= .=0A2)=C2=A0=C2=A0=C2=A0 Though there is no loss but we encountered another= issue i.e., for one or two associations, it performs chunk bundling by coa= lescing of multiple DATA chunks into a single SCTP packet and unnecessary d= elays are introduced. Unexpectedly it takes more than 20 seconds to put the= data on the wire, which was never the case before restart.=0ANotes: =0Aa)= =C2=A0=C2=A0=C2=A0 Our SCTP client application has requested kernel to not = to bundle by making SCTP_NODELAY on. Of course the kernel does=C2=A0=C2=A0 = not in itself stop all bundling from occurring (i.e., in case of congestion= or retransmission.=0Ab)=C2=A0=C2=A0=C2=A0 Peer has sent a_rwnd of 131072 b= ytes sent in the INIT when it restarts. It indicates that the peer has suff= icient buffer space.=0Ac)=C2=A0=C2=A0=C2=A0 Our client program (C++) runnin= g under RHEL4 (using kernel version: 2.6.9-55ELsmp and lksctp-tools-1.0.8-1= ).=0AWhat I understand, the excess delay most likely due to a stall caused = by congestion or peer flow control. Does it reset ssthresh to the correct v= alue (peer's a_rwnd) if the association has been restarted or it consists o= f SCTP_DEFAULT_MAXWINDOW (i.e., 65535)?=0AWhen restarting association,=0Aa)= =C2=A0=C2=A0=C2=A0 Does the Linux kernel reset the transport congestion var= iables?=0Ab)=C2=A0=C2=A0=C2=A0 Does it reset the cwnd (Congestion window va= lues for destination address)? =0AWhat I think, if it will be consisting th= e old values (i.e., =C2=A0cwnd, ssthresh) after occurrence of restart then,= it must not be transmitting new data to a peer since it will have wrong im= pression of old cwnd bytes of data outstanding to peer.Can anyone please va= lidate my understanding and correct me if I am wrong. =C2=A0Please point me= to right direction to fix this issue. Thanking you in advance for your res= ponse.=0ARegards,=0AChinmaya=0A=0A=0A=0A________________________________=0A= From: Randy Stewart =0ATo: Chinmaya Dwibedy =0ACc: Chris Benson ; "tsvwg@ietf.org" =0ASent: Friday, June 1, 2012 5:05 AM=0ASubject: Re: [tsvwg] Wh= en SCTP server is restarted, DATA chunks start to get dropped or lost after= sometime at SCTP client=E2=80=99s end.=0A=0AChinmaya:=0A=0AI would use tha= t has a starting point. Don't put a time-to-expire on it and see if=0Ayou n= o longer see this behavior. If you do, then it sounds like a bug in the lin= ux kernel=0Aimplementation=0A=0AR=0AOn May 31, 2012, at 3:20 PM, Chinmaya D= wibedy wrote:=0A=0A> Hi Chris,=0A> Thanks for your response.=0A> Our applic= ation consumes the message fast enough. Note that, we are using single Inte= l Xeon Quad-Core L5518 processor, 8 logical CPUs (speed of the processor is= 2.13GHz) and 12GB RAM. Moreover there are no other apps running on besides= our application. This problem appears after SCTP server gets restarted. Th= ere is absolutely no packets drop if we won=E2=80=99t restart the server.= =0A>=C2=A0 =0A> Do you recommend us to try with 0 ms timetolive which indic= ates no timeout should occur on this message and is treated as reliable?=0A= >=C2=A0 =0A> Regards,=0A> Chinmaya=0A> =0A> From: Chris Benson =0A> To: Chinmaya Dwibedy =0A> Cc: "tsvwg@ietf.= org" =0A> Sent: Friday, June 1, 2012 12:13 AM=0A> Subject:= Re: [tsvwg] When SCTP server is restarted, DATA chunks start to get droppe= d or lost after sometime at SCTP client=E2=80=99s end.=0A> =0A> Chinmaya,= =0A> =0A> Please forgive me if this is too basic and obvious a question.=0A= > =0A> Are you sure that your "application" (SCTP-user) at the client =0A> = side is consuming the incoming data AT LEAST AS FAST as it arrives?=0A> =0A= > If not, then you will see something like the behaviour you =0A> describe.= With thanks, from Chris=0A> =0A> On Thu, 31 May 2012, Chinmaya Dwibedy wro= te:=0A> =0A> >>=C2=A0 Date: Thu, 31 May 2012 11:35:17 -0700 (PDT)=0A> >>=C2= =A0 From: Chinmaya Dwibedy =0A> >>=C2=A0 To: "tsvwg@ie= tf.org" =0A> >>=C2=A0 Subject: [tsvwg] When SCTP server is = restarted,=0A> >>=C2=A0 =C2=A0 =C2=A0 DATA chunks start to get dropped or l= ost after sometime at SCTP client=0A> >>=C2=A0 =C2=A0 =C2=A0 end.=0A> >>=C2= =A0 =0A> >>=C2=A0 Hi, =0A> We have SCTP client program (C++) running under = RHEL4 (using kernel version: 2.6.9-55ELsmp and lksctp-tools-1.0.8-1). We ar= e using one-to-one style socket using connect () system call to setup an as= sociation with a SCTP server (i.e., SUT of vendor). Then it calls sctp_send= msg () library function to send a message from a socket while using the fol= lowing advanced features of SCTP (i.e., SCTP_UNORDERED for un-ordered deliv= ery of the message) and timetolive (TTL) is set to 1000 milliseconds for a = given message. We have typical defaults values for these RTO.Initial =3D 30= 00, RTO.Min =3D 1000, RTO.Max =3D 60000 milliseconds.The PR-SCTP extension = is enabled in the kernel (by default).=0A> We are using lot (4000) SCTP ass= ociations on a single system, all are in ESTABLISHED state and data communi= cation goes on fine without any drop/loss of message. But when the peer (i.= e., SCTP server) gets restarted, =0A> a)=C2=A0 =C2=A0 All the SCTP clients = receive INIT messages (with same address to the association) from SCTP serv= er. The INIT ACK is being sent with the new InitTag and Verification Tag se= t to the InitTag received in INIT for each association. =0A> b)=C2=A0 =C2= =A0 The four-way handshake gets completed. I believe the existing associati= on, including its current state, and the corresponding TCB does not get cha= nged. =0A> c)=C2=A0 =C2=A0 Afterward, all SCTP clients use DATA chunks to e= xchange information with SCTP server.=0A> The trouble is that, after someti= me (30-45 minutes), DATA chunks start to get dropped or lost and that goes = on increasing as the time advances.The data was not transmitted to the peer= at least once. Note that, the time after which this problem is being encou= ntered is also not consistent. I mean to say, sometime we noticed after 30 = minutes, 45 minutes and an hour. But when we lessen the number of SCTP asso= ciations to 2000, such problem does not appear.=C2=A0 =C2=A0 =0A> =0A> =0A>= a)=C2=A0 =C2=A0 Is there any chance that, that data messages time-out with= in the RTO although both the values are same? As a result, the data will be= skipped and no longer transmitted.=0A> b)=C2=A0 =C2=A0 Does it indicate th= at the message could never be transmitted to the peer (e.g., flow control p= revented the message from being sent before its lifetime expired), so the p= eer never received it? Please note that, we are using 1 Gig Intel NIC. =0A>= The preliminary=C2=A0 analysis says that, timetolive (in sctp_sendmsg() AP= I) can be set on a message independent of Partial Reliability.The timer (i.= e., sinfo_timetolive) only runs while the message is in the kernel send buf= fer and has not yet been put on the wire (for the first time). As soon as t= he message is put on the wire the first time, the timer is dropped. It is u= sed to indicate that a time based lifetime is being applied to the data.=C2= =A0 It is then a number of milliseconds for which the data is attempted to = be transmitted. If that many milliseconds elapsed and the data has not been= transmitted, As a result, they move the abandoned list and are never retra= nsmitted. Please feel free to correct me if I am wrong.=0A> Should we try w= ith 0 ms timetolive which indicates no timeout should occur on this message= and is treated as reliable? Please suggest and also let me know if you nee= d any additional information.=0A> Thanking you in advance for your response= . =0A> Regards,=0A> Chinmaya=0A> =0A=0A-----=0ARandall Stewart=0Arandall@la= kerest.net --1528062040-1910670411-1339093489=:85309 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Mr. Randy Stewart,<= ?xml:namespace prefix =3D o ns =3D "urn:schemas-microsoft-com:office:office= " />
Thanks a lot for your = valuable suggestion. We turned off Partial Reliability and set the 0 ms tim= etolive in sctp_sendmsg () API. Thereafter there was no loss in DATA chunks, upon restarting the peer (i.e., SCTP = server).
But when the peer (i.e., SCTP server) gets restarted,
1)     All the SCTP clients receive INIT messages (with same a= ddress to the association) from SCTP server. The INIT ACK is being sent wit= h the new InitTag and Verification Tag set to the InitTag received in INIT = for each association.  The fo= ur-way handshake gets completed.
2)    Though there is no loss but we encountered another issue i.e.= , for one or two associations, it performs chunk bundling by coalescing of = multiple DATA chunks into a single SCTP packet and unnecessary delays are i= ntroduced. Unexpectedly it takes more than 20 seconds to put the data on th= e wire, which was never the case before restart.
Notes:
a)    Our SCTP client application has requested kernel to not to bu= ndle by making SCTP_NODELAY on. Of course the kernel does   not in itself stop all bundling from oc= curring (i.e., in case of congestion or retransmission.
b)    Peer has sent a_rwnd of = 131072 bytes sent in the INIT when it restarts. It indicates that the peer = has sufficient buffer space.
= c)    Ou= r client program (C++) running under RHEL4 (using kernel version: 2.6.9-55E= Lsmp and lksctp-tools-1.0.8-1).
What I understand, the= excess delay most likely due to a stall caused by congestion or peer flow = control. Does it reset ssthresh to the correct value (peer's a_rwnd) if the= association has been restarted or it consists of SCTP_DEFAULT_MAXWINDOW (i= .e., 65535)?
When restarting associ= ation,
a)   = Does the Linux kernel reset the transport conge= stion variables?
b)   = Does it reset the cwnd (Congestion window value= s for destination address)?
What I think, if it wi= ll be consisting the old values (i.e., &n= bsp;cwnd, ssthresh) after occurrence of restart then, it must not be= transmitting new data to a peer since it will have wrong impression of old= cwnd bytes of data outstanding to peer. Can anyone please validate my understanding and correct me if I am wrong.=  Please point me to right di= rection to fix this issue. Thanking you in advance for your response.
Regards,
Chinmaya


From:= Randy Stewart <randall@lakerest.net>
To: Chinmaya Dwibedy <ckdwibedy@yahoo.com= >
Cc: Chris Benson &= lt;cbenson@adax.com>; "tsvwg@ietf.org" <tsvwg@ietf.org>
Sent: Friday, June 1, 2012 5:05 A= M
Subject: Re: [tsvwg] W= hen SCTP server is restarted, DATA chunks start to get dropped or lost afte= r sometime at SCTP client=E2=80=99s end.

Chinmaya:
<= BR>I would use that has a starting point. Don't put a time-to-expire on it and see if
you n= o longer see this behavior. If you do, then it sounds like a bug in the lin= ux kernel
implementation

R
On May 31, 2012, at 3:20 PM, Chinma= ya Dwibedy wrote:

> Hi Chris,
> Thanks for your response.> Our application consumes the message fast enough. Note that, we are = using single Intel Xeon Quad-Core L5518 processor, 8 logical CPUs (speed of= the processor is 2.13GHz) and 12GB RAM. Moreover there are no other apps r= unning on besides our application. This problem appears after SCTP server g= ets restarted. There is absolutely no packets drop if we won=E2=80=99t rest= art the server.

> Do you recommend us to try with 0 ms= timetolive which indicates no timeout should occur on this message and is = treated as reliable?

> Regards,
> Chinmaya
&g= t;
> From: Chris Benson <cbenson@adax.com>
> To: C= hinmaya Dwibedy <ckdwibedy@yahoo.com>
> Cc: "tsvwg@ietf.org" <= tsvwg@ietf.org>
> Sent: Friday, June 1, 2012 12:13 AM
>= Subject: Re: [tsvwg] When SCTP server is restarted, DATA chunks start to g= et dropped or lost after sometime at SCTP client=E2=80=99s end.
> > Chinmaya,
>
> Please forgive me if this is too basic and= obvious a question.
>
> Are you sure that your "application" = (SCTP-user) at the client
> side is consuming the incoming data AT L= EAST AS FAST as it arrives?
>
> If not, then you will see some= thing like the behaviour you
> describe. With thanks, from Chris
= >
> On Thu, 31 May 2012, Chinmaya Dwibedy wrote:
>
> >>&nbs= p; Date: Thu, 31 May 2012 11:35:17 -0700 (PDT)
> >>  From:= Chinmaya Dwibedy <ckdwibedy@yahoo.com>
> >> = To: "t= svwg@ietf.org" <tsvwg@ietf.org>
> >>  Subject: [tsv= wg] When SCTP server is restarted,
> >>      DAT= A chunks start to get dropped or lost after sometime at SCTP client
>= >>      end.
> >> 
> >>=   Hi,
> We have SCTP client program (C++) running under RHEL4 (= using kernel version: 2.6.9-55ELsmp and lksctp-tools-1.0.8-1). We are using= one-to-one style socket using connect () system call to setup an associati= on with a SCTP server (i.e., SUT of vendor). Then it calls sctp_sendmsg () li= brary function to send a message from a socket while using the following ad= vanced features of SCTP (i.e., SCTP_UNORDERED for un-ordered delivery of th= e message) and timetolive (TTL) is set to 1000 milliseconds for a given mes= sage. We have typical defaults values for these RTO.Initial =3D 3000, RTO.M= in =3D 1000, RTO.Max =3D 60000 milliseconds.The PR-SCTP extension is enable= d in the kernel (by default).
> We are using lot (4000) SCTP associat= ions on a single system, all are in ESTABLISHED state and data communicatio= n goes on fine without any drop/loss of message. But when the peer (i.e., S= CTP server) gets restarted,
> a)    All the SCTP clients r= eceive INIT messages (with same address to the association) from SCTP serve= r. The INIT ACK is being sent with the new InitTag and Verification Tag set= to the InitTag received in INIT for each association.
> b)    The four-way handshake gets completed. I believe the existing assoc= iation, including its current state, and the corresponding TCB does not get= changed.
> c)    Afterward, all SCTP clients use DATA chu= nks to exchange information with SCTP server.
> The trouble is that, = after sometime (30-45 minutes), DATA chunks start to get dropped or lost an= d that goes on increasing as the time advances.The data was not transmitted= to the peer at least once. Note that, the time after which this problem is= being encountered is also not consistent. I mean to say, sometime we notic= ed after 30 minutes, 45 minutes and an hour. But when we lessen the number = of SCTP associations to 2000, such problem does not appear.    >
>
> a)    Is there any chance that, that dat= a messages time-out within the RTO although both the values are same? As a = result, the data will be skipped and no longer transmitted.
> b)    Does it indicate that the message could never be transmitt= ed to the peer (e.g., flow control prevented the message from being sent be= fore its lifetime expired), so the peer never received it? Please note that= , we are using 1 Gig Intel NIC.
> The preliminary  analysis say= s that, timetolive (in sctp_sendmsg() API) can be set on a message independ= ent of Partial Reliability.The timer (i.e., sinfo_timetolive) only runs whi= le the message is in the kernel send buffer and has not yet been put on the= wire (for the first time). As soon as the message is put on the wire the f= irst time, the timer is dropped. It is used to indicate that a time based l= ifetime is being applied to the data.  It is then a number of millisec= onds for which the data is attempted to be transmitted. If that many millis= econds elapsed and the data has not been transmitted, As a result, they mov= e the abandoned list and are never retransmitted. Please feel free to correct me if I am wrong.
> Should we try with 0 ms timetolive wh= ich indicates no timeout should occur on this message and is treated as rel= iable? Please suggest and also let me know if you need any additional infor= mation.
> Thanking you in advance for your response.
> Regards= ,
> Chinmaya
>

-----
Randall Stewart
randall= @lakerest.net






--1528062040-1910670411-1339093489=:85309-- From Michael.Tuexen@lurchi.franken.de Thu Jun 7 13:13:04 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AFE11E80AD for ; Thu, 7 Jun 2012 13:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM7ZB1bTMXZ3 for ; Thu, 7 Jun 2012 13:13:03 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 1A91F11E80AA for ; Thu, 7 Jun 2012 13:13:02 -0700 (PDT) Received: from [192.168.1.103] (p508FB23B.dip.t-dialin.net [80.143.178.59]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 751DA1C0C0BCA; Thu, 7 Jun 2012 22:13:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Michael Tuexen In-Reply-To: <1339093489.85309.YahooMailNeo@web130106.mail.mud.yahoo.com> Date: Thu, 7 Jun 2012 22:12:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FBE562E.6000909@gmail.com> <1338463399.19395.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338467385.57530.YahooMailNeo@web130105.mail.mud.yahoo.com> <1338489317.38384.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338492008.97916.YahooMailNeo@web130103.mail.mud.yahoo.com> <1339093489.85309.YahooMailNeo@web130106.mail.mud.yahoo.com> To: Chinmaya Dwibedy X-Mailer: Apple Mail (2.1278) Cc: "tsvwg@ietf.org" , Randy Stewart Subject: Re: [tsvwg] =?windows-1252?q?When_SCTP_server_is_restarted=2C_DATA_ch?= =?windows-1252?q?unks_start_to_get_dropped_or_lost_after_sometime_at_SCTP?= =?windows-1252?q?_client=92s_end=2E?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 20:13:04 -0000 On Jun 7, 2012, at 8:24 PM, Chinmaya Dwibedy wrote: > Hi Mr. Randy Stewart, > Thanks a lot for your valuable suggestion. We turned off Partial = Reliability and set the 0 ms timetolive in sctp_sendmsg () API. = Thereafter there was no loss in DATA chunks, upon restarting the peer = (i.e., SCTP server). > But when the peer (i.e., SCTP server) gets restarted, > 1) All the SCTP clients receive INIT messages (with same address = to the association) from SCTP server. The INIT ACK is being sent with = the new InitTag and Verification Tag set to the InitTag received in INIT = for each association. The four-way handshake gets completed. > 2) Though there is no loss but we encountered another issue i.e., = for one or two associations, it performs chunk bundling by coalescing of = multiple DATA chunks into a single SCTP packet and unnecessary delays = are introduced. Unexpectedly it takes more than 20 seconds to put the = data on the wire, which was never the case before restart. > Notes: > a) Our SCTP client application has requested kernel to not to = bundle by making SCTP_NODELAY on. Of course the kernel does not in = itself stop all bundling from occurring (i.e., in case of congestion or = retransmission. > b) Peer has sent a_rwnd of 131072 bytes sent in the INIT when it = restarts. It indicates that the peer has sufficient buffer space. > c) Our client program (C++) running under RHEL4 (using kernel = version: 2.6.9-55ELsmp and lksctp-tools-1.0.8-1). > What I understand, the excess delay most likely due to a stall caused = by congestion or peer flow control. Does it reset ssthresh to the = correct value (peer's a_rwnd) if the association has been restarted or = it consists of SCTP_DEFAULT_MAXWINDOW (i.e., 65535)? > When restarting association, > a) Does the Linux kernel reset the transport congestion variables? > b) Does it reset the cwnd (Congestion window values for destination = address)? > What I think, if it will be consisting the old values (i.e., cwnd, = ssthresh) after occurrence of restart then, it must not be transmitting = new data to a peer since it will have wrong impression of old cwnd bytes = of data outstanding to peer. Can anyone please validate my understanding = and correct me if I am wrong. Please point me to right direction to fix = this issue. Thanking you in advance for your response. > Regards, > Chinmaya Chinmaya: This question is related to the Linux implementation, not the = protocol. So please please use the mailing list for the Linux Kernel implementation. (You = even got an answer there from the Linux SCTP maintainer). Best regards Michael >=20 >=20 > From: Randy Stewart > To: Chinmaya Dwibedy =20 > Cc: Chris Benson ; "tsvwg@ietf.org" =20= > Sent: Friday, June 1, 2012 5:05 AM > Subject: Re: [tsvwg] When SCTP server is restarted, DATA chunks start = to get dropped or lost after sometime at SCTP client=92s end. >=20 > Chinmaya: >=20 > I would use that has a starting point. Don't put a time-to-expire on = it and see if > you no longer see this behavior. If you do, then it sounds like a bug = in the linux kernel > implementation >=20 > R > On May 31, 2012, at 3:20 PM, Chinmaya Dwibedy wrote: >=20 > > Hi Chris, > > Thanks for your response. > > Our application consumes the message fast enough. Note that, we are = using single Intel Xeon Quad-Core L5518 processor, 8 logical CPUs (speed = of the processor is 2.13GHz) and 12GB RAM. Moreover there are no other = apps running on besides our application. This problem appears after SCTP = server gets restarted. There is absolutely no packets drop if we won=92t = restart the server. > > =20 > > Do you recommend us to try with 0 ms timetolive which indicates no = timeout should occur on this message and is treated as reliable? > > =20 > > Regards, > > Chinmaya > >=20 > > From: Chris Benson > > To: Chinmaya Dwibedy =20 > > Cc: "tsvwg@ietf.org" =20 > > Sent: Friday, June 1, 2012 12:13 AM > > Subject: Re: [tsvwg] When SCTP server is restarted, DATA chunks = start to get dropped or lost after sometime at SCTP client=92s end. > >=20 > > Chinmaya, > >=20 > > Please forgive me if this is too basic and obvious a question. > >=20 > > Are you sure that your "application" (SCTP-user) at the client=20 > > side is consuming the incoming data AT LEAST AS FAST as it arrives? > >=20 > > If not, then you will see something like the behaviour you=20 > > describe. With thanks, from Chris > >=20 > > On Thu, 31 May 2012, Chinmaya Dwibedy wrote: > >=20 > > >> Date: Thu, 31 May 2012 11:35:17 -0700 (PDT) > > >> From: Chinmaya Dwibedy > > >> To: "tsvwg@ietf.org" > > >> Subject: [tsvwg] When SCTP server is restarted, > > >> DATA chunks start to get dropped or lost after sometime at = SCTP client > > >> end. > > >> =20 > > >> Hi,=20 > > We have SCTP client program (C++) running under RHEL4 (using kernel = version: 2.6.9-55ELsmp and lksctp-tools-1.0.8-1). We are using = one-to-one style socket using connect () system call to setup an = association with a SCTP server (i.e., SUT of vendor). Then it calls = sctp_sendmsg () library function to send a message from a socket while = using the following advanced features of SCTP (i.e., SCTP_UNORDERED for = un-ordered delivery of the message) and timetolive (TTL) is set to 1000 = milliseconds for a given message. We have typical defaults values for = these RTO.Initial =3D 3000, RTO.Min =3D 1000, RTO.Max =3D 60000 = milliseconds.The PR-SCTP extension is enabled in the kernel (by = default). > > We are using lot (4000) SCTP associations on a single system, all = are in ESTABLISHED state and data communication goes on fine without any = drop/loss of message. But when the peer (i.e., SCTP server) gets = restarted,=20 > > a) All the SCTP clients receive INIT messages (with same address = to the association) from SCTP server. The INIT ACK is being sent with = the new InitTag and Verification Tag set to the InitTag received in INIT = for each association.=20 > > b) The four-way handshake gets completed. I believe the existing = association, including its current state, and the corresponding TCB does = not get changed.=20 > > c) Afterward, all SCTP clients use DATA chunks to exchange = information with SCTP server. > > The trouble is that, after sometime (30-45 minutes), DATA chunks = start to get dropped or lost and that goes on increasing as the time = advances.The data was not transmitted to the peer at least once. Note = that, the time after which this problem is being encountered is also not = consistent. I mean to say, sometime we noticed after 30 minutes, 45 = minutes and an hour. But when we lessen the number of SCTP associations = to 2000, such problem does not appear. =20 > >=20 > >=20 > > a) Is there any chance that, that data messages time-out within = the RTO although both the values are same? As a result, the data will be = skipped and no longer transmitted. > > b) Does it indicate that the message could never be transmitted = to the peer (e.g., flow control prevented the message from being sent = before its lifetime expired), so the peer never received it? Please note = that, we are using 1 Gig Intel NIC.=20 > > The preliminary analysis says that, timetolive (in sctp_sendmsg() = API) can be set on a message independent of Partial Reliability.The = timer (i.e., sinfo_timetolive) only runs while the message is in the = kernel send buffer and has not yet been put on the wire (for the first = time). As soon as the message is put on the wire the first time, the = timer is dropped. It is used to indicate that a time based lifetime is = being applied to the data. It is then a number of milliseconds for = which the data is attempted to be transmitted. If that many milliseconds = elapsed and the data has not been transmitted, As a result, they move = the abandoned list and are never retransmitted. Please feel free to = correct me if I am wrong. > > Should we try with 0 ms timetolive which indicates no timeout should = occur on this message and is treated as reliable? Please suggest and = also let me know if you need any additional information. > > Thanking you in advance for your response.=20 > > Regards, > > Chinmaya > >=20 >=20 > ----- > Randall Stewart > randall@lakerest.net >=20 >=20 >=20 >=20 >=20 >=20 From jmpolk@cisco.com Thu Jun 14 14:30:59 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E5811E808F for ; Thu, 14 Jun 2012 14:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.203 X-Spam-Level: X-Spam-Status: No, score=-109.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gncyd1A5Il+c for ; Thu, 14 Jun 2012 14:30:58 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id DDDC111E808E for ; Thu, 14 Jun 2012 14:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=6416; q=dns/txt; s=iport; t=1339709458; x=1340919058; h=message-id:date:to:from:subject:in-reply-to:references: mime-version:content-transfer-encoding; bh=cZeHgWML7qt9tTq3NijS81LejduSgKiT8XagdU40P/g=; b=c9EgGevA6LiYR4Am1JqHEDRDjaPg+Woq/5HuhSxHJzjbwylOmsWWwyFW eNiwCl37S3oeZUMk42iD6MQgJ3il2Q0NKgSyWgLQVLz0FnOzxQ8yaIsk2 ezMevI5x99v2PdkhcLft6RNq54GgXJb5ED+A8Wb3Fhv4KO7E0iAfMTMvu A=; X-IronPort-AV: E=Sophos;i="4.75,773,1330905600"; d="scan'208";a="45883402" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 14 Jun 2012 21:30:57 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5ELUvgJ017407; Thu, 14 Jun 2012 21:30:57 GMT Message-Id: <201206142130.q5ELUvgJ017407@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 Jun 2012 16:19:05 -0500 To: , , From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [tsvwg] Comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:30:59 -0000 Georgios Thank you for your review. I apologize for not=20 responding earlier. I tend to address these=20 review messages as I'm updating the draft, and I=20 hadn't cycled time to get to this draft until now. My comments are in-line below... At 01:58 AM 5/24/2012, karagian@cs.utwente.nl wrote: >Hi James, Hi all, > >I think that this ID is useful and that it can=20 >become a (tsvwg) WG document. However, I have some comments: > >Comment_1: Section 1 should enhance/enlarge the=20 >text that motivates why this document is needed! >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Comment_2: In Section 2, page 3 is mentioned: >=93No other Sub-types are defined by > any profile within this document, but can be included by individual > implementations=94 >It would be better to use MAY be instead of =93can be=94, see below: >=93No other Sub-types are defined by > any profile within this document, but MAY be included by individual > implementations=94 changed from informative (can) to normative (MAY) >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Comment_3: At the introductory part of Section 3=20 >emphasize that the IANA registries associated=20 >with the application profiles are given in Section 5.2. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Comment_4: In Section 3.1 it is emphasized that=20 >the Application profiles are including the field=20 >=93VER=94, but the semantics of this field are not explained. I'm not sure which point you have an issue with #1 - that I don't define what the VER field is, or #2 - that I don't sufficiently define how this=20 profiles document means for the VER field to be used. To #1 - RFC 2872 defines a VER field to denote=20 the version of a particular profile, though it is=20 not all that specific about it - because it only=20 implies the concept of "profiles". This draft=20 makes that explicit as far as what's in this=20 draft is concerned, but doesn't limit the use of=20 the APP-ID field for other uses. To #2 - we state the VER field, that's part of=20 the APP-ID Object, is to remain as is, and it is=20 set to have no value in any of the profiles this=20 draft defines. This allows 2 things, first that=20 each profile can be modified for a given traffic=20 type can be modified, and secondly, that any VER=3D=20 value means it has been modified from what is=20 defined by this document. I guess I could specify=20 that Ver=3D0 for each profile, but it would mean the same thing. Please comment if the draft needs more or=20 modified text to convey what I've said above. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Comment_5: Section 5.2.1: >o) In Broadcast Audio IPTV Profile, please=20 >chnage from: APP=3Dbroadcast.video.iptv, VER=3D" >INTO: >APP=3Dbroadcast.audio.iptv, VER=3D" > >o) The name of the fourth described profile should be changed from: >Broadcast Audio Live-events Profile >INTO: >Broadcast Video Live-events Profile done >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Comment_6: Section 5.2.3: >o) The name of the first described profile could be changed from: >Multimedia-Conferencing Profile >INTO: >Multimedia-Conferencing Profile =AD Presentation data > >o) The name of the second described profile could be changed from: >Multimedia-Conferencing Profile >INTO: >Multimedia-Conferencing Profile =AD Application Sharing > >o) The name of the third described profile could be changed from: >Multimedia-Conferencing Profile >INTO: >Multimedia-Conferencing Profile =AD Whiteboarding done >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Comment_7: Section 5.2.4: >o) The name of the first described profile could be changed from: > Multimedia-Streaming Profile >INTO: > Multimedia-Streaming Profile =AD Multiplex >o) The name of the second described profile could be changed from: > > Multimedia-Streaming Profile >INTO: >Multimedia-Streaming Profile =AD Webcast done >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Comment_8: The security considerations section=20 >(Section 4) is not clear, see below: >=93Given that each traffic flow is within separate reservations, and > RSVP does not have the ability to police the bits within any > reservation, solving for this appears to be administratively handled > at best. This is not meant to be a 'punt', but there really is > nothing this template creates that is going to make things any > harder for anyone (that we know of now).=94 >Please elaborate! What I mean to say here is to cover what happens=20 if some claims a certain type of traffic is=20 actually another type of traffic. In other words,=20 lying about which profile they used. I'm saying=20 that RSVP itself has no ability to police this. I=20 have changed the word "bits" to "type of traffic"=20 to make that distinction more clear. I hope you=20 agree. Let me know if you do not. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Comment_9: The reference to RFC 2750 is not=20 >listed in Section 8, while t is used in the text. oops - fixed Thank you James >Best regards, >Georgios > > > >________________________________________ >Van: tsvwg-bounces@ietf.org=20 >[tsvwg-bounces@ietf.org] namens James M. Polk [jmpolk@cisco.com] >Verzonden: woensdag 14 maart 2012 0:42 >Aan: tsvwg >Onderwerp: draft-polk-tsvwg-rsvp-app-id-vv-profiles uploaded > >TSVWG > >(as author) > >I've uploaded the next version of > >http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-app-id-vv-profile= s-03.txt > >The following changes were made in this version: > >- Added draft-ietf-mmusic-traffic-class-for-sdp-01.txt as a > reference > >- Changed to a new format of the profile string. > >- Added many new profiles based on the new format into each parent > category of Section 3. > >- changed the GUID to refer to draft-ietf-mmusic-traffic-class-for- > sdp-01.txt > >- changed 'desktop' adjective to 'avconf' to keep in alignment with > draft-ietf-mmusic-traffic-class-for-sdp-01.txt > >- Have a complete IANA Registry proposal for each application-ID > discussed in this draft. > >- General text clean-up of the draft. > >I don't believe there are any open issues with this document, and >hope to ask the WG to adopt this draft during the Paris meeting. > >James From karagian@cs.utwente.nl Fri Jun 15 03:06:51 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB51C21F84DF for ; Fri, 15 Jun 2012 03:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow6D5hcxztuV for ; Fri, 15 Jun 2012 03:06:50 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3BD21F84DD for ; Fri, 15 Jun 2012 03:06:49 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 15 Jun 2012 12:06:48 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.67]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Fri, 15 Jun 2012 12:06:47 +0200 From: To: , Thread-Topic: Comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles-03 Thread-Index: AQHNOXqo0HS1iLC9w0OpNc3cqfusCJb6dwz4gADSTUA= Date: Fri, 15 Jun 2012 10:06:46 +0000 Message-ID: References: <201206142130.q5ELUvgJ017407@mtv-core-3.cisco.com> In-Reply-To: <201206142130.q5ELUvgJ017407@mtv-core-3.cisco.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] Comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 10:06:51 -0000 Hi James, Please see in line! > -----Original Message----- > From: James Polk [mailto:jmpolk@cisco.com] > Sent: donderdag 14 juni 2012 23:19 > To: Karagiannis, G. (EWI); jmpolk@cisco.com; tsvwg@ietf.org > Subject: Re: Comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles-03 >=20 > Georgios >=20 > Thank you for your review. I apologize for not responding earlier. I tend= to > address these review messages as I'm updating the draft, and I hadn't cyc= led > time to get to this draft until now. >=20 > My comments are in-line below... >=20 > At 01:58 AM 5/24/2012, karagian@cs.utwente.nl wrote: > >Hi James, Hi all, > > > >I think that this ID is useful and that it can become a (tsvwg) WG > >document. However, I have some comments: > > > >Comment_1: Section 1 should enhance/enlarge the text that motivates > why > >this document is needed! > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >Comment_2: In Section 2, page 3 is mentioned: > >"No other Sub-types are defined by > > any profile within this document, but can be included by individual > > implementations" > >It would be better to use MAY be instead of "can be", see below: > >"No other Sub-types are defined by > > any profile within this document, but MAY be included by individual > > implementations" >=20 > changed from informative (can) to normative (MAY) Georgios: Okay >=20 > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >Comment_3: At the introductory part of Section 3 emphasize that the > >IANA registries associated with the application profiles are given in > >Section 5.2. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >Comment_4: In Section 3.1 it is emphasized that the Application > >profiles are including the field "VER", but the semantics of this field > >are not explained. >=20 > I'm not sure which point you have an issue with >=20 > #1 - that I don't define what the VER field is, or > #2 - that I don't sufficiently define how this profiles document means fo= r the > VER field to be used. >=20 > To #1 - RFC 2872 defines a VER field to denote the version of a particula= r > profile, though it is not all that specific about it - because it only im= plies the > concept of "profiles". This draft makes that explicit as far as what's in= this > draft is concerned, but doesn't limit the use of the APP-ID field for oth= er > uses. >=20 > To #2 - we state the VER field, that's part of the APP-ID Object, is to r= emain > as is, and it is set to have no value in any of the profiles this draft d= efines. This > allows 2 things, first that each profile can be modified for a given traf= fic type > can be modified, and secondly, that any VER=3D value means it has been > modified from what is defined by this document. I guess I could specify t= hat > Ver=3D0 for each profile, but it would mean the same thing. >=20 > Please comment if the draft needs more or modified text to convey what > I've said above. Georgios: Yes, I think that it will be good to provide more details in orde= r to convey what you mentioned above! >=20 >=20 > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Comment_5: Section 5.2.1: > >o) In Broadcast Audio IPTV Profile, please > >chnage from: APP=3Dbroadcast.video.iptv, VER=3D" > >INTO: > >APP=3Dbroadcast.audio.iptv, VER=3D" > > > >o) The name of the fourth described profile should be changed from: > >Broadcast Audio Live-events Profile > >INTO: > >Broadcast Video Live-events Profile >=20 > done >=20 > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >Comment_6: Section 5.2.3: > >o) The name of the first described profile could be changed from: > >Multimedia-Conferencing Profile > >INTO: > >Multimedia-Conferencing Profile Presentation data > > > >o) The name of the second described profile could be changed from: > >Multimedia-Conferencing Profile > >INTO: > >Multimedia-Conferencing Profile Application Sharing > > > >o) The name of the third described profile could be changed from: > >Multimedia-Conferencing Profile > >INTO: > >Multimedia-Conferencing Profile Whiteboarding >=20 > done >=20 > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >Comment_7: Section 5.2.4: > >o) The name of the first described profile could be changed from: > > Multimedia-Streaming Profile > >INTO: > > Multimedia-Streaming Profile Multiplex > >o) The name of the second described profile could be changed from: > > > > Multimedia-Streaming Profile > >INTO: > >Multimedia-Streaming Profile Webcast >=20 > done >=20 > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >Comment_8: The security considerations section > >(Section 4) is not clear, see below: > >"Given that each traffic flow is within separate reservations, and > > RSVP does not have the ability to police the bits within any > > reservation, solving for this appears to be administratively handled > > at best. This is not meant to be a 'punt', but there really is > > nothing this template creates that is going to make things any > > harder for anyone (that we know of now)." > >Please elaborate! >=20 > What I mean to say here is to cover what happens > if some claims a certain type of traffic is > actually another type of traffic. In other words, > lying about which profile they used. I'm saying > that RSVP itself has no ability to police this. I > have changed the word "bits" to "type of traffic" > to make that distinction more clear. I hope you > agree. Let me know if you do not. Georgios: Okay Best regards, Georgios >=20 > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >Comment_9: The reference to RFC 2750 is not > >listed in Section 8, while t is used in the text. >=20 > oops - fixed >=20 > Thank you >=20 > James >=20 >=20 >=20 > >Best regards, > >Georgios > > > > > > > >________________________________________ > >Van: tsvwg-bounces@ietf.org > >[tsvwg-bounces@ietf.org] namens James M. Polk [jmpolk@cisco.com] > >Verzonden: woensdag 14 maart 2012 0:42 > >Aan: tsvwg > >Onderwerp: draft-polk-tsvwg-rsvp-app-id-vv-profiles uploaded > > > >TSVWG > > > >(as author) > > > >I've uploaded the next version of > > > >http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-app-id-vv- > profiles-03.txt > > > >The following changes were made in this version: > > > >- Added draft-ietf-mmusic-traffic-class-for-sdp-01.txt as a > > reference > > > >- Changed to a new format of the profile string. > > > >- Added many new profiles based on the new format into each parent > > category of Section 3. > > > >- changed the GUID to refer to draft-ietf-mmusic-traffic-class-for- > > sdp-01.txt > > > >- changed 'desktop' adjective to 'avconf' to keep in alignment with > > draft-ietf-mmusic-traffic-class-for-sdp-01.txt > > > >- Have a complete IANA Registry proposal for each application-ID > > discussed in this draft. > > > >- General text clean-up of the draft. > > > >I don't believe there are any open issues with this document, and > >hope to ask the WG to adopt this draft during the Paris meeting. > > > >James From carlberg@g11.org.uk Fri Jun 15 10:19:18 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F5D21F865D for ; Fri, 15 Jun 2012 10:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWKFZtyPcT-T for ; Fri, 15 Jun 2012 10:19:17 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id B2D9821F865B for ; Fri, 15 Jun 2012 10:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=Mime-Version:To:Cc:Message-Id:Date:Subject:Content-Transfer-Encoding:Content-Type:From; bh=RfVYmrfWdl8rwM4cmwsI5UZIJjACI2ANenqb3zRfcmo=; b=YdYA9Y1PvwiF7+4fpZsb/QePrMFq3jIIvhrqYkXIB6P4dEfBFGmLB68zpPKb+l4j8Kqq2n1awCbav83GAaUVjd/BCxnGTKGp8j5TNxYd4PgbfZ2zN4sl7SSi2JmueVCB; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:52320 helo=miro-2.private) by portland.eukhosting.net with esmtpa (Exim 4.77) (envelope-from ) id 1SfaAu-00015I-6H; Fri, 15 Jun 2012 17:19:08 +0000 From: ken carlberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jun 2012 13:19:10 -0400 Message-Id: <32CA8067-8FBE-493A-BEBC-53D91730EF90@g11.org.uk> To: James Polk Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: tsvwg Subject: [tsvwg] Comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 17:19:18 -0000 James, at present, I just have just a few general and specific comments about = the draft, some of which are aimed at different audiences. To the = (other) chair and the group, I'd like to advocate changing the = disposition of the draft from individual contribution to a working group = draft. The document is very symbiotic to the existing working group = draft in MMUSIC, and = efforts that compliment or strengthen other work items are good things = to have. In addition, the document builds on existing work [rfc-2872] = and provides more granular information to nodes along the path, which I = feel is always a good thing. Finally, the draft appears in a state = where the foundation is solid, with only refinements that are needed -- = which seems sufficient in changing status to a working group draft as for some specific comments... - at the end of the 1'st paragraph in Section 1, you state "An = application profile defined by a sender may not be understood by the = intermediaries or receiver in the same or different domain". My = impression is that its different domains that may not under the = application profile, but that intermediaries *within the same domain* = would understand the profile. If I missed something, it would be = helpful to expand on your original text. - towards the end of section 2, you state that the specification "allows = an RFC that defines a well known word or string to be a valid = identifier". The first question that comes to mind is who/what defines = this well known word or string? Is it done later in the draft, or does = this come from some otehr draft/RFC or registry? Its the "well known" = part of the text that caught my eye. - i'm not convinced in how you separated real-time interactive profiles = in Section 3.2 and multimedia conferencing profiles in Section 3.3. I = say this because your brief description of each (which may be too brief) = doesn't seem associate characteristics that are different from each = other. Rather, each grouping only separates types of applications. in = contrast, broadcast and streaming are distinguished by the size of = buffers. =20 cheers, -ken From brian.e.carpenter@gmail.com Tue Jun 19 07:21:30 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E540A21F854A for ; Tue, 19 Jun 2012 07:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDGdIjCXG20Y for ; Tue, 19 Jun 2012 07:21:30 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B35E921F8463 for ; Tue, 19 Jun 2012 07:21:29 -0700 (PDT) Received: by eaaq13 with SMTP id q13so2256509eaa.31 for ; Tue, 19 Jun 2012 07:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iQ/mYe40LrDmf/lQEQJrLdVq2MtgpfqBA+Rs3UXIKRU=; b=TXblK4bjl1qiIXtI3yw4UQxFoB3pJJ/K4sMZb7IxXialxzKKX2Q1qzp4tx+l9u9sXi rEyKD4v71XA/LB0pgNgLl6Dj3LwpT54U/jWscV+WxEt5BStQLfMx5m8XjseLL6mJmOTq lVAPZdWELMA69Ayouump2Qs2NG//crIKXEg1LLX3eKIGuCm7ikEfechGPrGKuw83UdAX kmTcn2kPNWSswb589g5/pG3F+lm/MF+WfsUhcMSgjLnNdBmEa57m9lGZNq2JYfdfFUht GT/keDfP/UJ1aiStzYWSrtCj0OXUSbi5Gsr/q+kVOXC4Ldglb17jM+BLnx158mkS8JnV Posw== Received: by 10.14.98.204 with SMTP id v52mr4289973eef.198.1340115688652; Tue, 19 Jun 2012 07:21:28 -0700 (PDT) Received: from [128.232.110.88] (c088.al.cl.cam.ac.uk. [128.232.110.88]) by mx.google.com with ESMTPS id m46sm58746722eeh.9.2012.06.19.07.21.26 (version=SSLv3 cipher=OTHER); Tue, 19 Jun 2012 07:21:27 -0700 (PDT) Message-ID: <4FE08AE5.2040701@gmail.com> Date: Tue, 19 Jun 2012 15:21:25 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tsvwg@ietf.org References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> In-Reply-To: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 14:21:31 -0000 Hi, > In other words, even though a packet has the same > DSCP from source to destination, it can and often does experience > different treatment depending on the conditions of the nodes it > traverses on its journey. > > The DiffServ architecture allows for DSCP values within a packet to > be changed, or remarked, any number of times. In other words, a > packet can have its DSCP remarked at every layer-3 hop throughout > the life of that packet. This practice actually occurs infrequently, > but it is allowed. IMHO, this is confusing and misses part of the diffserv model. Rather than explaining what's wrong, here is a suggested rewrite: "A packet could have the same DSCP value from source to destination, but the intended mode of operation is for the DSCP value to be rewritten when the packet crosses the boundary of a diffserv administrative domain. Indeed, the packet may be fully reclassified at a domain boundary. The DSCP value should stay the same only if adjacent domains have agreed to use the same set of DSCP values and the same, or equivalent, PHBs. Inconsistency will arise if a domain does not rewrite the DSCP value when receiving a packet from another domain that uses a different set of DSCPs and PHBs." Then you aren't clear about the fact that RFC 5127 only exists because MPLS is lame and only has 3 bits available. > o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of > which is for aggregating many 6-bit DSCP values into a 3-bit (8 > value) field used specifically by service provider (SP) networks. This really should be made clear: "o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of which is for aggregating many 6-bit DSCP values into the 3-bit (8 value) field available in MPLS. This confusion arises because RFC 5127 is written in general terms, and indeed aggregation could be used on non-MPLS paths, but the specific restriction to 3 bits is due entirely to MPLS and only applies to the MPLS portion of a packet's path." Two details on this: > To this end, and perhaps because of it, MPLS was designed with only > 8 values of priority differentiation, i.e., the 3 EXP bits. Afaik the reason is entirely accidental: there were 3 spare bits. > ...LAN based IEEE has only a 3-bit priority field as well within > its specifications, known as the Priority Code Point... ... and for the Nth time, diffserv is *not* a priority scheme; it would be worth underlining this point yet again. I think in the end that what is lacking is a clear understanding of the first point I made - the notion of diffserv domain boundaries where one reclassifies the packet and/or rewrites the DSCP. If people have this clear, I think it's fairly obvious that squeezing the DSCP down to 3 bits in an MPLS tunnel is really a side-show. Therefore, an update to RFC 4594 is really quite orthogonal to using, or not using, RFC 5127. Brian From Michael.Tuexen@lurchi.franken.de Tue Jun 19 11:29:49 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C1111E8128 for ; Tue, 19 Jun 2012 11:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.24 X-Spam-Level: **** X-Spam-Status: No, score=4.24 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, GB_SUMOF=5, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+XcREdBOEuT for ; Tue, 19 Jun 2012 11:29:48 -0700 (PDT) Received: from mail-n.franken.de (mail-n.franken.de [193.175.24.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4CC11E811A for ; Tue, 19 Jun 2012 11:29:48 -0700 (PDT) Received: from [192.168.1.103] (p508FA119.dip.t-dialin.net [80.143.161.25]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 88D441C0C0BD6; Tue, 19 Jun 2012 20:29:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <1340115536.73550.YahooMailNeo@web130105.mail.mud.yahoo.com> Date: Tue, 19 Jun 2012 20:29:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <523CFFD8-4393-49A7-84E0-DB64DD9AA000@lurchi.franken.de> References: <4FBE562E.6000909@gmail.com> <1338463399.19395.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338467385.57530.YahooMailNeo@web130105.mail.mud.yahoo.com> <1338489317.38384.YahooMailNeo@web130103.mail.mud.yahoo.com> <1338492008.97916.YahooMailNeo@web130103.mail.mud.yahoo.com> <1339093489.85309.YahooMailNeo@web130106.mail.mud.yahoo.com> <1340115536.73550.YahooMailNeo@web130105.mail.mud.yahoo.com> To: Chinmaya Dwibedy X-Mailer: Apple Mail (2.1278) Cc: "tsvwg@ietf.org" , Randy Stewart Subject: Re: [tsvwg] Issue with failover in multi-homing setup X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 18:29:49 -0000 On Jun 19, 2012, at 4:18 PM, Chinmaya Dwibedy wrote: > Hi, > We are testing SCTP behavior in the following multihoming = configuration: 2 RHEL4 PCs, each pc has got 2 NICs, and these interfaces = are connected through 2 crossed cables. We established an SCTP = association between two signaling endpoints: A and B. The association = comprises of two routing paths: path#1 (primary path) and = path#2(secondary path). The signaling traffic (data chunks, mostly 250 = bytes) is sent on primary path. SCTP continuously monitors the = reachability on primary and secondary paths-on an active primary path = SCTP probes for reachability using transferred data packets themselves, = and on idle secondary path heartbeat packets are used. Some seconds = after transmission's beginning, I physically disconnected the primary = path (disconnecting one crossed cable). In this situation, as I had = expected, I did not experience the retransmission on the secondary path = and then notification of inactive primary path, and consequent path's = switching. Rather I found kernel notifies with SCTP_COMM_LOST as the = association is closed. Please have a look into the below stated and feel = free to correct me if you find me wrong at any point. > Thanks in advance for your clarifications and comments. > My general understanding of rfc-2960 says that, > 1) For each path (i.e., network destination), SCTP keeps an error = counter that counts the number of consecutively missed acknowledgments = to data or heartbeat packets. A path is considered unreachable when the = error counter of the path exceeds the value of the SCTP parameter = Path.Max.Retrans. I mean to say that, SCTP sends the data to the primary = address. If timeout occurs, it resends the data to a secondary address. = All new data will still be sent to the primary address. If a timeout = occurs again, it resends the data to the secondary address. It continues = this process until path-retransmit is reached on the primary address. > =20 > 2) A separate RTO is kept for each path. SCTP computes RTO values = based on RTT measurements. When packet retransmission occurs, the = timeout value is doubled for each retransmission, with an upper limit of = max RTO. The SCTP keeps the track of the number of RTOs and missing = heartbeat acknowledgements. If the sum of these two counts exceeds a = so-called Path.Max.Retrans threshold, the primary path will be declared = to be inactive, and the association enters the "Failover," which = continues to send all data to the secondary address. I mean to state = that, the number of path-retransmits multiplied by the retransmission = timer ultimately controls how fast a secondary address becomes the = primary path for multihomed nodes. > =20 > 3) For example, assuming the default (i.e., recommended values of = section 14 of RFC- 2960) Path.Max.Retrans =3D 5, RTO =3D RTO.Min =3D 1, = and RTO.Max =3D 60, Association.Max.Retrans=3D10 and HB.interval=3D 30 = seconds, an SCTP failover from minimal RTO will take 1 + 2 + 4 + 8 + 16 = + 32 =3D 63 seconds. Shortening this time can be achieved by setting the = RTO.Min, RTO.Max, and Path.Max.Retrans, to smaller values. In this = multi-homing setup, we have aggressively set parameters as follows i.e., = RTO.Init=3D 250ms, RTO.Min=3D 250ms, RTO.Max=3D400ms, = Path.Max.Retrans=3D5) in order to allow an IP network to meet the = time-sensitive requirements of LTE network. I think, the SCTP will take = changeover time to 250ms + 400ms + 400ms + 400ms + 400ms+ 400ms=3D2.250 = seconds You could also reduce Path.Max.Retrans... Or you make use of http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05 which is implemented in FreeBSD... But it could be implemented in Linux. = too. Best regards Michael > =20 > The association gets closed due to either an unreachability threshold = being triggered (i.e., the SCTP endpoint timed out multiple times and = hit its threshold, which indicates the peer is no longer reachable), or = the peer performed an abortive close. In this case, peer has not = performed abortive close. Thus is there any chance of getting = SCTP_COMM_LOST event with aforesaid configured parameters? What might be = the possible causes of this association lost when network cable of = primary path gets unplugged? > If we need faster failover, do you recommend us to change the = Path.Max.Retrans setting (without altering RTO.Init, RTO.Min and = RTO.Max), to limit the number of consecutive timeouts that will trigger = the failover? > Regards, > Chinmaya > =20 From jmpolk@cisco.com Tue Jun 19 11:32:31 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE2111E8123 for ; Tue, 19 Jun 2012 11:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.25 X-Spam-Level: X-Spam-Status: No, score=-110.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zta6LCzP4SeI for ; Tue, 19 Jun 2012 11:32:30 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id AD72B11E810E for ; Tue, 19 Jun 2012 11:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=4786; q=dns/txt; s=iport; t=1340130750; x=1341340350; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=qFqdJ77YhWAgtUfXYjDlgiadz6IGqme/TJYaE7buLPs=; b=kuHuIgSeByPrD2GVAuD64EgSO2lWigATDWuoQyEB8czSGpEzXTIHNUwa 3iS7TR2Ve3ytQgyklwXxcMVMxD77LpnE7NsSl+lNaV3zcypt+jl9FgNdh qxfLBdSCPzXJyPuYvIN2YqpSvtctOER1Tx4dgeIOAAK9/00pEIJKGDV8s I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAF3F4E+rRDoI/2dsb2JhbABFtWqBB4IYAQEBAwESASUCMhILBwQSBh4QGTAOBgErCYdkBJktoDyLL4YZA4hDmnmBZoJ+gTgG X-IronPort-AV: E=Sophos;i="4.75,799,1330905600"; d="scan'208";a="49438531" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 19 Jun 2012 18:32:30 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5JIWTQO021994; Tue, 19 Jun 2012 18:32:30 GMT Message-Id: <201206191832.q5JIWTQO021994@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 Jun 2012 13:32:29 -0500 To: Brian E Carpenter , From: James Polk In-Reply-To: <4FE08AE5.2040701@gmail.com> References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 18:32:32 -0000 BRian Thank you for the review. See comments in-line below At 09:21 AM 6/19/2012, Brian E Carpenter wrote: >Hi, > > > In other words, even though a packet has the same > > DSCP from source to destination, it can and often does experience > > different treatment depending on the conditions of the nodes it > > traverses on its journey. > > > > The DiffServ architecture allows for DSCP values within a packet to > > be changed, or remarked, any number of times. In other words, a > > packet can have its DSCP remarked at every layer-3 hop throughout > > the life of that packet. This practice actually occurs infrequently, > > but it is allowed. > >IMHO, this is confusing and misses part of the diffserv model. ok >Rather than explaining what's wrong, here is a suggested rewrite: > >"A packet could have the same DSCP value from source to destination, >but the intended mode of operation is for the DSCP value to be >rewritten when the packet crosses the boundary of a diffserv >administrative domain. Indeed, the packet may be fully reclassified >at a domain boundary. The DSCP value should stay the same only if >adjacent domains have agreed to use the same set of DSCP values >and the same, or equivalent, PHBs. Inconsistency will arise if a >domain does not rewrite the DSCP value when receiving a packet >from another domain that uses a different set of DSCPs and PHBs." I think this is much better than what I have. Thanks! >Then you aren't clear about the fact that RFC 5127 only exists >because MPLS is lame and only has 3 bits available. well... I wasn't going to write down that MPLS was lame ... ;-) > > o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of > > which is for aggregating many 6-bit DSCP values into a 3-bit (8 > > value) field used specifically by service provider (SP) networks. > >This really should be made clear: > > "o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of > which is for aggregating many 6-bit DSCP values into the 3-bit (8 > value) field available in MPLS. This confusion arises because > RFC 5127 is written in general terms, and indeed aggregation > could be used on non-MPLS paths, but the specific restriction > to 3 bits is due entirely to MPLS and only applies to the > MPLS portion of a packet's path." Again, this is better text that I have now, though I'll likely add a little something about the PCP field within IEEE's 802 - which has the same limitation of a 3-bit field. >Two details on this: > > > To this end, and perhaps because of it, MPLS was designed with only > > 8 values of priority differentiation, i.e., the 3 EXP bits. > >Afaik the reason is entirely accidental: there were 3 spare bits. > > > ...LAN based IEEE has only a 3-bit priority field as well within > > its specifications, known as the Priority Code Point... > >... and for the Nth time, diffserv is *not* a priority scheme; sorry, I know that - and probably was caught up in the thought of writing about the PCP field within Ethernet. I'll blame my proofreaders for not catching this one as well ;-) >it would >be worth underlining this point yet again. good idea. >I think in the end that what is lacking is a clear understanding of >the first point I made - the notion of diffserv domain boundaries >where one reclassifies the packet and/or rewrites the DSCP. If people >have this clear, I think it's fairly obvious that squeezing the DSCP >down to 3 bits in an MPLS tunnel is really a side-show. Therefore, >an update to RFC 4594 is really quite orthogonal to using, or >not using, RFC 5127. On this point, I don't believe you were in the Paris TSVWG meeting, so you didn't hear how many (in a row) brought this point up (and beat me over the head with it). Therefore, I have to stand by the evidence that at least some folks are still "...lacking is a clear understanding of the first point (you) made (above)..." I really don't see this RFC4594-update to hinge on the aggregation issue within RFC5127, yet that's nearly all I heard about throughout the presentation in Paris. Because that clear understanding remains elusive still, I believe this ID - and discussion in Vancouver - is needed to focus the discussion on gaining a greater understanding of this point. Then we can discuss if the RFC4594-update is going in a good direction, and if so, make the necessary changes to reach consensus for progression of that document. I'll update this draft quickly to have the clearer text you suggested included to help this discussion. Thanks again. James > Brian From Ruediger.Geib@telekom.de Wed Jun 20 00:50:29 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C3221F86DF for ; Wed, 20 Jun 2012 00:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzBT4IePly2X for ; Wed, 20 Jun 2012 00:50:28 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id ABB5A21F8673 for ; Wed, 20 Jun 2012 00:50:27 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 20 Jun 2012 09:50:24 +0200 Received: from HE113657.emea1.cds.t-internal.com (10.134.99.17) by HE110889.emea1.cds.t-internal.com (10.134.92.130) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 20 Jun 2012 09:50:23 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 20 Jun 2012 09:50:23 +0200 From: To: Date: Wed, 20 Jun 2012 09:50:22 +0200 Thread-Topic: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt Thread-Index: Ac1OJx4tBtBooGpETiaVMmQYjxIA6gAiUSDw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal.com> References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> In-Reply-To: <4FE08AE5.2040701@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 07:50:29 -0000 Brian, [RG] below indicates my replies to your statements (marked as [BC]). Regards, R=FCdiger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of B= rian E Carpenter Sent: Tuesday, June 19, 2012 4:21 PM To: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement= -00.txt Hi, > In other words, even though a packet has the same > DSCP from source to destination, it can and often does experience > different treatment depending on the conditions of the nodes it > traverses on its journey. > > The DiffServ architecture allows for DSCP values within a packet to > be changed, or remarked, any number of times. In other words, a > packet can have its DSCP remarked at every layer-3 hop throughout > the life of that packet. This practice actually occurs infrequently, > but it is allowed. [BC] IMHO, this is confusing and misses part of the diffserv model. Rather than explaining what's wrong, here is a suggested rewrite: [Text proposed by BC] "A packet could have the same DSCP value from source to destination, but the intended mode of operation is for the DSCP value to be rewritten when the packet crosses the boundary of a diffserv administrative domain. Indeed, the packet may be fully reclassified at a domain boundary. The DSCP value should stay the same only if adjacent domains have agreed to use the same set of DSCP values and the same, or equivalent, PHBs. Inconsistency will arise if a domain does not rewrite the DSCP value when receiving a packet from another domain that uses a different set of DSCPs and PHBs." [RG-start] What you say is the PHB needs to be stable end-to-end and the DSCP can (and looking at the deployments I am aware of often will) vary? Then it might be a good idea to standardise a limited set of PHBs, if those having need can agree on them. Codepoints are secondary. That's an often heard advice in talks with other carrier representatives. Together with Al Morton, I've started some work in ITU along these lines (covering IP, MPLS and Ethernet QoS at interconnection points - a liaision statement to TSVWG is under way, but I couldn't find an entry in the IETF liaision list today). The commercial staff of Deutsche Telekom told me, that they are not interested in negotiating PHB compatibilty and codepoint mapping. They ask for a standard. We've had interconnection talks between some carriers here in Germany and no two of them used the same codepoints to identify all their PHBs. What they've consented on was an "interconnection codepoint scheme". That's reasonable and reduces operational and commercial negotiation efforts. In Australia / New Zealand, the regulator initiated a QoS standard on some classes and codepoints, I was told by a colleague from the area. I'm aware of tendencies for interconnection class and codepoint schemes on European level. I agree with you that carriers can map codepoints. Besides creating additional work while agreeing interconneection, it's also not the task of the operational staff to somehow get along with a lack of standards - be that dealing 20 something (sub)classes or codepoints where hardly more than 6-9 are required or the mapping of DSCPs to 3 bit MPLS/Ethernet codepoints. Finally, I think the IETF process includes clean up and improvement when advancing an RFC (which I'd apply also to informational RFCs being put on standards track after years). I will support any work which results in a clean up of RFCs 4594 and RFC 5127. I will not support them unchanged or with even more classes and codepoints on standards track. And yes, I think both RFCs need to be revised together, if one is put on standards track. [RG-end] [BC from here on] Then you aren't clear about the fact that RFC 5127 only exists because MPLS is lame and only has 3 bits available. > o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of > which is for aggregating many 6-bit DSCP values into a 3-bit (8 > value) field used specifically by service provider (SP) networks. This really should be made clear: "o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of which is for aggregating many 6-bit DSCP values into the 3-bit (8 value) field available in MPLS. This confusion arises because RFC 5127 is written in general terms, and indeed aggregation could be used on non-MPLS paths, but the specific restriction to 3 bits is due entirely to MPLS and only applies to the MPLS portion of a packet's path." Two details on this: > To this end, and perhaps because of it, MPLS was designed with only > 8 values of priority differentiation, i.e., the 3 EXP bits. Afaik the reason is entirely accidental: there were 3 spare bits. > ...LAN based IEEE has only a 3-bit priority field as well within > its specifications, known as the Priority Code Point... ... and for the Nth time, diffserv is *not* a priority scheme; it would be worth underlining this point yet again. I think in the end that what is lacking is a clear understanding of the first point I made - the notion of diffserv domain boundaries where one reclassifies the packet and/or rewrites the DSCP. If people have this clear, I think it's fairly obvious that squeezing the DSCP down to 3 bits in an MPLS tunnel is really a side-show. Therefore, an update to RFC 4594 is really quite orthogonal to using, or not using, RFC 5127. Brian From brian.e.carpenter@gmail.com Wed Jun 20 01:28:25 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D331521F8609 for ; Wed, 20 Jun 2012 01:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.762 X-Spam-Level: X-Spam-Status: No, score=-100.762 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ouok23a7u+o for ; Wed, 20 Jun 2012 01:28:25 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 948F221F8608 for ; Wed, 20 Jun 2012 01:28:24 -0700 (PDT) Received: by eekd4 with SMTP id d4so2570632eek.31 for ; Wed, 20 Jun 2012 01:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GR+eNNEdNwgTQfjmHYZnW7scQ8iJ/DmBeGWvbjjqjIw=; b=bwDSGUhncIrTUV86ZKvT8YJHUPPA26rgvGwZWrkrTGMvV/a6LJqcqMzVwfRgmjn/up 0jpFuw+qwjNuj5PatJF7+TQMzaLaH71g5W+EJx3XEU+leif35Xag1oeI875m8XL7oJc7 EWB4iJAUp33L3D3Eu7jflfhXC8gMdmmIJmjjOGxwvPZYqNEaPOwZvpzujLUcX0GXoFBx iCrceOSImEinbSN7Uzhk6yooXhURG3j5lNcDjCiz05pjV7G96EiGwZ5jUbwVyMOmh7PE FOI7kMFHUIvAmM7IB+YB7luckBFvTFam1NsYFaLZrWimCmQKObktzXrt9U0JYGqLr1pY ilXQ== Received: by 10.14.188.129 with SMTP id a1mr4966990een.183.1340180903421; Wed, 20 Jun 2012 01:28:23 -0700 (PDT) Received: from [192.168.1.66] (host-2-102-216-245.as13285.net. [2.102.216.245]) by mx.google.com with ESMTPS id y54sm87125772eef.10.2012.06.20.01.28.21 (version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 01:28:22 -0700 (PDT) Message-ID: <4FE189A1.4040006@gmail.com> Date: Wed, 20 Jun 2012 09:28:17 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 08:28:26 -0000 Ruediger, Thanks for your comments. On 2012-06-20 08:50, Ruediger.Geib@telekom.de wrote: > Brian, >=20 > [RG] below indicates my replies to your statements > (marked as [BC]). >=20 > Regards, R=C3=BCdiger >=20 > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf = Of Brian E Carpenter > Sent: Tuesday, June 19, 2012 4:21 PM > To: tsvwg@ietf.org > Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-state= ment-00.txt >=20 > Hi, >=20 >> In other words, even though a packet has the same >> DSCP from source to destination, it can and often does experience >> different treatment depending on the conditions of the nodes it >> traverses on its journey. >> >> The DiffServ architecture allows for DSCP values within a packet to= >> be changed, or remarked, any number of times. In other words, a >> packet can have its DSCP remarked at every layer-3 hop throughout >> the life of that packet. This practice actually occurs infrequently= , >> but it is allowed. >=20 > [BC] IMHO, this is confusing and misses part of the diffserv model. > Rather than explaining what's wrong, here is a suggested rewrite: >=20 > [Text proposed by BC] > "A packet could have the same DSCP value from source to destination, > but the intended mode of operation is for the DSCP value to be > rewritten when the packet crosses the boundary of a diffserv > administrative domain. Indeed, the packet may be fully reclassified > at a domain boundary. The DSCP value should stay the same only if > adjacent domains have agreed to use the same set of DSCP values > and the same, or equivalent, PHBs. Inconsistency will arise if a > domain does not rewrite the DSCP value when receiving a packet > from another domain that uses a different set of DSCPs and PHBs." >=20 >=20 > [RG-start] What you say is the PHB needs to be stable end-to-end > and the DSCP can (and looking at the deployments I am aware of > often will) vary? If you want consistent behaviour from end to end, that is correct, and that was the intention from the beginning. It's also the reason we defined PHBIDs (RFC 3140), in case the PHB needed to be signalled in some way (e.g. in SLA signalling). > Then it might be a good idea to standardise a limited set of PHBs, > if those having need can agree on them. Codepoints are secondary. > That's an often heard advice in talks with other carrier > representatives. Together with Al Morton, I've started some work > in ITU along these lines (covering IP, MPLS and Ethernet QoS at > interconnection points - a liaision statement to TSVWG is under > way, but I couldn't find an entry in the IETF liaision list today). >=20 > The commercial staff of Deutsche Telekom told me, that > they are not interested in negotiating PHB compatibilty and > codepoint mapping. They ask for a standard. However, at the time we designed diffserv (I was WG co-chair for that), we got a very strong message from the operators involved that they *required* the flexibility to define their own PHBs. I'm not against what amounts to an operator's agreement on a set of recommended PHBs, and I can understand why carriers might want that - otherwise you need a commutative string of SLAs along the whole path. In fact, the reason we defined PHBIDs was so that there could be an unambiguous definition of many more PHBs than you can fit in a 6 bit space, allowing for a locally configured mapping down to 6 (or even 3) bits. I think it's time for people to start using RFC 3140. >=20 > We've had interconnection talks between some carriers here > in Germany and no two of them used the same codepoints > to identify all their PHBs. What they've consented on was an > "interconnection codepoint scheme". That's reasonable and reduces > operational and commercial negotiation efforts. Exactly. Again, that was why we invented PHBIDs. > In Australia / New Zealand, the regulator initiated a QoS standard > on some classes and codepoints, I was told by a colleague from the > area. I'm aware of tendencies for interconnection class and > codepoint schemes on European level. Er, there is no common regulator for AU and NZ. Do you have a reference for this work? > I agree with you that carriers can map codepoints. Besides creating > additional work while agreeing interconneection, it's also not the > task of the operational staff to somehow get along with a lack of > standards - be that dealing 20 something (sub)classes or codepoints > where hardly more than 6-9 are required or the mapping of DSCPs > to 3 bit MPLS/Ethernet codepoints. >=20 > Finally, I think the IETF process includes clean up and improvement > when advancing an RFC (which I'd apply also to informational RFCs > being put on standards track after years). I will support > any work which results in a clean up of RFCs 4594 and RFC 5127. > I will not support them unchanged or with even more classes > and codepoints on standards track. And yes, I think both RFCs > need to be revised together, if one is put on standards track. > [RG-end] I have always believed personally that only a few PHBs are needed and that 6 bits is plenty. But as I said, the operators involved in the diffserv design insisted on more flexibility. However, a BCP that recommends (not mandates) a finite set of PHBs would be consistent with both views. I don't see any harm in defining more PHBs, if in line with RFC 3086. They will not be mandatory. However, we shouldn't confuse details of specific SLA parameters or specific QoS implementations with the general idea of a PHB. (In my not in the least humble opinion, that is the problem with RFC 3246.) Regards Brian > [BC from here on] Then you aren't clear about the fact that RFC 5127 > only exists because MPLS is lame and only has 3 bits available. >=20 >> o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of= >> which is for aggregating many 6-bit DSCP values into a 3-bit (8 >> value) field used specifically by service provider (SP) networks= =2E >=20 > This really should be made clear: >=20 > "o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of > which is for aggregating many 6-bit DSCP values into the 3-bit (8= > value) field available in MPLS. This confusion arises because > RFC 5127 is written in general terms, and indeed aggregation > could be used on non-MPLS paths, but the specific restriction > to 3 bits is due entirely to MPLS and only applies to the > MPLS portion of a packet's path." >=20 > Two details on this: >=20 >> To this end, and perhaps because of it, MPLS was designed with only= >> 8 values of priority differentiation, i.e., the 3 EXP bits. >=20 > Afaik the reason is entirely accidental: there were 3 spare bits. >=20 >> ...LAN based IEEE has only a 3-bit priority field as well within >> its specifications, known as the Priority Code Point... >=20 > ... and for the Nth time, diffserv is *not* a priority scheme; it would= > be worth underlining this point yet again. >=20 > I think in the end that what is lacking is a clear understanding of > the first point I made - the notion of diffserv domain boundaries > where one reclassifies the packet and/or rewrites the DSCP. If people > have this clear, I think it's fairly obvious that squeezing the DSCP > down to 3 bits in an MPLS tunnel is really a side-show. Therefore, > an update to RFC 4594 is really quite orthogonal to using, or > not using, RFC 5127. >=20 > Brian >=20 From jtw@lcs.mit.edu Wed Jun 20 01:55:40 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE7B21F8737 for ; Wed, 20 Jun 2012 01:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW2edYLH3wkn for ; Wed, 20 Jun 2012 01:55:40 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id D2BB121F872E for ; Wed, 20 Jun 2012 01:55:39 -0700 (PDT) Received: from [192.168.246.66] (cpe-76-171-96-62.socal.res.rr.com [76.171.96.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mercury.lcs.mit.edu (Postfix) with ESMTP id 839A118C0EE; Wed, 20 Jun 2012 04:55:36 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal. com> References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal. com> Date: Wed, 20 Jun 2012 01:55:32 -0700 To: , From: John Wroclawski Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 08:55:41 -0000 Hello, On Jun 20, 2012, at 12:50 AM, Ruediger Geib wrote= : > Brian, > > [RG] below indicates my replies to your statements (marked as [BC]). > > Regards, R=FCdiger > > [BC] IMHO, this is confusing and misses part of the diffserv model. > Rather than explaining what's wrong, here is a suggested rewrite: > > [RG-start] What you say is the PHB needs to be stable end-to-end > and the DSCP can (and looking at the deployments I am aware of > often will) vary? However the original diffserv model specifically=20 contemplated that the PHB might *not* be stable=20 from end to end. Since the per hop behavior applied to a packet is=20 only one aspect of the overall QOS seen by that=20 packet within an administrative domain, there are=20 two reasons this might be so. 1) Different administrative domains along an end=20 to end path are using different technical means -=20 different combinations of PHB, border traffic=20 shaping, admission control, overcapacity, etc -=20 to implement the same overall QOS for a service=20 class, or 2) Different administrative domains along an end=20 to end path are providing different QOS to the=20 data flow due to different administrative=20 agreements, etc. 4594 touches on this: "Each domain may choose to implement different service classes or to use different behaviors to implement the service classes or to aggregate different kinds of traffic into the aggregates and still achieve their required characteristics. For example, low delay, loss, and jitter may be realized using the EF PHB, or with an over- provisioned AF PHB." Consequently I'm not sure I would actually agree with the following On Jun 20, 2012, at 1:28 AM, Brian E Carpenter wrote: >> >> [RG-start] What you say is the PHB needs to be stable end-to-end >> and the DSCP can (and looking at the deployments I am aware of >> often will) vary? > > If you want consistent behaviour from end to end, that is correct, > and that was the intention from the beginning. In fact I'd say rather that the intention was to=20 support the notion that different administrative=20 domains might explicitly choose to implement the=20 same QOS for a flow or class of packets using=20 different technical means, as convenient and=20 appropriate for the domain, and that this should=20 be supported in the architecture. cheers john From brian.e.carpenter@gmail.com Wed Jun 20 08:14:37 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278BD21F8631 for ; Wed, 20 Jun 2012 08:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.814 X-Spam-Level: X-Spam-Status: No, score=-100.814 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bofzmRzf-mD1 for ; Wed, 20 Jun 2012 08:14:36 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5684C21F85E1 for ; Wed, 20 Jun 2012 08:14:36 -0700 (PDT) Received: by eekd4 with SMTP id d4so2806705eek.31 for ; Wed, 20 Jun 2012 08:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V5mnrg6tpKjdEWybLaVh1DVkQpeYEAbe89sd34AGsx4=; b=pRkZ54ARrxVktpxcVNybF7IbO1DZnASy6wqDE6BdA9KsxVM1bfjSFSL4pt377cJgBB U3KBtK8y2vIdnVz4L0g2eGXW/qbrBWaeSl873T7j88hlvY3QCIaNDZd0EgLEI4EnAMp6 18F+Kl2KEkzBnJIHq+1F2q6zv3/SNgT+/XoAU6E2BclycQ/qUvm90jGMFEKORPfjFMPV 8u6nm2q1+b+4dTq0VvMpJvZ3la1l9l9jQlpWb/T1a36tCsHF5OJsidfJICPEv9EBmdgx a+jyjok4qj6hYNRpCawRhhiM6uZhTyZNOed2XBvYIHDmsWTTOD4rMOTpkLfFnDY8y0Cd mBAg== Received: by 10.14.97.135 with SMTP id t7mr5117003eef.177.1340205275341; Wed, 20 Jun 2012 08:14:35 -0700 (PDT) Received: from [192.168.1.69] (host-2-102-216-245.as13285.net. [2.102.216.245]) by mx.google.com with ESMTPS id e45sm91854981eeb.6.2012.06.20.08.14.33 (version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 08:14:34 -0700 (PDT) Message-ID: <4FE1E8D6.4090301@gmail.com> Date: Wed, 20 Jun 2012 16:14:30 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Wroclawski References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal. com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 15:14:37 -0000 On 2012-06-20 09:55, John Wroclawski wrote: > Hello, >=20 > On Jun 20, 2012, at 12:50 AM, Ruediger Geib > wrote: >> Brian, >> >> [RG] below indicates my replies to your statements (marked as [BC]). >> >> Regards, R=C3=BCdiger >> >> [BC] IMHO, this is confusing and misses part of the diffserv model. >> Rather than explaining what's wrong, here is a suggested rewrite: >> >> [RG-start] What you say is the PHB needs to be stable end-to-end >> and the DSCP can (and looking at the deployments I am aware of >> often will) vary? >=20 > However the original diffserv model specifically contemplated that the > PHB might *not* be stable from end to end. Yes, indeed - you can only assume stability if there are e2e agreements in place; the only safe assumption is that it might change. > Since the per hop behavior applied to a packet is only one aspect of th= e > overall QOS seen by that packet within an administrative domain, there > are two reasons this might be so. >=20 > 1) Different administrative domains along an end to end path are using > different technical means - different combinations of PHB, border > traffic shaping, admission control, overcapacity, etc - to implement th= e > same overall QOS for a service class, or >=20 > 2) Different administrative domains along an end to end path are > providing different QOS to the data flow due to different administrativ= e > agreements, etc. >=20 > 4594 touches on this: >=20 > "Each domain may choose to implement different service classes or to > use different behaviors to implement the service classes or to > aggregate different kinds of traffic into the aggregates and still > achieve their required characteristics. For example, low delay, > loss, and jitter may be realized using the EF PHB, or with an over- > provisioned AF PHB." >=20 > Consequently I'm not sure I would actually agree with the following >=20 > On Jun 20, 2012, at 1:28 AM, Brian E Carpenter wrote: >>> >>> [RG-start] What you say is the PHB needs to be stable end-to-end >>> and the DSCP can (and looking at the deployments I am aware of >>> often will) vary? >> >> If you want consistent behaviour from end to end, that is correct, >> and that was the intention from the beginning. >=20 > In fact I'd say rather that the intention was to support the notion tha= t > different administrative domains might explicitly choose to implement > the same QOS for a flow or class of packets using different technical > means, as convenient and appropriate for the domain, and that this > should be supported in the architecture. Yes, you are correct, but a set of operators who choose to use the same set of PHBs can achieve more consistent behaviour by doing so. However, if a stream of packets arrives via an operator who does not make the same= choice, it needs to be reclassified and re-marked (in the simplest case, marked as Best Effort); there's no way out of that. Therefore, even if a BCP is published that defines a recommended set of PHBs, you still need to classify traffic from any source that is not definitely known to implement that BCP. Brian From jmpolk@cisco.com Wed Jun 20 14:31:17 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAC311E80AA for ; Wed, 20 Jun 2012 14:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.366 X-Spam-Level: X-Spam-Status: No, score=-110.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOGNV0cbmnCT for ; Wed, 20 Jun 2012 14:31:16 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C6D2D11E8083 for ; Wed, 20 Jun 2012 14:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2620; q=dns/txt; s=iport; t=1340227876; x=1341437476; h=message-id:date:to:from:subject:mime-version; bh=Vd507De+tv/l1UiurCXc2rcFA9eqSi6Yu3ffXv+oq+Y=; b=aeJpb9fS+WCIN2w/tPeVOwOfqMx7LLDoMFPnYKMQBCNlrrIykf65HeIQ bPeCJGZzy3XMVNiBZ9CcNJ828OwLDUxfqHdddFYTwawWm/17ZgliullQ+ 2+2wTzgEpvN7I45woOIwrYVh0TUzeU4MfobnbAyILYy0p1l8q7ZpPQFvp 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAINA4k+rRDoI/2dsb2JhbABFtVKBB4IYAQEBBQEBDwElAjQiFQMBAh8pDighCRmHaAyXRIEojWGSXosugn+CPGADiEaNdolzgxaBZoJ9 X-IronPort-AV: E=Sophos;i="4.77,446,1336348800"; d="scan'208";a="49645906" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 20 Jun 2012 21:31:16 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5KLVGwD028099 for ; Wed, 20 Jun 2012 21:31:16 GMT Message-Id: <201206202131.q5KLVGwD028099@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 Jun 2012 16:31:16 -0500 To: tsvwg@ietf.org From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [tsvwg] New side ID discussing DiffServ brought up in Paris X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 21:31:18 -0000 TSVWG (individual hat on) I've written a new DiffServ draft discussing a problem statement surrounding why we feel the need to update RFC 4594, and soon update RFC 5127. This -00 has already had a few comments on the list, and I've quickly updated to a -01 version based on Brian's comments. The links are below. We will have a presentation on this draft in Vancouver - and hope to have it be in what TSVWG should consider a second meeting slot, even though it may be called something different (like 'DiffServ'). The reason for this is to get more folks from other areas involved in the discussion that wouldn't normally come to our TSVWG meetings. Comments are welcome and, in fact, requested. James >From: >To: >Subject: I-D Action: draft-polk-diffserv-stds-problem-statement-01.txt >Date: Wed, 20 Jun 2012 14:07:41 -0700 > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : The Problem Statement for the Standard > Configuration of DiffServ Service Classes > Author(s) : James Polk > Filename : draft-polk-diffserv-stds-problem-statement-01.txt > Pages : 9 > Date : 2012-06-20 > >Abstract: > This document describes the problem statement on two recently > proposed expansions to DiffServ. The first of these expansions > proposes updating the informational RFC 4594 document to standards > track status, while making the necessary changes to make it current; > for example, creating more granular traffic treatments, some with > new Per Hop Behaviors (PHB). The second proposal defines 6 new > DiffServ Codepoints necessary from these new PHBs in the proposal > within the first draft. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-polk-diffserv-stds-problem-statement > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-polk-diffserv-stds-problem-statement-01 > >A diff from previous version is available at: >http://tools.ietf.org/rfcdiff?url2=draft-polk-diffserv-stds-problem-statement-01 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From jmpolk@cisco.com Wed Jun 20 14:48:14 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CDE21F8604 for ; Wed, 20 Jun 2012 14:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.4 X-Spam-Level: X-Spam-Status: No, score=-110.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kw0eDOtoj6ov for ; Wed, 20 Jun 2012 14:48:13 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 57E4521F85FB for ; Wed, 20 Jun 2012 14:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1429; q=dns/txt; s=iport; t=1340228893; x=1341438493; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=HfhuNdzA/GygPhABXuPG78CYvCRXZa6gt+P4UyxY0+s=; b=CTeJrFzzUw8XfdTyJx+IpiyRamWZ4ep99/v8GavfG/7WSbuVXtewm1Qr vaqwMW8u8F+QOWl64Mm2O39DIC2VW1/dBktPt5+qMBCXvNR3kz/dsBsaR DL6oGG4yjZlIMV0hUf2hun5ffhZil64D19XW+Zt6sLBxJal+qid9kkcdx A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPdE4k+rRDoJ/2dsb2JhbABFtVKBB4IZAQEEEgElAi0SEAcENhAZPgYBEiKHaJh2oEOLLoYbA4hGmn+BZoJ9gUE X-IronPort-AV: E=Sophos;i="4.77,447,1336348800"; d="scan'208";a="47074776" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 20 Jun 2012 21:47:50 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5KLlnjR019270; Wed, 20 Jun 2012 21:47:49 GMT Message-Id: <201206202147.q5KLlnjR019270@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 Jun 2012 16:47:49 -0500 To: , From: James Polk In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1. cds.t-internal.com> References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 21:48:14 -0000 At 02:50 AM 6/20/2012, Ruediger.Geib@telekom.de wrote: >I agree with you that carriers can map codepoints. Besides creating >additional work while agreeing interconneection, it's also not the >task of the operational staff to somehow get along with a lack of >standards - be that dealing 20 something (sub)classes or codepoints >where hardly more than 6-9 are required or the mapping of DSCPs >to 3 bit MPLS/Ethernet codepoints. > >Finally, I think the IETF process includes clean up and improvement >when advancing an RFC (which I'd apply also to informational RFCs >being put on standards track after years). I will support >any work which results in a clean up of RFCs 4594 and RFC 5127. >I will not support them unchanged or with even more classes >and codepoints on standards track. And yes, I think both RFCs >need to be revised together, if one is put on standards track. >[RG-end] Ruediger Just trying to be clear here, you don't want any increase in the number of service classes or treatment aggregates (of service classes)? The two are very different. Hearing you in Paris, as well as reading what you've said on several email threads - including what you have above from today, I believe you are not approving of additional treatment aggregates. I could be wrong though, and therefore am asking directly. James (individual hat on in all these discussions) From mary.ietf.barnes@gmail.com Wed Jun 20 17:34:37 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D4911E80B6 for ; Wed, 20 Jun 2012 17:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.348 X-Spam-Level: X-Spam-Status: No, score=-104.348 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrII5qfQN+8I for ; Wed, 20 Jun 2012 17:34:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B91611E8079 for ; Wed, 20 Jun 2012 17:34:29 -0700 (PDT) Received: by yenq13 with SMTP id q13so48667yen.31 for ; Wed, 20 Jun 2012 17:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CI43NmcTsFVacUoLSs941r0ipt8+EDpArjODqXXMrYA=; b=zfIw5H9t49FPiO3kTW12sM7JXGiKxJgeELvKCkqWqPDcjNws/7QK0QuDoZLn/1GHL2 4vEiDR00vectd+0SbRhonA0AnbUHZlOqfA/hiDIJOHio3qIhl7HUUuHq0tmSUQ2kYTA8 OwJVzzgS6PxvgMQdZOz3VIJ2+Ez3AcvV43aZlJEJkifTDYSR7CHUPdG8XABeNkdj4OTH w+sbSKdUXkXBp6z4M9yEt+q8/5IuGr2b7u9KacjAtDe3fnZ/9diNgNik2wp88sd/WS3J HEpjktspE12OXXfJh56L672LLnR7FDWeFwWOVk0NvII11yWqcp55Ecog0FTMgCb3CFOn oOMQ== MIME-Version: 1.0 Received: by 10.60.3.202 with SMTP id e10mr25947943oee.52.1340238867560; Wed, 20 Jun 2012 17:34:27 -0700 (PDT) Received: by 10.182.38.67 with HTTP; Wed, 20 Jun 2012 17:34:27 -0700 (PDT) In-Reply-To: References: <738CB59DA2E60242BA7C6273D0326BC6023EC798@tk5ex14mbxc272.redmond.corp.microsoft.com> Date: Wed, 20 Jun 2012 19:34:27 -0500 Message-ID: From: Mary Barnes To: tsvwg@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff1ce4c9d77c804c2f0adf0 X-Mailman-Approved-At: Wed, 20 Jun 2012 23:40:13 -0700 Subject: [tsvwg] Support for Remote Participation at the July 28 IAB / IRTF Workshop on Congestion Control for Interactive Real-Time Communication X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 00:34:37 -0000 --e89a8ff1ce4c9d77c804c2f0adf0 Content-Type: text/plain; charset=ISO-8859-1 FYI...here's an updated announcement. Note, that arrangements are being made to allow remote participation. ---------- Forwarded message ---------- From: Bernard Aboba Date: Wed, Jun 20, 2012 at 5:53 PM Subject: [rtcweb] Support for Remote Participation at the July 28 IAB / IRTF Workshop on Congestion Control for Interactive Real-Time Communication To: rtcweb@ietf.org The Program Committee has received inquiries about remote participation at the IAB/IRTF Congestion Control Workshop to be held on June 28, 2012 in Vancouver, Canada. While participants are strongly encouraged to attend the meeting in person, arrangements for remote participation are planned (for those with accepted papers). Therefore if you were considering submitting a paper but could not make the workshop in person, we would encourage you to go ahead and submit; please indicate in your submission if you are only able to participate remotely. *Call for Papers* The IAB and IRTF will hold a workshop on "Congestion Control for Interactive Real-Time Communication" in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting. More information on the workshop is available at http://www.iab.org/cc-workshop/ This is an invitation-only workshop. Every prospective workshop participant must submit a position paper. The position paper reflects your views on a particular area of the workshop theme. We are interested in your opinion as an expert rather than your official company position. Keep your submission short and focused. The focus should be on the problems and challenges that exist, rather than a detailed solution. If your expertise allows you to write about a range of topics, please pick the one topic you think would bring the most value to the workshop. Papers up to 3 pages, formatted in HTML, PDF, or plain text (for example, as a submitted Internet-Draft) are ideal. Authors of accepted papers will be invited to the workshop. Accepted position papers will be published. Please use the following Website for submitting your papers: http://iab.org/ccirtc/paper?p=new *Important Dates * Position paper submission deadline: June 23, 2012 Notification to paper authors: June 30, 2012 Workshop date: July 28, 2012 Note: please contact us if you are interested in submitting a paper but have an issue with the submission deadline. *IPR Policy * Due to the close relationship to ongoing IRTF and IETF work, the IPR policies described in RFC 5378 and RFC 3979 apply, both to submitted position papers and to discussions at the workshop. *Privacy Notice * Paper submissions have to contain a name and an email address. We use this information to subscribe you to a mailing list for sharing workshop related information prior to the workshop (e.g., updates regarding the meeting venue, feedback on the position paper submissions). This specially created mailing list is only used for the duration of the workshop and will be deleted after the publication of the workshop report (which may take several months). You may at any time decide to unsubscribe from the mailing list (at your risk of missing information workshop related postings). Your name will be listed in the meeting minutes and the workshop report. We will also publish all accepted position papers. There will be an audio recording of the workshop discussion. This workshop recording will not be distributed to the workshop participants nor to the public; the purpose of the recording is to ensure that the workshop report and the meeting minutes accurately reflect the discussions. *Meeting Venue* The workshop will be held in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.html). Additional details about the meeting venue will be provided to authors of accepted papers. While participants are strongly encouraged to attend the meeting in person, arrangements for remote participation are planned (for those with accepted papers). Please indicate in your submission if you are only able to participate remotely. *Sponsorship* If you are interested to help us working towards better interactive media congestion control mechanisms on the Internet (such as by making a contribution towards catering costs and room rental), please contact us! *Contact Information * In case of questions please send email to mary.ietf.barnes at gmail.com _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --e89a8ff1ce4c9d77c804c2f0adf0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI...here's an updated announcement. Note, = that arrangements are being made to allow remote participation.

---------- Forwarded message ----------
From: Bernard Aboba <= ;bernard_abo= ba@hotmail.com>
Date: Wed, Jun 20, 2012 at 5:53 PM
Subject: [rtcweb] Support for Remote = Participation at the July 28 IAB / IRTF Workshop on Congestion Control for = Interactive Real-Time Communication
To: rtcweb@ietf.org


The Program Committee has received inquiries about remote participation at = the IAB/IRTF Congestion Control Workshop to be held on June 28, 2012 in Van= couver, Canada.=A0 While participants are strongly encouraged to attend the= meeting in person, arrangements for remote participation are planned (for those with accepted papers).=A0= =A0 Therefore if you were considering submitting a paper but could not make= the workshop in person, we would encourage you to go ahead and submit;=A0 = please indicate in your submission if you are only able to participate remotely.

=A0

Call for Papers

=A0

The IAB and IRTF will hold a workshop on "Congestion Control for In= teractive Real-Time Communication" in Vancouver, Canada on Saturday, J= uly 28th, 2012 prior to the IETF-84 meeting.=A0 More information on the wor= kshop is available at=A0 http://www.iab.org/cc-workshop/

=A0

This is an invitation-only workshop.

=A0

Every prospective workshop participant must submit a position paper. The= position paper reflects your views on a particular area of the workshop th= eme. We are interested in your opinion as an expert rather than your offici= al company position.=A0 Keep your submission short and focused.=A0 The focus should be on the prob= lems and challenges that exist, rather than a detailed solution.=A0 If your= expertise allows you to write about a range of topics, please pick the one= topic you think would bring the most value to the workshop.

=A0

Papers up to 3 pages, formatted in HTML, PDF, or plain text (for example= , as a submitted Internet-Draft) are ideal.=A0 Authors of accepted papers w= ill be invited to the workshop.=A0 Accepted position papers will be publish= ed.=A0

=A0

Please use the following Website for submitting your papers:

http:/= /iab.org/ccirtc/paper?p=3Dnew


Important Dates

=A0

Position paper submission deadline: June 23, 2012

Notification to paper authors: June 30, 2012

Workshop date: July 28, 2012

=A0

Note: please contact us if you are interested in submitting a paper but = have an issue with the submission deadline.=A0

=A0

IPR Policy

=A0

Due to the close relationship to ongoing IRTF and IETF work, the IPR pol= icies described in RFC 5378 and RFC 3979 apply, both to submitted position = papers and to discussions at the workshop.

=A0

Privacy Notice

=A0

Paper submissions have to contain a name and an email address. We use th= is information to subscribe you to a mailing list for sharing workshop rela= ted information prior to the workshop (e.g., updates regarding the meeting = venue, feedback on the position paper submissions). This specially created mailing list is= only used for the duration of the workshop and will be deleted after the p= ublication of the workshop report (which may take several months). You may = at any time decide to unsubscribe from the mailing list (at your risk of missing information workshop relate= d postings).=A0

=A0

Your name will be listed in the meeting minutes and the workshop report.= We will also publish all accepted position papers.

=A0

There will be an audio recording of the workshop discussion. This worksh= op recording will not be distributed to the workshop participants nor to th= e public; the purpose of the recording is to ensure that the workshop repor= t and the meeting minutes accurately reflect the discussions.=A0

=A0

Meeting Venue

=A0

The workshop will be held in Vancouver, Canada on Saturday, July 28th, 2= 012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.htm= l).=A0 Additional details about the meeting venue will be provided to a= uthors of accepted papers.=A0

=A0

While participants are strongly encouraged to attend the meeting in pers= on, arrangements for remote participation are planned (for those with accep= ted papers).=A0=A0 Please indicate in your submission if you are only able = to participate remotely.

=A0

Sponsorship

=A0

If you are interested to help us working towards better interactive medi= a congestion control mechanisms on the Internet (such as by making a contri= bution towards catering costs and room rental), please contact us!

=A0

Contact Information

=A0

In case of questions please send email to mary.ietf.barnes at gmail.com


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb




--e89a8ff1ce4c9d77c804c2f0adf0-- From Ruediger.Geib@telekom.de Wed Jun 20 23:52:50 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F90821F85C3 for ; Wed, 20 Jun 2012 23:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfU12gGT1rVf for ; Wed, 20 Jun 2012 23:52:49 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 108AA21F85A8 for ; Wed, 20 Jun 2012 23:52:48 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 21 Jun 2012 08:52:46 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Thu, 21 Jun 2012 08:52:46 +0200 From: To: Date: Thu, 21 Jun 2012 08:52:45 +0200 Thread-Topic: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt Thread-Index: Ac1PLmQseHbpvj9uSbmI1W1M7pQ9qwAR3tog Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434FE41FD@HE111648.emea1.cds.t-internal.com> References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal.com> <201206202147.q5KLlnjR019270@mtv-core-4.cisco.com> In-Reply-To: <201206202147.q5KLlnjR019270@mtv-core-4.cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 06:52:50 -0000 James, I'm not opposing new classes in general. I agree to anything new if - there's a clear demand of many parties requiring more than what we have - that new stuff remains experimental or informational, especially if suggested by individuals only I'm favouring the use or the modification of what's available. I'd in fact be interested to learn how man providers have implemented AF41, 42 and 43. I'd expect to see support for AF41. The same holds for the other AF classes= . What I hear you suggesting is "let's make classes and codepoints a standard of which we don't know or care whether anybody deployed them". And the other message: by the way, I got more to be put on standards track. I've been dealing with ATM interconnection and I work on the IP/MPLS/Ethern= et QoS architecture of Deutsche Telekom. In both cases, a lack of a clear and crisp standards on how to build E2E transport services based on a technolog= y will at least delay deployment. The statement "we are not interested in long technical negotiations" from commercial folk related to IP QoS interconnection rings a bell for me. That's exactly what they've said when we interconnected ATM. The latter wasn't a success story. What I'd be really happy with: 4 QoS classes / PHBs as standard 7-9 DSCPs, if we can agree on them as standard. The aim is here: universal support, mappings are a "may" at best. Some standard MPLS TCs New DSCPs / classes go experimental/informtional - if required at all. Review of the AF classes and of some CS classes as well. Putting IP-Precedence to MPLS TC/P-Bit copying into an apropriate documen= t (be it a BCP or a standard) - that's about cross layer QoS interworking. Some not assigned DSCP/MPLS TC and Ethernet P-Bit space to leave room for migration, new services and carrier internal QoS classes (I regard network management/routing as a (sub)class not to be shared with externals)= . As mentioned, some ITU documents are under way to IETF. Apart from that, I'm happy to submit a draft or act as a content providing co-author. But I won't be able to do that prior to Vancouver (I also won't participate physically and remote participation may depend on the time slot). Regards, R=FCdiger -----Original Message----- From: James Polk [mailto:jmpolk@cisco.com] Sent: Wednesday, June 20, 2012 11:48 PM To: Geib, R=FCdiger; brian.e.carpenter@gmail.com Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement= -00.txt At 02:50 AM 6/20/2012, Ruediger.Geib@telekom.de wrote: >I agree with you that carriers can map codepoints. Besides creating >additional work while agreeing interconneection, it's also not the >task of the operational staff to somehow get along with a lack of >standards - be that dealing 20 something (sub)classes or codepoints >where hardly more than 6-9 are required or the mapping of DSCPs >to 3 bit MPLS/Ethernet codepoints. > >Finally, I think the IETF process includes clean up and improvement >when advancing an RFC (which I'd apply also to informational RFCs >being put on standards track after years). I will support >any work which results in a clean up of RFCs 4594 and RFC 5127. >I will not support them unchanged or with even more classes >and codepoints on standards track. And yes, I think both RFCs >need to be revised together, if one is put on standards track. >[RG-end] Ruediger Just trying to be clear here, you don't want any increase in the number of service classes or treatment aggregates (of service classes)? The two are very different. Hearing you in Paris, as well as reading what you've said on several email threads - including what you have above from today, I believe you are not approving of additional treatment aggregates. I could be wrong though, and therefore am asking directly. James (individual hat on in all these discussions) From Ruediger.Geib@telekom.de Thu Jun 21 00:10:06 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE6721F85D6 for ; Thu, 21 Jun 2012 00:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-Nk+lGxiwQA for ; Thu, 21 Jun 2012 00:10:05 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8083E21F851E for ; Thu, 21 Jun 2012 00:10:05 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 21 Jun 2012 09:10:02 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 21 Jun 2012 09:09:48 +0200 From: To: Date: Thu, 21 Jun 2012 09:09:47 +0200 Thread-Topic: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt Thread-Index: Ac1OwngCrJ2eMxvUS4y7EnD9SCD2wQAuOPmw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434FE4269@HE111648.emea1.cds.t-internal.com> References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal. com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 07:10:06 -0000 John, you've emphasised 1) Different administrative domains along an end to end path are using different technical means - different combinations of PHB, border traffic shaping, admission control, overcapacity, etc - to implement the same overall QOS for a service class, or 2) Different administrative domains along an end to end path are providing different QOS to the data flow due to different administrative agreements, etc. I'd like to understand which approach you favour: - RFC4594 is informational and should be left like that to continue giving freedom while deploying DiffServ. - Standardise a limited set of PHBs and assigned codepoints. This allows for some E2E QoS deployments and leaves room for other, more flexible deployments. - Standardise all QoS class/codepoint assignments of RFC4594 and add some new ones. This limits space for deployment of flexible schemes. Regards, R=FCdiger From Ruediger.Geib@telekom.de Thu Jun 21 00:21:43 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BA121F846E for ; Thu, 21 Jun 2012 00:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3ML2dxK2jTV for ; Thu, 21 Jun 2012 00:21:42 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFF011E80A1 for ; Thu, 21 Jun 2012 00:21:35 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 21 Jun 2012 09:21:22 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 21 Jun 2012 09:21:22 +0200 From: To: Date: Thu, 21 Jun 2012 09:21:21 +0200 Thread-Topic: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt Thread-Index: Ac1O92eiqF0i1YpPQtKD6ycZ129JdAAhYgKA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434FE42AB@HE111648.emea1.cds.t-internal.com> References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal. com> <4FE1E8D6.4090301@gmail.com> In-Reply-To: <4FE1E8D6.4090301@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 07:21:44 -0000 >>> [RG-start] What you say is the PHB needs to be stable end-to-end >>> and the DSCP can (and looking at the deployments I am aware of >>> often will) vary? >> BC If you want consistent behaviour from end to end, that is correct, >> and that was the intention from the beginning. > JW In fact I'd say rather that the intention was to support the notion tha= t > different administrative domains might explicitly choose to implement > the same QOS for a flow or class of packets using different technical > means, as convenient and appropriate for the domain, and that this > should be supported in the architecture. [BC] Yes, you are correct, but a set of operators who choose to use the same set of PHBs can achieve more consistent behaviour by doing so. However, if a stream of packets arrives via an operator who does not make the same choice, it needs to be reclassified and re-marked (in the simplest case, marked as Best Effort); there's no way out of that. Therefore, even if a BCP is published that defines a recommended set of PHBs, you still need to classify traffic from any source that is not definitely known to implement that BCP. [RG] Thank's Brian, that's exactly what the company I work for can't deal with. Quality of Service as described above is a "maybe". It can't be defined in commercial terms, monitored or operated or be explained to a customer. A BCP or any other document which is giving clearer guidance than the AF specification or RFC4594 will help. Look at EF to see something which sees widespread deployment. EF can be put on standards track any time and the expectation to see E2E deployment is justified. Regards, R=FCdiger From brian.e.carpenter@gmail.com Thu Jun 21 05:32:52 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F0A21F8565 for ; Thu, 21 Jun 2012 05:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.877 X-Spam-Level: X-Spam-Status: No, score=-100.877 tagged_above=-999 required=5 tests=[AWL=0.814, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ekxy8EfG6EAM for ; Thu, 21 Jun 2012 05:32:52 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A462721F855E for ; Thu, 21 Jun 2012 05:32:51 -0700 (PDT) Received: by eekd4 with SMTP id d4so210766eek.31 for ; Thu, 21 Jun 2012 05:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xrR07CueY6mRdhZtKtMhz8UY8j0y83XQVHTqJoavoxg=; b=SEUlgBdJSTikId5jvPGU7RUajogzo3Jb9HFotwJ7QHEhQMEP/11FAr1Rd+R8imWhxb DzPaMjV9ByS/gjKyGD2StS0crPHokZtqSZSRY4Xuzk/wqwaP8DIhPMuC4o3aX8XnrpDP ETdHSOkEgruMKpouzOA6/5HoTB3Oh/qhXW6CqHS5WHqSAQaP9Hnk9mPdqxFgvK1CGxNw +yrF6tqxly8gLAD0L66S/BSJpT7HneRjvGk+8H6nFc2+XZhS4EM7srIJhOotS7nROOUE PRIi2JpEyKHKwqS0OR73iggytflMANeQA5e2dm/O5jbhsYy4ZZVu38wG4GgDGUxgbkqQ rz3g== Received: by 10.14.98.202 with SMTP id v50mr5607386eef.80.1340281970714; Thu, 21 Jun 2012 05:32:50 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-59.as13285.net. [2.102.216.59]) by mx.google.com with ESMTPS id c51sm102393985eei.12.2012.06.21.05.32.49 (version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 05:32:49 -0700 (PDT) Message-ID: <4FE3146C.5010904@gmail.com> Date: Thu, 21 Jun 2012 13:32:44 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal. com> <4FE1E8D6.4090301@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434FE42AB@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434FE42AB@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 12:32:52 -0000 I need to highlight one remark by R=C3=BCdiger: On 2012-06-21 08:21, Ruediger.Geib@telekom.de wrote: =2E.. > Quality of Service as described above is a "maybe". It > can't be defined in commercial terms, monitored or operated or be > explained to a customer. That is Internet 101. I've been dealing with operators such as your employer since the time when they were still called PTTs, and I know that this is as hard for them to accept now as it was in 1990. However, there will *always* be best effort traffic in the Internet, and I suspect it will always be the majority of traffic. As I have been known to say, you can't beat queueing theory. At best, diffserv can partially compensate for this, but that's all. I understand that this may be hard to explain to business managers, but it does set limits on what we can achieve. Brian From Ruediger.Geib@telekom.de Fri Jun 22 04:29:41 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1777121F8592 for ; Fri, 22 Jun 2012 04:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lIvjckUlOZa for ; Fri, 22 Jun 2012 04:29:40 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBDF21F85D4 for ; Fri, 22 Jun 2012 04:29:40 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 22 Jun 2012 13:29:38 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 22 Jun 2012 13:29:12 +0200 From: To: Date: Fri, 22 Jun 2012 13:29:11 +0200 Thread-Topic: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt Thread-Index: Ac1Pqfn09eiKnP9USDKhi2G+R1JlpAAla3Sw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D143504B039@HE111648.emea1.cds.t-internal.com> References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal. com> <4FE1E8D6.4090301@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434FE42AB@HE111648.emea1.cds.t-internal.com> <4FE3146C.5010904@gmail.com> In-Reply-To: <4FE3146C.5010904@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 11:29:41 -0000 Brian, the core network of the company I work for is as connectionless as can be, i.e. we apply metric optimisation based Traffic Engineering. This is made QoS aware. We've adapted our core network architecture, introduced Traffic Engineering and deployed QoS from 2000 on. The resulting service is meeting commercial service requirements (I recall my boss having a smile in his face when he compared figures of measured IP core delay variation with the 125 us of ISDN). The IP/MPLS core network exposes deterministic behaviour under foreseeable operational conditions. This I expect to be true for all carriers applying Traffic Engineering. But also data center providers nowadays engineer their infrastructure on other factors than just cost. Part of all the engineering is based on an assumption, that the majority of traffic will be Best Effort. I hope, you and other senior IETF members keep in mind, that while the age of PTTs is over, also the "Internet of 1990" is no longer existing. Regards, R=FCdiger -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] Sent: Thursday, June 21, 2012 2:33 PM To: Geib, R=FCdiger Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement= -00.txt I need to highlight one remark by R=FCdiger: On 2012-06-21 08:21, Ruediger.Geib@telekom.de wrote: ... > Quality of Service as described above is a "maybe". It > can't be defined in commercial terms, monitored or operated or be > explained to a customer. That is Internet 101. I've been dealing with operators such as your employer since the time when they were still called PTTs, and I know that this is as hard for them to accept now as it was in 1990. However, there will *always* be best effort traffic in the Internet, and I suspect it will always be the majority of traffic. As I have been known to say, you can't beat queueing theory. At best, diffserv can partially compensate for this, but that's all. I understand that this may be hard to explain to business managers, but it does set limits on what we can achieve. Brian From brian.e.carpenter@gmail.com Fri Jun 22 04:50:15 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4147F21F867E for ; Fri, 22 Jun 2012 04:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMPLBwgrgMjI for ; Fri, 22 Jun 2012 04:50:14 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6918A21F8674 for ; Fri, 22 Jun 2012 04:50:14 -0700 (PDT) Received: by eaaq13 with SMTP id q13so629026eaa.31 for ; Fri, 22 Jun 2012 04:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DNXR4/DzJG+n3qbvkmdzr7YAyutWBtociC4BFuLNA08=; b=pOnVwjPvo92posXNhQGHemDct7gFkjeD31E/S9M+iKCf9mkTuZ59gpwBs/q6uUrPtF GSD5SFTMPnZEX1AOGJwoljdDXKkxqsah19PFs5u8+OZVQW7awcV39+GMhSZFcWnn8pdz xFMbQuGrN6/rPWevs342U5tl2ov+FifTBWTs39nbREQ+v1d1UZHXGH3lAL7FLlhhBAjw jY1OZ83WCmwQBPh4orWOqD43S+UdY65HKHnkXPyVwSrrJxtsDz3KsCzoxDpalRkZkSDw NBO74aIA8bUg9Mlm+oG583sygKnOvB/up/1nDGsJvoU+E0yM8W6ejg4W1yopql/baOmv UK3A== Received: by 10.14.95.138 with SMTP id p10mr384762eef.110.1340365813364; Fri, 22 Jun 2012 04:50:13 -0700 (PDT) Received: from [192.168.1.66] (host-2-101-188-35.as13285.net. [2.101.188.35]) by mx.google.com with ESMTPS id m46sm94139036eeh.9.2012.06.22.04.50.11 (version=SSLv3 cipher=OTHER); Fri, 22 Jun 2012 04:50:12 -0700 (PDT) Message-ID: <4FE45BEF.6040302@gmail.com> Date: Fri, 22 Jun 2012 12:50:07 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal. com> <4FE1E8D6.4090301@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434FE42AB@HE111648.emea1.cds.t-internal.com> <4FE3146C.5010904@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D143504B039@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D143504B039@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 11:50:15 -0000 R=C3=BCdiger, I don't think we disagree in any fundamental way. However, when you say "we've deployed QoS from 2000 on", can you state which technology you mean? Regards Brian Carpenter On 2012-06-22 12:29, Ruediger.Geib@telekom.de wrote: > Brian, >=20 > the core network of the company I work for is as > connectionless as can be, i.e. we apply metric > optimisation based Traffic Engineering. > This is made QoS aware. We've adapted our core network > architecture, introduced Traffic Engineering and deployed > QoS from 2000 on. The resulting service is meeting commercial > service requirements (I recall my boss having a smile in > his face when he compared figures of measured IP core > delay variation with the 125 us of ISDN). >=20 > The IP/MPLS core network exposes deterministic behaviour > under foreseeable operational conditions. >=20 > This I expect to be true for all carriers applying > Traffic Engineering. But also data center providers > nowadays engineer their infrastructure on other factors > than just cost. >=20 > Part of all the engineering is based on an assumption, > that the majority of traffic will be Best Effort. >=20 > I hope, you and other senior IETF members keep in mind, > that while the age of PTTs is over, also the "Internet > of 1990" is no longer existing. >=20 > Regards, >=20 > R=C3=BCdiger >=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Thursday, June 21, 2012 2:33 PM > To: Geib, R=C3=BCdiger > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-state= ment-00.txt >=20 > I need to highlight one remark by R=C3=BCdiger: >=20 > On 2012-06-21 08:21, Ruediger.Geib@telekom.de wrote: > ... >> Quality of Service as described above is a "maybe". It >> can't be defined in commercial terms, monitored or operated or be >> explained to a customer. >=20 > That is Internet 101. I've been dealing with operators such as > your employer since the time when they were still called PTTs, > and I know that this is as hard for them to accept now as it was > in 1990. However, there will *always* be best effort traffic in > the Internet, and I suspect it will always be the majority of > traffic. As I have been known to say, you can't beat queueing > theory. At best, diffserv can partially compensate for this, but > that's all. >=20 > I understand that this may be hard to explain to business > managers, but it does set limits on what we can achieve. >=20 > Brian >=20 >=20 >=20 From Ruediger.Geib@telekom.de Fri Jun 22 07:11:07 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDA221F8621 for ; Fri, 22 Jun 2012 07:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJCXPMcPpSnv for ; Fri, 22 Jun 2012 07:11:06 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5879721F8618 for ; Fri, 22 Jun 2012 07:11:06 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 22 Jun 2012 16:11:03 +0200 Received: from HE113656.emea1.cds.t-internal.com (10.134.99.16) by HE111628.emea1.cds.t-internal.com (10.134.93.20) with Microsoft SMTP Server (TLS) id 8.3.245.1; Fri, 22 Jun 2012 16:11:03 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 22 Jun 2012 16:11:03 +0200 From: To: Date: Fri, 22 Jun 2012 16:11:01 +0200 Thread-Topic: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt Thread-Index: Ac1QbTAaZYJr3wEwSIaBdMQrwtZkrgACkuXw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D143504B29B@HE111648.emea1.cds.t-internal.com> References: <20120615213036.6748.34733.idtracker@ietfa.amsl.com> <4FE08AE5.2040701@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434F620B9@HE111648.emea1.cds.t-internal. com> <4FE1E8D6.4090301@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1434FE42AB@HE111648.emea1.cds.t-internal.com> <4FE3146C.5010904@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D143504B039@HE111648.emea1.cds.t-internal.com> <4FE45BEF.6040302@gmail.com> In-Reply-To: <4FE45BEF.6040302@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 14:11:07 -0000 Brian, would the he reply DiffServ, deployed in the complete core network (IP and MPLS) be sufficient? Up to now, we didn't deploy or operate any RSVP based solutions. Regards, R=FCdiger -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] Sent: Friday, June 22, 2012 1:50 PM To: Geib, R=FCdiger Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement= -00.txt R=FCdiger, I don't think we disagree in any fundamental way. However, when you say "we've deployed QoS from 2000 on", can you state which technology you mean? Regards Brian Carpenter On 2012-06-22 12:29, Ruediger.Geib@telekom.de wrote: > Brian, > > the core network of the company I work for is as > connectionless as can be, i.e. we apply metric > optimisation based Traffic Engineering. > This is made QoS aware. We've adapted our core network > architecture, introduced Traffic Engineering and deployed > QoS from 2000 on. The resulting service is meeting commercial > service requirements (I recall my boss having a smile in > his face when he compared figures of measured IP core > delay variation with the 125 us of ISDN). > > The IP/MPLS core network exposes deterministic behaviour > under foreseeable operational conditions. > > This I expect to be true for all carriers applying > Traffic Engineering. But also data center providers > nowadays engineer their infrastructure on other factors > than just cost. > > Part of all the engineering is based on an assumption, > that the majority of traffic will be Best Effort. > > I hope, you and other senior IETF members keep in mind, > that while the age of PTTs is over, also the "Internet > of 1990" is no longer existing. > > Regards, > > R=FCdiger > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Thursday, June 21, 2012 2:33 PM > To: Geib, R=FCdiger > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-stateme= nt-00.txt > > I need to highlight one remark by R=FCdiger: > > On 2012-06-21 08:21, Ruediger.Geib@telekom.de wrote: > ... >> Quality of Service as described above is a "maybe". It >> can't be defined in commercial terms, monitored or operated or be >> explained to a customer. > > That is Internet 101. I've been dealing with operators such as > your employer since the time when they were still called PTTs, > and I know that this is as hard for them to accept now as it was > in 1990. However, there will *always* be best effort traffic in > the Internet, and I suspect it will always be the majority of > traffic. As I have been known to say, you can't beat queueing > theory. At best, diffserv can partially compensate for this, but > that's all. > > I understand that this may be hard to explain to business > managers, but it does set limits on what we can achieve. > > Brian > > > From gorry@erg.abdn.ac.uk Tue Jun 26 00:26:26 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8675821F856D; Tue, 26 Jun 2012 00:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0eQ1JYb43pg; Tue, 26 Jun 2012 00:26:26 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id C0E1D21F855A; Tue, 26 Jun 2012 00:26:24 -0700 (PDT) Received: from Gorry.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q5Q7QEFD025112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 Jun 2012 08:26:15 +0100 (BST) Message-ID: <4FE96416.1010502@erg.abdn.ac.uk> Date: Tue, 26 Jun 2012 08:26:14 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: tsvwg-chairs@ietf.org, draft-nishida-tsvwg-sctp-failover@tools.ietf.org Subject: [tsvwg] Comments requested on adoption of draft-nishida-tsvwg-sctp-failover-05 as a TSVWG draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 07:26:26 -0000 All, The TSVWG is considering adopting the following draft as a working group document for publication as PS: Quick Failover Algorithm in SCTP draft-nishida-tsvwg-sctp-failover-05 http://datatracker.ietf.org/doc/draft-nishida-tsvwg-sctp-failover/ This draft has been discussed at previous IETF meetings and is thought to not conflict with any current or planned IETF work. It also appears to fall within the charter of this WG. Please state your opinion, positive or negative, on the mailing list or to the chairs. This consensus call will end on June 26, 2012. Regards, Gorry Fairhurst & James Polk (TSVWG Co-Chairs) -------------------------------------------------------------------- IETF TSVWG working group mailing list From Michael.Tuexen@lurchi.franken.de Tue Jun 26 01:18:11 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9542421F8589; Tue, 26 Jun 2012 01:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKc0CK5fzM8w; Tue, 26 Jun 2012 01:18:11 -0700 (PDT) Received: from mail-n.franken.de (mail-n.franken.de [193.175.24.27]) by ietfa.amsl.com (Postfix) with ESMTP id 10C7B21F8582; Tue, 26 Jun 2012 01:18:10 -0700 (PDT) Received: from [10.0.1.101] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6CEB51C0B4627; Tue, 26 Jun 2012 10:18:08 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <4FE96416.1010502@erg.abdn.ac.uk> Date: Tue, 26 Jun 2012 10:18:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A5317F9-2427-4BE8-82CA-C00FAAF4D71A@lurchi.franken.de> References: <4FE96416.1010502@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1278) Cc: draft-nishida-tsvwg-sctp-failover@tools.ietf.org, tsvwg@ietf.org, tsvwg-chairs@ietf.org Subject: Re: [tsvwg] Comments requested on adoption of draft-nishida-tsvwg-sctp-failover-05 as a TSVWG draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 08:18:11 -0000 On Jun 26, 2012, at 9:26 AM, Gorry Fairhurst wrote: > All, >=20 > The TSVWG is considering adopting the following draft as a working = group document for publication as PS: >=20 > Quick Failover Algorithm in SCTP > draft-nishida-tsvwg-sctp-failover-05 > http://datatracker.ietf.org/doc/draft-nishida-tsvwg-sctp-failover/ >=20 > This draft has been discussed at previous IETF meetings and is thought = to not conflict with any current or planned IETF work. It also appears = to fall within the charter of this WG. Please state your opinion, = positive or negative, on the mailing list or to the chairs. This = consensus call will end on June 26, 2012. I think this should be adopted as a WG item. I read it, provided = comments and I'm willing to review upcoming versions. This current version has also been implemented in FreeBSD. Best regards Michael >=20 > Regards, >=20 > Gorry Fairhurst & James Polk > (TSVWG Co-Chairs) >=20 > -------------------------------------------------------------------- > IETF TSVWG working group mailing list >=20 >=20 From jacl@tid.es Tue Jun 26 06:55:59 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FB521F8653 for ; Tue, 26 Jun 2012 06:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.242 X-Spam-Level: X-Spam-Status: No, score=-5.242 tagged_above=-999 required=5 tests=[AWL=1.357, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEMI21d1tAAK for ; Tue, 26 Jun 2012 06:55:58 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5B9D21F860B for ; Tue, 26 Jun 2012 06:55:57 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M68006YQ9D44U@tid.hi.inet> for tsvwg@ietf.org; Tue, 26 Jun 2012 15:55:52 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id B6.C2.26499.86FB9EF4; Tue, 26 Jun 2012 15:55:52 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M68006YN9D44U@tid.hi.inet> for tsvwg@ietf.org; Tue, 26 Jun 2012 15:55:52 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Tue, 26 Jun 2012 15:55:52 +0200 Date: Tue, 26 Jun 2012 15:55:51 +0200 From: JUAN ANTONIO CASTELL LUCIA To: "tsvwg@ietf.org" Message-id: <7AB622D0785205478D7D819B3C13533581B6703590@EXCLU2K7.hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: es-ES Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: Extension proposal for draft-saldana-tsvwg-tcmtf-02: asking for feedback Thread-index: Ac1To2WFtuHooc5uQZ23/a7eA/CLOA== acceptlanguage: es-ES, en-US X-AuditID: 0a5f4068-b7f206d000006783-c9-4fe9bf68a1f4 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsXCFe/ApZux/6W/wZePMhbH3txlc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpSrO1gKzohUdCxfwNTA2CHSxcjJISFgIjHv4SRGCFtM4sK9 9WxdjFwcQgIbGSW+9BxnhnB+MkqsW3OJFcJpZJTYe/c/K0gLi4CqxNXLK5hBbDYBPYlDq/6D jRIWCJZoWPifBcQWAaq53LGWCcTmFfCU2PH1HQuELSjxY/I9IJuDg1lAXWLKlFyQMLOAuMSc XxNZIWxFiWmLGsBGMgrISqw8f5oRYmSExI+Pa9ghbD2J32u+skLUyEj8X76XBeIbAYkle84z Q9iiEi8f/2OdwCgyC8nmWQibZyHZPAvJ5gWMLKsYxYqTijLTM0pyEzNz0g0M9TIy9TLzUks2 MUKCP2MH4/KdKocYBTgYlXh4Pepf+AuxJpYVV+YeYpTkYFIS5T2w56W/EF9SfkplRmJxRnxR aU5q8SFGCQ5mJRFeuW1AOd6UxMqq1KJ8mJQMB4eSBO+KfUApwaLU9NSKtMwcYIzDpJk4OEHa eYDa54HU8BYXJOYWZ6ZD5E8xSkqJQyQEQBIZpXlwva8YxYGOFOZdBpLlASYjuK5XQAOZgAZy bHoBMrAkESEl1cDI7ajIs8VvF8fqqWkzDLk+yWS3SbDN5uKz3C63qMArYV/d4WwH/+WPux9I 3N3a++OtQUxFk//+tYd4VvB8ynC6FPxI+NI9nUKRqtn/EhbpuKptXrNhk8T8X9J5zFzPrEP1 uAIOGpYJnpVbvaMh/7PvNlllg+C/T3bVGvJ7RsSdKw4S0s1RnazEUpyRaKjFXFScCADm6lVd AwMAAA== Subject: [tsvwg] Extension proposal for draft-saldana-tsvwg-tcmtf-02: asking for feedback X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 13:57:36 -0000 SGkgYWxsLCBJJ3ZlIHJlYWQgdGhlIGRyYWZ0LCBhbmQgZm9yIG1lIGl0IGhhcyByZXN1bHRlZCB2 ZXJ5IGludGVyZXN0aW5nLiBBcyBhIHByb3Bvc2FsIG9mIGNvdmVyYWdlIGV4dGVuc2lvbiBvZiB0 aGUgc3RhbmRhcmQsIEkgd291bGQgbGlrZSB0byBwcm9wb3NlIHlvdSB0byBkb24ndCBwdXQgZm9j dXMgb25seSBpbiByZWFsLXRpbWUgZmxvd3MuDQpGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGEg bmV0d29yayBvcGVyYXRvciwgdGhlcmUgYXJlIGxvdHMgb2Yga2luZCBvZiBzbWFsbCBwYWNrZXRz IHRoYXQgc3VwcG9zZSBhIGJpZyBhbW91bnQgb2YgaW5mb3JtYXRpb24gYW5kIHBhY2tldHMgdHJh dmVsbGluZyB0aHJvdWdoIHRoZSBuZXR3b3JrLiBBbiBleGFtcGxlIGNvdWxkIGJlIEROUyBwYWNr ZXRzLiBBIEROUyBwYWNrZXQgbWF5IGhhdmUgYW4gYXZlcmFnZSBzaXplIHVuZGVyIDEwMCBieXRl cywgaW5jbHVkZWQgaGVhZGVyIGJ5dGVzLiBBbmQgdGhlIGFtb3VudCBvZiBETlMgcGFja2V0cyBp biBhIG1lZGl1bSBvciBiaWcgb3BlcmF0b3IgbWF5IGFjaGlldmUgYSByYXRlIG9mIHRob3VzYW5k cyBvZiBwYWNrZXRzIHBlciBzZWNvbmQuIEl0IGNvdWxkIGFsc28gYmUgdXNlZCBpbiB0aGUgY29t bXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBjYWNoZSBETlMgYW5kIHRoZSBhdXRob3JpdGF0aXZlIERO UyBUTEQgc2VydmVycywgcmVkdWNpbmcgdGhlIGJhbmR3aWR0aCBhbmQgYWRkaW5nIGFsc28gYSBu ZXcga2luZCBvZiBzZWN1cmUgY29tbXVuaWNhdGlvbnMgKHRoZSB0dW5uZWwgY291bGQgYmUgYSBz ZWN1cmUgb25lLCBhcyBJUFNlYykuIEFsdGhvdWdoIHRoZXJlIGlzIGFscmVhZHkgYSBzZWN1cmUg RE5TIFNlYyBwcm90b2NvbCBkZWZpbmVkIGJ5IElFVEYsIHRoaXMgbXVzdCBub3QgYmUgc2VlbiBh cyBpbmNvbXBhdGlibGUuDQoNCkJlc2lkZXMsIHRoZXJlIGFyZSBvdGhlciBraW5kcyBvZiB0cmFm ZmljIG9mIHNlcnZpY2VzLCBhcyBjb3VsZCBiZSBjaGF0dGluZyBhcHBsaWNhdGlvbnMgbGlrZSB3 aGF0c2FwcCBhbmQgc2ltaWxhciBvbmVzLCB0aGF0IGNhbiBzdXBwb3NlIGEgbG90IG9mIGJ5dGVz IHRoYXQgY2FuIGJlIGNvbXByZXNzZWQsIG11bHRpcGxleGVkLCBhbmQgdHVubmVsbGVkIHRvIHRo ZSBzZXJ2ZXIgZW5kcG9pbnQuDQpTcGVjaWFsbHkgaW4gcnVzaCBob3VycywgbGlrZSBuZXcgeWVh cidzIG5pZ2h0LCBDaHJpc3RtYXMgZGF5LCBldGMuLi50aGlzIGNvdWxkIGJlIHZlcnkgdXNlZnVs LCBub3Qgb25seSBmb3IgdGhlIG9wZXJhdG9yLCBidXQgYWxzbyBmb3IgdGhlIGFwcGxpY2F0aW9u IG93bmVyLg0KDQpJbiBzdW1tYXJ5LCBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB5b3UgdG8gaW5j bHVkZSBvdGhlciBzdWJjaGFwdGVyIDEuWCBmb3Igc3VjaCBraW5kIG9mIHRyYWZmaWMsIG5vdCBh cyBzZW5zaWJsZSB0byBkZWxheSBhcyB0aGUgb3RoZXIgb25lcyB5b3UgY29tbWVudCBpbiB0aGUg ZHJhZnQsIGJ1dCB2ZXJ5IG9wdGltaXphYmxlcy4NCg0KV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQg aXQ/DQoNClJlZ2FyZHMsDQoNCkp1YW4gQW50b25pbw0KDQoNCg0KDQoNCkVzdGUgbWVuc2FqZSBz ZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRh ciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVj dHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBp cyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFu ZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdA0KaHR0 cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== From Martin.Stiemerling@neclab.eu Tue Jun 26 07:29:40 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC7C21F858F for ; Tue, 26 Jun 2012 07:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Juz-je6vuCW2 for ; Tue, 26 Jun 2012 07:29:40 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C71C121F8518 for ; Tue, 26 Jun 2012 07:29:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 331C4101656; Tue, 26 Jun 2012 16:34:01 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6Cy5fy8j3ZR; Tue, 26 Jun 2012 16:34:01 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 1BECD101643; Tue, 26 Jun 2012 16:33:51 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 26 Jun 2012 16:30:59 +0200 Message-ID: <4FE9C748.3080601@neclab.eu> Date: Tue, 26 Jun 2012 16:29:28 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Cc: "tsv-ads@tools.ietf.org" , Rolf Winter Subject: [tsvwg] A new co-chair for TSVWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:29:40 -0000 Hi, I'm happy to announce that we have a new third co-chair for the TSVWG: Please welcome Rolf Winter (rolf.winter@neclab.eu) as co-chair. Best regards Martin -- IETF Transport Area Director martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From jsaldana@unizar.es Wed Jun 27 00:55:56 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708CA21F864B for ; Wed, 27 Jun 2012 00:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBPCb8zPsGxq for ; Wed, 27 Jun 2012 00:55:55 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4F71F21F8648 for ; Wed, 27 Jun 2012 00:55:44 -0700 (PDT) Received: from jsaldanapc (n33d97.cs.unibo.it [130.136.33.97]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q5R7tdFf005379; Wed, 27 Jun 2012 09:55:40 +0200 From: "Jose Saldana" To: "'JUAN ANTONIO CASTELL LUCIA'" , References: <7AB622D0785205478D7D819B3C13533581B6703590@EXCLU2K7.hi.inet> In-Reply-To: <7AB622D0785205478D7D819B3C13533581B6703590@EXCLU2K7.hi.inet> Date: Wed, 27 Jun 2012 09:55:39 +0200 Message-ID: <001c01cd543a$3f091a90$bd1b4fb0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIZWKol1SiGyT52I9oehEwlyGAJ+5Z1ugSw Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tsvwg] Extension proposal for draft-saldana-tsvwg-tcmtf-02: asking for feedback X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 07:55:56 -0000 Juan Antonio, I think your proposal is interesting. By now, we are mostly focused in = real-time flows, since you can find flows of e.g. 50 pps, with a common = origin and destination. In that cases, the header compression rate is = big, since all the packets have, at least, the same IP-port origin and = destinations. So you can save a lot of bytes in each packet. We should not forget that the proposal is for tunneling, compressing and = multiplexing. So for the DNS case, we should think a bit more. Some = thoughts: - Are there scenarios where many DNS flows share a path?: In the case of = " the communication between the cache DNS and the authoritative DNS TLD = servers", perhaps you can simply establish a tunnel with header = compression. But I don't think multiplexing is present: which flows do = you aggregate? Isn't it only one flow? So we have tunneling and = compressing, but not multiplexing. (If somebody finds a scenario where = multiplexing is also possible, it would be fine). - In the case of Whatsapp, I think TCMTF can be applied, but if you = really want to save bandwidth, you need to locate the multiplexer in a = place where you can bundle a really high number of flows. In addition, = the flows will not have the same IP origin (you cannot multiplex two = messages from the same user, since you would lose the interactivity). = Perhaps all the flows behind a NAT would have the same IP origin and = destination but, how many flows can you find there? On the other hand, = the advantage is that the multiplexing period can be bigger in order to = get more savings. I think a Whatsapp user would not notice a delay of 1 = or 2 seconds. (In contrast, for a FPS game, adding more than 40-50 ms is = really bad). Logically, these effects and the savings should be studied, = but nothing prevents us to include non real-time flows as a use case in = the draft. Perhaps we could deploy some preliminary calculations. It is not = difficult to find the asymptote of the bandwidth saving: is a very = simple quotient: you only need to estimate the average size of the = compressed header you would obtain. (You can find an example in the = equation (2) of this paper: = http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf)=20 Best regards, Jose -----Mensaje original----- De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de = JUAN ANTONIO CASTELL LUCIA Enviado el: martes, 26 de junio de 2012 15:56 Para: tsvwg@ietf.org Asunto: [tsvwg] Extension proposal for draft-saldana-tsvwg-tcmtf-02: = asking for feedback Hi all, I've read the draft, and for me it has resulted very = interesting. As a proposal of coverage extension of the standard, I = would like to propose you to don't put focus only in real-time flows. >From the point of view of a network operator, there are lots of kind of = small packets that suppose a big amount of information and packets = travelling through the network. An example could be DNS packets. A DNS = packet may have an average size under 100 bytes, included header bytes. = And the amount of DNS packets in a medium or big operator may achieve a = rate of thousands of packets per second. It could also be used in the = communication between the cache DNS and the authoritative DNS TLD = servers, reducing the bandwidth and adding also a new kind of secure = communications (the tunnel could be a secure one, as IPSec). Although = there is already a secure DNS Sec protocol defined by IETF, this must = not be seen as incompatible. Besides, there are other kinds of traffic of services, as could be = chatting applications like whatsapp and similar ones, that can suppose a = lot of bytes that can be compressed, multiplexed, and tunnelled to the = server endpoint. Specially in rush hours, like new year's night, Christmas day, = etc...this could be very useful, not only for the operator, but also for = the application owner. In summary, I would like to propose you to include other subchapter 1.X = for such kind of traffic, not as sensible to delay as the other ones you = comment in the draft, but very optimizables. What do you think about it? Regards, Juan Antonio Este mensaje se dirige exclusivamente a su destinatario. Puede consultar = nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo = electr=C3=B3nico en el enlace situado m=C3=A1s abajo. This message is intended exclusively for its addressee. We only send and = receive email on the basis of the terms set out at = http://www.tid.es/ES/PAGINAS/disclaimer.aspx From jsaldana@unizar.es Wed Jun 27 01:19:45 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C47821F8671; Wed, 27 Jun 2012 01:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFUg5le8ZRlw; Wed, 27 Jun 2012 01:19:43 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 21DED21F8657; Wed, 27 Jun 2012 01:19:42 -0700 (PDT) Received: from jsaldanapc (n33d97.cs.unibo.it [130.136.33.97]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q5R8JOFa023423; Wed, 27 Jun 2012 10:19:37 +0200 From: "Jose Saldana" To: "'Michael Tuexen'" , References: <4FE96416.1010502@erg.abdn.ac.uk> <2A5317F9-2427-4BE8-82CA-C00FAAF4D71A@lurchi.franken.de> In-Reply-To: <2A5317F9-2427-4BE8-82CA-C00FAAF4D71A@lurchi.franken.de> Date: Wed, 27 Jun 2012 10:19:24 +0200 Message-ID: <001d01cd543d$97bb1190$c73134b0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01CD544E.5B44F300" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVfl9FtTLwjs6W7VA+PXNn42KHCwF1ZLhclnHPR0A= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg-chairs@ietf.org, draft-nishida-tsvwg-sctp-failover@tools.ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] Comments requested on adoption of draft-nishida-tsvwg-sctp-failover-05 as a TSVWG draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 08:19:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001E_01CD544E.5B44F300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have read the draft and I find it very interesting for improving SCTP when dealing with network failures. I agree with adopting it as a WG item. Some small things which could be corrected: - First paragraph of Section 4.2: "During failover process. RTO keeps being doubled." "During failover process, RTO keeps being doubled." - First paragraph of page 8: "SCTP MUST NOT send any notification to the upper layer about the active to PF state transition." "SCTP MUST NOT send any notification to the upper layer about the Active to PF state transition." There are some other places talking about "active state". In contrast, "Inactive state" is always capitalized. - There are two places where "primary path" is called "primacy path". - Section 5.3: "however, it will require more detail analysis since it might impact on SCTP failover algorithm." "however, it will require more detailed analysis since it might impact on SCTP failover algorithm." Best regards, Jose -----Mensaje original----- De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de Michael Tuexen Enviado el: martes, 26 de junio de 2012 10:18 Para: gorry@erg.abdn.ac.uk CC: draft-nishida-tsvwg-sctp-failover@tools.ietf.org; tsvwg@ietf.org; tsvwg-chairs@ietf.org Asunto: Re: [tsvwg] Comments requested on adoption of draft-nishida-tsvwg-sctp-failover-05 as a TSVWG draft On Jun 26, 2012, at 9:26 AM, Gorry Fairhurst wrote: > All, > > The TSVWG is considering adopting the following draft as a working group document for publication as PS: > > Quick Failover Algorithm in SCTP > draft-nishida-tsvwg-sctp-failover-05 > http://datatracker.ietf.org/doc/draft-nishida-tsvwg-sctp-failover/ > > This draft has been discussed at previous IETF meetings and is thought to not conflict with any current or planned IETF work. It also appears to fall within the charter of this WG. Please state your opinion, positive or negative, on the mailing list or to the chairs. This consensus call will end on June 26, 2012. I think this should be adopted as a WG item. I read it, provided comments and I'm willing to review upcoming versions. This current version has also been implemented in FreeBSD. Best regards Michael > > Regards, > > Gorry Fairhurst & James Polk > (TSVWG Co-Chairs) > > -------------------------------------------------------------------- > IETF TSVWG working group mailing list > > ------=_NextPart_000_001E_01CD544E.5B44F300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have read the draft and I find it very interesting for = improving SCTP when dealing with network failures. I agree with adopting = it as a WG item.

 

Some small things which could be = corrected:

 

- First paragraph of Section 4.2:

"During failover = process.  RTO keeps being doubled."

"During failover = process,  RTO keeps being = doubled."

 

- First paragraph of page 8:

"SCTP MUST NOT send any = notification to the upper layer about the active to PF state = transition."

"SCTP MUST NOT send any notification to the upper = layer about the Active to PF state = transition."

There are some other places talking about "active = state". In contrast, "Inactive state" is always = capitalized.

 

- There are two places where "primary path" is = called "primacy path".

 

- Section = 5.3:

"however, it will require more detail analysis since = it might  impact on SCTP failover = algorithm."

"however, it will require more detailed = analysis since it might  impact on SCTP failover = algorithm."

 

Best regards,

 

Jose

 

-----Mensaje original-----
De: = tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de = Michael Tuexen
Enviado el: martes, 26 de junio de 2012 10:18
Para: = gorry@erg.abdn.ac.uk
CC: = draft-nishida-tsvwg-sctp-failover@tools.ietf.org; tsvwg@ietf.org; = tsvwg-chairs@ietf.org
Asunto: Re: [tsvwg] Comments requested on = adoption of draft-nishida-tsvwg-sctp-failover-05 as a TSVWG = draft

 

On Jun 26, 2012, at 9:26 AM, Gorry Fairhurst = wrote:

 

> All,

>

> = The TSVWG is considering adopting the following draft as a working group = document for publication as PS:

>

>  Quick Failover Algorithm in = SCTP

>  = draft-nishida-tsvwg-sctp-failover-05

http://datatracker.ietf.o= rg/doc/draft-nishida-tsvwg-sctp-failover/

>

> = This draft has been discussed at previous IETF meetings and is thought = to not conflict with any current or planned IETF work. It also appears = to fall within the charter of this WG. Please state your opinion, = positive or negative, on the mailing list or to the chairs. This = consensus call will end on June 26, 2012.

I think this should be adopted as a WG item. I read = it, provided comments and I'm willing to review upcoming = versions.

This current version has = also been implemented in FreeBSD.

 

Best = regards

Michael

>

> = Regards,

>

> Gorry Fairhurst & James = Polk

> (TSVWG = Co-Chairs)

>

> = --------------------------------------------------------------------=

> IETF TSVWG working group mailing = list

>

> 

------=_NextPart_000_001E_01CD544E.5B44F300-- From jsaldana@unizar.es Wed Jun 27 01:21:44 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DBD21F8678; Wed, 27 Jun 2012 01:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-6qd3W-VjZ1; Wed, 27 Jun 2012 01:21:42 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0B81D21F867C; Wed, 27 Jun 2012 01:21:39 -0700 (PDT) Received: from jsaldanapc (n33d97.cs.unibo.it [130.136.33.97]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q5R8LZ6o025449; Wed, 27 Jun 2012 10:21:35 +0200 From: "Jose Saldana" To: , References: <4FE96416.1010502@erg.abdn.ac.uk> <2A5317F9-2427-4BE8-82CA-C00FAAF4D71A@lurchi.franken.de> In-Reply-To: <2A5317F9-2427-4BE8-82CA-C00FAAF4D71A@lurchi.franken.de> Date: Wed, 27 Jun 2012 10:21:35 +0200 Message-ID: <000301cd543d$de0b8e90$9a22abb0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CD544E.A1957000" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVfl9FtTLwjs6W7VA+PXNn42KHCwF1ZLhclnHPR0A= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tsvwg] Comments requested on adoption of draft-nishida-tsvwg-sctp-failover-05 as a TSVWG draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 08:21:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0004_01CD544E.A1957000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have read the draft and I find it very interesting for improving SCTP when dealing with network failures. I agree with adopting it as a WG item. Some small things which could be corrected: - First paragraph of Section 4.2: "During failover process. RTO keeps being doubled." "During failover process, RTO keeps being doubled." - First paragraph of page 8: "SCTP MUST NOT send any notification to the upper layer about the active to PF state transition." "SCTP MUST NOT send any notification to the upper layer about the Active to PF state transition." There are some other places talking about "active state". In contrast, "Inactive state" is always capitalized. - There are two places where "primary path" is called "primacy path". - Section 5.3: "however, it will require more detail analysis since it might impact on SCTP failover algorithm." "however, it will require more detailed analysis since it might impact on SCTP failover algorithm." Best regards, Jose -----Mensaje original----- De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de Michael Tuexen Enviado el: martes, 26 de junio de 2012 10:18 Para: gorry@erg.abdn.ac.uk CC: draft-nishida-tsvwg-sctp-failover@tools.ietf.org; tsvwg@ietf.org; tsvwg-chairs@ietf.org Asunto: Re: [tsvwg] Comments requested on adoption of draft-nishida-tsvwg-sctp-failover-05 as a TSVWG draft On Jun 26, 2012, at 9:26 AM, Gorry Fairhurst wrote: > All, > > The TSVWG is considering adopting the following draft as a working group document for publication as PS: > > Quick Failover Algorithm in SCTP > draft-nishida-tsvwg-sctp-failover-05 > http://datatracker.ietf.org/doc/draft-nishida-tsvwg-sctp-failover/ > > This draft has been discussed at previous IETF meetings and is thought to not conflict with any current or planned IETF work. It also appears to fall within the charter of this WG. Please state your opinion, positive or negative, on the mailing list or to the chairs. This consensus call will end on June 26, 2012. I think this should be adopted as a WG item. I read it, provided comments and I'm willing to review upcoming versions. This current version has also been implemented in FreeBSD. Best regards Michael > > Regards, > > Gorry Fairhurst & James Polk > (TSVWG Co-Chairs) > > -------------------------------------------------------------------- > IETF TSVWG working group mailing list > > ------=_NextPart_000_0004_01CD544E.A1957000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have read the draft and I find it very interesting for = improving SCTP when dealing with network failures. I agree with adopting = it as a WG item.

 

Some small things which could be = corrected:

 

- First paragraph of Section 4.2:

"During failover = process.  RTO keeps being doubled."

"During failover = process,  RTO keeps being = doubled."

 

- First paragraph of page 8:

"SCTP MUST NOT send any = notification to the upper layer about the active to PF state = transition."

"SCTP MUST NOT send any notification to the upper = layer about the Active to PF state = transition."

There are some other places talking about "active = state". In contrast, "Inactive state" is always = capitalized.

 

- There are two places where "primary path" is = called "primacy path".

 

- Section = 5.3:

"however, it will require more detail analysis since = it might  impact on SCTP failover = algorithm."

"however, it will require more detailed = analysis since it might  impact on SCTP failover = algorithm."

 

Best regards,

 

Jose

 

-----Mensaje original-----
De: = tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de = Michael Tuexen
Enviado el: martes, 26 de junio de 2012 10:18
Para: = gorry@erg.abdn.ac.uk
CC: = draft-nishida-tsvwg-sctp-failover@tools.ietf.org; tsvwg@ietf.org; = tsvwg-chairs@ietf.org
Asunto: Re: [tsvwg] Comments requested on = adoption of draft-nishida-tsvwg-sctp-failover-05 as a TSVWG = draft

 

On Jun = 26, 2012, at 9:26 AM, Gorry Fairhurst wrote:

 

> = All,

>

> The TSVWG is considering adopting the = following draft as a working group document for publication as = PS:

>

>  Quick Failover Algorithm in = SCTP

>  = draft-nishida-tsvwg-sctp-failover-05

http://datatracker.ietf.o= rg/doc/draft-nishida-tsvwg-sctp-failover/

>

> = This draft has been discussed at previous IETF meetings and is thought = to not conflict with any current or planned IETF work. It also appears = to fall within the charter of this WG. Please state your opinion, = positive or negative, on the mailing list or to the chairs. This = consensus call will end on June 26, 2012.

I think this should be adopted as a WG item. I read = it, provided comments and I'm willing to review upcoming = versions.

This current version has = also been implemented in FreeBSD.

 

Best = regards

Michael

>

> = Regards,

>

> Gorry Fairhurst & James = Polk

> (TSVWG = Co-Chairs)

>

> = --------------------------------------------------------------------=

> IETF TSVWG working group mailing = list

>

> 

------=_NextPart_000_0004_01CD544E.A1957000-- From fpb@tid.es Wed Jun 27 04:59:01 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B782C21F85F0 for ; Wed, 27 Jun 2012 04:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19sThcZfvpsC for ; Wed, 27 Jun 2012 04:59:01 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id DAF6321F8570 for ; Wed, 27 Jun 2012 04:58:59 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M6900M6FYM5MV@tid.hi.inet> for tsvwg@ietf.org; Wed, 27 Jun 2012 13:58:58 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id E4.24.26499.285FAEF4; Wed, 27 Jun 2012 13:58:58 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M6900L6WYM9ZO@tid.hi.inet> for tsvwg@ietf.org; Wed, 27 Jun 2012 13:58:58 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Wed, 27 Jun 2012 13:58:58 +0200 Date: Wed, 27 Jun 2012 11:58:56 +0000 From: FERNANDO PASCUAL BLANCO X-Originating-IP: [10.95.64.115] To: "tsvwg@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_b6wniXaX0Mp5FhtpPPIFzw)" Content-language: en-US Accept-Language: en-US Thread-topic: draft-saldana-tsvwg-tcmtf and MPLS: asking for feedback Thread-index: Ac1UXA1gHZAncIqnT8iOh3E1+WJCJg== X-AuditID: 0a5f4068-b7f206d000006783-95-4feaf5820158 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKKsWRmVeSWpSXmKPExsXCFe/Apdv09ZW/waJWLotjb+6yOTB6LFny kymAMYrLJiU1J7MstUjfLoErY/eNScwFZ4MqLv9oZmxgvOvZxcjJISFgInH7/h1WCFtM4sK9 9WxdjFwcQgIbGSX23W9ihXB+MkpcerKIBaRKSGApo8SL7X4gNouAqsT7rd/A4mwCWhKn764C s4UFHCTmzFrPAjFVQeLPucdgtghQ/eWOtUwgNq+At8S5H/8YIWxBiR+T74HVMAukS2xr28gE YYtLNLfeBIszAl33/dQaoDgH0BxXiW9TVSFG6kksnNzNDLFKROLhxdNsELaoxMvH/1gnMArP QrJhFpINs5BsgLDzJc5fe8IIYetJ3Jg6hQ3C1pZYtvA1M4StKzHj3yEWTHE7iVsbF7JD2AYS h3/+BKrhArJ3MEqcuLUQapCixJTuh+wLGHlWMYoVJxVlpmeU5CZm5qQbGOplZOpl5qWWbGKE xGnGDsblO1UOMQpwMCrx8K768dJfiDWxrLgy9xCjJAeTkihvzOdX/kJ8SfkplRmJxRnxRaU5 qcWHGCU4mJVEeK2fA+V4UxIrq1KL8mFSMhwcShK8sV+AUoJFqempFWmZOcBkBJNm4uAEaecB ajcCqeEtLkjMLc5Mh8ifYpSUEud1B0kIgCQySvPgel8xigMdKcxrCpLlAaZNuK5XQAOZgAZy bHoBMrAkESEl1cBodOG27lOJFXX/K3/2BrPtK/a/LJZb+2LtasX1TwVTX/48slgwO0P5nweT V/OVLeLuXhz5zz+pv7zcaCi1/eCzsCPbL3S17GH3ZvA//vj31eMT8yfsvH1c98qCpQJ2Jmc/ 6WwrWRNqpfw8O+PH4ztswXpRiY/tTNjTvSfrXpjANivgTqGtzv1GJZbijERDLeai4kQAeYwA 5VgDAAA= Subject: [tsvwg] draft-saldana-tsvwg-tcmtf and MPLS: asking for feedback X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 11:59:01 -0000 --Boundary_(ID_b6wniXaX0Mp5FhtpPPIFzw) Content-type: multipart/alternative; boundary="Boundary_(ID_aAgtqnMsF8gOuEE2pQ4Iog)" --Boundary_(ID_aAgtqnMsF8gOuEE2pQ4Iog) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hello all, I=B4m interested in TCMTF because I think it could improve = network efficiency, and mainly in network operators. I would like to propos= e a different tunneling method: MPLS. Many network operators use MPLS in their networks, that bas= ically are network clouds composed by edge routers (LERs) and switch router= s (LSRs). When an unlabeled packet enters the ingress router, the router fi= rst determines the MPLS tunnel the packet should be in and then inserts one= or more labels in the MPLS header (between level 2 and level 3). LSRs only= have to evaluate the MPLS label to determine the next hop within the MPLS = cloud. That means that several flows can share an MPLS tunnel identified by= a label. My understanding is that MPLS could be considered as a tunn= eling method in some TCMTF scenarios (MPLS tunnels should be used by packet= s with similar delay requirements). Note that the protocol stack could be: =B7 ROHC (compression) =B7 PPP-Mux (multiplexing) =B7 MPLS (tunnel) =B7 Ethernet IP and L2TP (or GRE) headers (to maintain the tunnel) could be suppressed a= nd payload versus header efficiency could be increased. What do you think about it? Regards, Fernando ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_aAgtqnMsF8gOuEE2pQ4Iog) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hello all,

 

     &= nbsp;          I=B4m intereste= d in TCMTF because I think it could improve network efficiency, and mainly = in network operators. I would like to propose a different tunneling method:= MPLS.

 

     &= nbsp;          Many network op= erators use MPLS in their networks, that basically are network clouds compo= sed by edge routers (LERs) and switch routers (LSRs). When an unlabeled pac= ket enters the ingress router, the router first determines the MPLS tunnel the packet should be in and then inserts = one or more labels in the MPLS header (between level 2 and level 3). LSRs o= nly have to evaluate the MPLS label to determine the next hop within the MP= LS cloud. That means that several flows can share an MPLS tunnel identified by a label.

     &= nbsp;         

     &= nbsp;          My understandin= g is that MPLS could be considered as a tunneling method in some TCMTF scen= arios (MPLS tunnels should be used by packets with similar delay requiremen= ts). Note that the protocol stack could be:

 

=B7      &nbs= p;  ROHC (compression)

=B7      &nbs= p;  PPP-Mux (multiplexing)

=B7      &nbs= p;  MPLS (tunnel)

=B7      &nbs= p;  Ethernet

 

IP= and L2TP (or GRE) headers (to maintain the tunnel) could be suppressed and= payload versus header efficiency could be increased.

 

What do you think about it?

 

Regards,

 

Fernando

 




Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
--Boundary_(ID_aAgtqnMsF8gOuEE2pQ4Iog)-- --Boundary_(ID_b6wniXaX0Mp5FhtpPPIFzw) Content-type: text/x-vcard; name="Fernando Pascual Blanco.vcf" Content-transfer-encoding: base64 Content-disposition: attachment; filename="Fernando Pascual Blanco.vcf"; size=1782; creation-date="Wed, 27 Jun 2012 11:58:56 GMT"; modification-date="Wed, 27 Jun 2012 11:58:56 GMT" Content-description: Fernando Pascual Blanco.vcf QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpYLU1TLVNJR05BVFVSRTpZRVMNCk47TEFOR1VBR0U9 ZXM6UGFzY3VhbCBCbGFuY287RmVybmFuZG8NCkZOOkZlcm5hbmRvIFBhc2N1YWwgQmxhbmNvDQpP Ukc7Q0hBUlNFVD1XaW5kb3dzLTEyNTI6VGVsZWbzbmljYSBJK0QNClRJVExFOk5ldHdvcmsgQXV0 b21hdGlvbiBhbmQgRHluYW1pemF0aW9uDQpURUw7V09SSztWT0lDRTozNCA5MTMxMjg3NzkNClRF TDtDRUxMO1ZPSUNFOjM0IDY4MjAwNTE2OA0KQURSO1dPUks7UFJFRjtDSEFSU0VUPVdpbmRvd3Mt MTI1Mjo7O0RvbiBSYW3zbiBkZSBsYSBDcnV6IDgyLTg0O01hZHJpZDtNYWRyaWQ7MjgwMDY7U3Bh aW4NCkxBQkVMO1dPUks7UFJFRjtDSEFSU0VUPVdpbmRvd3MtMTI1MjtFTkNPRElORz1RVU9URUQt UFJJTlRBQkxFOkRvbiBSYW09RjNuIGRlIGxhIENydXogODItODQ9MEQ9MEE9DQoyODAwNiAgTWFk cmlkICBNYWRyaWQ9MEQ9MEE9DQpTcGFpbg0KWC1NUy1PTC1ERUZBVUxULVBPU1RBTC1BRERSRVNT OjINCkVNQUlMO1BSRUY7SU5URVJORVQ6ZnBiQHRpZC5lcw0KWC1NUy1PTC1ERVNJR047Q0hBUlNF VD11dGYtODo8Y2FyZCB4bWxucz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2Uv b3V0bG9vay8xMi9lbGVjdHJvbmljYnVzaW5lc3NjYXJkcyIgdmVyPSIxLjAiIGxheW91dD0ibGVm dCIgYmdjb2xvcj0iZmZmZmZmIj48aW1nIHhtbG5zPSIiIGFsaWduPSJmaXQiIGFyZWE9IjE2IiB1 c2U9ImNhcmRwaWN0dXJlIi8+PGZsZCB4bWxucz0iIiBwcm9wPSJuYW1lIiBhbGlnbj0ibGVmdCIg ZGlyPSJsdHIiIHN0eWxlPSJiIiBjb2xvcj0iMDAwMDAwIiBzaXplPSIxMCIvPjxmbGQgeG1sbnM9 IiIgcHJvcD0ib3JnIiBhbGlnbj0ibGVmdCIgZGlyPSJsdHIiIGNvbG9yPSIwMDAwMDAiIHNpemU9 IjgiLz48ZmxkIHhtbG5zPSIiIHByb3A9InRpdGxlIiBhbGlnbj0ibGVmdCIgZGlyPSJsdHIiIGNv bG9yPSIwMDAwMDAiIHNpemU9IjgiLz48ZmxkIHhtbG5zPSIiIHByb3A9ImJsYW5rIiBzaXplPSI4 Ii8+PGZsZCB4bWxucz0iIiBwcm9wPSJ0ZWx3b3JrIiBhbGlnbj0ibGVmdCIgZGlyPSJsdHIiIGNv bG9yPSIwMDAwMDAiIHNpemU9IjgiPjxsYWJlbCBhbGlnbj0icmlnaHQiIGNvbG9yPSI2MjYyNjIi Pldvcms8L2xhYmVsPjwvZmxkPjxmbGQgeG1sbnM9IiIgcHJvcD0idGVsY2VsbCIgYWxpZ249Imxl ZnQiIGRpcj0ibHRyIiBjb2xvcj0iMDAwMDAwIiBzaXplPSI4Ij48bGFiZWwgYWxpZ249InJpZ2h0 IiBjb2xvcj0iNjI2MjYyIj5Nb2JpbGU8L2xhYmVsPjwvZmxkPjxmbGQgeG1sbnM9IiIgcHJvcD0i ZW1haWwiIGFsaWduPSJsZWZ0IiBkaXI9Imx0ciIgY29sb3I9IjAwMDAwMCIgc2l6ZT0iOCIvPjxm bGQgeG1sbnM9IiIgcHJvcD0iYWRkcndvcmsiIGFsaWduPSJsZWZ0IiBkaXI9Imx0ciIgY29sb3I9 IjAwMDAwMCIgc2l6ZT0iOCIvPjxmbGQgeG1sbnM9IiIgcHJvcD0iYmxhbmsiIHNpemU9IjgiLz48 ZmxkIHhtbG5zPSIiIHByb3A9ImJsYW5rIiBzaXplPSI4Ii8+PGZsZCB4bWxucz0iIiBwcm9wPSJi bGFuayIgc2l6ZT0iOCIvPjxmbGQgeG1sbnM9IiIgcHJvcD0iYmxhbmsiIHNpemU9IjgiLz48Zmxk IHhtbG5zPSIiIHByb3A9ImJsYW5rIiBzaXplPSI4Ii8+PGZsZCB4bWxucz0iIiBwcm9wPSJibGFu ayIgc2l6ZT0iOCIvPjxmbGQgeG1sbnM9IiIgcHJvcD0iYmxhbmsiIHNpemU9IjgiLz48ZmxkIHht bG5zPSIiIHByb3A9ImJsYW5rIiBzaXplPSI4Ii8+PC9jYXJkPg0KUkVWOjIwMTIwNTA5VDA3NTI1 NFoNCkVORDpWQ0FSRA0K --Boundary_(ID_b6wniXaX0Mp5FhtpPPIFzw)-- From sailabala.lenka@exfo.com Wed Jun 27 05:54:48 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC0D21F86CB for ; Wed, 27 Jun 2012 05:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9LA9uMI4ue5 for ; Wed, 27 Jun 2012 05:54:48 -0700 (PDT) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAE021F867E for ; Wed, 27 Jun 2012 05:54:41 -0700 (PDT) Received: from smtpinfi.exfo.com ([10.3.200.10]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 08:54:40 -0400 Received: from SPFIEXC02.exfo.com ([10.4.4.59]) by smtpinfi.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 15:54:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: A+sU BJxj BPE2 BnaS ByN6 Bzi+ CwjI DTeQ EyJC E8ot Gq/7 H/Im IG+f KFOQ K28z K+2o; 1; dABzAHYAdwBnAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {73046207-6D76-483C-B742-69B646E4615B}; cwBhAGkAbABhAGIAYQBsAGEALgBsAGUAbgBrAGEAQABlAHgAZgBvAC4AYwBvAG0A; Wed, 27 Jun 2012 12:54:03 GMT; SABvAHcAIAB0AG8AIABzAHQAbwBwACAASABlAGEAcgB0AGIAZQBhAHQAIABSAGUAdAByAGkAZQBzACAAZgBvAHIAIABMAG8AbgBnACAAVABpAG0AZQA= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD5463.EA03084D" x-cr-puzzleid: {73046207-6D76-483C-B742-69B646E4615B} Content-class: urn:content-classes:message Date: Wed, 27 Jun 2012 15:54:03 +0300 Message-ID: <2A8BDDA94AD2144DAACF159874B765E80193177A@SPFIEXC02.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How to stop Heartbeat Retries for Long Time Thread-Index: Ac1UY+3fBvGbNsF5TnKr05n8egOpZQ== From: "Sailabala Lenka" To: X-OriginalArrivalTime: 27 Jun 2012 12:54:39.0304 (UTC) FILETIME=[0355F480:01CD5464] Subject: [tsvwg] How to stop Heartbeat Retries for Long Time X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 12:54:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD5463.EA03084D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 How can we reduce path failure notification time when heartbeat sent to an idle address is not acknowledged. Heartbeat is being sent upto 40mins without any acknowledgement then path failure notice is being sent . We are using kernel version: 2.6.9-55.ELsmp Please suggest on this. =20 Sailabala ------_=_NextPart_001_01CD5463.EA03084D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

How can we reduce path failure notification time when = heartbeat sent to an idle address is not acknowledged.

Heartbeat is being sent upto 40mins without any = acknowledgement then path failure notice is being sent .

We are using kernel version: = 2.6.9-55.ELsmp

Please suggest on this.

 

Sailabala

------_=_NextPart_001_01CD5463.EA03084D-- From randall@lakerest.net Wed Jun 27 13:56:52 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5111E8086; Wed, 27 Jun 2012 13:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvGOD9UKqytH; Wed, 27 Jun 2012 13:56:52 -0700 (PDT) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id CF25D11E808C; Wed, 27 Jun 2012 13:56:50 -0700 (PDT) Received: from [10.1.1.141] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id q5RKsC0f006276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Jun 2012 16:54:13 -0400 (EDT) (envelope-from randall@lakerest.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Randy Stewart In-Reply-To: <2A5317F9-2427-4BE8-82CA-C00FAAF4D71A@lurchi.franken.de> Date: Wed, 27 Jun 2012 14:07:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FE96416.1010502@erg.abdn.ac.uk> <2A5317F9-2427-4BE8-82CA-C00FAAF4D71A@lurchi.franken.de> To: Michael Tuexen X-Mailer: Apple Mail (2.1278) Cc: gorry@erg.abdn.ac.uk, tsvwg-chairs@ietf.org, draft-nishida-tsvwg-sctp-failover@tools.ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] Comments requested on adoption of draft-nishida-tsvwg-sctp-failover-05 as a TSVWG draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:56:53 -0000 +1 and yes I will review/read and provide comments R On Jun 26, 2012, at 4:18 AM, Michael Tuexen wrote: > On Jun 26, 2012, at 9:26 AM, Gorry Fairhurst wrote: >=20 >> All, >>=20 >> The TSVWG is considering adopting the following draft as a working = group document for publication as PS: >>=20 >> Quick Failover Algorithm in SCTP >> draft-nishida-tsvwg-sctp-failover-05 >> http://datatracker.ietf.org/doc/draft-nishida-tsvwg-sctp-failover/ >>=20 >> This draft has been discussed at previous IETF meetings and is = thought to not conflict with any current or planned IETF work. It also = appears to fall within the charter of this WG. Please state your = opinion, positive or negative, on the mailing list or to the chairs. = This consensus call will end on June 26, 2012. > I think this should be adopted as a WG item. I read it, provided = comments and I'm > willing to review upcoming versions. > This current version has also been implemented in FreeBSD. >=20 > Best regards > Michael >>=20 >> Regards, >>=20 >> Gorry Fairhurst & James Polk >> (TSVWG Co-Chairs) >>=20 >> -------------------------------------------------------------------- >> IETF TSVWG working group mailing list >>=20 >>=20 >=20 >=20 ----- Randall Stewart randall@lakerest.net ----- Randall Stewart randall@lakerest.net From jsaldana@unizar.es Thu Jun 28 03:08:40 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C22321F8438 for ; Thu, 28 Jun 2012 03:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufv8h8r3UUz4 for ; Thu, 28 Jun 2012 03:08:39 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9251921F88D4 for ; Thu, 28 Jun 2012 02:04:28 -0700 (PDT) Received: from jsaldanapc (n33d97.cs.unibo.it [130.136.33.97]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q5S94LCX006774; Thu, 28 Jun 2012 11:04:23 +0200 From: "Jose Saldana" To: "'FERNANDO PASCUAL BLANCO'" , References: In-Reply-To: Date: Thu, 28 Jun 2012 11:04:21 +0200 Message-ID: <006e01cd550d$030bc050$092340f0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01CD551D.C695C8D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD18utVAPG/Kj5TgmUI2CdI0BV0Kpi+Mnxw Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tsvwg] draft-saldana-tsvwg-tcmtf and MPLS: asking for feedback X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:08:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006F_01CD551D.C695C8D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fernando, =20 Just a preliminary answer. I have commented your proposal with some = people, and I think it is very interesting. Many carriers and service providers = have MPLS networks, so it could be good if the draft also included it as an option for the tunneling part. Nevertheless, we have to study it more, = in order to think about all the issues that could arise if we include that option. =20 Thanks for the proposal, =20 Jose =20 De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de FERNANDO PASCUAL BLANCO Enviado el: mi=E9rcoles, 27 de junio de 2012 13:59 Para: tsvwg@ietf.org Asunto: [tsvwg] draft-saldana-tsvwg-tcmtf and MPLS: asking for feedback =20 Hello all, =20 I=B4m interested in TCMTF because I think it could = improve network efficiency, and mainly in network operators. I would like to = propose a different tunneling method: MPLS. =20 Many network operators use MPLS in their networks, that basically are network clouds composed by edge routers (LERs) and switch routers (LSRs). When an unlabeled packet enters the ingress router, the router first determines the MPLS tunnel the packet should be in and then inserts one or more labels in the MPLS header (between level 2 and level = 3). LSRs only have to evaluate the MPLS label to determine the next hop = within the MPLS cloud. That means that several flows can share an MPLS tunnel identified by a label. =20 My understanding is that MPLS could be considered as a tunneling method in some TCMTF scenarios (MPLS tunnels should be used by packets with similar delay requirements). Note that the protocol stack = could be: =20 =B7 ROHC (compression) =B7 PPP-Mux (multiplexing) =B7 MPLS (tunnel) =B7 Ethernet =20 IP and L2TP (or GRE) headers (to maintain the tunnel) could be = suppressed and payload versus header efficiency could be increased. =20 What do you think about it? =20 Regards, =20 Fernando =20 =20 _____ =20 Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en = el enlace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx ------=_NextPart_000_006F_01CD551D.C695C8D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fernando,

 

Just a = preliminary answer. I have commented your proposal with some people, and = I think it is very interesting. Many carriers and service providers have = MPLS networks, so it could be good if the draft also included it as an = option for the tunneling part. Nevertheless, we have to study it more, = in order to think about all the issues that could arise if we include = that option.

 

Thanks for = the proposal,

 

Jose

 

De: = tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf= .org] En nombre de FERNANDO PASCUAL BLANCO
Enviado el: = mi=E9rcoles, 27 de junio de 2012 13:59
Para: = tsvwg@ietf.org
Asunto: [tsvwg] draft-saldana-tsvwg-tcmtf and = MPLS: asking for feedback

 

Hello all,

 

          =       I=B4m interested in TCMTF because I think = it could improve network efficiency, and mainly in network operators. I = would like to propose a different tunneling method: = MPLS.

 

          =       Many network operators use MPLS in their = networks, that basically are network clouds composed by edge routers = (LERs) and switch routers (LSRs). When an unlabeled packet enters the = ingress router, the router first determines the MPLS tunnel the packet = should be in and then inserts one or more labels in the MPLS header = (between level 2 and level 3). LSRs only have to evaluate the MPLS label = to determine the next hop within the MPLS cloud. That means that several = flows can share an MPLS tunnel identified by a = label.

          =      

          =       My understanding is that MPLS could be = considered as a tunneling method in some TCMTF scenarios (MPLS tunnels = should be used by packets with similar delay requirements). Note that = the protocol stack could be:

 

=B7         = ROHC (compression)

=B7         = PPP-Mux (multiplexing)

=B7         = MPLS (tunnel)

=B7         = Ethernet

 

IP and = L2TP (or GRE) headers (to maintain the tunnel) could be suppressed and = payload versus header efficiency could be = increased.

 

What do you think about it?

 

Regards,

 

Fernando

 

 


Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico en el enlace situado m=E1s abajo.
This message is = intended exclusively for its addressee. We only send and receive email = on the basis of the terms set out at.
http://www.tid.es/E= S/PAGINAS/disclaimer.aspx

------=_NextPart_000_006F_01CD551D.C695C8D0-- From jacl@tid.es Thu Jun 28 03:10:36 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676AE21F85FF for ; Thu, 28 Jun 2012 03:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqmRqwS0RPBV for ; Thu, 28 Jun 2012 03:10:35 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1586321F884F for ; Thu, 28 Jun 2012 01:54:34 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M6B00CD7KQXTF@tid.hi.inet> for tsvwg@ietf.org; Thu, 28 Jun 2012 10:54:33 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 2A.D6.02752.8CB1CEF4; Thu, 28 Jun 2012 10:54:33 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M6B00CD3KQWTF@tid.hi.inet> for tsvwg@ietf.org; Thu, 28 Jun 2012 10:54:32 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Thu, 28 Jun 2012 10:54:32 +0200 Date: Thu, 28 Jun 2012 10:54:30 +0200 From: JUAN ANTONIO CASTELL LUCIA In-reply-to: <001c01cd543a$3f091a90$bd1b4fb0$@unizar.es> To: Jose Saldana , "tsvwg@ietf.org" Message-id: <7AB622D0785205478D7D819B3C13533581B6703745@EXCLU2K7.hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: es-ES Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: [tsvwg] Extension proposal for draft-saldana-tsvwg-tcmtf-02: asking for feedback Thread-index: AQIZWKol1SiGyT52I9oehEwlyGAJ+5Z1ugSwgAGiIRA= acceptlanguage: es-ES, en-US X-AuditID: 0a5f4e69-b7f6d6d000000ac0-5b-4fec1bc85ce6 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsXCFe9nqHtS+o2/wZYZbBbH3txlc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvzrogU7HCq+dF9hbmB8YtfFyMkhIWAi0bxwIhOELSZx4d56 ti5GLg4hge2MEkce7GCGcH4ySuy68J0dwmlklJj6cAo7SAuLgKrElqkfWUBsNgE9iUOr/jOC 2MIC8RI3710DGsXBwSlgIXHiozRIWETAQ+Lly4tg5bwCnhKv1nxgh7AFJX5MvscCUs4soC4x ZUouSJhZQFxizq+JrBC2osS0RQ1g0xkFZCVWnj/NCDEyQaKhtRPKtpKY0bmAGaJGRuL/8r0s EI8JSCzZc54ZwhaVePn4H9hMIYFyiddnV7FMYBSbheSKWQhXzEJyxSwkVyxgZFnFKFacVJSZ nlGSm5iZk25gpJeRqZeZl1qyiRESKZk7GJfvVDnEKMDBqMTDq+z12l+INbGsuDL3EKMkB5OS KK+7+Bt/Ib6k/JTKjMTijPii0pzU4kOMEhzMSiK83+OAynlTEiurUovyYVIyHBxKEryzpIDa BItS01Mr0jJzgOkAJs3EwQnSzgPUvgKkhre4IDG3ODMdIn+KUZVj8boTNxiFWPLy81KlxHn3 gRQJgBRllObBzXnFKA50sDDvK5AsDzChwU14BTScCWi4UwDIbcUliQgpqQbGpInpju5tcy9m rZl8snZ1Q7XA5ks7HNO03jDlubzd/dXj8+1zP49Lzef+JFlvs4NXJeIV43zxs7Xbj5+Z0MNz cmX/8wYh2xXqqxIS1/jxhLUd4ppzuqXb3Pv/Bc8LOjmuXstFV0reZ2z4oRV05snCj21/1VNe HOdoETklIyDHXNX7fG8R/4dqJZbijERDLeai4kQAQv8GtiUDAAA= References: <7AB622D0785205478D7D819B3C13533581B6703590@EXCLU2K7.hi.inet> <001c01cd543a$3f091a90$bd1b4fb0$@unizar.es> Subject: Re: [tsvwg] Extension proposal for draft-saldana-tsvwg-tcmtf-02: asking for feedback X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:10:36 -0000 Sm9zZSwgZmlyc3Qgb2YgYWxsLCB0aGFua3MgZm9yIGdpdmluZyBtZSB5b3VyIG9waW5pb24uDQoN ClJlZ2FyZGluZyB5b3VyIGZpcnN0IHF1ZXN0aW9uLCBpZiB0aGVyZSBhcmUgY29tbW9uIHBhdGhz IGZvciBtYW55IEROUyBmbG93cyB3aGVyZSBpdCBjb3VsZCBiZSBwb3NzaWJsZSB0byBhcHBseSBU Q01URiwgdGhlIGFuc3dlciBpcyB5ZXMuIEluIGNhc2Ugb2YgdGhlIHF1ZXN0aW9uIGFib3V0IGlm IHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgZmxvdywgdGhlIGFuc3dlciBpcyB5ZXMgYWdhaW4uIFRo ZSBmYWN0IHRoYXQgdGhlIEROUyByZXF1ZXN0cyBjYW4gaGF2ZSB0aGUgc2FtZSBvcmlnaW4gSVAg ZG9lc24ndCBtZWFuIHRoYXQgdGhlIHJlcXVlc3RzIGNvcnJlc3BvbmQgdG8gdGhlIHNhbWUgcmVx dWVzdG9yLg0KQW55d2F5LCB0aGlzIGlzIG9ubHkgb25lIG9mIGEgaGFuZGZ1bCBvZiB1c2UgY2Fz ZXMgd2hlcmUgaXQgaXMgcG9zc2libGUgdG8gYXBwbHkgdGhlIFRDTVRGLiBUaGVyZWZvcmUsIEkg c3VnZ2VzdCB5b3UgdG8gY2hvb3NlIHdoaWNoIHlvdSBjb25zaWRlciBtb3JlIHN1aXRhYmxlLg0K DQpSZWdhcmRpbmcgd2hhdHNhcHAgdXNlIGNhc2UgKGJ1dCBub3Qgb25seSB3aGF0c2FwcCwgYWxz byB0d2l0dGVyLCBNU04sIHNreXBlLCAuLi4pLCB0aGVyZSBhcmUgcGxhY2VzIGluIHRoZSBuZXR3 b3JrIHRvICJjb2xsZWN0IiBmbG93cyBmcm9tIGRpZmZlcmVudCB1c2VycyBpbiBvcmRlciB0byBt YXkgYXBwbHkgbXVsdGlwbGV4aW5nLCBsaWtlIHRoZSBJUCBlZGdlIG9yIHRoZSBEUEkuDQpPbmx5 IGZvciB0aGlzIHNlY29uZCB1c2UgY2FzZSwgSSB0aGluayBpdCdzIHdvcnRoIHRvIHVzZSBUQ01U RiBmb3Igbm9uIHJlYWwtdGltZSBmbG93cywgYnV0LCBtb3JlIHVzZSBjYXNlcyBhcmUgb3V0IHRo ZXJlIQ0KDQpLaW5kIFJlZ2FyZHMsDQpKdWFuIEFudG9uaW8NCg0KLS0tLS1NZW5zYWplIG9yaWdp bmFsLS0tLS0NCkRlOiBKb3NlIFNhbGRhbmEgW21haWx0bzpqc2FsZGFuYUB1bml6YXIuZXNdDQpF bnZpYWRvIGVsOiBtacOpcmNvbGVzLCAyNyBkZSBqdW5pbyBkZSAyMDEyIDk6NTYNClBhcmE6IEpV QU4gQU5UT05JTyBDQVNURUxMIExVQ0lBOyB0c3Z3Z0BpZXRmLm9yZw0KQXN1bnRvOiBSRTogW3Rz dndnXSBFeHRlbnNpb24gcHJvcG9zYWwgZm9yIGRyYWZ0LXNhbGRhbmEtdHN2d2ctdGNtdGYtMDI6 IGFza2luZyBmb3IgZmVlZGJhY2sNCg0KSnVhbiBBbnRvbmlvLA0KDQpJIHRoaW5rIHlvdXIgcHJv cG9zYWwgaXMgaW50ZXJlc3RpbmcuIEJ5IG5vdywgd2UgYXJlIG1vc3RseSBmb2N1c2VkIGluIHJl YWwtdGltZSBmbG93cywgc2luY2UgeW91IGNhbiBmaW5kIGZsb3dzIG9mIGUuZy4gNTAgcHBzLCB3 aXRoIGEgY29tbW9uIG9yaWdpbiBhbmQgZGVzdGluYXRpb24uIEluIHRoYXQgY2FzZXMsIHRoZSBo ZWFkZXIgY29tcHJlc3Npb24gcmF0ZSBpcyBiaWcsIHNpbmNlIGFsbCB0aGUgcGFja2V0cyBoYXZl LCBhdCBsZWFzdCwgdGhlIHNhbWUgSVAtcG9ydCBvcmlnaW4gYW5kIGRlc3RpbmF0aW9ucy4gU28g eW91IGNhbiBzYXZlIGEgbG90IG9mIGJ5dGVzIGluIGVhY2ggcGFja2V0Lg0KDQpXZSBzaG91bGQg bm90IGZvcmdldCB0aGF0IHRoZSBwcm9wb3NhbCBpcyBmb3IgdHVubmVsaW5nLCBjb21wcmVzc2lu ZyBhbmQgbXVsdGlwbGV4aW5nLiBTbyBmb3IgdGhlIEROUyBjYXNlLCB3ZSBzaG91bGQgdGhpbmsg YSBiaXQgbW9yZS4gU29tZSB0aG91Z2h0czoNCg0KLSBBcmUgdGhlcmUgc2NlbmFyaW9zIHdoZXJl IG1hbnkgRE5TIGZsb3dzIHNoYXJlIGEgcGF0aD86IEluIHRoZSBjYXNlIG9mICAiIHRoZSBjb21t dW5pY2F0aW9uIGJldHdlZW4gdGhlIGNhY2hlIEROUyBhbmQgdGhlIGF1dGhvcml0YXRpdmUgRE5T IFRMRCBzZXJ2ZXJzIiwgcGVyaGFwcyB5b3UgY2FuIHNpbXBseSBlc3RhYmxpc2ggYSB0dW5uZWwg d2l0aCBoZWFkZXIgY29tcHJlc3Npb24uIEJ1dCBJIGRvbid0IHRoaW5rIG11bHRpcGxleGluZyBp cyBwcmVzZW50OiB3aGljaCBmbG93cyBkbyB5b3UgYWdncmVnYXRlPyBJc24ndCBpdCBvbmx5IG9u ZSBmbG93PyBTbyB3ZSBoYXZlIHR1bm5lbGluZyBhbmQgY29tcHJlc3NpbmcsIGJ1dCBub3QgbXVs dGlwbGV4aW5nLiAoSWYgc29tZWJvZHkgZmluZHMgYSBzY2VuYXJpbyB3aGVyZSBtdWx0aXBsZXhp bmcgaXMgYWxzbyBwb3NzaWJsZSwgaXQgd291bGQgYmUgZmluZSkuDQoNCi0gSW4gdGhlIGNhc2Ug b2YgV2hhdHNhcHAsIEkgdGhpbmsgVENNVEYgY2FuIGJlIGFwcGxpZWQsIGJ1dCBpZiB5b3UgcmVh bGx5IHdhbnQgdG8gc2F2ZSBiYW5kd2lkdGgsIHlvdSBuZWVkIHRvIGxvY2F0ZSB0aGUgbXVsdGlw bGV4ZXIgaW4gYSBwbGFjZSB3aGVyZSB5b3UgY2FuIGJ1bmRsZSBhIHJlYWxseSBoaWdoIG51bWJl ciBvZiBmbG93cy4gSW4gYWRkaXRpb24sIHRoZSBmbG93cyB3aWxsIG5vdCBoYXZlIHRoZSBzYW1l IElQIG9yaWdpbiAoeW91IGNhbm5vdCBtdWx0aXBsZXggdHdvIG1lc3NhZ2VzIGZyb20gdGhlIHNh bWUgdXNlciwgc2luY2UgeW91IHdvdWxkIGxvc2UgdGhlIGludGVyYWN0aXZpdHkpLiBQZXJoYXBz IGFsbCB0aGUgZmxvd3MgYmVoaW5kIGEgTkFUIHdvdWxkIGhhdmUgdGhlIHNhbWUgSVAgb3JpZ2lu IGFuZCBkZXN0aW5hdGlvbiBidXQsIGhvdyBtYW55IGZsb3dzIGNhbiB5b3UgZmluZCB0aGVyZT8g T24gdGhlIG90aGVyIGhhbmQsIHRoZSBhZHZhbnRhZ2UgaXMgdGhhdCB0aGUgbXVsdGlwbGV4aW5n IHBlcmlvZCBjYW4gYmUgYmlnZ2VyIGluIG9yZGVyIHRvIGdldCBtb3JlIHNhdmluZ3MuIEkgdGhp bmsgYSBXaGF0c2FwcCB1c2VyIHdvdWxkIG5vdCBub3RpY2UgYSBkZWxheSBvZiAxIG9yIDIgc2Vj b25kcy4gKEluIGNvbnRyYXN0LCBmb3IgYSBGUFMgZ2FtZSwgYWRkaW5nIG1vcmUgdGhhbiA0MC01 MCBtcyBpcyByZWFsbHkgYmFkKS4gTG9naWNhbGx5LCB0aGVzZSBlZmZlY3RzIGFuZCB0aGUgc2F2 aW5ncyBzaG91bGQgYmUgc3R1ZGllZCwgYnV0IG5vdGhpbmcgcHJldmVudHMgdXMgdG8gaW5jbHVk ZSBub24gcmVhbC10aW1lIGZsb3dzIGFzIGEgdXNlIGNhc2UgaW4gdGhlIGRyYWZ0Lg0KDQpQZXJo YXBzIHdlIGNvdWxkIGRlcGxveSBzb21lIHByZWxpbWluYXJ5IGNhbGN1bGF0aW9ucy4gSXQgaXMg bm90IGRpZmZpY3VsdCB0byBmaW5kIHRoZSBhc3ltcHRvdGUgb2YgdGhlIGJhbmR3aWR0aCBzYXZp bmc6IGlzIGEgdmVyeSBzaW1wbGUgcXVvdGllbnQ6IHlvdSBvbmx5IG5lZWQgdG8gZXN0aW1hdGUg dGhlIGF2ZXJhZ2Ugc2l6ZSBvZiB0aGUgY29tcHJlc3NlZCBoZWFkZXIgeW91IHdvdWxkIG9idGFp bi4gKFlvdSBjYW4gZmluZCBhbiBleGFtcGxlIGluIHRoZSBlcXVhdGlvbiAoMikgb2YgdGhpcyBw YXBlcjogIGh0dHA6Ly9kaWVjLnVuaXphci5lcy9+anNhbGRhbmEvcGVyc29uYWwvY29tbWFnX25v dl8yMDExX2pzYWxkYW5hLnBkZikNCg0KQmVzdCByZWdhcmRzLA0KDQpKb3NlDQoNCi0tLS0tTWVu c2FqZSBvcmlnaW5hbC0tLS0tDQpEZTogdHN2d2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRz dndnLWJvdW5jZXNAaWV0Zi5vcmddIEVuIG5vbWJyZSBkZSBKVUFOIEFOVE9OSU8gQ0FTVEVMTCBM VUNJQQ0KRW52aWFkbyBlbDogbWFydGVzLCAyNiBkZSBqdW5pbyBkZSAyMDEyIDE1OjU2DQpQYXJh OiB0c3Z3Z0BpZXRmLm9yZw0KQXN1bnRvOiBbdHN2d2ddIEV4dGVuc2lvbiBwcm9wb3NhbCBmb3Ig ZHJhZnQtc2FsZGFuYS10c3Z3Zy10Y210Zi0wMjogYXNraW5nIGZvciBmZWVkYmFjaw0KDQpIaSBh bGwsIEkndmUgcmVhZCB0aGUgZHJhZnQsIGFuZCBmb3IgbWUgaXQgaGFzIHJlc3VsdGVkIHZlcnkg aW50ZXJlc3RpbmcuIEFzIGEgcHJvcG9zYWwgb2YgY292ZXJhZ2UgZXh0ZW5zaW9uIG9mIHRoZSBz dGFuZGFyZCwgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgeW91IHRvIGRvbid0IHB1dCBmb2N1cyBv bmx5IGluIHJlYWwtdGltZSBmbG93cy4NCkZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgYSBuZXR3 b3JrIG9wZXJhdG9yLCB0aGVyZSBhcmUgbG90cyBvZiBraW5kIG9mIHNtYWxsIHBhY2tldHMgdGhh dCBzdXBwb3NlIGEgYmlnIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhbmQgcGFja2V0cyB0cmF2ZWxs aW5nIHRocm91Z2ggdGhlIG5ldHdvcmsuIEFuIGV4YW1wbGUgY291bGQgYmUgRE5TIHBhY2tldHMu IEEgRE5TIHBhY2tldCBtYXkgaGF2ZSBhbiBhdmVyYWdlIHNpemUgdW5kZXIgMTAwIGJ5dGVzLCBp bmNsdWRlZCBoZWFkZXIgYnl0ZXMuIEFuZCB0aGUgYW1vdW50IG9mIEROUyBwYWNrZXRzIGluIGEg bWVkaXVtIG9yIGJpZyBvcGVyYXRvciBtYXkgYWNoaWV2ZSBhIHJhdGUgb2YgdGhvdXNhbmRzIG9m IHBhY2tldHMgcGVyIHNlY29uZC4gSXQgY291bGQgYWxzbyBiZSB1c2VkIGluIHRoZSBjb21tdW5p Y2F0aW9uIGJldHdlZW4gdGhlIGNhY2hlIEROUyBhbmQgdGhlIGF1dGhvcml0YXRpdmUgRE5TIFRM RCBzZXJ2ZXJzLCByZWR1Y2luZyB0aGUgYmFuZHdpZHRoIGFuZCBhZGRpbmcgYWxzbyBhIG5ldyBr aW5kIG9mIHNlY3VyZSBjb21tdW5pY2F0aW9ucyAodGhlIHR1bm5lbCBjb3VsZCBiZSBhIHNlY3Vy ZSBvbmUsIGFzIElQU2VjKS4gQWx0aG91Z2ggdGhlcmUgaXMgYWxyZWFkeSBhIHNlY3VyZSBETlMg U2VjIHByb3RvY29sIGRlZmluZWQgYnkgSUVURiwgdGhpcyBtdXN0IG5vdCBiZSBzZWVuIGFzIGlu Y29tcGF0aWJsZS4NCg0KQmVzaWRlcywgdGhlcmUgYXJlIG90aGVyIGtpbmRzIG9mIHRyYWZmaWMg b2Ygc2VydmljZXMsIGFzIGNvdWxkIGJlIGNoYXR0aW5nIGFwcGxpY2F0aW9ucyBsaWtlIHdoYXRz YXBwIGFuZCBzaW1pbGFyIG9uZXMsIHRoYXQgY2FuIHN1cHBvc2UgYSBsb3Qgb2YgYnl0ZXMgdGhh dCBjYW4gYmUgY29tcHJlc3NlZCwgbXVsdGlwbGV4ZWQsIGFuZCB0dW5uZWxsZWQgdG8gdGhlIHNl cnZlciBlbmRwb2ludC4NClNwZWNpYWxseSBpbiBydXNoIGhvdXJzLCBsaWtlIG5ldyB5ZWFyJ3Mg bmlnaHQsIENocmlzdG1hcyBkYXksIGV0Yy4uLnRoaXMgY291bGQgYmUgdmVyeSB1c2VmdWwsIG5v dCBvbmx5IGZvciB0aGUgb3BlcmF0b3IsIGJ1dCBhbHNvIGZvciB0aGUgYXBwbGljYXRpb24gb3du ZXIuDQoNCkluIHN1bW1hcnksIEkgd291bGQgbGlrZSB0byBwcm9wb3NlIHlvdSB0byBpbmNsdWRl IG90aGVyIHN1YmNoYXB0ZXIgMS5YIGZvciBzdWNoIGtpbmQgb2YgdHJhZmZpYywgbm90IGFzIHNl bnNpYmxlIHRvIGRlbGF5IGFzIHRoZSBvdGhlciBvbmVzIHlvdSBjb21tZW50IGluIHRoZSBkcmFm dCwgYnV0IHZlcnkgb3B0aW1pemFibGVzLg0KDQpXaGF0IGRvIHlvdSB0aGluayBhYm91dCBpdD8N Cg0KUmVnYXJkcywNCg0KSnVhbiBBbnRvbmlvDQoNCg0KDQoNCg0KRXN0ZSBtZW5zYWplIHNlIGRp cmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51 ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOz bmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGlu dGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJl Y2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0IGh0dHA6Ly93 d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQoNCg0KRXN0ZSBtZW5zYWplIHNl IGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFy IG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0 csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlz IGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5k IHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0DQpodHRw Oi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From Karen.Nielsen@tieto.com Thu Jun 28 03:50:06 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931D521F849B for ; Thu, 28 Jun 2012 03:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZiMbYqSSJ+r for ; Thu, 28 Jun 2012 03:50:06 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id DDD2E21F84A0 for ; Thu, 28 Jun 2012 03:49:59 -0700 (PDT) X-AuditID: 83cfa826-b7cabae00000347a-41-4fec36d6acaa Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 24.37.13434.6D63CEF4; Thu, 28 Jun 2012 13:49:58 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.81]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Thu, 28 Jun 2012 13:49:58 +0300 From: To: Date: Thu, 28 Jun 2012 13:49:57 +0300 Thread-Topic: IETF84 meeting agenda Thread-Index: Ac1VG8Jb+EgvMr92RG230DPqgRIcqg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B1449DE7A2CEXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [tsvwg] IETF84 meeting agenda X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:50:06 -0000 --_000_CF340E42AED0874C81947E18863DE77B1449DE7A2CEXMB03eutieto_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Does the wg have a planned slot for the next meeting ? Thanks ! BR, Karen --_000_CF340E42AED0874C81947E18863DE77B1449DE7A2CEXMB03eutieto_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

=

 

Does the wg have a plan= ned slot for the next meeting ?

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> = ;

Thanks !

 

BR, Karen

 

 

 

= --_000_CF340E42AED0874C81947E18863DE77B1449DE7A2CEXMB03eutieto_-- From Karen.Nielsen@tieto.com Thu Jun 28 04:32:35 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E6021F84FE; Thu, 28 Jun 2012 04:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqkv3C42uCO5; Thu, 28 Jun 2012 04:32:34 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id 006A121F84D6; Thu, 28 Jun 2012 04:32:30 -0700 (PDT) X-AuditID: 83cfa826-b7cabae00000347a-02-4fec40cdb893 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb06.tieto.com (SMTP Mailer) with SMTP id DE.6A.13434.DC04CEF4; Thu, 28 Jun 2012 14:32:30 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.81]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Thu, 28 Jun 2012 14:32:29 +0300 From: To: , Date: Thu, 28 Jun 2012 14:32:28 +0300 Thread-Topic: [tsvwg] Comments requested on adoption of draft-nishida-tsvwg-sctp-failover-05 as a TSVWG draft Thread-Index: Ac1TbQLjbE9vLpHaTeeQ4+53a1SKNABtGlWw Message-ID: References: <4FE96416.1010502@erg.abdn.ac.uk> In-Reply-To: <4FE96416.1010502@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: tsvwg-chairs@ietf.org, draft-nishida-tsvwg-sctp-failover@tools.ietf.org Subject: Re: [tsvwg] Comments requested on adoption of draft-nishida-tsvwg-sctp-failover-05 as a TSVWG draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 11:32:35 -0000 Hi, I believe that this work addresses a very important need for more efficient= failover process in SCTP. I fully support to adopt this work as a tsvwg item and would be willing to = support further work on the draft. BR, Karen -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of G= orry Fairhurst Sent: 26. juni 2012 09:26 To: tsvwg@ietf.org Cc: tsvwg-chairs@ietf.org; draft-nishida-tsvwg-sctp-failover@tools.ietf.org Subject: [tsvwg] Comments requested on adoption of draft-nishida-tsvwg-sctp= -failover-05 as a TSVWG draft All, The TSVWG is considering adopting the following draft as a working group=20 document for publication as PS: Quick Failover Algorithm in SCTP draft-nishida-tsvwg-sctp-failover-05 http://datatracker.ietf.org/doc/draft-nishida-tsvwg-sctp-failover/ This draft has been discussed at previous IETF meetings and is thought=20 to not conflict with any current or planned IETF work. It also appears=20 to fall within the charter of this WG. Please state your opinion,=20 positive or negative, on the mailing list or to the chairs. This=20 consensus call will end on June 26, 2012. Regards, Gorry Fairhurst & James Polk (TSVWG Co-Chairs) -------------------------------------------------------------------- IETF TSVWG working group mailing list From jmpolk@cisco.com Thu Jun 28 13:08:15 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E1421F84D5 for ; Thu, 28 Jun 2012 13:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHdq99aTvyZY for ; Thu, 28 Jun 2012 13:08:14 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9F15D21F84D2 for ; Thu, 28 Jun 2012 13:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=289; q=dns/txt; s=iport; t=1340914094; x=1342123694; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=GBmUmbZoqm5kOzQZ6cX7KSH4D0o8BViuL1wWwqL4Ig0=; b=eqa7PsMyvm5pR64baRtAUXrEFImuMhw1kkp7jJf1s7vAqF/NJvee7uK7 xue7hCms2rQZNPQ78w3gHax1PRm5kbBJSO9tGgAo19A9ZiTo5DFuG/1Tx az+N9/Mz2YvaBJyElfeuRmSqOfkK8oCIFSxvYfdpJ0iFFnvK+PTngjyYi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABS57E+rRDoG/2dsb2JhbABFtiuBB4IYAQEBBBIBJQJPBwQYHhAZPgYBEiKHaJhMoHKLN4YKA4hKmwWBZoJ9 X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="50418779" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 28 Jun 2012 20:08:14 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5SK8Dk9012250; Thu, 28 Jun 2012 20:08:14 GMT Message-Id: <201206282008.q5SK8Dk9012250@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jun 2012 15:08:14 -0500 To: , From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [tsvwg] IETF84 meeting agenda X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 20:08:15 -0000 Karen TSVWG will meet for 2 hours in Vancouver, but a day and time have not been assigned yet. James (TSVWG co-chair) At 05:49 AM 6/28/2012, Karen.Nielsen@tieto.com wrote: >Hi, > >Does the wg have a planned slot for the next meeting ? > >Thanks ! > >BR, Karen > > > From jmpolk@cisco.com Thu Jun 28 16:14:50 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E654611E808C for ; Thu, 28 Jun 2012 16:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c9uDpN-+6Rt for ; Thu, 28 Jun 2012 16:14:48 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A6BE811E8088 for ; Thu, 28 Jun 2012 16:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1234; q=dns/txt; s=iport; t=1340925288; x=1342134888; h=message-id:date:to:from:subject:cc:mime-version; bh=cewR9z1Av7n8w/mZ/cNZ82focZGYgFHBZMGRENWu5h4=; b=KwCH0AiUutnqw5XAV6GzZcReeXzP5tjGmECZli0qnTwOADrih+Xfcb8b g+aKtwr/0TOWrcRREjjiQcjMP9iNRtKaRuH6adZpccYZMqdVvg6gm6nHD ZbLr3P1kWpETlf+aMa/H0rRi0XsGfOAw1PXzSb/0YBG0KfmqzRqG1n4Dy 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG7k7E+rRDoG/2dsb2JhbABFtkSBB4IxAQobAj8XOil5h2iYNqBijiWDHAOISpsFgWaCfQ X-IronPort-AV: E=Sophos;i="4.77,494,1336348800"; d="scan'208";a="50513868" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 28 Jun 2012 23:14:48 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5SNEli7005196; Thu, 28 Jun 2012 23:14:48 GMT Message-Id: <201206282314.q5SNEli7005196@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jun 2012 18:14:48 -0500 To: tsvwg@ietf.org From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Gorry Fairhurst Subject: [tsvwg] TSVWG - Call for presentations in Vancouver X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 23:14:50 -0000 TSVWG Today the chair received this *draft* session time for TSVWG TSVWG (2 hours) Wednesday, Afternoon Session II 1510-1710 Room Name: Regency B THIS IS SUBJECT TO CHANGE, so do *not* make travel plans according to this timeslot on this day!!!! This note also is a TSVWG call for those wanting to present during our meeting (whenever it ends up being scheduled). Please respond to *me* with the following: - name of draft - URL to draft in repository - name of expected presenter - time presenter will want to present - this amount will be adjusted up or down based on the number of presentations to be given within the time we have scheduled. The general starting point is 10 minutes though. Presentation preference will be given to - WG items first; - then to non-WG items that have been discussed in the past on our list (i.e., from previous meetings); - then to new items destined for this WG that have had discussion on our list; Therefore, it behoves authors to initiate discussion on this list as well as to create interest within TSVWG for any ID they want presented during the meeting. James, Gorry and Rolf TSVWG chairs From gorry@erg.abdn.ac.uk Thu Jun 28 23:49:56 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FF011E8113 for ; Thu, 28 Jun 2012 23:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pPy+o9ws5D0 for ; Thu, 28 Jun 2012 23:49:55 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id DBE9D11E80CB for ; Thu, 28 Jun 2012 23:49:53 -0700 (PDT) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q5T6nmuS029669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 29 Jun 2012 07:49:49 +0100 (BST) Message-ID: <4FED500C.8060406@erg.abdn.ac.uk> Date: Fri, 29 Jun 2012 07:49:48 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org References: <4FEC1812.6090007@erg.abdn.ac.uk> In-Reply-To: <4FEC1812.6090007@erg.abdn.ac.uk> X-Forwarded-Message-Id: <4FEC1812.6090007@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: [tsvwg] TSVWG Status for June 2012 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 06:49:56 -0000 The list below shows the status of the working group documents as we see it. Please check below and comment on drafts using the list. Please do send any corrections/omissions to the chairs. Best wishes, James, Rolf and Gorry (TSVWG Chairs) --- Recently published: draft-ietf-tsvwg-rsvp-security-groupkeying was published as RFC 6411. draft-ietf-tsvwg-sctpsocket was published as RFC 6458. draft-ietf-tsvwg-sctp-strrst was published as RFC 6535. draft-ietf-tsvwg-source-quench was published as RFC 6633. ------------------------------------------------------------------- IDs in RFC Editor Queue: http://www.rfc-editor.org/queue.html None. ------------------------------------------------------------------- IDs in IESG processing: draft-ietf-tsvwg-byte-pkt-congest New editor added Jul 2010. New revision 25 Oct 2010. WG -01, June 10, 2011 IETF-81: discussed whether this should be BCP. ADs & Chairs agree to progress as a BCP Status changed to BCP (new-ID WG -05) Presented at IETF-82 (Taipei), request for WGLC. Gorry added as Shepherd (Jan 2012) WGLC concluded with comments on I-D, Friday 30th March 2012. DUE: Being prepared for submission to AD. - Gorry re-requested authors 26/6/2012. ------------------------------------------------------------------- WG Drafts with Chairs: draft-ietf-tsvwg-sctp-udp-encap (Replaced: draft-tuexen-sctp-udp-encap) Lars sent a note as AD agreeing to progress this work. Work to be coordinated with DCCP work on encaps. draft-tuexen-sctp-udp-encaps-06, January 10, 2011 Adopted as a work item 21 Sept 2010 (Gorry) WG -02 8 Dec 2011 WGLC completed Friday 20th April 2012 DUE: Authors to update draft. - Gorry re-requested authors 22/6/2012. ------------------------------------------------------------------- WG Drafts: draft-ietf-tsvwg-natsupp-tsvwg (Replaced: draft-stewart-natsupp-tsvw) Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg WG -01, June 1, 2011 DUE: Authors to restructure draft. DUE: Reviews need. draft-ietf-tsvwg-intserv-multiple-tspec WG interest in this topic recorded at IETF-78. Charter update would be needed to progress this work. 5 Reviews needed to determine energy/technical direction. WG -05 (presented in Beijing, IETF-79) WG -06 (presented in Prague, IETF-80) RSVP directorate was consulted. 2 reviews from RSVP-DIR received (Bruce Davie, ?) 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs asked AD for a Charter update (IESG agreed) Draft discussed at IETF-80, and request to update charter agreed - AD advised 4 named reviewers will be required Adopted for progression as PS, for May 2012 draft-ietf-tsvwg-rsvp-pcn Previous version : draft-karagiannis-pcn-tsvwg-rsvp-pcn WG interest in this topic recorded at IETF-81. Individual -01, 2011-07-11 AD decision allowed this to be added to the milestones The document was adopted WG -00 8 Oct 2011 DUE: New revision need draft-ietf-tsvwg-port-use-00 (replaces draft-touch-tsvwg-port-use-00) - Intended to be advice to protocol designers needing a port. 5 people have looked at this document, Prague IETF-80 Individual -01 July 2011 IETF-81 insufficient feedback from WG at this time. WG needs to assess if the new draft should be a work item. IETF-82, discussed - Chairs will ask WG to consider. Adopted by WG Please comment on list. ------------------------------------------------------------------- WG action required: draft-nishida-tsvwg-sctp-failover Individual-00 Presented in Prague, IETF-80. - understood not to conflict with draft-tuexen-tsvwg-sctp-multipath - PF has been coded into FreeBSD DUE: WG adoption being considered - please comment to list 26/6/2012. draft-polk-tsvwg-rsvp-app-id-vv-profiles -01 Presented in Beijing, IETF-79. -02, 14-Mar-2011 Presented IET-80. WG needs to assess if the new draft should be a work item. Seek to coordinate with music with partner ID: draft-polk-mmusic-traffic-class-for-sdp Author request to make a WG work item... Gorry liaised with MMUSIC WG Chairs on companion draft Gorry - not much discussion on this list, please assess as a candidate working document. Please comment on list. draft-tuexen-tsvwg-sctp-multipath -00 Presented in Prague, IETF-80. - understood not to conflict with draft-nishida-tsvwg-sctp-failover -01, 2010-12-27 Please comment to list. ------------------------------------------------------------------- The following have received recent discussion at TSVWG meetings or on the list. Inclusion in the list below does not indicate support for these specific drafts and other contributions are also warmly welcomed. draft-carlberg-tsvwg-ecn-reactions Reactions to Signaling from ECN Support for RTP/RTCP -00 presented IETF-82 WG needs to assess if the new draft should be a work item. Please comment on list. draft-tuexen-tsvwg-sctp-sack-immediately -05, 2011-01-02 - Aug 2011, discussed on list and issues raised. DUE: Chairs need to confirm adoption (need to do work). DUE: New revision need (to address comments) Please comment on list. draft-stewart-tsvwg-sctpecn-02 Partially replaces (draft-stewart-tsvwg-sctp-nonce) IETF-78 suggested there was interest in this topic. Discussed at IETF-83, Paris. DUE: ECN is within the TSVWG Charter, will call for adoption on the list. Please comment on list. draft-polk-tsvwg-rfc4594-update-00 Discussed at IETF-83, Paris A Revised ID is needed. draft-briscoe-tsvwg-ecn-encap-guidelines -00 Presented in Prague, IETF-80. - comments at IETF-80 (see minutes) Authors need to update this draft. Please comment on list. DUE: Please check liaison status with other SDOs. ------------------------------------------------------------------- Related non-WG items: draft-ietf-behave-sctpnat-03.txt BEHAVE WG item linked to SCTP encapsulation work. draft-ietf-6man-udpzero Previoiusly: draft-fairhurst-tsvwg-6man-udpzero Draft was adopted by 6man, please discuss on the 6man list. A WGLC of this draft is expected in 6MAN WG. Related draft: draft-ietf-6man-udpchecksums-00 This draft was also LC'ed in TSVWG (end 3rd May 2012) draft-saldana-tsvwg-tcmtf-00 Discussed at IETF-83, Paris No decision was made, please comment on the list. ------------------------------------------------------------------ Other news: RSVP Directorate (formed in May 2010) Charter updated Aug 2011. Rolf joined as a co-chair in June 2012. ------------------------------------------------------------------ From gorry@erg.abdn.ac.uk Sat Jun 30 00:26:36 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3373921F866B for ; Sat, 30 Jun 2012 00:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoaEsCx44P8k for ; Sat, 30 Jun 2012 00:26:35 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 771A221F8667 for ; Sat, 30 Jun 2012 00:26:34 -0700 (PDT) Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q5U7QPDA022673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 30 Jun 2012 08:26:25 +0100 (BST) Message-ID: <4FEEAA21.9070900@erg.abdn.ac.uk> Date: Sat, 30 Jun 2012 08:26:25 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: tsvwg WG , tsvwg chair Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: [tsvwg] Approval for draft-nishida-tsvwg-sctp-failover to be adopted as TSVWG work item X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 07:26:36 -0000 This email marks end of the confirmation of adoption of the above draft. Authors - please suggest to me a realistic target date for final submission of a complete document, and I'll request creation of a document milestone. Best wishes, Gorry, James & Rolf (TSVWG Chairs)