Subject: [Softwires] [softwire] Merged version of lightweight 4over6

From: Qiong <[email-masked]>
Date: Sat, 4 Feb 2012 23:40:55 +0800

Dear all,

We have published a merged version of lightweight 4over6 in:
http://www.ietf.org/internet-drafts/draft-cui-softwire-b4-translated-ds-lite-05.txt.

This mechanism moves the translation function from the tunnel concentrator
(AFTR) to initiators (B4s), and hence reduces the mapping scale on the
concentrator to per-subscriber level.

It has got wilely support in the last Taipei IETF meeting, and the only
action we need to do is to merge I-D.cui-softwire-b4-translated-ds-lite
and I-D.zhou-softwire-b4-nat into one draft.

Now that the merge work has done, from the authors of this document's view,
it is ready to be adopted as working group document. We would be
appreciated to have your comments.

Thanks in advance !

Best wishes

Qiong

---

From: "Eleven Fu(Yu)" <[email-masked]>
Date: Wed, 08 Feb 2012 02:31:59 +0000

Hi  Qiong,

     I think the merged version of this draft is mature to be adopted as WG document.  So I support WG adoption for this draft.

Cheers

Yu

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qiong
Sent: Saturday, February 04, 2012 11:41 PM
To: [email-masked]
Subject: [Softwires] [softwire] Merged version of lightweight 4over6

Dear all,

This mechanism moves the translation function from the tunnel concentrator (AFTR) to initiators (B4s), and hence reduces the mapping scale on the concentrator to per-subscriber level.

It has got wilely support in the last Taipei IETF meeting, and the only action we need to do is to merge I-D.cui-softwire-b4-translated-ds-lite
and I-D.zhou-softwire-b4-nat into one draft.

Now that the merge work has done, from the authors of this document's view, it is ready to be adopted as working group document. We would be appreciated to have your comments.

Thanks in advance !

Best wishes

Qiong

---

From: Maoke <[email-masked]>
Date: Wed, 15 Feb 2012 16:38:36 +0900

sp. the merged document meets the requirements where flexible dynamic IPv4
address sharing in IPv6 domain and meanwhile 1) considerably reduces the
states that the AFTR needs to handle; 2) reduces the overload of AFTR
through distributing the NAT functionality over Initiators.

i think the document is ready for WG adoption.

a further discussion is: DS-Lite (RFC6333) states some limitations related
to the potentially high burden of AFTR. as i understand, there are at least
two:
1) for fragmentation and reassembly (RFC6333, sec 5.3, sec 6.3), it is
required to reassembly before the decapsulation. DS-Lite states because of
the high buffer requirements, AFTR doesn't do the reassembly but only B4 do
that. it is reasonable in the case of client/server communications where
large datagrams happen often in the inbound. however, it implies that
DS-Lite is not very suitable for the p2p communications where outbound
datagram might be large as well.
2) on the issue of ALG (RFC6333, sec 8.3), it is stated that DS-Lite AFTR
doesn't do ALG for any applications. thus some applications might be
impacted.

my question is: can lightweight 4over6 improve 1) and 2) because the AFTR
load has been enlighted? if so, i suggest the author to state the
improvement of releasing the limitations.

regards,
maoke

2012/2/5 Qiong <[email-masked]>

> Now that the merge work has done, from the authors of this document's
> view, it is ready to be adopted as working group document. We would be
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 15 Feb 2012 09:21:48 +0100

2012-02-15 à 08:38, Maoke :

> sp. the merged document meets the requirements where flexible dynamic IPv4 address sharing in IPv6 domain and meanwhile 1) considerably reduces the states that the AFTR needs to handle; 2) reduces the overload of AFTR through distributing the NAT functionality over Initiators. 
> 

Because Lightweight 4over6 permits AFTRs to be stateful per customer but stateless per flow, it fills a gap between DS-lite (whose AFTRs are stateful per flow) and currently discussed solutions that are stateless per customer (MAP-T, MAP-E, 4rd-U ). 

=> +1

RD

---

From: buptnoc <[email-masked]>
Date: Thu, 16 Feb 2012 00:02:50 +0800

sp.

The merged version of lightweight 4over6 is ready for WG adoption.

zhaoqin

BUPT

于 2012-2-4 23:40, Qiong 写道:

Dear all,

This mechanism moves the translation function from the tunnel
concentrator (AFTR) to initiators (B4s), and hence reduces the
mapping scale on the concentrator to per-subscriber level.

It has got wilely support in the last Taipei IETF meeting, and the
only action we need to do is to merge
I-D.cui-softwire-b4-translated-ds-lite

