[PWE3] RE: Header Compression over MPLS & Allison's DISCUSS Comment on PWE3 IANA Allocation Draft

["Ash, Gerald R \(Jerry\), ALABS" <gash at att.com>]

Hi Kristofer, All,

> I must admit that I'm confused by this discussion. After 
> browsing the draft in question, I don't see why you would
> need separate code points for CRTP, ECRTP & IPHC.
> 
> After all, you will be separating them via the "PW Control 
> Octet", and since they share identifier space there, I don't 
> see why they can't share that at the signalling as well (i.e. 
> the code points being discussed).
> 
> Since you are using the 3544 negotiation, you can still 
> decide which of the schemes to use separately, so I think 
> they should share a code point (disclaimer: I know nothing 
> about how the pwe3 works).
> 
> So, I'd like to see:
> OLD:
>    0x001B  cTCP [RFC1144] Transport Header-compressed Packets
>    0x001C  IPHC [RFC2507] Transport Header-compressed Packets
>    0x001D  cRTP [RFC2508] Transport Header-compressed Packets
>    0x001E  ROHC [RFC3095] Transport Header-compressed Packets
>    0x001F  ECRTP [RFC3545] Transport Header-compressed Packets
> NEW:
>    0x001C  IPHC/CRTP/ECRTP
>    0x001E  ROHC [RFC3095] Transport Header-compressed Packets
> 
> Which should work as well as the current allocation.

Your suggestion looks good to us, since we can distinguish between
header compression schemes PW Control Octet in the header and/or the RFC
3544 negotiation.  It would be good to see what others think in view of
the earlier proposals for separate code points for each HC scheme:
http://www1.ietf.org/mail-archive/web/pwe3/current/msg07064.html
http://www1.ietf.org/mail-archive/web/pwe3/current/msg07066.html
 
> As note, I removed 1144, and I think that one is highly 
> unsuitable. Just the fact that it does not handle TCP 
> Timestamps makes it quite a poor option today.

Agreed.
 
> Regarding banning IPHC/CRTP:
> If they can share code points, I think banning these schemes is just
> silly. Better to write some short text to warn about the risks and
> say that CRTP is not recommended on certain links. Regarding IPHC,
> as has already been pointed out, the COMPRESSED_NONTCP is a robust
> packet format, but we should not forget that one can also run
> TCP_NODELTA packets, and also read section 11.2 which provides
> optional means to improve further on this for TCP streams. Perhaps
> it could be useful to specify means for using this packet sequence
> number so that IPHC can be used to its full extent on these links?
> 
> So, a short section on the possible downsides involved in using
> each scheme over reordering/lossy links and suggested implementation
> adaptations 
> (*) is the only thing I think would be needed to allow all the
> schemes to be used in this case.
> 
> (*) "...IPHC should use TCP_NODELTA, ECRTP should send absolute
> values, ROHC should be adapted as in rohc-over-reordering yada yada
> in case of reordering channels..."

Agree with this approach, thanks for the suggestions.

Regards,
Jerry

_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3