From owner-ietf-ppp-outgoing@merit.edu Tue May 1 01:15:37 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07752 for ; Tue, 1 May 2001 01:15:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C7B025E4EC; Mon, 30 Apr 2001 23:42:58 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 75E875E5B2; Mon, 30 Apr 2001 22:41:57 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 2706A5E497 for ; Mon, 30 Apr 2001 21:40:31 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f411eUg16501 env-from ; Mon, 30 Apr 2001 19:40:30 -0600 (MDT) Date: Mon, 30 Apr 2001 19:40:30 -0600 (MDT) From: Vernon Schryver Message-Id: <200105010140.f411eUg16501@calcite.rhyolite.com> To: ietf-ppp@merit.edu, tissa@force10networks.com Subject: RE: POS flow control: draft-tsenevir-ppp-flow-00.txt reply to Ver non Cc: neena@force10networks.com Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Tissa Senevirathne > To: "'Vernon Schryver'" , ietf-ppp@merit.edu > Cc: neena@force10networks.com, tissa@force10networks.com > This is similar to flow control like XON/XOFF. Do you think it was bad for > original designers to have XON/XOFF. XON/XOFF dates from at least mechanical teletypes ("tty's") as a mechanism to start and stop a remote paper tape reader. In its realm it was the only and clearly necessary and appropriate flow control mechanism. IP applications already have a flow control mechanism in the form of TCP and various UDP mechanisms. Consider when and why XON/XOFF or RTS/CTS flow control is useful with PPP over modems. When the PPP link is connected to a host that is a TCP endpoint, the TCP state machine can notice when the local PPP/modem transmit queue is too full and stop the application. That does not apply to any router, including one with a SONET link. On the other hand, if a router drops a packet, a distant TCP sender will notice and stop sending so much. If any of the protocols or applications used above PPP needed help with flow control, would the reliable link form of PPP defined in RFC 1663 be dead and forgotten? If something other than just dropping packets that don't fit in queues were good for PPP, wouldn't we be doing that for modems? What is different about SONET except speed? > Please also see the reply to James. > What is your opinion on Ethernet PAUSE frames. Do you think that is not > useful and affects IP flows ? TCP/IP reacts badly to link layers that delay data. TCP/IP wants to know about congestion on any link or connection among links. To tell TCP about congestion in a link, you must signal it to the distant hosts that have the TCP state machines. You can do that by setting bits in IP or TCP headers (for an example, look for "ECN"), sending new kinds of packets (look for "ICMP source quench") or by deleting packets entirely. There is no fourth possiblity. A link layer that adds buffering or retransmits is failing to tell TCP about congestion, and that is usually a bad thing. Yes, if the congestion is very short term, TCP does not need to know, but the easiest way to do that is to do what network hardware has done since before TCP, Ethernet, and even the ARPANet, and that is to have a FIFO (or other kind of) quiet buffer. I don't know anything about Ethernet PAUSE frames, and given history including 100VG-AnyLAN 802.12, I'm afraid to learn. Maybe Ethernet PAUSE frames are good things that restore the link layer flow control lost with so called "switches" (really multi-port bridges) and then with FDX. The TCP state machines in hosts connected to classic Ethernet could notice when the wire was too full (i.e. collisions) and stop pushing more data. Switches and FDX broke that and can cause TCP retransmissions, but only when for hosts connected directly to the Ethernet. Does your proposal involve hosts or routers with SONET links? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Tue May 1 13:59:50 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06118 for ; Tue, 1 May 2001 13:59:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 29C615E09D; Tue, 1 May 2001 13:58:59 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0DF815E07E; Tue, 1 May 2001 13:58:59 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 44F665E133 for ; Tue, 1 May 2001 13:58:50 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f41HwnM09572 env-from ; Tue, 1 May 2001 11:58:49 -0600 (MDT) Date: Tue, 1 May 2001 11:58:49 -0600 (MDT) From: Vernon Schryver Message-Id: <200105011758.f41HwnM09572@calcite.rhyolite.com> To: ietf-ppp@merit.edu, tissa@force10networks.com Subject: RE: POS flow control: draft-tsenevir-ppp-flow-00.txt reply to Ver non Cc: neena@force10networks.com Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Why is my sense of lurking patents tingling? > From: Tissa Senevirathne > To: "'Vernon Schryver'" , ietf-ppp@merit.edu, > tissa@force10networks.com > Cc: neena@force10networks.com > Another point with the flow control is it really helps transmitting end to > set ECN bits on TCP flows. Without buffer buildup this will not happen. SO I > feel having flow control as proposed will help in generating ECN etc.. How does your proposal affect routers setting the ECN bits? Why have the authors of the ECN RFC's not mentioned the utility of equivalents to XON/XOFF? What does your proposal communicate between PPP peers anything that migh be used to set ECN bits and that is not already known by the router that shoudl be setting the ECN bits? The router with the full buffers (either output or input) knows it has full buffers. It does not need to be told its buffers are full in order to set ECN bits, and neither does it need to tell some other router so that the other router can set ECN bits. ] From: Tissa Senevirathne ] To: "'Vernon Schryver'" , ietf-ppp@merit.edu, ] tissa@force10networks.com ] Cc: neena@force10networks.com ] The proposal involve connections betwen routers. Almost allways POS is ] between routers. On the other hand applications we are focusing is not ] necessaraly TCP/IP. It can be any variation of Layer 2, MPLS or IP tunnels. Given that this is the IETF and your proposal is for PPP, what applications do you anticipate? (Note that MPLS and IP tunnels generally must be counted as "TCP" because that's what is usually what is happening at the top.) ] What we are trying to do here is when limted input buffer over flow occurs ] use the large Egress buffers to hold on packets during temporay ingress ] buffer overuns. Is it reasonable to expect routers to shuffle free buffer space pools at SONET speeds? From what little I've seen, the answer to that question is emphatically no. Consider why router vendors are talking about including 100-200 MByte of buffering in OC 192 interface cards in order to have 10 milliseconds of buffering (i.e. buffer efficiency of <15% due to fragmentation, such as putting a 200 byte packet in a 1534 byte buffer). ] What our stdudies indicated was, ability to buffer temporary congestion ] infact help TCP flows. It maintained a smooth flow rather than quinching ] windows. Did your studies compare the relative costs of statically allocating more RAM in each port as opposed to making it dynamic? ] On the other hand use of ECN is still not so wide spread and ] applications are required to implement that. That is mistaken. Applications have nothing to do with, for, or to ECN. Second, ECN will be widely implemented far sooner than a new PPP-SONET XON/XOFF protocol. ] On the other hand when we were ] tunneling non IP packets we need to provide as smooth flow as possible ] between router. What non-IP packets do you anticipate tunnelling above PPP? ] IN theory receive router appears as a DCE to the sending ] router since they are directly connected via a POS (SONET) link, Hence all ] RTS/CTS and XON/XOFF philosphies apply directly. Once you start thinking to ] routers are DCE/DTE pair all what we presented may appear as logical. May be ] that is something we should have highlighetd. If that is the case please let ] us know we would include that in the next revision Again, please explain why your proposal has not been required for all other serial links among routers. Why aren't RTS/CTS or XON/XOFF with buffer management signalling such as you propose used for all other serial links? How does SONET differ from an old fashioned CSU/DSU leased line link, except that your proposal might be implementable at low speeds? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Tue May 1 21:01:56 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13385 for ; Tue, 1 May 2001 21:01:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 674AF5DF5F; Tue, 1 May 2001 20:52:08 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 35E365E015; Tue, 1 May 2001 20:52:06 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 7770C5DF5F for ; Tue, 1 May 2001 20:52:03 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f420q2L02620 env-from ; Tue, 1 May 2001 18:52:02 -0600 (MDT) Date: Tue, 1 May 2001 18:52:02 -0600 (MDT) From: Vernon Schryver Message-Id: <200105020052.f420q2L02620@calcite.rhyolite.com> To: ietf-ppp@merit.edu, tissa@force10networks.com Subject: RE: POS flow control: draft-tsenevir-ppp-flow-00.txt reply to Ver non Cc: neena@force10networks.com Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Tissa Senevirathne > To: "'Vernon Schryver'" , ietf-ppp@merit.edu, > tissa@force10networks.com > Cc: neena@force10networks.com > When you are tail dropping at the remote end there is no way that the > buffers over flow, hence there is no ECN bit set. As I said earlier POS > peers appears like DCE/DTE hence, hence flow control help to build the > egress buffers at the transmit end and hence kick in ECN algorithms. You did say that, but I didn't understand. Your document says "Packet Over SONET (POS)" which implies to me that each "POS peer" does not "appear lke DCE/DTE". The PPP universe is about complete routers that are DTE's. The DCE stuff is below PPP. Why can't any PPP peer that is connected to a PPP peer by SONET, modems, leased lines or wet string and that is dropping packets from heads, tails or elsewhere in its queues set the ECN bits? Why can't any PPP/SONET router watch its own ingress queue and mark packets that it doesn't drop with the ECN bits? > In older implementations, DSU and DCU were sitting between. Now with POS > two routesr appears like they are back to back connected. I presume that you > would atleast agree on that.... Either I don't understand that or I disagree. If you envision pairs of boxes connected by SONET links where the pair of boxes acts as if it were a single PPP router containing a medium bandwidth (10 Gbits/bit) internal bus that is very long (up to many miles) with very high latency (packet serialization plus speed of light), then I don't see what your proposal has to do with PPP and the IETF. "Half-bridges" are not the concern of the IETF but are in the territory of one of the offices down the hall, such as IEEE 802. On the other hand, there are plenty of SONET routers that use PPP and know better than any other box whether they are dropping packets from any of their queues and that can and (realsoonnow) do their own ECN marking. How is SONET different from an ancient 56 kbit/sec leased line using CSU/DSU's or modern v.90 modem? For your proposal to be needed, there must be something about SONET that is very different from those case, because in neither of those cases does one PPP peer need to tell the other PPP about XON/XOFF, RTS/CTS, or other flow control. PPP implementations using modems do care about RTS/CTS or XON/XOFF flow control, but those cares are outside the domain of the IETF. The EIA, TIA, or some such standards organization is in charge of those DCE/DTE flow control issues, not the IETF. To put it yet another way, I don't understand or disagree with the this statement in your document: ] PPP ] [RFC 1661] protocol depends on the lower layer to provide required flow ] control The word "flow" does not appear in RFC 1661. Consider the implications of the single instance of "flow" in RFC 1662 (PPP in HDLC-like Framing). Notice that "flow" does not appear in RFC 1618 (PPP over ISDN). "Flow control" is not mentioned in RFC 2823 (PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing) or RFC 2615 (PPP over SONET/SDH). In still other words, how do existing PPP/SONET implementations work without IEEE 802 Ethernet-PAUSE frames? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed May 2 15:11:09 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20412 for ; Wed, 2 May 2001 15:11:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0B8B45E26A; Wed, 2 May 2001 15:09:50 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 76F915E278; Wed, 2 May 2001 15:08:06 -0400 (EDT) Received: from relay1.ne.smtp.psi.net (relay1.ne.smtp.psi.net [38.9.153.2]) by segue.merit.edu (Postfix) with ESMTP id 26F625E1D1 for ; Wed, 2 May 2001 15:05:30 -0400 (EDT) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.ne.smtp.psi.net with smtp (Exim 3.13 #3) id 14v1wH-0003J6-00 for ietf-ppp@merit.edu; Wed, 02 May 2001 15:05:29 -0400 Received: from sirius.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA12921; Wed, 2 May 01 14:57:28 EDT Received: from txc.com by sirius.txc.com (SMI-8.6/SMI-SVR4) id PAA11062; Wed, 2 May 2001 15:07:11 -0400 Message-Id: <3AF05ADB.3810E38@txc.com> Date: Wed, 02 May 2001 15:07:07 -0400 From: srihari varada X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en Mime-Version: 1.0 To: ietf-ppp@merit.edu Subject: (no subject) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA833A7146F755355085A5C61" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a cryptographically signed message in MIME format. --------------msA833A7146F755355085A5C61 Content-Type: multipart/alternative; boundary="------------F5D9DADA3AF69638B53F38F4" --------------F5D9DADA3AF69638B53F38F4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello: I am in search of pointers for the following and was guided to this mailling list: -- Note(s) on the "ML-PPP Deployment experiences" by the Network Service Providers The archived mailing list traffic wasn't very useful in the search as there is apparently no search tool to plow through the archives. I would appreciate, if some one could shed some light on the above. Regards, Srihari Varada --------------F5D9DADA3AF69638B53F38F4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello:

