Subject: RE: [PWE3] RE: [AVT] Re: Header Compression over MPLS & Allison'sDISCUSS Commenton PWE3 IANA Allocation Draft

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 24 Oct 2005 07:02:49 +0200

> > ROHC (RFC3095) -- encourage
> > eCRTP (RFC3545)-- encourage
> 
> So would the plan be to leave the above registry entries in 
> the IANA draft and delete the other three?
> 
> - Stewart

No, I don't see that as a reasonable compromise.

cRTP is what is presently implemented,
and there is a lot of reluctance to go over to ECRTP.

Although the problems relating to cRTP relating to packet loss
are real, the fact that the PW goes through multiple hops
is unimportant and should not by itself cause cRTP or cTCP to break, 
as the PW looks like a single link to the endpoints.

So I would suggest either :

1) removing the lot and allocating
either when the full documentation is ready
or when usage requires

2) leaving all (does anyone need IPHC?)
and possibly later deprecating any for
which there is no demand.

Y(J)S

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Allison Mankin <[email-masked]>
Date: Sun, 23 Oct 2005 22:25:57 -0700

Yaakov,

> as the PW looks like a single link to the endpoints.

Multihop is concealed by a tunnel, yes, but it causes
the extra lossiness and delay that brings out the problems
eCRTP was engineered for.

May I ask:  why is the troublesome behavior of
CRTP acceptable and the performance of eCRTP not sought?
The loss effects mean resetting the compressor at least
and poor compression, and possibly other defects.

eCRTP has been in out there for quite a while now.
RFC 3545 was published July 2003, approved at least six
months earlier.

I'm just eager to learn at this point.

And this requires a bit more stretching to teach people, but
it is something of interest:

 "cRTP is what is presently implemented"

 "there is a lot of reluctance to go over to ECRTP""

What kind of implementation base are you describing?  If it
is implementation of Jerry's/AVT's solution for voice, that is not
so close to completion, so I think the implementations should
not be gelling, but it's better for us to know what these issues
are.

Allison

---

From: "Hand, James C, ALABS" <[email-masked]>
Date: Mon, 24 Oct 2005 08:29:35 -0500

> -----Original Message-----
> From: Allison Mankin [mailto:[email-masked]]
> Sent: Monday, October 24, 2005 1:26 AM
> To: Yaakov Stein
> Cc: Stewart Bryant; Ash, Gerald R (Jerry), ALABS; pwe3; [email-masked]
> Subject: Re: [PWE3] RE: [AVT] Re: Header Compression over MPLS &
> Allison'sDISCUSS Commenton PWE3 IANA Allocation Draft 
> 

> and poor compression, and possibly other defects.

A couple of things.  First, if you're using cRTP for VoIP, then things
are probably engineered so that there is negligible packet loss due to
congestion.  So you're left with packet loss due to corruption/noise.
And in the wireless environments that are most susceptible to packet
corruption, I suspect that they may be using RoHC, or possibly other
schemes (I am not working in that environment, so I can't say for sure).

In the evironments in which I've had to do voice quality
troubleshooting, while I've sometimes suspected that the cRTP packet
loss multiplication effect had a significant impact on voice quality,
I've never been able to show this conclusively. It's even sometimes
difficult to discover if burst VoIP loss is occuring: it does not show
up in the CDR records of most equipment that I've worked with.  The one
place I've run into in which intermittent packet loss seems to give us
trouble is on terrestrial microwave links, and they are subject to burst
corruption loss anyway, so it's difficult to determine the extent to
which cRTP loss multiplication may be exacerbating the problem.

>  "there is a lot of reluctance to go over to ECRTP""

I have not seen reluctance, just lack of demand.  And from what we've
seen so far, even if ECRTP were widely available, and the implementation
was essentially free, we might only use it in very specific environments
unless there was little or no increase in CPU load vice cRTP.
Particularly if we have to do compression/decompression hop-by-hop.

> Allison

Thanks,
Jim Hand
[email-masked]
732-420-3017