headers
Bob Briscoe | 1 Aug 2007 02:10
Picon

Re: feedback on draft-briscoe-tsvwg-ecn-tunnel-00

Sally,

I was taking a couple of weeks off when you sent this, so only now am I 
catching up with the backlog...

At 22:30 19/07/2007, Sally Floyd wrote:
>Bob -
>
>Here is some feedback on Layered Encapsulation of Congestion Notification,
>draft-briscoe-tsvwg-ecn-tunnel-00.
>
>As I have said earlier, it is fine by me to update RFC 3168 to say
>that a tunnel ingress should copy the ECN field from the inner
>header to the outer header.  So this feedback is about smaller bits
>and pieces.  (SHOULD vs. MUST, for example...)
>
>- Sally
>
>
>Feedback on draft-briscoe-tsvwg-ecn-tunnel-00:
>
>Section 3.1:
>"ECN at the IP layer is designed to carry information about congestion
>from a congested resource to some downstream node that will feed the
>information back somehow to the point upstream of the congestion that
>can regulate the load on the congested resource."
>
>Actually, that is not true.  RFC 3168 has two parts, specifying
>ECN in both IP and in TCP, but ECN in the IP layer wasn't designed
>only for unicast transport protocols.  E.g., at the time multicast
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bob Briscoe | 1 Aug 2007 02:50
Picon

RE: ECN with Tunnels - to copy or change the ECN in the outerheader

Gorry,

At 03:42 30/07/2007, Black_David <at> emc.com wrote:
>Gorry,
>
>>[GF]: I have a query about the draft on ECN use with Tunnels, relating to 
>>the ECN codepoint copying that I raised in the TSV meeting yesterday.
>>
>>As I understand, the adjustment to IPsec related only to copying the 2 
>>ECN bits (plus DS codepoints) from the outer to the inner on ingress and 
>>back again at egress. I agree we SHOULD also do a similar recommendation 
>>for Tunnels in general, and I'd like to see this STD-Track for use in the 
>>General Internet.
>
>[DB]: IPsec (RFC 4301) does something slightly different on egress - it only
>copies a CE codepoint from outer to inner.

[BB]: I deliberately kept the behaviour at the egress unchanged from 
RFC3168 ECN and RFC4301 IPsec (except I added some "MAY warn" statements 
for illegal transitions).

>>[GF]: However, I am concerned that this draft does not only address these 
>>problems (which could be a PS), but it also adds new concepts as well.
>>
>>In the ECN architecture, my understanding is that HOSTs choose to set the 
>>ECN field to ECT(0) and ECT(1), depending upon the policy at the sender.

