[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PWE3] RE: [rohc] RE: Header Compression over MPLS & Allison's DISCUSS Commenton PWE3 IANA Allocation Draft
Hi 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.
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.
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 adaptions (*) 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..."
BR,
Kristofer
> -----Original Message-----
> From: rohc-bounces at ietf.org [mailto:rohc-bounces at ietf.org] On
> Behalf Of Ash, Gerald R (Jerry), ALABS
> Sent: Monday, October 24, 2005 1:02 PM
> To: Stewart Bryant
> Cc: Ash, Gerald R (Jerry), ALABS; rohc at ietf.org; pwe3; IETF
> AVT WG; Allison Mankin
> Subject: [rohc] RE: Header Compression over MPLS & Allison's
> DISCUSS Commenton PWE3 IANA Allocation Draft
>
> Stewart,
>
> > > 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?
>
> Yes, I think that is Allison's suggestion.
>
> I've suggested that cRTP and IPHC be proposed as
> to-be-assigned in the header compression over MPLS protocol
> draft pending consensus to include them.
>
> Thanks,
> Jerry
>
> _______________________________________________
> Rohc mailing list
> Rohc at ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
>
_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3