Subject: forwarded message from Pete McCann

From: Pete McCann <[email-masked]>
Date: Thu, 24 May 2001 10:19:55 -0500 (CDT)

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

Subject: RE: [rohc] ROHC-over-PPP
From: Pete McCann <[email-masked]>
To: "Dr. Carsten Bormann" <[email-masked]>
Cc: "ROHC Mailing List" <[email-masked]>, [email-masked]

Hi, Carsten,

"Dr. Carsten Bormann" <[email-masked]> (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

---

From: James Carlson <[email-masked]>
Date: Thu, 24 May 2001 11:41:38 -0400 (EDT)

>         select a single compression protocol at any time.

Right.  Unless there's a defined meaning, you shouldn't be doing it.

> 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.)

> (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       <[email-masked]>
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: Pete McCann <[email-masked]>
Date: Thu, 24 May 2001 11:04:51 -0500 (CDT)

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 <[email-masked]> (JC) writes:

>> select a single compression protocol at any time.

JC> Right.  Unless there's a defined meaning, you shouldn't be doing it.

>> 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.)

>> (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       <[email-masked]>
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: James Carlson <[email-masked]>
Date: Thu, 24 May 2001 13:13:22 -0400 (EDT)

Pete McCann writes:
> 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

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 ...

---

From: Pete McCann <[email-masked]>
Date: Thu, 24 May 2001 13:29:14 -0500 (CDT)

Hi, James,

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.

>> 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: Bernard Aboba <[email-masked]>
Date: Sun, 27 May 2001 11:46:31 -0700 (PDT)

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?