

--Boundary_(ID_kYnTmoOgCoTGeDBshpQ1aw)--
>From [email-masked] Wed May 24 15:22:53 2006
Date: Wed, 24 May 2006 10:58:25 +0530
From: "Syam Madanapalli" <[email-masked]>
To: [email-masked]
Subject: Re: [16ng] Fw: I-D ACTION:draft-iab-link-encaps-00.txt

Now I see the problems with multiple Convergence Sublayers in 802.16.

But I have a couple of comments.

1. The document seems to be assumed that  802.16 PHY link supports broadcast,
so the problems arises if a host sends a broadcast message with a particular CS
type and the another host supporting another type of CS may not be able to
receive it.

I think 802.16 is an interface between the Host and Base Station. If tow hosts
with 802.16 i/f wants to communicate, there will be two disjoint
connections, one
between MS1 and BS and another between BS and MS2. In such scenario I do
not see any problem for the two MSs to communicate each other as long as BS
implements the both CSs.

But the problem still remains, for down link multicast which requires
at least one
common type of CS supported by the all hosts attached to a base station.

2. The recommendations seems to be favoring the support for Ethernet CS.

.....
  it has been argued that IEEE 802 or Ethernet
   encapsulation of IP result in excessive overhead due to the size of
   the data frame headers, and that this can adversely affect
   performance on wireless networks, particularly in situations where
   support of Voice over IP (VOIP) is required.  However, even where
   these performance concerns are valid, solutions exist that do not
   require defining multiple IP encapsulation methods.  For example,
   links may support Ethernet frame compression so that Ethernet Source
   and Destination Address fields are not sent with every packet.
......

The question I am getting here is, I think we are creating a problem
(use of extra
Ethernet header with out any purpose (?)) and then solving it (with Header
compression).

Nonetheless I believe having multiple CSs on same link is harmful and hosts
must support at least one common CS.

Thanks,
Syam

On 5/24/06, Soohong Daniel Park <[email-masked]> wrote:
> fyi...
>
> Special thanks to Bernard for his quick contribution...:-)
>
> > Title : Multiple Encapsulation Methods Considered Harmful
> > Author(s) : B. Aboba, et al.
> > Filename : draft-iab-link-encaps-00.txt
> > Pages : 15
> > Date : 2006-5-23
> >
> > This document describes architectural and operational issues that
> > arise from link layer protocols supporting multiple Internet Protocol
> > encapsulation methods.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-iab-link-encaps-00.txt
>
>
>
> Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, SAMSUNG Electronics.
>
>
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>
>
>
>
>From [email-masked] Wed May 24 16:32:01 2006
Date: Wed, 24 May 2006 15:37:41 +0900
From: Soohong Daniel Park <[email-masked]>
Subject: Re: [16ng] Fw: I-D ACTION:draft-iab-link-encaps-00.txt
To: Syam Madanapalli <[email-masked]>, [email-masked]

Syam - I didn't go through this document yet. But in fact,
16ng should make lots of comments on this document wrt 
802.16 stuff to make it more sharp. Also, this concern might 
be included into the 16ng deliverables especially, "problem, 
goal and req." or "deployment scenario and consideration"
as well. IAB's effort is for a good initiative. Further works
will be done in this room hopefully...:-)

Cheers.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

----- Original Message ----- 
From: "Syam Madanapalli" <[email-masked]>
To: <[email-masked]>
Cc: "Soohong Daniel Park" <[email-masked]>
Sent: Wednesday, May 24, 2006 2:28 PM
Subject: Re: [16ng] Fw: I-D ACTION:draft-iab-link-encaps-00.txt

> Now I see the problems with multiple Convergence Sublayers in 802.16.
> 
> But I have a couple of comments.
> 
> 1. The document seems to be assumed that  802.16 PHY link supports broadcast,
> so the problems arises if a host sends a broadcast message with a particular CS
> type and the another host supporting another type of CS may not be able to
> receive it.
> 
> I think 802.16 is an interface between the Host and Base Station. If tow hosts
> with 802.16 i/f wants to communicate, there will be two disjoint
> connections, one
> between MS1 and BS and another between BS and MS2. In such scenario I do
> not see any problem for the two MSs to communicate each other as long as BS
> implements the both CSs.
> 
> But the problem still remains, for down link multicast which requires
> at least one
> common type of CS supported by the all hosts attached to a base station.
> 
> 2. The recommendations seems to be favoring the support for Ethernet CS.
> 
> .....
>  it has been argued that IEEE 802 or Ethernet
>   encapsulation of IP result in excessive overhead due to the size of
>   the data frame headers, and that this can adversely affect
>   performance on wireless networks, particularly in situations where
>   support of Voice over IP (VOIP) is required.  However, even where
>   these performance concerns are valid, solutions exist that do not
>   require defining multiple IP encapsulation methods.  For example,
>   links may support Ethernet frame compression so that Ethernet Source
>   and Destination Address fields are not sent with every packet.
> ......
> 
> The question I am getting here is, I think we are creating a problem
> (use of extra
> Ethernet header with out any purpose (?)) and then solving it (with Header
> compression).
> 
> Nonetheless I believe having multiple CSs on same link is harmful and hosts
> must support at least one common CS.
> 
> Thanks,
> Syam
> 
> 
> On 5/24/06, Soohong Daniel Park <[email-masked]> wrote:
>> fyi...
>>
>> Special thanks to Bernard for his quick contribution...:-)
>>
>> > Title : Multiple Encapsulation Methods Considered Harmful
>> > Author(s) : B. Aboba, et al.
>> > Filename : draft-iab-link-encaps-00.txt
>> > Pages : 15
>> > Date : 2006-5-23
>> >
>> > This document describes architectural and operational issues that
>> > arise from link layer protocols supporting multiple Internet Protocol
>> > encapsulation methods.
>> >
>> >
>> > A URL for this Internet-Draft is:
>> > http://www.ietf.org/internet-drafts/draft-iab-link-encaps-00.txt
>>
>>
>>
>> Daniel (Soohong Daniel Park)
>> Mobile Convergence Laboratory, SAMSUNG Electronics.
>>
>>
>> _______________________________________________
>> 16ng mailing list
>> [email-masked]
>> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>>
>>
>>
>>
> 
>
>From [email-masked] Fri May 26 06:49:26 2006
Date: Thu, 25 May 2006 23:55:32 +0300
From: Jari Arkko <[email-masked]>
To: [email-masked]
Subject: [16ng] 16ng WG approval process

Hi all,

The IESG has discussed the 16ng WG approval. There are
two remaining issues to deal with:

1. Getting to a final consensus on what the charter should
    say about the multiple CSes (all PS/some info, some
    mandatory, etc.). I will send a separate e-mail about this.

2. Review from IEEE 802.16. We have received a request
    from the 802.16 to allocate time so that they can arrange
    for a review of the proposed charter. As soon as I learn
    what the time frame for that will be I will let you know.

--Jari