Now that the merge work has done, from the authors of this
document's view, it is ready to be adopted as working group
document. We would be appreciated to have your comments.

Thanks in advance !

Best wishes

Qiong

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 15 Feb 2012 19:55:22 +0000

Hi Maoke,

For 1, it is not a ds-lite problem but a general problem for any tunneling
protocol. Once option is the 4o6 TC passes the fragmented packets and hope
the destination would reassemble them. This option would break the
end-to-end model if the destination rejects fragmented packets. The current
model in RFC6333 will not in exchange with extra CPU and buffer overhead.

For 2, we can mention ALG could be implemented in the 4o6 TI. We still want
to keep the 4o6 TC simple.

Thanks,
Yiu

From:  Maoke <[email-masked]>
Date:  Wed, 15 Feb 2012 16:38:36 +0900
To:  Qiong <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [Softwires] [softwire] Merged version of lightweight 4over6

regards,
maoke

> It has got wilely support in the last Taipei IETF meeting, and the only action
> we need to do is to merge I-D.cui-softwire-b4-translated-ds-lite
> Now that the merge work has done, from the authors of this document's view, it
> is ready to be adopted as working group document. We would be appreciated to
> have your comments.
> 
> Thanks in advance !
> 
> Best wishes
> 
> Qiong
> 
> 
>  
> 
> 
> 

_______________________________________________ Softwires mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/softwires

---

From: Maoke <[email-masked]>
Date: Thu, 16 Feb 2012 11:50:33 +0900

hi Yiu,

thanks for the explanation.

2012/2/16 Lee, Yiu <[email-masked]>

> model in RFC6333 will not in exchange with extra CPU and buffer overhead.
got it. this point is fine. and i also mean that DS-Lite states (Sec 6.3):

   This reassembly process will significantly
   impact the AFTR's performance. However, this impact only happens
   when many clients simultaneously source large IPv4 packets. Since we
   believe that the majority of the clients will receive large IPv4
   packets (such as watching video streams) instead of sourcing large
   IPv4 packets (such as sourcing video streams), reassembly is only a
   fraction of the overall AFTR's workload.

the "since we believe" is true in the term that client/server model is
dominating the Internet usage. but the situation is changing, AFTR might
suffer a heavy burden with reassembly in the environment where p2p is
dominating. can we (actually you authors) surely state lightweight 4over6
improves this? if we can, it is a happy point. ;-)

best,
maoke

> For 2, we can mention ALG could be implemented in the 4o6 TI. We still
> want to keep the 4o6 TC simple.
>
> Thanks,
> Yiu
>
>> concentrator (AFTR) to initiators (B4s), and hence reduces the mapping
>> scale on the concentrator to per-subscriber level.
>>

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 16 Feb 2012 03:56:57 +0000

Hi Maoke,

There are always trade-offs. We can suggest few options and ask the WG to
choose one. 

1) Let the host to reassemble the fragmented packets
2) Let the 4o6 TC to assemble the fragmented packets
3) Don¹t suggest anything and leave this open for implementation

/Yiu

From:  Maoke <[email-masked]>
Date:  Thu, 16 Feb 2012 11:50:33 +0900
To:  "Yiu L. LEE" <[email-masked]>
Cc:  Qiong <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [Softwires] [softwire] Merged version of lightweight 4over6

---

From: Maoke <[email-masked]>
Date: Thu, 16 Feb 2012 13:20:45 +0900

> There are always trade-offs. We can suggest few options and ask the WG to

good point. acceptable. :) - maoke

> 3) Don’t suggest anything and leave this open for implementation
>
> /Yiu
>
>

---

From: Tina TSOU <[email-masked]>
Date: Thu, 16 Feb 2012 14:06:46 +0000

Sent from my iPad

On Feb 16, 2012, at 5:21 AM, "Maoke" <[email-masked]<mailto:[email-masked]>> wrote:

2012/2/16 Lee, Yiu <[email-masked]<mailto:[email-masked]>>
Hi Maoke,

There are always trade-offs. We can suggest few options and ask the WG to choose one.

2) may be easier.

/Yiu

From: Maoke <[email-masked]<mailto:[email-masked]>>
Date: Thu, 16 Feb 2012 11:50:33 +0900
To: "Yiu L. LEE" <[email-masked]<mailto:[email-masked]>>
Cc: Qiong <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

the "since we believe" is true in the term that client/server model is dominating the Internet usage. but the situation is changing, AFTR might suffer a heavy burden with reassembly in the environment where p2p is dominating. can we (actually you authors) surely state lightweight 4over6 improves this? if we can, it is a happy point. ;-)