Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt

[<[e-mail]>]

The host should send A and AAAA in parallel, hence one would assume in usual case replies should arrive roughly at the same time. This 300ms is for difference on reply arrival times and hence should not depend much on access network latency. If the host sends queries in series, then it would be different thing. I was also considering reference to Happy Eyeballs draft: draft-ietf-v6ops-happy-eyeballs-07 , but thought maybe not..

If it is hard to agree on specific time, we could just say instead:"If no reply for A query is received after ENR implementation specific timeout, after reception of positive AAAA response, the ENR MAY choose to proceed as if there were only AAAA record available for the destination."

Best regards,

Teemu

________________________________
From: ext Cameron Byrne [[e-mail]]
Sent: Friday, December 23, 2011 2:06 PM
To: Savolainen Teemu (Nokia-NRC/Tampere)
Cc: [e-mail]
Subject: Re: [BEHAVE] Changes on draft-ietf-behave-v4v6-bih-08.txt


On Dec 23, 2011 2:31 AM, <[e-mail]<mailto:[e-mail]>> wrote:
>
> Behave WG,
>
> A new revision of BIH was made to respond to comments given by IESG. In addition to some clarifications best seen in diff (http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-v4v6-bih-08), the main changes were:
> - Introduction of 1.1 Terminology section
> - Significantly revising section 8.  Changes since RFC2767 and RFC3338
>
> Then there was question from Pete Resnick: "MUST the ENR wait for an explicit negative
> response on the A record lookup, or can it synthesize from the AAAA in other
> circumstances? Probably best to explicitly say so." For this following text was added:
> --
> If no reply for A query is received after 300 ms since reception of positive AAAA response, the ENR MAY choose to proceed as if there were only AAAA record available for the destination.
> --
>

Do you have any data to support 300ms?  My concern is the highly latent wireless networks will not work best with 300 ms.

Cb

> Any comments?
>
> Best regards,
>
>        Teemu
>
> -----Original Message-----
> From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of ext [e-mail]<mailto:[e-mail]>
> Sent: 23. joulukuuta 2011 09:24
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-08.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.
>
>        Title           : Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
>        Author(s)       : Bill Huang
>                          Hui Deng
>                          Teemu Savolainen
>        Filename        : draft-ietf-behave-v4v6-bih-08.txt
>        Pages           : 29
>        Date            : 2011-12-22
>
>   Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol
>   translation mechanism that allows a class of IPv4-only applications
>   that work through NATs to communicate with IPv6-only peers.  The host
>   on which applications are running may be connected to IPv6-only or
>   dual-stack access networks.  BIH hides IPv6 and makes the IPv4-only
>   applications think they are talking with IPv4 peers by local
>   synthesis of IPv4 addresses.  This document obsoletes RFC 2767 and
>   RFC 3338.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-08.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-08.txt
>
> _______________________________________________
> Behave mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/behave