I am in search of pointers for the following and was guided to this mailling list:
--  Note(s) on the "ML-PPP Deployment experiences" by the Network Service Providers

The archived mailing list traffic wasn't very useful in the search as there is apparently no search tool to plow through the archives. I would appreciate, if some one could shed some light on the above.

Regards,

Srihari Varada
  --------------F5D9DADA3AF69638B53F38F4-- --------------msA833A7146F755355085A5C61 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJqgYJKoZIhvcNAQcCoIIJmzCCCZcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BzYwggQAMIIDaaADAgECAhB3M9lwGPdPV1OziIB0iD8qMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyMjAwMDAw MFoXDTAxMDkyMjIzNTk1OVowggEPMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlNyaWhhcmkgVmFyYWRhMR0wGwYJKoZI hvcNAQkBFg52YXJhZGFAdHhjLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1tk+ 1mkaLtLJgCr8SqdHyo9X96/dmMCPjY6Tib9BdElJIGndA8RWN5wWCUAAlynVtCzv8zagDMKl NU8ixMS7da00l6J8LV4XD7TcQ4B82C1DEfBHsoLCmU+YcUiq0Z3L6tKPKqkUUmsira0Y1tFZ NGk8JATI4RVkVSDPYWMQA1UCAwEAAaOBnDCBmTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHAQgwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YTARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJp c2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCA+LTDZrUrsoVOeXy/xIkz V25NNx4zsI2onewoo//nvmObqNKitoFms7o/curJtBz/awXcxkMXRF1DOd8ZG7tlDgT1hlvL clvRqVwzzXxGMuFMS3trzCPA58HCUcT3i9J2U9rUN9jm4rnC83vDKE+2rp56WLccSsxD/Y1M 1LFhPTCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3Mg MSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAw MDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/ VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3Qg VmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8V eDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vC O7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErI CQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhF AQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8G A1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3 AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrl Cwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhq wY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgw RgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJz b25hIE5vdCBWYWxpZGF0ZWQCEHcz2XAY909XU7OIgHSIPyowCQYFKw4DAhoFAKCBsTAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTA1MDIxOTA3MDlaMCMG CSqGSIb3DQEJBDEWBBT1rFCr0eaDzCL0PCa7SiaEdVNXZDBSBgkqhkiG9w0BCQ8xRTBDMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggq hkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgGxP4ibtFW3GQlHIGnaBEVMGTNd+KYRU2w+9 jUrgIyyW1tz2LEA4CTA+f5oaxl5jMzBigbAyw+GB7qrUPdka6hlQieLBV3V+u3Tmza3Ao+dN iDkuzPnyzxhZNTt2ryqEQJV+vE50kOSBgqYs6hDsxSHSjrJJNNLqp8Tv/9gtW8sJ --------------msA833A7146F755355085A5C61-- From owner-ietf-ppp-outgoing@merit.edu Mon May 7 09:22:36 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10699 for ; Mon, 7 May 2001 09:22:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 139CA5DD92; Mon, 7 May 2001 09:21:50 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ECDCC5DD90; Mon, 7 May 2001 09:21:49 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 04DE15DE07 for ; Mon, 7 May 2001 09:21:48 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f47DLvS15817 for ; Mon, 7 May 2001 16:21:57 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 7 May 2001 16:21:46 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 7 May 2001 16:21:46 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E6260D@treis03nok> From: henry.haverinen@nokia.com To: ietf-ppp@merit.edu Subject: EAP/SIM roundtrips Date: Mon, 7 May 2001 16:21:45 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi all, I have been asked why the EAP/SIM draft (draft-haverinen-pppext-eap-sim-01.txt) uses so many roundtrips and if it would be possible to save them. Here is a clarification. Yes, we could save a roundtrip by sending the challenge already in the first EAP/SIM Request like this: Client Authenticator <- EAP-Req/Identity EAP-Resp/Identity -> <- EAP-Req/SIM (RAND, MAC_RAND) -> EAP-Resp/SIM (NONCE_MT, MAC_SRES) <- EAP Success A problem here is that in this case NONCE_MT wouldn't be included in the calculation of the MAC_RAND authenticator, and the terminal couldn't recognize if the EAP-Req/SIM is a replay. This would mean weaker network authentication. NONCE_MT could still be included in MAC_SRES and the key. As this is a tradeoff between security and roundtrips, I think it is better to prefer security. Regards, Henry From owner-ietf-ppp-outgoing@merit.edu Fri May 18 06:55:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21974 for ; Fri, 18 May 2001 06:55:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 478F85DE5C; Fri, 18 May 2001 06:55:24 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 304BD5DE87; Fri, 18 May 2001 06:55:24 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 643E65DE5C for ; Fri, 18 May 2001 06:55:22 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21852; Fri, 18 May 2001 06:55:10 -0400 (EDT) Message-Id: <200105181055.GAA21852@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-arkko-pppext-eap-aka-00.txt Date: Fri, 18 May 2001 06:55:10 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP AKA Authentication Author(s) : J. Arkko, H. Haverinen Filename : draft-arkko-pppext-eap-aka-00.txt Pages : 19 Date : 17-May-01 This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the UMTS AKA authentication mechanism. AKA is based on symmetric keys, and runs in a UMTS Subscriber Identity Module, a smart card like device. AKA provides also backward compatibility to GSM authentication, making it possible to use EAP AKA for authenticating both GSM and UMTS subscribers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-arkko-pppext-eap-aka-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-arkko-pppext-eap-aka-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010517101105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-arkko-pppext-eap-aka-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-arkko-pppext-eap-aka-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010517101105.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Tue May 22 04:49:31 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11931 for ; Tue, 22 May 2001 04:49:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 65C3D5DE01; Tue, 22 May 2001 04:49:20 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 48CB25DE8E; Tue, 22 May 2001 04:49:20 -0400 (EDT) Received: from exchange.Ic4ic.com (unknown [194.90.135.194]) by segue.merit.edu (Postfix) with SMTP id 303815DE01 for ; Tue, 22 May 2001 04:49:18 -0400 (EDT) Received: through eSafe SMTP Relay 989359948; Tue May 22 11:51:15 2001 content-class: urn:content-classes:message Subject: PPPmux transmitter stopping criteria in the concatenation process MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Date: Tue, 22 May 2001 11:49:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D0B3905@exchange.Ic4ic.com> Thread-Topic: PPPmux transmitter stopping criteria in the concatenation process Thread-Index: AcDinBNDtnbakjD1SDyUwiOwMAoTdQ== From: "Daniel Feldman" To: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA11931 Hello friends of PPPmux! How can a transmitter know there are no more subframes to concatenate (stopping criteria iii in the concatenation process)? If the only way is through a timer, then the paragraph: "Implementers may choose additionally to implement using timers. In such a case a timeout in addition to the conditions stated above is used as a stopping criteria of the multiplexing process." is not needed. Thanks a lot, Daniel Feldman IC4IC Ltd. System Engineer From owner-ietf-ppp-outgoing@merit.edu Tue May 22 09:01:53 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16345 for ; Tue, 22 May 2001 09:01:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D07C5DDCF; Tue, 22 May 2001 09:01:25 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 10AFC5DDF1; Tue, 22 May 2001 09:01:24 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 369035DDCF for ; Tue, 22 May 2001 09:01:22 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15877; Tue, 22 May 2001 06:01:18 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15778; Tue, 22 May 2001 09:01:17 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f4MD22I11508; Tue, 22 May 2001 09:02:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15114.25417.810681.358340@gargle.gargle.HOWL> Date: Tue, 22 May 2001 09:02:01 -0400 (EDT) From: James Carlson To: "Daniel Feldman" Cc: Subject: Re: PPPmux transmitter stopping criteria in the concatenation process In-Reply-To: Daniel Feldman's message of 22 May 2001 11:49:04 References: <88BC9E379956AE4DB689CC5FF6F5A43D0B3905@exchange.Ic4ic.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Daniel Feldman writes: > How can a transmitter know there are no more subframes to > concatenate (stopping criteria iii in the concatenation process)? It's implementation dependent. One could easily imagine twisted implementations that either (a) never stop sending packets or (b) have some sort of "I'm done sending" indication from the transport layer. These would not need a timer. > If the > only way is through a timer, then the paragraph: > "Implementers may choose additionally to implement using timers. In such > a case a timeout in addition to the conditions stated above is used as a > stopping criteria of the multiplexing process." > is not needed. I don't see why that paragraph is unneeded. Perhaps the "may" should have been strengthened to "SHOULD," but I don't see how omitting important implementation information is helpful. There are two general ways to determine when to stop the multiplexing, and most implementations probably should use both. The timer is one good way to do it. The other is when the accumulated data would exceed the peer's MRU. Still another issue to consider is possible packet priority. You may want to terminate multiplexing because a low-priority packet is about to be appended. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp-outgoing@merit.edu Tue May 22 09:46:33 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18110 for ; Tue, 22 May 2001 09:46:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 037505DE8C; Tue, 22 May 2001 09:45:56 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E03755DE17; Tue, 22 May 2001 09:45:55 -0400 (EDT) Received: from stargate.ttc.com (stargate.ttc.com [157.234.250.2]) by segue.merit.edu (Postfix) with ESMTP id 43EA55DD95 for ; Tue, 22 May 2001 09:45:53 -0400 (EDT) Received: from relay.ttc.com (relay.ttc.com [157.234.7.6]) by stargate.ttc.com with ESMTP id JAA01243 for ; Tue, 22 May 2001 09:47:27 -0400 (EDT) From: michael.koller@acterna.com Received: from relay.ttc.com by relay.ttc.com with SMTP id JAA26248 for ; Tue, 22 May 2001 09:45:51 -0400 (EDT) Received: by ttcmta1-7.ttc.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A54.004B9C0B ; Tue, 22 May 2001 09:45:51 -0400 X-Lotus-FromDomain: GLOBAL To: ietf-ppp@merit.edu Message-ID: <85256A54.004B99D6.00@ttcmta1-7.ttc.com> Date: Tue, 22 May 2001 09:45:09 -0400 Subject: Escape Error in HDLC Framing Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I apologize if this is off-topic. Please ignore if it is. NOTE: I am keeping track of the following counts: 1. Total valid frames (i.e. every frame, except invalid). 2. Total FCS errored frames 3. Total invalid frames Invalid HDLC Frames (which are dropped), can be sub-classified as: 1. Short frames; or 2. Escape errors (0x7d followed by 0x7e). It is #2 that concerns me with regard to how to proceed AFTER the escape error has been detected. As I see it, there are two ways to go about it. (1) real frame start real frame end 0x7E .............. 0x7D 0x7E .......................... 0x7E |----------escape error-----|----------fcs error------------| escape error is detected and an invalid frame is counted. then, count the '7e' in the escape error as the start of the next frame, likely leading to an FCS error or possibly a short frame error. ----OR---- (2) real frame start real frame end 0x7E .............. 0x7D 0x7E .......................... 0x7E |----------escape error-----|-------ignore to next 7E-------| escape error is detected, but the '7e' in the escape error is NOT considered the start of the next frame. The next frame is not considered to have started until another '7E' is encountered. These approaches provided very different results with respect to the counters I am tracking. Unfortunately, the RFC RE: PPP over HDLC does (1662) not address how to resolve this issue. Thanks for your help. From owner-ietf-ppp-outgoing@merit.edu Tue May 22 10:14:50 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19327 for ; Tue, 22 May 2001 10:14:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A1DC05DE2E; Tue, 22 May 2001 10:14:37 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8DFD95DE2D; Tue, 22 May 2001 10:14:37 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 4A0365DE2A for ; Tue, 22 May 2001 10:14:35 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14894; Tue, 22 May 2001 07:14:13 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28725; Tue, 22 May 2001 10:14:12 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f4MEEul11989; Tue, 22 May 2001 10:14:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15114.29791.923412.719297@gargle.gargle.HOWL> Date: Tue, 22 May 2001 10:14:55 -0400 (EDT) From: James Carlson To: michael.koller@acterna.com Cc: ietf-ppp@merit.edu Subject: Re: Escape Error in HDLC Framing In-Reply-To: michael.koller@acterna.com's message of 22 May 2001 09:45:09 References: <85256A54.004B99D6.00@ttcmta1-7.ttc.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit michael.koller@acterna.com writes: > I apologize if this is off-topic. Please ignore if it is. Nope; this is right on-topic. > Invalid HDLC Frames (which are dropped), can be sub-classified as: > > 1. Short frames; or > 2. Escape errors (0x7d followed by 0x7e). You should be counting these separately. The latter case is actually an aborted frame. See RFC 1662: On reception, prior to FCS computation, each octet with value less than hexadecimal 0x20 is checked. If it is flagged in the receiving ACCM, it is simply removed (it may have been inserted by intervening data communications equipment). Each Control Escape octet is also removed, and the following octet is exclusive-or'd with hexadecimal 0x20, unless it is the Flag Sequence (which aborts a frame). > It is #2 that concerns me with regard to how to proceed AFTER the escape > error has been detected. As I see it, there are two ways to go about it. You just start with a clean slate. You're in a new frame. > (1) [...] > escape error is detected and an invalid frame is counted. then, count > the '7e' in the escape error as the start of the next frame, likely > leading to an FCS error or possibly a short frame error. Version (1) is the proper handling. > These approaches provided very different results with respect to the > counters I am tracking. Unfortunately, the RFC RE: PPP over HDLC does (1662) > not address how to resolve this issue. Actually, it does. 7E on the line is a frame end marker. Always. There are no exceptions at all. 4.1. Flag Sequence The Flag Sequence indicates the beginning or end of a frame. The octet stream is examined on an octet-by-octet basis for the value 01111110 (hexadecimal 0x7e). -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp-outgoing@merit.edu Tue May 22 17:45:17 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05145 for ; Tue, 22 May 2001 17:45:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 49D4C5DE20; Tue, 22 May 2001 17:36:54 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 36A085DE1F; Tue, 22 May 2001 17:36:54 -0400 (EDT) Received: from fs-sd-exch2.coppermountain.com (fs-sd-exch2.coppermountain.com [209.246.224.234]) by segue.merit.edu (Postfix) with ESMTP id EDDEA5DE18 for ; Tue, 22 May 2001 17:36:52 -0400 (EDT) Received: by fs-sd-exch2.coppermountain.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 May 2001 14:37:28 -0700 Message-ID: <583EFB625043D511920400D0B74178C8347CAB@fs-sd-exch2.coppermountain.com> From: emichelsen@coppermountain.com To: ietf-ppp@merit.edu Subject: RE: POS flow control: draft-tsenevir-ppp-flow-00.txt Date: Tue, 22 May 2001 14:37:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > -----Original Message----- > From: Vernon Schryver [mailto:vjs@calcite.rhyolite.com] > Sent: Monday, April 30, 2001 16:09 > To: ietf-ppp@merit.edu > Cc: neena@force10networks.com; tissa@force10networks.com > Subject: Re: POS flow control: draft-tsenevir-ppp-flow-00.txt > > > > From: James Carlson > > To: pppext > > Cc: tissa@force10networks.com, neena@force10networks.com > > > Has anyone else looked at this individual submission? > > yes, from the title and before reading it, I guessed it might be > another aspect of the strange world of SONET. > > > It is defining new LCP options to negotiate a SONET-and-802.3x > > specific flow control mechanism for PPP, plus a new control protocol > > to actually signal flow control. > > > > This doesn't sound like a good thing to me. Implementations are > > typically expected to buffer as much as practical for > expected bursts > > (250ms+, usually), and to drop otherwise. Adding flow > control in here > > makes a bad situation worse -- it pushes the buffering back into the > > network rather than in the hosts where it belongs, and presents TCP > > with more delay variance. It sounds like the result of a > > misunderstanding of how IP-based congestion control works. > > > > Is it possible that the original authors just need bigger buffers > > and/or RED? > > Yes, contrary to the thesis of the Internet Draft, dropping > packets is a > good thing and putting a flow controlling protocol such as TCP above a > second flow controlling protocol like x.25 or this SONET proposal is a > quite bad thing except in some special cases. I've always wondered why L2TP includes flow control for PPP sessions. In fact, at an L2TP development meeting in San Ramon, one developer insisted that "without flow control, L2TP won't work." I didn't believe it then, and I still don't. How does L2TP differ from other bursty links on which PPP rides (and works without flow control)? From owner-ietf-ppp-outgoing@merit.edu Wed May 23 08:01:55 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01622 for ; Wed, 23 May 2001 08:01:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C51235DF03; Wed, 23 May 2001 08:01:31 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AEAAF5DEB2; Wed, 23 May 2001 08:01:31 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 6F7145DED0 for ; Wed, 23 May 2001 08:01:29 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27705; Wed, 23 May 2001 06:01:26 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00231; Wed, 23 May 2001 08:01:26 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f4NC2Cl13317; Wed, 23 May 2001 08:02:12 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15115.42691.807842.636314@gargle.gargle.HOWL> Date: Wed, 23 May 2001 08:02:11 -0400 (EDT) From: James Carlson To: emichelsen@coppermountain.com Cc: ietf-ppp@merit.edu Subject: RE: POS flow control: draft-tsenevir-ppp-flow-00.txt In-Reply-To: emichelsen@coppermountain.com's message of 22 May 2001 14:37:18 References: <583EFB625043D511920400D0B74178C8347CAB@fs-sd-exch2.coppermountain.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit emichelsen@coppermountain.com writes: > I've always wondered why L2TP includes flow control for PPP > sessions. L2TP does not include flow control for PPP sessions. It has flow control on its control channel, but not on the data channel. (There was data channel flow control in an old draft that had inherited this flaw from PPTP; it was later eliminated, and it's not in the RFC.) It does have optional *sequencing* on the data channel. This is handy because the PPP state machine and many network layer protocols don't tolerate reordering, and some networks can reorder packets. There's no implied flow control in it, though. > In > fact, at an L2TP development meeting in San Ramon, one developer insisted > that "without flow control, L2TP won't work." I didn't believe it then, and > I still don't. How does L2TP differ from other bursty links on which PPP > rides (and works without flow control)? It doesn't. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp-outgoing@merit.edu Wed May 23 09:40:58 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04889 for ; Wed, 23 May 2001 09:40:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE1515DDA8; Wed, 23 May 2001 09:40:44 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DA2145DE0F; Wed, 23 May 2001 09:40:44 -0400 (EDT) Received: from relay4.ftech.net (ibm6.ftech.net [212.32.16.76]) by segue.merit.edu (Postfix) with ESMTP id A9BEB5DDA8 for ; Wed, 23 May 2001 09:40:43 -0400 (EDT) Received: from ibm9.ftech.net ([212.32.16.79] helo=hardy.farsite.co.uk) by relay4.ftech.net with esmtp (Exim 3.22-ftech-p6.1 #2) id 152YsU-0000Vt-00 for ietf-ppp@merit.edu; Wed, 23 May 2001 14:40:42 +0100 Received: by HARDY with Internet Mail Service (5.5.2650.21) id ; Wed, 23 May 2001 14:03:13 +0100 Message-ID: From: Jonathan Goodchild To: "'ietf-ppp@merit.edu'" Subject: Silent Packet Loss & Header Compression Date: Wed, 23 May 2001 14:03:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu (Apologies if this is slightly off-topic.) James Carlson writes: > [L2TP] ... does have optional *sequencing* on the data > channel. This is handy because the PPP state machine and > many network layer protocols don't tolerate reordering, > and some networks can reorder packets. Does this sequencing have the additional benefit of helping to overcome the problem of silent loss of packets? (Which can have unpleasant effects on Van Jacobson decompressors.) Also, does anyone know if the additional techniques described in RFC 2507 mean that decompressors can cope without explicit notification of packet loss? -- Jonathan Goodchild FarSite Communications From owner-ietf-ppp-outgoing@merit.edu Wed May 23 09:55:35 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05282 for ; Wed, 23 May 2001 09:55:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 395625DE48; Wed, 23 May 2001 09:55:24 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 266125DE47; Wed, 23 May 2001 09:55:24 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 78E095DE0F for ; Wed, 23 May 2001 09:55:22 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA07097; Wed, 23 May 2001 06:55:18 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18482; Wed, 23 May 2001 09:55:16 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f4NDu0q13670; Wed, 23 May 2001 09:56:00 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15115.49520.105953.266644@gargle.gargle.HOWL> Date: Wed, 23 May 2001 09:56:00 -0400 (EDT) From: James Carlson To: Jonathan Goodchild Cc: "'ietf-ppp@merit.edu'" Reply-To: l2tp@l2tp.net Subject: Re: Silent Packet Loss & Header Compression In-Reply-To: Jonathan Goodchild's message of 23 May 2001 14:03:12 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Jonathan Goodchild writes: > (Apologies if this is slightly off-topic.) Likely, yeah. > > [L2TP] ... does have optional *sequencing* on the data > > channel. This is handy because the PPP state machine and > > many network layer protocols don't tolerate reordering, > > and some networks can reorder packets. > > Does this sequencing have the additional benefit of helping to overcome the > problem of silent loss of packets? (Which can have unpleasant effects on > Van Jacobson decompressors.) That and CCP problems, yes. Of course, it's not at all clear to me *why* you would want to run VJ over the tunneled portion of the connection. It doesn't help there at all. Basically, this reveals a known architectural flaw in L2TP. There's no good reason not to allow differences in the negotiated options as seen between the "client" and LAC versus between the LAC and LNS. In other words, it's perfectly legitimate for the LAC to negotiate VJ compression with the client by adding and stripping the necessary IPCP option on the fly, and leave the LNS out of the equation. The LAC would then maintain the VJ state on the serial link and the LNS would see regular IP frames only. As long as the translation is done correctly, it's completely transparent, and it repairs substantial flaws in LCP renegotiation, CCP operation, and SLI semantics. > Also, does anyone know if the additional techniques described in RFC 2507 > mean that decompressors can cope without explicit notification of packet > loss? That appears to be the intent, yes. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp-outgoing@merit.edu Wed May 23 12:03:53 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08261 for ; Wed, 23 May 2001 12:03:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8497A5DE41; Wed, 23 May 2001 12:03:43 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 12B8E5DE52; Wed, 23 May 2001 12:03:38 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 3B9FD5DE41 for ; Wed, 23 May 2001 12:03:36 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06944; Wed, 23 May 2001 10:03:28 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24652; Wed, 23 May 2001 12:03:28 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f4NG4DX14693; Wed, 23 May 2001 12:04:13 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15115.57212.693500.873969@gargle.gargle.HOWL> Date: Wed, 23 May 2001 12:04:12 -0400 (EDT) From: James Carlson To: Ignacio Goyret Cc: l2tp@l2tp.net, Jonathan Goodchild , "'ietf-ppp@merit.edu'" Subject: Re: Silent Packet Loss & Header Compression In-Reply-To: Ignacio Goyret's message of 23 May 2001 08:28:38 References: <3.0.5.32.20010523082838.0392c610@grigri.eng.ascend.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Ignacio Goyret writes: > That would fail fatally if the client is using MP since no single LAC is > guaranteed that it will have access to all the channels composing an MP > link, which is one of many reasons why LACs should not do anything like that. Running MP over L2TP over a lossy or delay-prone network is a bad idea to begin with. Having the MP links bundled in a LAC-local manner (as with Bay's MMP) and then representing the bundle as a single PPP session to the LNS is a much better answer. Note that because of the Endpoint-Discriminator issues, MP over L2TP where the LAC endpoints are *not* reasonably local to each other just doesn't work anyway. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp-outgoing@merit.edu Thu May 24 11:22:04 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15280 for ; Thu, 24 May 2001 11:22:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E24D5DDB2; Thu, 24 May 2001 11:21:47 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EA6215DDA1; Thu, 24 May 2001 11:21:46 -0400 (EDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by segue.merit.edu (Postfix) with SMTP id 365D15DD8F for ; Thu, 24 May 2001 11:21:45 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Thu May 24 11:20:13 EDT 2001 Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Thu May 24 11:20:18 EDT 2001 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id E02A85701F for ; Thu, 24 May 2001 10:19:55 -0500 (CDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="4G+jTqFCzn" Content-Transfer-Encoding: 7bit From: Pete McCann To: ietf-ppp@merit.edu Subject: forwarded message from Pete McCann X-Mailer: VM 6.33 under Emacs 19.34.2 Message-Id: <20010524151955.E02A85701F@king.research.bell-labs.com> Date: Thu, 24 May 2001 10:19:55 -0500 (CDT) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --4G+jTqFCzn Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I sent this e-mail out on April 20, but it doesn't seem to have gotten through to ietf-ppp (I can't find it in the archives). I'd appreciate it if pppext'ers could comment on the question of whether we can specify multiple IP-Compression configuration options during IPCP. I think this is something that is not quite supported by the current drafts as written, but I think it will be necessary for some of the emerging wireless links. Can we make this change in the ROHC-over-PPP draft? -Pete --4G+jTqFCzn Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii BCC: Raymond Hsu , tom.hiller@lucent.com In-Reply-To: References: <20010419194702.883065701F@king.research.bell-labs.com> X-Mailer: VM 6.33 under Emacs 19.34.2 From: Pete McCann To: "Dr. Carsten Bormann" Cc: "ROHC Mailing List" , ietf-ppp@merit.edu Subject: RE: [rohc] ROHC-over-PPP Hi, Carsten, "Dr. Carsten Bormann" (CB) writes: >> Of course, this text is copied from 2509, but I think there will >> sometimes be a requirement to run ROHC plus some other IP header >> compression protocol simultaneously. For example, it may sometimes be >> desirable to run V-J header compression (RFC 1144) and ROHC-RTP over >> the same PPP link, albeit on channels with different levels of >> reliability. CB> It's probably more useful to run 2507 TCP compression in parallel CB> with ROHC. Unfortunately, in 2509, we made the mistake of not CB> enabling the negotiation of just TCP compression; once you CB> negotiate 2507, you have to support 2507 UDP as well. Oh well... Yes, being able to run 2507 in parallel would be nice as well. And there may be cases where normal non-RTP UDP traffic should be treated with 2507-UDP (over a reliable channel), but RTP should be treated with ROHC. It is probably not possible to do this with the heuristics outlined in 2508, but maybe we can solve this problem with other techniques. We could say something like, "If any of the negotiated compression mechanisms apply to overlapping types of packets, the compressor must decide which packet flows are to be compressed with which mechanisms. Making such decisions is outside the scope of this specification." >> Could the above text be changed to include something like, >> >> "This specification explicitly updates RFC 1332 to allow more than >> one IP-Compression-Protocol configuration option. If the >> configuration option is repeated, then each type of compression >> protocol may independently establish its own parameters." CB> This is a very good question. I think the PPP people will have an CB> opinion about the amount of breakage this generates in their CB> crufty old PPP implementations. I'm not saying this change is CB> impossible, but we do need to check with them. Yes, I agree. I am cross-posting this to pppext. For their benefit, we are discussing the current ROHC-over-PPP draft (draft-ietf-rohc-over-ppp-01.txt), which borrows the following text from RFC 2509: NOTE: The specification of link and network layer parameter negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not prohibit multiple instances of one configuration option but states that the specification of a configuration option must explicitly allow multiple instances. From the current specification of the IPCP IP-Compression-Protocol configuration option [RFC1332, p 6] it follows that it can only be used to select a single compression protocol at any time. We seem to have identified a requirement to support multiple compression protocols in parallell over PPP. Any opinions? Also, I think that this draft is likely to be implemented first by those connecting to a 3GPP2 network. In this case both ends of the PPP will probably be implemented by vendors who are aware of the special characteristics of our link layer (multiple channels, etc). Especially if someone is implementing ROHC-over-PPP, it seems they could make this change to their PPP implementation at the same time (which is why this draft is the logical place to make the change). CB> Gruesse, Carsten CB> PS.: Pete, I apologize for being slow answering your earlier mail. No problem - I am glad we are getting the issue resolved. -Pete --4G+jTqFCzn-- From owner-ietf-ppp-outgoing@merit.edu Thu May 24 11:41:11 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15774 for ; Thu, 24 May 2001 11:41:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D1A5D5DE7A; Thu, 24 May 2001 11:41:00 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B56975DEB0; Thu, 24 May 2001 11:41:00 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id E14085DE7A for ; Thu, 24 May 2001 11:40:58 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00143; Thu, 24 May 2001 09:40:54 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26200; Thu, 24 May 2001 11:40:54 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f4OFfc218524; Thu, 24 May 2001 11:41:39 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15117.11186.665313.476556@gargle.gargle.HOWL> Date: Thu, 24 May 2001 11:41:38 -0400 (EDT) From: James Carlson To: Pete McCann Cc: ietf-ppp@merit.edu Subject: Re: forwarded message from Pete McCann In-Reply-To: Pete McCann's message of 24 May 2001 10:19:55 References: <20010524151955.E02A85701F@king.research.bell-labs.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Pete McCann writes: > NOTE: The specification of link and network layer parameter > negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not > prohibit multiple instances of one configuration option but > states that the specification of a configuration option must > explicitly allow multiple instances. From the current > specification of the IPCP IP-Compression-Protocol configuration > option [RFC1332, p 6] it follows that it can only be used to > select a single compression protocol at any time. Right. Unless there's a defined meaning, you shouldn't be doing it. > We seem to have identified a requirement to support multiple compression > protocols in parallell over PPP. Any opinions? I read through the draft several times, and I don't see the need to negotiate multiple simultaneous compression protocols. Can you explain this? (If you're referring to v4 versus v6; that's not a problem. They're negotiated using separate NCPs. Since the protocol numbers are the same for the compressed data, the receiver must allocate decompression context space equal to the maximum of both requested, but that's not the same as negotiating them together.) > Also, I think that this draft is likely to be implemented first by > those connecting to a 3GPP2 network. In this case both ends of the > PPP will probably be implemented by vendors who are aware of the > special characteristics of our link layer (multiple channels, etc). > Especially if someone is implementing ROHC-over-PPP, it seems they > could make this change to their PPP implementation at the same time > (which is why this draft is the logical place to make the change). Having domain-specific usage is doable, but probably not a good idea. It's likely to lead to interoperability problems in the future. Also, this note in the draft is puzzling: NOTE: [RFC1332] is not explicit about whether the option negotiates the capabilities of the receiver or of the sender. In keeping with current practice, we assume that the option describes the capabilities of the decompressor (receiving side) of the peer that sends the Config-Req. The assumption is correct, but completely unnecessary. RFC 1332 section 4 says this: The IP-Compression-Protocol Configuration Option is used to indicate the ability to receive compressed packets. Each end of the link must separately request this option if bi-directional compression is desired. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp-outgoing@merit.edu Thu May 24 12:07:12 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16327 for ; Thu, 24 May 2001 12:07:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CE7D35E00B; Thu, 24 May 2001 12:06:09 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 99CF15E009; Thu, 24 May 2001 12:06:08 -0400 (EDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by segue.merit.edu (Postfix) with SMTP id 03B695DFD7 for ; Thu, 24 May 2001 12:05:47 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Thu May 24 12:05:10 EDT 2001 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Thu May 24 12:05:05 EDT 2001 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 6733C57045; Thu, 24 May 2001 11:04:50 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Pete McCann To: James Carlson Cc: ietf-ppp@merit.edu, "Dr. Carsten Bormann" Subject: Re: forwarded message from Pete McCann In-Reply-To: <15117.11186.665313.476556@gargle.gargle.HOWL> References: <20010524151955.E02A85701F@king.research.bell-labs.com> <15117.11186.665313.476556@gargle.gargle.HOWL> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-Id: <20010524160451.6733C57045@king.research.bell-labs.com> Date: Thu, 24 May 2001 11:04:51 -0500 (CDT) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi, James, Thanks for the response. You are right, the draft itself does not explain the need for multiple IP-Compression protocols; this requirement is coming from 3GPP2. We are imagining situations where an endpoint might want to run ROHC for its RTP traffic, but then V-J 1144 for its TCP traffic. These would run over links with different channel characteristics but would be negotiated with a single IPCP exchange. Would you be opposed to explicitly allowing this behavior in the ROHC-over-PPP draft? If that is the consensus of pppext then we need to figure something else out. -Pete James Carlson (JC) writes: JC> Pete McCann writes: >> NOTE: The specification of link and network layer parameter >> negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not >> prohibit multiple instances of one configuration option but >> states that the specification of a configuration option must >> explicitly allow multiple instances. From the current >> specification of the IPCP IP-Compression-Protocol configuration >> option [RFC1332, p 6] it follows that it can only be used to >> select a single compression protocol at any time. JC> Right. Unless there's a defined meaning, you shouldn't be doing it. >> We seem to have identified a requirement to support multiple compression >> protocols in parallell over PPP. Any opinions? JC> I read through the draft several times, and I don't see the need to JC> negotiate multiple simultaneous compression protocols. Can you JC> explain this? JC> (If you're referring to v4 versus v6; that's not a problem. They're JC> negotiated using separate NCPs. Since the protocol numbers are the JC> same for the compressed data, the receiver must allocate decompression JC> context space equal to the maximum of both requested, but that's not JC> the same as negotiating them together.) >> Also, I think that this draft is likely to be implemented first by >> those connecting to a 3GPP2 network. In this case both ends of the >> PPP will probably be implemented by vendors who are aware of the >> special characteristics of our link layer (multiple channels, etc). >> Especially if someone is implementing ROHC-over-PPP, it seems they >> could make this change to their PPP implementation at the same time >> (which is why this draft is the logical place to make the change). JC> Having domain-specific usage is doable, but probably not a good idea. JC> It's likely to lead to interoperability problems in the future. JC> Also, this note in the draft is puzzling: JC> NOTE: [RFC1332] is not explicit about whether the option JC> negotiates the capabilities of the receiver or of the sender. JC> In keeping with current practice, we assume that the option JC> describes the capabilities of the decompressor (receiving side) JC> of the peer that sends the Config-Req. JC> The assumption is correct, but completely unnecessary. RFC 1332 JC> section 4 says this: JC> The IP-Compression-Protocol Configuration Option is used to indicate the JC> ability to receive compressed packets. Each end of the link must JC> separately request this option if bi-directional compression is desired. JC> -- JC> James Carlson, Internet Engineering JC> SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 JC> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp-outgoing@merit.edu Thu May 24 13:14:38 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17539 for ; Thu, 24 May 2001 13:14:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A99D15E1C3; Thu, 24 May 2001 13:13:56 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E171E5E039; Thu, 24 May 2001 13:13:43 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id E69825E1A7 for ; Thu, 24 May 2001 13:12:53 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18497; Thu, 24 May 2001 10:12:45 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12513; Thu, 24 May 2001 13:12:41 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f4OHDNV18620; Thu, 24 May 2001 13:13:23 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15117.16690.915587.379755@gargle.gargle.HOWL> Date: Thu, 24 May 2001 13:13:22 -0400 (EDT) From: James Carlson To: Pete McCann Cc: ietf-ppp@merit.edu, "Dr. Carsten Bormann" Subject: Re: forwarded message from Pete McCann In-Reply-To: Pete McCann's message of 24 May 2001 11:04:51 References: <20010524151955.E02A85701F@king.research.bell-labs.com> <15117.11186.665313.476556@gargle.gargle.HOWL> <20010524160451.6733C57045@king.research.bell-labs.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Pete McCann writes: > You are right, the draft itself does not explain the need for multiple > IP-Compression protocols; this requirement is coming from 3GPP2. We > are imagining situations where an endpoint might want to run ROHC for > its RTP traffic, but then V-J 1144 for its TCP traffic. If you have RFC 2507/2509 compression implemented, then why do you need VJ compression? Isn't 2507 good enough? > These would > run over links with different channel characteristics but would be > negotiated with a single IPCP exchange. > > Would you be opposed to explicitly allowing this behavior in the > ROHC-over-PPP draft? If that is the consensus of pppext then we need > to figure something else out. Not at all. I think the usage is mostly harmless, since implementations that don't support this fancy new RFC 2509 extension will be forced to either Configure-Nak or Configure-Reject it, and you could then withdraw your parallel request for RFC 1144 compression as a side-effect. It seems pretty odd, though ... -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp-outgoing@merit.edu Thu May 24 16:30:33 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20389 for ; Thu, 24 May 2001 16:30:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 541E95E6F5; Thu, 24 May 2001 15:11:14 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 575895E882; Thu, 24 May 2001 14:49:49 -0400 (EDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by segue.merit.edu (Postfix) with SMTP id 92C5D5DEC8 for ; Thu, 24 May 2001 14:29:45 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Thu May 24 14:29:31 EDT 2001 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Thu May 24 14:29:26 EDT 2001 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 007355701F; Thu, 24 May 2001 13:29:13 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Pete McCann To: James Carlson Cc: ietf-ppp@merit.edu, "Dr. Carsten Bormann" Subject: Re: forwarded message from Pete McCann In-Reply-To: <15117.16690.915587.379755@gargle.gargle.HOWL> References: <20010524151955.E02A85701F@king.research.bell-labs.com> <15117.11186.665313.476556@gargle.gargle.HOWL> <20010524160451.6733C57045@king.research.bell-labs.com> <15117.16690.915587.379755@gargle.gargle.HOWL> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-Id: <20010524182914.007355701F@king.research.bell-labs.com> Date: Thu, 24 May 2001 13:29:14 -0500 (CDT) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi, James, James Carlson (JC) writes: JC> If you have RFC 2507/2509 compression implemented, then why do you JC> need VJ compression? Isn't 2507 good enough? One could ask the same question about 2507 and ROHC-RTP running in parallel. The point is that ROHC is in a state today where it works for RTP flows, but TCP flows are still a work in progress. Also, it is not clear to me that we need a "robust against loss" TCP-compression scheme because these flows should be taken over reliable links in the first place. More ARQ or better channel coding will be used to increase the reliability underneath IP in these cases. So, we have 1144 and 2507 that work today, we just need a mechanism to invoke them at the same time as ROHC. >> These would >> run over links with different channel characteristics but would be >> negotiated with a single IPCP exchange. >> >> Would you be opposed to explicitly allowing this behavior in the >> ROHC-over-PPP draft? If that is the consensus of pppext then we need >> to figure something else out. JC> Not at all. I think the usage is mostly harmless, since JC> implementations that don't support this fancy new RFC 2509 extension JC> will be forced to either Configure-Nak or Configure-Reject it, and you JC> could then withdraw your parallel request for RFC 1144 compression as JC> a side-effect. Ok, sounds good. JC> It seems pretty odd, though ... Yes, it is odd. These wireless links are going to be strange beasts. -Pete From owner-ietf-ppp-outgoing@merit.edu Fri May 25 08:21:03 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15949 for ; Fri, 25 May 2001 08:21:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD6625E4A6; Fri, 25 May 2001 08:18:56 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C76765E4C2; Fri, 25 May 2001 08:18:54 -0400 (EDT) Received: from relay4.ftech.net (ibm6.ftech.net [212.32.16.76]) by segue.merit.edu (Postfix) with ESMTP id DA4EA5E498 for ; Fri, 25 May 2001 08:18:44 -0400 (EDT) Received: from ibm9.ftech.net ([212.32.16.79] helo=hardy.farsite.co.uk) by relay4.ftech.net with esmtp (Exim 3.22-ftech-p6.1 #2) id 153GYE-0004yW-00; Fri, 25 May 2001 13:18:42 +0100 Received: by HARDY with Internet Mail Service (5.5.2650.21) id ; Fri, 25 May 2001 13:10:33 +0100 Message-ID: From: Jonathan Goodchild To: "'Pete McCann'" Cc: "'ietf-ppp@merit.edu'" Subject: RE: ROHC-over-PPP Date: Fri, 25 May 2001 13:10:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Pete McCann writes: > it is not clear to me that we need a "robust against loss" > TCP-compression scheme because these flows should be taken over > reliable links in the first place. I don't think that is the case at all - Vernon Schryver made the exact opposite point quite recently: ] .. bad things happen with necessarily smart link layers such as ] TCP/IP/wireless-modems, where the wireless links do retransmissions. ] There are Internet Drafts that discuss these issues in ] http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-05.txt ] http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-06.txt and ] http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-05.txt Funnily enough, I was at a meeting this morning at which I argued that supporting PDCP (3GPP TS 25.323) over acknowledged mode RLC was a waste of time, whilst the only traffic types defined for PDCP are PPP and IP. It seems to me that a "robust against packet loss" (and what's more, silent packet loss) TCP-compression scheme is highly desirable. -- Jonathan Goodchild FarSite Communications From owner-ietf-ppp-outgoing@merit.edu Fri May 25 19:44:01 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27401 for ; Fri, 25 May 2001 19:44:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BAC415EDB1; Fri, 25 May 2001 18:18:27 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 56A665EE07; Fri, 25 May 2001 16:42:53 -0400 (EDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by segue.merit.edu (Postfix) with SMTP id 7424D5EA84 for ; Fri, 25 May 2001 15:51:47 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri May 25 15:51:01 EDT 2001 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Fri May 25 15:50:57 EDT 2001 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 755C95701F; Fri, 25 May 2001 14:50:44 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Pete McCann To: Jonathan Goodchild Cc: "'ietf-ppp@merit.edu'" Subject: RE: ROHC-over-PPP In-Reply-To: References: X-Mailer: VM 6.33 under Emacs 19.34.2 Message-Id: <20010525195044.755C95701F@king.research.bell-labs.com> Date: Fri, 25 May 2001 14:50:44 -0500 (CDT) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi, Not sure this is the right list (these are really PILC-ROHC issues) but I wanted to respond here. Jonathan Goodchild (JG) writes: JG> ] .. bad things happen with necessarily smart link layers such as JG> ] TCP/IP/wireless-modems, where the wireless links do retransmissions. JG> ] There are Internet Drafts that discuss these issues in JG> ] http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-05.txt JG> ] http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-06.txt and JG> ] http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-05.txt It is certainly true that too much link-layer retransmission can interact badly with TCP, but without any way of increasing the reliability of the raw wireless channel, the IP-layer "goodput" will be terrible and end-to-end performance will suffer. This is not at all inconsistent with the above drafts or this one: draft-ietf-pilc-link-arq-issues-01.txt These documents points out that (low persistency) link-layer reliability mechanisms can improve end-to-end performance, especially when frame sizes are small and raw frame error rates are high. JG> Funnily enough, I was at a meeting this morning at which I argued that JG> supporting PDCP (3GPP TS 25.323) over acknowledged mode RLC was a waste of JG> time, whilst the only traffic types defined for PDCP are PPP and IP. JG> It seems to me that a "robust against packet loss" (and what's more, silent JG> packet loss) TCP-compression scheme is highly desirable. Once a certain amount of link-layer retransmission is done, it is not clear to me what the benefit of "robust against packet loss" TCP header compression will be. With 2 or 3 retransmissions, it is possible to get the wireless link packet errors down to ranges comparable to wired links. If that can be done without introducing an amount of delay that will trigger TCP badness, then I see little reason to spend time and effort on robust TCP compression. Of course, if someone can show me simulations that say it can't be done, I might be willing to change my mind. -Pete From owner-ietf-ppp-outgoing@merit.edu Sun May 27 14:58:03 2001 Received: from segue.merit.edu ([198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11412 for ; Sun, 27 May 2001 14:58:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A3C7A5DEFB; Sun, 27 May 2001 14:56:45 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9B5345DE90; Sun, 27 May 2001 14:56:31 -0400 (EDT) Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A5F8E5DEF2 for ; Sun, 27 May 2001 14:56:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id LAA46802; Sun, 27 May 2001 11:46:32 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sun, 27 May 2001 11:46:31 -0700 (PDT) From: Bernard Aboba To: ietf-ppp@merit.edu Cc: aboba@internaut.com Subject: EAP Draft Standard application? In-Reply-To: <20010524160451.6733C57045@king.research.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu With a number of EAP implementations now shipping or in the works, it has been suggested that it would be appropriate to take EAP to Draft Standard. As part of the draft standard process, it is necessary to come up with a list of implementations and what portions of RFC 2284 are supported. If you have an EAP implementation for any media, can you please post some basic info to the list? I'll have a full draft-standard questionairre available later. Also, it has been suggested that an RFC 2284bis document be produced in the process to document those portions of RFC 2284 that qualify for draft standard, and also to clarify points of confusion in RFC 2284. If you have any points of confusion in RFC 2284 which need resolution, please post these as well. Some of those we already have are given below. =========== Issues for resolution in RFC 2284bis ==================== a. Is it possible to do more than one EAP authentication in sequence? b. Is it possible to place data in an EAP-Success or EAP-Failure? c. What about media in which alternative failure/success indications are unavailable? d. What about media in which EAP messages can be duplicated? Received out of order? e. What does an authenticator do if it receives an EAP-Response to an EAP-Failure or Success? From owner-ietf-ppp@merit.edu Tue May 29 21:19:53 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13542 for ; Tue, 29 May 2001 21:19:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CEF129126B; Tue, 29 May 2001 21:19:42 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2CDC9126D; Tue, 29 May 2001 21:19:42 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B10669126B for ; Tue, 29 May 2001 21:19:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45C365DE05; Tue, 29 May 2001 21:19:50 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from fs-sd-exch2.coppermountain.com (fs-sd-exch2.coppermountain.com [209.246.224.234]) by segue.merit.edu (Postfix) with ESMTP id B14B45DDF1 for ; Tue, 29 May 2001 21:19:49 -0400 (EDT) Received: by fs-sd-exch2.coppermountain.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 May 2001 18:20:16 -0700 Message-ID: <583EFB625043D511920400D0B74178C8347CE1@fs-sd-exch2.coppermountain.com> From: emichelsen@coppermountain.com To: ietf-ppp@merit.edu Subject: RE: ROHC-over-PPP Date: Tue, 29 May 2001 18:20:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I think this is a good point: it's not retransmission that's bad; it's *slow* retransmission that's bad. Fast retransmission appears to an upper layer as a small amount of delivery jitter, something that's been present since Ethernet has been around. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: Pete McCann [mailto:mccap@research.bell-labs.com] > Sent: Friday, May 25, 2001 12:51 > To: Jonathan Goodchild > Cc: 'ietf-ppp@merit.edu' > Subject: RE: ROHC-over-PPP > > > > Hi, > > Not sure this is the right list (these are really PILC-ROHC > issues) but > I wanted to respond here. > > Jonathan Goodchild (JG) writes: > > JG> ] .. bad things happen with necessarily smart link layers such as > JG> ] TCP/IP/wireless-modems, where the wireless links do > retransmissions. > JG> ] There are Internet Drafts that discuss these issues in > JG> ] http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-05.txt > JG> ] > http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-06.txt and > JG> ] > http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-05.txt > > It is certainly true that too much link-layer retransmission can > interact badly with TCP, but without any way of increasing the > reliability of the raw wireless channel, the IP-layer "goodput" will > be terrible and end-to-end performance will suffer. This is not at > all inconsistent with the above drafts or this one: > > draft-ietf-pilc-link-arq-issues-01.txt > > These documents points out that (low persistency) link-layer > reliability mechanisms can improve end-to-end performance, especially > when frame sizes are small and raw frame error rates are high. > > JG> Funnily enough, I was at a meeting this morning at which > I argued that > JG> supporting PDCP (3GPP TS 25.323) over acknowledged mode > RLC was a waste of > JG> time, whilst the only traffic types defined for PDCP are > PPP and IP. > > JG> It seems to me that a "robust against packet loss" (and > what's more, silent > JG> packet loss) TCP-compression scheme is highly desirable. > > Once a certain amount of link-layer retransmission is done, it is not > clear to me what the benefit of "robust against packet loss" TCP > header compression will be. With 2 or 3 retransmissions, it is > possible to get the wireless link packet errors down to ranges > comparable to wired links. If that can be done without introducing an > amount of delay that will trigger TCP badness, then I see little > reason to spend time and effort on robust TCP compression. Of course, > if someone can show me simulations that say it can't be done, I might > be willing to change my mind. > > -Pete > > > > >