The IP over ATM Mailing List Archive by date

[Tim Dwight <0006078043@mcimail.com>]

Curtis:

What I was attempting to propose, should have nothing to do with TCP.
All the fields proposed to be compressed, are at the IP layer.  I was
imagining both ATM VCC's between routers (where relatively little 
IP header compression might be possible) and ATM VCC's between hosts
(where more could be compressed, e.g., the destination address).  That's
the reason for proposing the negotiation of compressable-fields, at
VCC establishment.

I apologize if I've re-invented something the group has already abandoned,
and if I've been less than clear.

Best Regards,

Tim Dwight
MCI

-------------------------------------------
> 
> In message <42951021061324/0006078043DC3EM@MCIMAIL.COM>, Tim Dwight writes:
> > There is always the option of defining a "service specific convergence
> > sublayer (SSCS)", which could strip off information made redundant
> > by the connection-oriented nature of ATM, at the sending side, and
> > put it back in on the receiving side.  This might include:
> > 
> >      - protocol version    ( 4 bits)
> >      - header length       ( 4 bits)  // optional
> >      - type of service     ( 8 bits)  // optional
> >      - header checksum     (16 bits)
> >      - destination address (32 bits)  // optional
> > 
> > This list is probably flawed, but it's a rough estimate to get the
> > ball rolling.  Some of these may never need to be transported over
> > an ATM VCC, others may be excludable only in some configurations. 
> > For example, the destination address may be excludable if the VCC 
> > terminates at a host which does not perform IP routing.  The TOS field
> > may be excluded if the sender (and anybody whose datagrams may be routed
> > by the sender) doesn't support it.
> > 
> > In the ATM connection setup, at the SSCS layer of the AAL, we could
> > negotiate which header fields are to be carried.  Those not carried,
> > would either have to have default values, value-to-use conveyed in the
> > signaling, or be re-creatable at the destination.   I favor the latter
> > 2 options more than the first, but list it for completeness.
> 
> This assumes one flow per VC.  It is essentially TULIP/TUNIC.  I think
> that died a long time ago since one flow per VC is a very unsafe
> assumption for TCP traffic and the setup load to make that true would
> far outweigh the gains for most TCP flows.
> 
> VJ compression assumes a low number of flows (256?), but allows more
> than 1.  This might be useful for low speed ATM.  Additional VC can be
> setup if there are more than 256 flows between two points and
> compression is needed.
> 
> > FYI, the SSCS is a sub-sub-layer of the ATM Adaptation Layer.  AAL
> > is divided into the convergence sublayer and the segmentation/reassembly
> > sublayer.  The convergence sublayer is further divided into service-specific
> > (SSCS) and common part (CPCS).  Most applications use the 'NULL' SSCS;
> > i.e., they don't use one.  Frame Relay has one, I think.
> > 
> > Tim Dwight
> > MCI
> 
> I only see this as potentially useful for ATM over low speed links.
> Keep in mind no one does this except over very slow links.
> 
> Curtis