[BB]: FYI,  somewhere around the time the ECN spec was in the last stages 
of becoming RFC3168 in early 2001, I discussed with Sally the possibility 
of in-path nodes ('proxies') setting ECT (I think it was off-list, but I
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bob Briscoe | 1 Aug 2007 04:02
Picon

Re: Initial I-D: draft-briscoe-tsvwg-byte-pkt-mark-00

Sally,

Again, catching up on my backlog - apologies for delayed reply...

At 00:30 20/07/2007, Sally Floyd wrote:
>Bob -
>
>Some feedback on "Byte and Packet Congestion Notification",
>draft-briscoe-tsvwg-byte-pkt-mark-00:
>
>It seems odd to me to talk about RED in byte vs. packet mode, and
>not to talk about the similar performance difference between
>Drop-Tail queues in bytes vs. packets.  (Well, someone could
>care about RED and not Drop-Tail because one cared only
>about packet marks in an ECN environment, but for this document
>it strikes me as quite odd to talk about RED in byte vs. packet mode,
>and not to talk also about Drop-Tail queues in bytes vs. packets.)
>
>I am enclosing some text from some 2/26/2007 email that I sent you
>about this, in response to "draft-briscoe-tsvwg-byte-pkt-mark-00c".
>(I didn't reread the new draft, but I did look at the diffs between
>draft-briscoe-tsvwg-byte-pkt-mark-00 and
>draft-briscoe-tsvwg-byte-pkt-mark-00c, and I didn't notice anything
>added about Drop-Tail queues in bytes vs. packets.)

After I had posted the draft, I realised I still hadn't taken this point 
you made into account. Sorry about that - it will be in the -01 update.

I tried to make up for this at least in my presentation in Chicago, where I 
warned people not to turn off RED altogether (actually, I hadn't read this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Briscoe | 1 Aug 2007 05:09
Picon

Re: Re: terminology issues in draft-floyd-tsvwg-besteffort - flat monthly pricing

Dimitri,

At 09:46 31/07/2007, dimitri papadimitriou wrote:
>bob,
>
>see in-line
>
>>>you wrote:
>>>
>>>"so there won't be sufficient incentives for anyone to invest in more 
>>>capacity for those of us who want to use the Internet responsibly."
>>>
>>>this might be indeed a concern
>>>
>>>but as shorter life socialist ;-) i do also strongly believe that before 
>>>discussing the solution space we should first within the IETF community 
>>>at large come with a good, clear, and common understanding whether this 
>>>is a concern or not, if this is the case how important & urgent it might 
>>>be, have better understanding about of some of the root causes, etc.
>>I've been working in non-IETF fora where that issue has been debated for 
>>some years. That would be difficult for the IETF to do. It's difficult 
>>for economists to come to any conclusion on that issue. Partly because it 
>>gets convolved with monopoly issues in access networks.
>
>since you are trying to address a non technical problem with a technical 
>solution, there is a need for:
>- determining whether this is a concern that the ietf is willing to
>   address
>- understanding root causes and effects and how penalizing they are
>- the impact of the various mechanisms that could be put in place to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francois Le Faucheur IMAP | 1 Aug 2007 12:01
Picon
Favicon

draft-ietf-tsvwg-rsvp-proxy-proto-approaches

Hi Ken,

>
>>
>> 5) Finally, this may be a nit, but it might be helpful to add a  
>> Considerations section at the end of the document that mentions  
>> the possible scenario of proxy reservations being established and  
>> yet the end-host destination being unreachable/non-existent?   
>> Proxy RSVP routers will know if the downstream leaf router is  
>> reachable, but they won't necessarily know if the last hop to the  
>> end host is reachable.  And since the proxy segment may be part of  
>> an asymmetric path, one can't rely on upstream data to give a hint  
>> to the proxy receiver that the destination is up.
>>
>> I don't think this is major liability, but just something that  
>> needs to be mentioned to those that choose to deploy this work.
>
> I would say this consideration is not specific to the particular  
> type of RSVP Proxy discussed in this document, but actually  
> applicable to most RSVP Proxy scenario/approaches. So I would  
> suggest we bring this point in the rsvp-proxy-approaches document.
>
> As you say, generally in practice I don't expect this is to be a  
> major concern since application level-signaling would take place  
> with the sender/receiver before RSVP reservations are established,  
> so that if either is unreachable, application signaling will be  
> affected first. But it is conceivable that receiver is reachable  
> from application server and not reachable from sender. So we may as  
> well bring up that point (in proxy-approaches).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Magnus Westerlund | 1 Aug 2007 16:14
Picon
Favicon

Re: [Tsvwg] Draft Liaision response to SG13 on Emergency Telecommunications

Janet P Gunn skrev:
> 
> Magnus,
> 
> You might want to add-
> 
> draft-polk-tsvwg-signaled-domain-id-00.txt

Well, I want to be somewhat restricted in adding individual work into 
the liaison. Also to me it is not clear how this is applicable in the 
emergency context.

> and
> draft-polk-ecrit-local-emergency-rph-namespace-01.txt
> 

Well, I got another comment about ECRIT WG document which we hadn't 
considered. I will contact the WG chairs and see what they say.

> 
> And maybe
> draft-carlberg-trip-attribute-rp-02

Well, this is in IETF last call currently. So I will put it on my list 
of documents to consider and try to learn more about it.

> 
> My spelling checker says "Liaision" should be "Liaison", but it may be a 
> US centric dictionary.
(Continue reading)

Permalink | Reply | 0 comments |
headers
li suozhu | 1 Aug 2007 16:41
Picon
Favicon

a query related to multi-homed feature about sctp using vrf

Hi All, 

I have a query  related to multi-homed feature about sctp when using vrf.

There are two endpoints ,endpoint-1 and endpoint-2,Endpoint-1 has 2 
interfaces with same IP address but differents vrf( IP1-vrf 1, IP1-vrf2) 
,while endpoint-2 has 2 interfaces with IP2-vrf 1 and IP3-vrf 2 seprately.
In this case ,I want to know what the IPv4 Address Parameter will be ,in 
INIT (endpoint-1 is client)or INIT ACK(endpoint-1 is server) chunk ,Only 
one IPv4 Address or Two same IPv4 Address? and how can a sctp endpoint know 
vrf about a IP address ?

