[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