Could someone explain right solution?

Best regards,

Li

-----------------------------------------------------------------------

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn/
Permalink | Reply | 0 comments |
headers
Brian F. G. Bidulock | 1 Aug 2007 17:15
Favicon

Re: a query related to multi-homed feature about sctp using vrf

li,

What's a vrf?

--brian

li suozhu wrote:                                   (Wed, 01 Aug 2007 22:41:01)
> Hi All, 
> 
> I have a query  related to multi-homed feature about sctp when using vrf.
> 
> There are two endpoints ,endpoint-1 and endpoint-2,Endpoint-1 has 2 
> interfaces with same IP address but differents vrf( IP1-vrf 1, IP1-vrf2) 
> ,while endpoint-2 has 2 interfaces with IP2-vrf 1 and IP3-vrf 2 seprately.
> In this case ,I want to know what the IPv4 Address Parameter will be ,in 
> INIT (endpoint-1 is client)or INIT ACK(endpoint-1 is server) chunk ,Only 
> one IPv4 Address or Two same IPv4 Address? and how can a sctp endpoint know 
> vrf about a IP address ?
> 
> Could someone explain right solution?
>  
> Best regards,
> 
> Li

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Janet P Gunn | 1 Aug 2007 18:18
Favicon

Re: [Tsvwg] Draft Liaision response to SG13 on Emergency Telecommunications





Magnus Westerlund <magnus.westerlund <at> ericsson.com> wrote on 08/01/2007 10:14:50 AM:

> Janet P Gunn skrev:
> >
> > Magnus,
> >
> > You might want to add-
> >
> > draft-polk-tsvwg-signaled-domain-id-00.txt
>
> Well, I want to be somewhat restricted in adding individual work into
> the liaison. Also to me it is not clear how this is applicable in the
> emergency context.

Well, you included draft-polk-sip-rph-new-namespaces-01, and draft-polk-tsvwg-signaled-domain-id-00 addresses the same scenarios.  It would make sense to include either both or neither.
>
> > and
> > draft-polk-ecrit-local-emergency-rph-namespace-01.txt
> >
>
> Well, I got another comment about ECRIT WG document which we hadn't
> considered. I will contact the WG chairs and see what they say.

Yes, ecrit should make the call. But I know at least one other stds body (PacketCable PKT2 0-SP-RSTF-D01-060330 TCHG) is addressing it.

Janet

>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
> ----------------------------------------------------------------------
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |
headers
ronnie | 1 Aug 2007 18:31

RE: a query related to multi-homed feature about sctp using vrf

If there is only one IP address at an endpoint that endpoint is single homed as far as SCTP is concerned.  Only
one IP address (if any) would be listed in it's INIT or INIT ACK chunks.  SCTP knows nothing about interfaces.

Ronnie

---
Ronnie Sellar			Emerson Network Power, Embedded Computing
Tel: +44 131 475 7015		Suite 4, 2 Anderson Place
Fax: +44 131 475 7001		Edinburgh EH6 5NP
mailto:ronnie <at> artesyncp.com	http://www.emersonembeddedcomputing.com

> -----Original Message-----
> From: li suozhu [mailto:li.suozhu <at> hotmail.com] 
> Sent: 01 August 2007 15:41
> To: tsvwg <at> ietf.org; sigtran <at> ietf.org
> Subject: [Tsvwg] a query related to multi-homed feature about 
> sctp using vrf
> 
> Hi All, 
> 
> I have a query  related to multi-homed feature about sctp 
> when using vrf.
> 
> There are two endpoints ,endpoint-1 and endpoint-2,Endpoint-1 
> has 2 interfaces with same IP address but differents vrf( 
> IP1-vrf 1, IP1-vrf2) ,while endpoint-2 has 2 interfaces with 
> IP2-vrf 1 and IP3-vrf 2 seprately.
> In this case ,I want to know what the IPv4 Address Parameter 
> will be ,in INIT (endpoint-1 is client)or INIT ACK(endpoint-1 
> is server) chunk ,Only one IPv4 Address or Two same IPv4 
> Address? and how can a sctp endpoint know vrf about a IP address ?
> 
> Could someone explain right solution?
>  
> Best regards,
> 
> Li
> 
> --------------------------------------------------------------
> ---------
> 
> _________________________________________________________________
> 免费下载 MSN Explorer:   http://explorer.msn.com/lccn/  
> 
> 
> 
>
Permalink | Reply | 0 comments |

Gmane